2024 DevOps Lifecycle: Share your expertise on CI/CD, deployment metrics, tech debt, and more for our Feb. Trend Report (+ enter a raffle!).
Kubernetes in the Enterprise: Join our Virtual Roundtable as we dive into Kubernetes over the past year, core usages, and emerging trends.
Stats
Reputation: | 226 |
Pageviews: | 48.7K |
Articles: | 2 |
Comments: | 6 |
Articles
Trend Reports
Data Persistence
At the core of every modern application is an endless, diverse stream of data and with it, an inherent demand for scalability, increased speed, higher performance, and strengthened security. Although data management tools and strategies have matured rapidly in recent years, the complexity of architectural and implementation choices has intensified as well, creating unique challenges — and opportunities — for those who are designing data-intensive applications.DZone’s 2021 Data Persistence Trend Report examines the current state of the industry, with a specific focus on effective tools and strategies for data storage and persistence. Featured in this report are observations and analyses of survey results from our research, as well as an interview with industry leader Jenny Tsai-Smith. Readers will also find contributor insights written by DZone community members, who cover topics ranging from microservice polyglot persistence scenarios to data storage solutions and the Materialized Path pattern. Read on to learn more!
Comments
Jul 06, 2023 · Marcy Tillman
Thank you for this article. In general, I think that the big challenges in breaking a monolith are not only technical but mainly organizational. What do you think?
Oct 14, 2022 · Claudio Guidi
Hi Danny, thank you for this reply. I think that the topic is very important to be addressed because, as you said, it allows for reducing the complexity of a microservice architecture. I just have a look to your platform and it seems very nice. With Jolie we decided to follow another approach that is the linguistic one, that allows for programming following a new paradigm. Thanks to this, in Jolie embedding is trivial. On the other hand a new progtramming language is more difficult to be adopted, in particular when it changes the usual practices. Nevrethless, I think that we need a new generation of programming languages just because the traditional programming paradigms are no more sufficient to grasp the complexity of distributed applications.
Aug 30, 2022 · Marcy Tillman
I think that data services have been introduced in order to decouple business services to the raw data of the persistence level. It is true that data services provide CRUD operations that could appear not useful because, as you said, you could just use the data from the persistence level, but at the same time they provide a first abstraction of the raw data just offering to consumers only the relevant information and not everything. Moreover the consumers are not bound to any specific technology of the persistence layer, but they are just coupled with a service based technology (e.g. REST) In this way, you are more independent from the technology used in the persistence layer.
I think that the weak point of data services, is that it is very difficult to design operations that work well with all the possible consumers, so you need to manage them frequently.
Data gateways seem to offer a solution to this point but my doubt is that it just move the problem from a technology stack to another (so in this case I get your point when you said "Your suggestion is to double down on an already bad idea and
gather/aggregate data through additional infrastructure").
Anyway, interesting article for me.
Many thanks to Jeffrey.
Mar 08, 2021 · Melissa Habit
Hi D L, and thank you for your feedback. In the following my answers:
a) Generally speaking there could be scenarios where there are more microservices on the same dataset. As an example you could need to separate API into different microservices for business reasons. In the article I provided the example of huge product catalogue which contains a lot of different products. Let us suppose to be in a B2B scenario where we have a customer that asks to have a special set of refined APIs just for a subset of this catalogue, and you want to manage them separately. In that case you could have another microservice that uses the same dataset. Another example could be the case where you want to differentiate writing APIs from reading APIs.
b) The microservice data layer offers an abstraction of the underlying data layer, in order to abstract away from the technicalities of the specific technology. It is not mandatory, in the sense that it is not the "right way" and, dually, it is not the "bad way". It is just a normalized reference for dealing with different scenarios, then it is up to the architect/developer to choose the solution that best fits its needs. In any case, there is not any relationship between the team that manages the microservice data layer and the teams that manage the microservices at the functional layer. They are separate microservices. The microservice at the microservice data layer is just a dependency of those at the functional layer. This is a general approach that enables the reuse of the microservice data layer. If reuse is not necessary, the microservice data layer is not necessary but both functional and data layers can be compressed into one single microservice.
Dec 07, 2020 · Claudio Guidi
Thank you Robert for this debate. Microservices are not a well established discipline, thus it is important to have a constructive dialog about them.
There are three main elements in your answer I would like to respond to:
Scalability: from my point of view, scalability is just a property of an application/component that must be decided at design time. It is quite difficult to have scalability if you did not design properly your component. This fact it is independent from the technology you adopt. The usage of REST does not prevent to develop not-scalable services.
REST services: for me REST is just a way for modelling the API of a service. There is a restricted set of verbs (just the minimal set for achieving crud operations) and all the API must be designed for modelling the access of a resource. It is independent from the technology you use for designing and developing the service. Btw, in Jolie you can program also REST services.
About coordination with REST you said: "The client receives options to choose from and it *navigates* these options to reach its goal". That is fine with me. It is a possibility you have for coordinating services. In this case, you are shifting some of the coordination logics to the client side, but if this is feasible in the target scenario, it might be a good choice. I think the best thing is to have different possibilities and choose the one that is best suited to the problem we have. With Jolie we just want to simplify the development of services by reducing the technology stack and facilitating the development of distributed architectures.
Thanks again for this interesting debate.
Dec 04, 2020 · Claudio Guidi
Hi Robert, thank you very much for your feedback. Here in the following some answers to the points you highlighted:
- Microservices are not about coordination, web services are instead. This is an opinion that comes from the fact that mainstream usually talks about microservices and web services in this way. Jolie has been built on top of a theoretical model about SOA, in particular from WS-BPEL (that is a Web Service technology). In Jolie you can build an orchestrator like you can do in WS-BPEL. But in Jolie you can deploy that orchestrator independently, as you do with a microservice. Thus, in Jolie you are able to achieve orchestration and coordination with microservices. Moreover, you can program microservices as you do with other technologies. So I disagree with your assumption "Microservices are not about coordination" and I would like to change it appending "...so far". This is one of the main reasons that allow me to say that Jolie can change the way we are approaching microservices.
- A new language, if it is coherent, allows to change the designing of a solution because it changes how we think and solve a problem. In particular, in Jolie the basic building block is a service, thus everything you can create with jolie is a service or a composition of services that is a service again. There are no objects or functions, the developer directly thinks in services by skipping all the unnecessary steps to get a service abstraction starting from another linguistic paradigm (like the object oriented one). In my opinion, this is a clear advantage because it allows to cut all the technical layers you need, to achieve the abstraction of a service.
- EJB is not a good comparison, because EJB have been built on top of Java that is an object oriented language. EJB is a superstructure which increase the level of complexity of a project. On the contrary, a new programming language simply offers a new clean syntax for directly dealing with service-oriented programming. We have experiences in which developers without any expertise in service architectures and programming, after a few days of training on Jolie, have been able to program distributed service applications. If you are looking for a good comparison, another language that is going in the same direction of Jolie, is Ballerina.