The Microservice Architecture is foggy. No matter what you do, it always seems wrong, and you may hit the wall accidentally behind the fog. With a little knowledge, some people choose to introduce container platforms (such as Kubernetes) to take a step by step; some people choose to wait and see before figuring out what are the first needs to be “advanced deployment.” It doesn’t matter how you play the game and how many steps you take, you will never see through the fog, and have no way to find the end of the game.
In particular, customers who have already invested in infrastructure are more frightened than anyone else. When they come to us, they all hope that we can feasibly guide them. Even if pointed out, it is still a difficult path, but it is more reassuring to customers than groping in the dark.
From our partners:
This article sorts out various key technical and neglected issues in the entire microservice architecture. Helping companies and organizations understand the challenges facing by introducing microservice architecture.
What have most companies done?
Many enterprises already have the foundation for implementing microservice architecture in infrastructure (for example, Kubernetes, CI/CD, etc.). Leaving aside issues such as development norms and organizational policy reforms are probably no problems at deployment and maintenance. The next issues are application development, service transformation, and implementation of the architecture.
Firstly is to choose a lightweight application framework to meet the scattered needs of microservice deployment in application development. Under such considerations, there are different choices according to language enterprises initially used. For example, enterprises accustomed to Java usually choose Spring Boot.
On the other hand, in the view of architecture design, the service splitting of microservice thinking is an obvious problem to be solved. Therefore, many companies have begun to use Domain-Driven Design (DDD) as the only means to sort out existing businesses and split existing services.
From all aspects, it seems that everything is complete.
What did you miss?
At first glance, in terms of technology selection, most companies that want to invest in microservices architecture seem to have both application frameworks and domain-driven design methods. In theory, they should go smoothly on the road to microservices. However, the market continues to hear voices of companies failing to introduce or eventually can’t go until the end.
There are still many things missing between the “application framework” and “service logic split,” as shown in the above figure’s red block. However, the missing part is the most complicated and trapped area in the design and implementation of microservice architecture.
The various designs under the decentralized architecture are not the same as the past thinking to be cognizant. We could achieve the functions in a single database, and the same memory in the past will be moved out to different machines and nodes, and then collaborate across networks. For many developers, this is a new field, a new design model, and old experience is even useless.
According to experience, it is easy to find out the result is just a bunch of distributed monoliths at the microservice architecture, without the slightest benefit of microservice. It even attracted many challenging problems and fell into a trap that was difficult to turn over.
After ignoring various issues, it is almost impossible to construct the microservice architecture correctly.
Data decoupling is the starting point in the fog.
Despite the introduction of many design patterns or domain-driven design (DDD) to decouple services, most of the focus is still on the splitting of application logic. Most people usually choose to ignore or give up the data decoupling work at the data layer, especially if the knowledge of related technologies is lacking. That is why many people find consultants to introduce DDD, and once they enter the technical implementation, they find out it is not effective or not be able to implement.
You should know that data is the most weighty part of the application. Only the decoupling of data can truly achieve the service splitting of the microservice architecture. We will never implement the microservice architecture correctly if we adapt the data, make the wrong aggregation at the work of DDD or service splitting, and eventually lead to failure.
As for data decoupling, is it necessary to do high-risk demolition of tables and databases? No need. Suppose you are interested in understanding the purpose of data decoupling and data management methods after decoupling. In that case, you can refer to our other article: The Magic Trick of CQRS: Microservice Data Decoupling.
Note:
Some DDD books often mention technical design patterns such as CQRS to assist the data exchange or aggregation of domain boundaries in DDD. However, many people only treat DDD as a purely theoretical method and ignore the technical issues mentioned in these books, resulting in a mere formality and lack of effective treatment.
Data consistency is the core of everything.
The microservice architecture is the design of a decentralized system, which means that service status and data are not centralized. In addition to the state consistency problem between services, we must also consider data synchronization and sharing issues. However, in the face of different applications, the requirements for data consistency are also different. Some applications require absolute consistency, some can accept strong consistency, and some scenarios only need to achieve final consistency.
The solutions are also quite diverse when facing different data consistency requirements. The major topics distribute into data management, state and object lifecycle management, distributed transaction, and stateful service.
Only by adequately designing these management mechanisms or by proper integration can it be possible to implement a microservice architecture under different applications. As long as too much emphasis is placed on specific design patterns, or the wrong method is adopted in an inappropriate situation, it will cause many sequelae and even failure.
Note:
The wrong design may result in decoupled databases, monolithic architectures that are difficult to scale, and even face performance impact and maintainability issues.
Figure out how to meet low-latency needs
Theoretically, the problem that cannot be solved by the decentralized architecture is latency. Due to the program logic and decentralization of data, most tasks require communication, synchronization, and state exchange across services. Meaning that latency will always occur, but only the acceptance delay degree of the target application and whether it is acceptable.
Although the current computer and network performance and speed are speedy, these delays are not apparent to users and are acceptable for most applications. But if your application cannot accept these delays and needs more extreme immediate needs, you have to rely on stateful service design.
However, the stateful service is not right in scalability and fault tolerance, and it can easily become a performance bottleneck and a beach instability. The accompanying single point of failure and decentralized monolithic architecture problems are all traps. Therefore, how to decouple and optimize stateful services and minimize their operational risks is the key. At this time, knowing how to design the state management and event scheduling mechanism to achieve the requirements of low latency with scalability and high throughput becomes something that needs to be clarified.
Painful developers are not superhuman
Many developers originally expected the Application Framework to have a comprehensive solution. However, the reality is that there is still a long way to go, and it needs to be solved by the developer. There is not yet an ultimate and complete solution.
Besides, although some open source projects can partially solve or cover some issues, as different development backgrounds of these projects, their starting points, and focus are different. Many may not meet the needs of various enterprises, or even still require customization and self-maintenance. It again depends on the experience and capabilities of developers to realize the microservice mechanism necessary.
However, each of the various issues should not be underestimated. The application developers of general enterprises have to spend a lot of energy and human resources to invest in any one point, and they may not have time to take care of application development. In particular, the stability and scalability of these mechanisms are the keys to the microservice architecture’s smooth operation. If it is not well designed and maintained, the final result is predictable.
We have not yet mentioned how risky it is for developers who are new to microservice architecture to complete these critical mechanisms with little knowledge. It is also extremely painful for developers who initially focus on application logic.
How to solve these issues and avoid traps?
Since the data consistency issue is the core of microservices, the mechanism to support the consistency of various types of data is the top priority for us to solve, so it is the best place to start. Then, after solving most of the data issues, the technical problems of service splitting will be further expanded.
Within this introduction approach, the introduction of CQRS, decentralized transaction mechanism, object status, life cycle management mechanism, and event scheduling mechanism is a critical part of technology implementation. Then you don’t have to worry too much about event-driven communication mechanism issues. They can be achieved through proper education training or traditional solutions.
The final strong recommendation
If you still feel unfamiliar with the topics and design patterns mentioned in this article, or you haven’t even heard them. It is recommended that you stop before encountering the larger issues and continue your microservice journey only after understanding the meaning and solutions behind these issues.
—
This article’s materials and sources are all from Brobridge‘s microservice architecture design education and training courses. If you want to know more about microservice architecture design issues, or interested in specific microservice components, please feel free to contact us.
For enquiries, product placements, sponsorships, and collaborations, connect with us at [email protected]. We'd love to hear from you!
Our humans need coffee too! Your support is highly appreciated, thank you!
