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 implemented[1] using microservices:[2]

CRM as a Collection of Microservices

Figure 6.3 CRM as a Collection of Microservices

  • • 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 microservices 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 microservice 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. Microservices 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.

Communication in the Case of Microservices

Figure 6.4 Communication in the Case of Microservices

SOA for Migrating to Microservices

Figure 6.5 SOA for Migrating to Microservices

  • [1] http://slideshare.net/ewolff/micro-services-neither-micro-nor-service
  • [2] https://blogs.oracle.com/soacommunity/entry/podcast_show_notes_microservices_roundtable
< Prev   CONTENTS   Source   Next >