Traceability Microservices: A Retrospective on Distributed Enterprise Applications
In the cloud era, microservices have become the de facto standard for enterprise-class applications. However, the technology itself is not revolutionary, but rather a refinement of existing concepts. Distributed communication frameworks, cross-platform independent service registration and discovery, intelligent routing, and scheduling technologies have been around for decades, dating back to CORBA and SOA eras.
A Lesson Learned
In this article, we reflect on the distributed enterprise applications landscape and compare it to the previous microservices era. We examine the areas where we made progress and where we continued to struggle. The key takeaway is that the abstract boundary between services is a critical aspect of microservices architecture.
Abstract Configuration and the Operating System
The operating system takes over from the CPU scheduling, memory address space allocation, and I/O, liberating the programmer’s mind to focus on business logic. However, this often leads to a bad abstract abyss, where energy is wasted on the disclosure of abstract concepts. In distributed systems, we focus on communication and engineering practices between components, achieving a better balance between technical constraints and business value.
From RPC to API
Initially, we thought that communication between components was just a technical issue that needed to be addressed. However, as we delved deeper, we realized that it was not just about RPC, but about API design. We started to use REST, which provided a more lightweight and agile approach to building APIs. The benefits of REST include caching, scalability, and separation of concerns.
From Technical Components to Business Services
As we moved from technical components to business services, we realized that the focus should be on business capabilities rather than just technical implementation. We started to use domain-driven design to define service boundaries and achieve a better balance between technical constraints and business value.
Decoupling Services
Decoupling services is not enough; we need to focus on the center of everything. Even with well-designed APIs, we still need a matching engineering practice to successfully implement them. This includes using container technology, such as Docker, to deploy services independently.
Centralized Database
Coupled databases are another critical factor affecting independent service changes. We should take into account data consistency and use a decentralized approach to data governance. Even if we decouple services, if we hand them over to a centralized team to implement, we are likely to end up with a coupled architecture.
Conway’s Law
Conway’s Law tells us that the system architecture design is influenced by the communication structure of the organization. However, we can reverse this law by adjusting the team structure to align with the target architecture. This is a must for microservices.
Monitoring and Operation
Microservices bring bigger challenges to run-time monitoring and operation and maintenance. We need to adopt a DevOps culture, where product teams are responsible for the entire life cycle of the microservices. Authorized decentralized autonomous teams are a necessary condition for the implementation of microservices.
Lingering Anti-Patterns
Despite the progress we made, many problems are still happening in reincarnation. We need to learn from history and avoid the old anti-patterns. Examples of lingering anti-patterns include strongly typed RPC code generation, ESB, and overambitious API gateways.
Service Mesh, Chaos Engineering, and Observability as Code
We can track the state of microservices technology and see the direction of the forefront of this area, including Service Mesh, Chaos Engineering, and Observability as Code. However, history tells us that new technologies may also create new problems.
Principles Stay Forever
The principles of architecture and those behind the practice are enduring. From operating systems to mobile applications, we require high cohesion and low coupling within the framework of any software development. We should remember these core principles and focus on creating software that solves the problem of value.
Conclusion
In conclusion, microservices have become the de facto standard for enterprise-class applications. However, we need to focus on the center of everything and avoid the old anti-patterns. We should adopt a DevOps culture and use container technology to deploy services independently. By doing so, we can create software that solves the problem of value and achieves a better balance between technical constraints and business value.