adam121 - Fotolia
3 lessons microservices developers can learn from SOA
Microservices developers can learn from past SOA mistakes to build more resilient and high-performance applications today. Take a look at three major lessons for microservices projects.
As new application development styles and technology arrive on the enterprise scene, developers must not only adapt, but also build upon the practices of yesterday. This is especially true as organizations move from monolithic to distributed microservices architectures.
The microservices architecture, in many ways, represents the next generation of service-oriented architecture (SOA). However, microservices practitioners had to address many of the inherent weaknesses of SOA that became a hindrance to development processes. As organizations shift toward microservices, they must learn key lessons from SOA to avoid falling into the same development pitfalls with a new name.
The three lessons SOA teaches microservices adopters include:
- Manage service size;
- Avoid single points of failure; and
- Build the team to match the architecture.
1. The importance of service size
The goal of SOA was to divide monolithic applications into collections of services. However, as developers began to create separated services, they learned quickly that the size of services profoundly affected the outcome of their efforts.
In the early days of SOA, developers created large, coarsely grained services that had overlapping -- and sometimes conflicting -- resource and management requirements. These services often shared a common database and were tightly coupled with neighboring services. This sizing was done to simplify management, but it became difficult to know where the boundary and context for one service ended and the next service began. Without clear breaks between services, what exactly does each developer work on? How can they predict how a change will affect a related service?
Microservices development champions small, fine-grained services that perform their duties independent of neighboring services. Each service has its own data storage and its own communication protocols. This architectural pattern aims to share as little as possible across services and enforces a bounded context for every service. Isolation gives teams more independence in how they manage the services they own and maintain. Furthermore, it reduces the risk of one service creating cascading failures if it goes down.
However, a word of caution from SOA design principles: Avoid creating huge numbers of extremely fine-grained services. Doing so only adds to management complexity and makes it too difficult to track services. While the intent with a microservices approach is to go more granular with services than SOA, it's still critical to find the right balance between the rigidity of oversized services and the complexity of undersized ones.
2. Eliminate the single point of failure
The centerpiece of SOA was the enterprise service bus (ESB), which coordinated all communication between services. However, this ESB could easily become its downfall -- a single point of failure that would impact all communication to services in the event of an overload or crash. For instance, if one service experienced an abnormal spike of traffic and requests, the ESB risked becoming overloaded with messages, backing up the flow of communication and creating errors for other services. In addition, the ESB was often designed only to handle specific protocols and languages.
SOA's flaw with the ESB made organizations realize the importance of fault tolerance in an application design. A microservices architecture replaces the ESB with an API-based messaging system that allows services to facilitate communication through APIs rather than depending on a centralized ESB. APIs support services irrespective of the programming language they're built with. They are also more efficient at message delivery, leaving out ESB middleware. API-based communication significantly improves fault tolerance, since it allows developers to isolate failures in the event of a problem.
3. Organize teams around services
While SOA aimed to break up applications into services, legacy development team practices still dictated separate teams formed around IT functionality, such as infrastructure, database management, middleware and UI. The practice created silos within the organization, and any small change to one part of a system required collaboration and sign-off from multiple teams. The mismatch between architecture and way of working greatly slowed down the pace of development.
Microservices practitioners realize the value of organizing teams around individual services or types of services. Since each service can be managed independently, its team is also independent and won't require sign-off for every change it implements. This healthy autonomy not only quickens the pace of development, it also encourages developers to embrace the single-responsibility principle, where a team takes complete ownership and concern for its assigned work product.
