This post is part of a series of posts with my personal notes about the chapters in the book “Microservices vs. Service-Oriented Architecture” by Mark Richards.
In this chapter I compare microservices and SOA by focusing on how the services are classified within each pattern (i.e., service taxonomy), how services are coordinated based on the service owner, and finally the difference in service granularity between microservices and SOA
The term service taxonomy refers to how services are classified within an architecture.
Microservices architectures have a limited service taxonomy when it comes to service type classification, mostly consisting of only two service types as illustrated in below Figure. Functional services are services that support specific business operations or functions, whereas infrastructure services support nonfunctional tasks such as authentication, authorization, auditing, logging, and monitoring.
The service taxonomy within SOA varies significantly from microservices taxonomy. The architecture pattern defines four basic types, as illustrated in below Figure
Business services are abstract, high-level, coarse-grained services that define the core business operations that are performed at the enterprise level, typically represented through either XML, Web Services Definition Language(WSDL), or Business Process Execution Language (BPEL). ProcessTrade is a good business service candidate
Enterprise services are concrete, enterprise-level, coarse-grained services that implement the functionality defined by business services. CheckTradeCompliance, CreateCustomer, ValidateOrder, and GetInventory are all good examples of enterprise services. Enterprise services typically rely on application services and infrastructure services to fulfill a particular business request, but in some cases all of the business functionality needed for a particular request may be self-contained within that enterprise service.
Application services are fine-grained, application-specific services that are bound to a specific application context. Some examples of an application service might be AddDriver, AddVehicle, and CalculateAutoQuote.
The final basic type of service found in SOA is infrastructure services. As in microservices architecture, these are services that implement nonfunctional tasks such as auditing, security, and logging.
Service Ownership and Coordination
A service owner is the type of group within the organization that is responsible for creating and maintaining a service.
Because microservices architecture has a limited service taxonomy (functional services and infrastructure services), it is typical for application development teams to own both the infrastructure and functional services
With SOA, there are usually different service owners for each type of service. Business services are typically owned by business users, whereas enterprise services are typically owned by shared services teams or architects. Application services are usually owned by application development teams, and infrastructure services are owned by either application development teams or infrastructure services teams. Although not formally a service, the middle-ware components usually found in SOA are typically owned by integration architects or middle-ware teams.
The significance of the service owner is that of overall service coordination. In SOA, you must coordinate with multiple groups to create or maintain a single business request; business users must be consulted about the abstract business services, shared services teams must be consulted about the enterprise services created to implement the business services, application development teams must be coordinated so that enterprise services can invoke lower-level functionality, and infrastructure teams must be coordinated to ensure nonfunctional requirements are met through the infrastructure services. Finally, all of that needs to be coordinated through the middle-ware teams or integration architects managing the messaging middle-ware.
With microservices, there is little or no coordination among services to fulfill a single business request. If coordination is needed among service owners, it is done quickly and efficiently through small application development teams
One of the bigger differences from a services perspective between microservices and SOA is service granularity. Whether you are using a microservices architecture or SOA, designing services with the right level of granularity is not an easy task.
As the name suggests, microservices are small, fine-grained services. With SOA, service components can range in size anywhere from small application services to very large enterprise services. In fact, it is common to have a service component within SOA represented by a large product or even a subsystem.
Service granularity affects both performance and transaction management. Services that are too fine-grained will require inter service communication to fulfill a single business request, resulting in numerous remote service calls that take up valuable time.
Transaction management is also impacted by service granularity. I am referring here to traditional ACID transactions, not the BASE transactions I discussed in the previous chapter. If your remote services are too fine-grained, you will not be able to coordinate the services using a single transactional unit of work
When dealing with service granularity I usually find it easier to start out with services that are more coarse-grained than that you might otherwise create, and then break them apart as you learn how they are used. As Sam Newman states in his excellent book Building Microservices (O’Reilly), “Start with a small number of larger services frst.” Just watch out for transaction issues and too much inter-service communication, particularly with microservices—these are good indicators that your services might be too fine-grained.
Granularity and Pattern Selection
Microservices allows this architecture pattern to improve all aspects of the software development life-cycle, including development, testing, deployment, and maintenance. Although moving to services that are more coarse-grained certainly resolves performance and transactional issues
If you find that your services range in size from small to large, you will likely need to look toward more of a SOA pattern than the more simple microservices architecture pattern. However,if you are able to break down the business functionality of your application into very small, independent parts, then the microservices pattern is a likely candidate for your architecture.
In chapter 3, we will compare Architecture Characteristics of Microservices and SOA