Chapter 6. Microservices and SOA
At first glance microservices and SOA (service-oriented architecture) seem to have a lot in common, for both approaches focus on the modularization of large systems into services. Are SOA and microservices actually the same or are there differences? Answering this question helps us to get an in-depth understanding of microservices, and some of the concepts from the SOA field are interesting for microservice-based architectures. An SOA approach can be advantageous when migrating to microservices. It separates the functionality of the old applications into services that can then be replaced or supplemented by microservices.
Section 6.1 defines the term “SOA” as well as the term “service” within the context of SOA. Section 6.2 extends this topic by highlighting the differences between SOA and microservices.
6.1 What Is SOA?
SOA and microservices have one thing in common: neither has a clear definition. This section looks only at one possible definition. Some definitions would suggest that SOA and microservices are identical. In the end, both approaches are based on services and the distribution of applications into services.
The term “service” is central to SOA.
An SOA service should have the following characteristics:
• It should implement an individual piece of the domain.
• It should be possible to use it independently.
• It should be available over the network.
• Each service has an interface. Knowledge about the interface is sufficient to use the service.
• The service can be used by different programming languages and platforms.
• To make it easy to use, the service is registered in a directory. To locate and use the service, clients search this directory at run time.
• The service should be coarse grained in order to reduce dependencies. Small services can only implement useful functionality when used in conjunction with other services. Therefore, SOA focuses on larger services.
SOA services do not need to be newly implemented; they may already be present in company applications. Introducing SOA requires these services to be made available outside of those applications. Splitting applications into services means they can be used in different ways. This is supposed to improve the flexibility of the overall IT and is the goal of SOA. By splitting applications into individual services it is possible to reuse services during the implementation of business processes. This simply requires the orchestration of the individual services.
Figure 6.1 shows a possible SOA landscape. Like the previous examples this one comes from the field of e-commerce. There are different systems in the SOA landscape:
• The CRM (customer relationship management) is an application that stores essential information about customers. This information includes not only contact details but also the history of all transactions with the customer—telephone calls as well as emails and orders. The CRM exposes services that, for instance, support the creation of a new customer, provide information about a customer, or generate reports for all customers.
• The order system is responsible for order processing. It can receive new orders, provide information about the status of an order, and cancel an order. This system provides access to the different pieces of functionality via individual services. These services may have been added as additional interfaces to the system after the first version was put into production.
• In the diagram the CRM and order system are the only systems. In reality there would certainly be additional systems that would, for example, provide the product catalog. However, to illustrate an SOA landscape these two systems will suffice.
• For the systems to be able to call each other there is an integration platform. This platform enables communication between the services. It can compose the services through orchestration. The orchestration can be controlled by a technology that models business processes and calls the individual services to execute the different processes.
• Therefore, orchestration is responsible for coordinating the different services. The infrastructure is intelligent and can react appropriately to different messages. It contains the model of the business processes and is therefore an important part of the business logic.
• The SOA system can be used via a portal. The portal is responsible for providing users with an interface for using the services. There can be different portals: one for the customers, one for the support, and one for internal employees, for instance. Also, the system can be called via rich client applications or mobile apps. From an architectural perspective this makes no difference: All such systems access the different services and make them usable for a user. They are effectively a universal UI—able to use all services in the SOA.
Each of these systems could be operated and developed by individual teams. In this example there could be one team for the CRM and another for the order system. Additional teams could be allocated for each portal, and finally one team could take care of integration and orchestration.
Figure 6.2 shows how communication is structured in an SOA architecture. Users typically work with the SOA via the portal. From here business processes can be initiated that are then implemented in the orchestration layer. These processes use the services. When migrating from a monolith to an SOA, users might still use a monolith through its own user interface. However, SOA usually aims to have a portal as the central user interface and an orchestration layer for implementing processes.
Introducing SOA
Introducing SOA into a business is a strategic initiative involving different teams. The end game is to distribute the company’s entire IT into separate services. Once separated, the services are easier to compose in new and different ways to create new functionality and processes. However, this is only possible when all systems in the entire organization have been modified. Only when enough services are available can business processes actually be implemented by simple orchestration. This is when SOA's advantages are really evident. Therefore, the integration and orchestration technology has to be used across the entire IT to enable service communication and integration. This involves high investment costs as the entire IT landscape has to be changed. This is one of the main points of criticism1 of SOA.
1. http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
The services can also be offered to other companies and users via the Internet or over private networks. This makes SOA well suited to support business concepts that are based on the outsourcing of services or the inclusion of external services. In an e-commerce application an external provider could, for instance, offer simple services like address validation or complex services like a credit check.
Services in an SOA
When introducing SOA based on old systems, the SOA services are simply interfaces of large deployment monoliths. One monolith offers several services. The services are built upon the existing applications. Often it is not even necessary to adjust the internals of a system in order to offer the services. Such a service typically does not have a UI; instead, it just offers an interface for other applications. A UI exists for all systems. It is not part of a service, but independent—for instance, in the portal.
In addition, it is possible to implement smaller deployment units in an SOA. The definition of an SOA service does not limit the size of the deployment units, which is quite different from microservices where the size of the deployment units is a defining feature.
Interfaces and Versioning
Service versioning in SOA is a particular challenge. Service changes have to be coordinated with the users of the respective service. Because of this coordination requirement, changes to the interface of the services can be laborious. Service users are unlikely to adjust their own software if they do not benefit from the new interface. Therefore, old interface versions frequently have to be supported as well. This means that numerous interface versions probably have to be supported if a service is used by many clients. This increases software complexity and makes changes more difficult. The correct functioning of the old interfaces has to be ensured with each new software release. If data is added, challenges arise because the old interfaces do not support this new data. This is not a problem during reading. However, when writing, it can be difficult to create new data sets without the additional data.
External Interfaces
If there are external users outside the company using the service, interface changes get even more difficult. In a worst case the provider of the service may not even know who is using it if it is available to anonymous users on the Internet. In that situation it is very difficult to coordinate changes. Consequently, switching off an old service version can be unfeasible. This leads to a growing number of interface versions, and service changes get more and more difficult. This problem can occur with microservices as well (see section 8.6).
The interface users also face challenges: If they need an interface modification, they have to coordinate this with the team offering the service. Then the changes have to be prioritized in relation to all the other changes and wishes of other teams. As discussed previously, an interface change is no easy task. This can lead to it taking a long time before changes are, in fact, implemented. This further hampers the development of the system.
Interfaces Enforce a Coordination of Deployments
After a change to the interface the deployment of the services has to be coordinated. First the service has to be deployed to offer the new version of the interface. Only then can the service that uses the new interface be deployed. Since applications are mostly deployment monoliths in the case of SOA, several services can sometimes only be deployed together. This makes the coordination of services more difficult. In addition, the deployment risk increases as the release of a monolith takes a long time and is hard to undo—just because the changes are so extensive.
Coordination and Orchestration
Coordinating an SOA system via orchestration in the integration layer poses a number of challenges. In a way, a monolith is generated: All business processes are reflected in this orchestration. This monolith is often even worse than the usual monoliths as it is using all the systems within the enterprise IT. In extreme cases it can end up that the services only perform data administration while all the logic is found in the orchestration. In such situations the entire SOA can deteriorate to being nothing other than a monolith that has its entire logic in the orchestration.
However, even in other settings, changes to SOA are not easy. Domains are divided into services in the different systems and into business processes in orchestration. When a change to functionality also concerns services or the user interface, things get difficult. Changing the business processes is relatively simple, but changing the service is only possible by writing code and by deploying a new version of the application providing the service. The necessary code changes and the deployment can be very laborious. Thus, the flexibility of SOA, which was meant to arise from a simple orchestration of services, is lost. Modifications of the user interface cause changes to the portal or to the other user interface systems and also require a new deployment.
Technologies
SOA is an architectural approach and is independent of concrete technology. However, an SOA has to enforce common technology for communication between the services, like microservices do. In addition, a concrete technology needs to be enforced for the orchestration of services. Often, introducing an SOA leads to the introduction of complex technologies to enable the integration and orchestration of services. There are special products that support all aspects of SOA. However, they are typically complex, and their features are rarely ever used to full capacity.
This technology can rapidly turn into a bottleneck. Many problems with these technologies are attributed to SOA although SOA could be implemented with other technologies as well. One of the problems is the complexity of the web services protocols. SOA on its own is quite simple; however, in conjunction with the extensions from the WS-* environment, a complex protocol stack arises. WS-* is necessary for transactions, security, and other extensions. Complex protocols exacerbate the interoperability—however, interoperability is a prerequisite for an SOA.
An action on the user interface has to be processed by the orchestration and the different services. These are distributed calls within the network with associated overhead and latency. Worse still, this communication runs via the central integration and orchestration technology, which therefore has to cope with numerous calls.
6.2 Differences between SOA and Microservices
SOA and microservices are related: both aim at splitting applications into services. It is not easy to distinguish between SOA and microservices by just considering what is happening on the network. Both architectural approaches have services exchanging information over the network.
Communication
Like microservices, SOA can be based on asynchronous communication or synchronous communication. SOAs can be uncoupled by merely sending events such as “new order.” In these situations, every SOA service can react to the event with different logic. One service can write a bill and another can initiate delivery. The services are strongly uncoupled since they only react to events without knowing the trigger for the events. New services can easily be integrated into the system by also reacting to such events.
Orchestration
However, at the integration level the differences between SOA and microservices appear. In SOA the integration solution is also responsible for orchestrating the services. A business process is built up from services. In a microservice-based architecture the integration solution does not possess any intelligence. The microservices are responsible for communicating with other services. SOA attempts to use orchestration to gain additional flexibility for the implementation of business processes. This will only work out when services and user interface are stable and do not have to be modified frequently.
Flexibility
For achieving the necessary flexibility microservices, on the other hand, exploit the fact that each microservice can be easily changed and brought into production. When the flexible business processes of SOA are not sufficient, SOA forces the change of services into deployment monolith or user interfaces in an additional deployment monolith.
Microservices place emphasis on isolation: Ideally a user interaction is completely processed within one microservice without the need to call another microservice. Therefore, changes required for new features are limited to individual microservices. SOA distributes the logic to the portal, the orchestration, and the individual services.
Microservices: Project Level
However, the most important difference between SOA and microservices is the level at which the architecture aims. SOA considers the entire enterprise. It defines how a multitude of systems interact within the enterprise IT. Microservices, on the other hand, represent an architecture for an individual system. They are an alternative to other modularization technologies. It would be possible to implement a microservice-based system with another modularization technology and then to bring the system into production as a deployment monolith without distributed services. An entire SOA spans the entire enterprise IT. It has to look at different systems. An alternative to a distributed approach is not possible. Therefore, the decision to use a microservice-based architecture can be limited to an individual project while the introduction and implementation of SOA relates to the entire enterprise.
The SOA scenario depicted in Figure 6.1 results in a fundamentally different architecture (see Figure 6.3) if implemented2 using microservices:3
2. http://slideshare.net/ewolff/micro-services-neither-micro-nor-service
3. https://blogs.oracle.com/soacommunity/entry/podcast_show_notes_microservices_roundtable
• Since microservices refer to a single system, the architecture does not need to involve the entire IT with its different systems but can be limited to an individual system. In Figure 6.3 this system is the CRM. Thus, implementing micro-ser-vices is relatively easy and not very costly as it is sufficient to implement one individual project rather than change the entire IT landscape of the enterprise.
• Accordingly, a microservice-based architecture does not require an integration technology to be introduced and used throughout the company. The use of a specific integration and communication technology is limited to the micro-service system—it is even possible to use several approaches. For instance, high-performance access to large data sets can be implemented by replicating the data in the database. For access to other systems, again, other technologies can be used. In the case of SOA all services in the entire company need to be accessible via a uniform technology. This requires a uniform technology stack. Microservices focus on simpler technologies, which do not have to fulfill requirements as complex as those in SOA suites.
• In addition, communication between microservices is different: Microservices employ simple communication systems without any intelligence. Microservices call each other or send messages. The integration technology does not perform any orchestration. A microservice can call several other microservices and implement an orchestration on its own. In that situation, the logic for the orchestration resides in the microservice and not in an integration layer. In the case of microservices the integration solution contains no logic, because it would originate from different domains. This conflicts with the distribution according to domains, which microservice-based architectures aim at.
• The use of integration is also entirely different. Microservices avoid communication with other microservices by having the UI integrated into the microservice due to their domain-based distribution. SOA focuses on communication. SOA obtains its flexibility by orchestration—this is accompanied by communication between services. In the case of microservices the communication does not necessarily have to be implemented via messaging or REST: An integration at the UI level or via data replication is also possible.
• CRM as a complete system is not really present anymore in a microservice-based architecture. Instead there is a collection of microservices, each covering specific functionality like reports or forecasting transaction volume.
• While in SOA all functionality of the CRM system is collected in a single deployment unit, each service is an independent deployment unit and can be brought into production independently of the other services in the case of microservice-based approaches. Depending on the concrete technical infrastructure the services can be even smaller than the ones depicted in Figure 6.3.
• Finally, the handling of UI is different: For microservices the UI is part of the microservice, while SOA typically offers only services, which then can be used by a portal.
• The division into UI and service in SOA has far-reaching consequences: To implement a new piece of functionality including the UI in SOA, at minimum the service has to be changed and the UI adjusted. This means that at least two teams have to be coordinated. When other services in other applications are used, even more teams are involved, resulting in even greater coordination efforts. In addition, there are also orchestration changes, which are implemented by a separate team. Microservices, on the other hand, try to ensure that an individual team can bring new functionality into production with as little need for coordination with other teams as possible. Due to the microservice-based architecture, interfaces between layers, which are normally between teams, are now within a team. This facilitates the implementation of changes. The changes can be processed in one team. If another team were involved, the changes have to be prioritized in relation to other requirements.
• Each microservice can be developed and operated by one individual team. This team is responsible for a specific domain and can implement new requirements or changes to the domain completely independently of other teams.
• Also, the approach is different between SOA and microservices: SOA introduces only one new layer above the existing services in order to combine applications in new ways. It aims at a flexible integration of existing applications. Micro-services serve to change the structure of the applications themselves—in pursuit of the goal of making changes to applications easier.
The communication relationships of microservices are depicted in Figure 6.4. The user interacts with the UI, which is implemented by the different microservices. In addition, the microservices communicate with each other. There is no central UI or orchestration.
Synergies
There are definitely areas where microservices and SOA have synergies. In the end both approaches pursue the goal of separating applications into services. Such a step can be helpful when migrating an application to microservices: When the application is split into SOA services, individual services can be replaced or supplemented by microservices. Certain calls can be processed by a microservice while other calls are still processed by the application. This enables the migration of applications and the implementation of microservices in a step-by-step manner.
Figure 6.5 shows an example: The uppermost service of CRM is supplemented by a microservice. This microservice now takes all calls and can, if necessary, call the CRM. The second CRM service is completely replaced by a microservice. Using this approach, new functionality can be added to the CRM. At the same time, it is not necessary to reimplement the entire CRM; instead, microservices can complement it at selected places. Section 7.6 presents additional approaches to how legacy applications can be replaced by microservices.
6.3 Conclusion
Table 6.1 summarizes the differences between SOA and microservices.
At an organizational level the approaches are very different: SOAs place emphasis on the structure of the entire enterprise IT whereas microservices can be utilized in an individual project. SOAs focus on an organization where some teams develop backend services, while a different team implements the UI. In a microservice-based approach one team should implement everything in order to facilitate communication and speed up the implementation of features. That is not a goal of SOA. In SOA a new feature can involve changes to numerous services and therefore requires communication between a large number of teams. Micro-services try to avoid this.
At a technical level there are similarities: Both concepts are based on services. The service granularity can be similar. Because of these technical similarities, it can be difficult to distinguish between SOA and microservices. However, from conceptual, architectural, and organizational viewpoints both approaches have very different features.
Essential Points
• SOA and microservices split applications into services that are available on the network. Similar technologies can be employed to this end.
• SOA aims at flexibility at the enterprise IT level through the orchestration of services. This is a complex undertaking and only works when the services don't need to be modified.
• Microservices focus on individual projects and aim at facilitating deployment and parallel work on different services.