SOA(Service Oriented Architecture) and microservices are two different ways of considering the technical architecture of a project. When deploying a technical project, the question of its architecture arises from the start. While some IT managers have a systematic preference for one or the other of these architectures, it is more rational to consider the project as a whole in order to make the right choice.
And the answer is difficult to put in place since it is necessary to anticipate the "scalability" of the said project, its evolution in the short, medium and long term. The question is nonetheless crucial: monolithic architecture, SOA or microservices? Discover the similarities and differences between two systems in order to make the best decision.
SOA, microservices: two architectural styles
The SOA architecture
SOA appeared to solve interoperability problems; for example, when two applications running on different technologies (Java and .Net, Windows and Linux, etc.) have to communicate.
In an SOA, all applications must connect to anEnterprise Service Bus (ESB) in order to communicate with other applications. The ESB acts as the backbone of the integration, through which software services and application components flow. The ESB allows data to be transformed, completed and enriched.
The MS microservice architecture: no more "spaghetti dish
The microservice architecture appeared to solve scalability problems of the "spaghetti dish". This is the expression that designates a set of services that are strongly coupled. So well coupled that it becomes difficult to modify one service without impacting another.
A microservice application is a set of loosely coupled microservices. Each microservice can be modified and delivered independently, without impacting the other services. We can say that the microservice architecture is an evolution of the SOA. It offers a finer granularity to meet new needs, such as reducing the "time to market" by delivering and testing only what is strictly necessary.
A microservice is :
- elastic: scalable independently of other microservices.
- resilient: if this service crashes, it must not impact the other microservices.
- composable: it must offer an interface that facilitates its use
- minimal: the service must do only one thing (we talk about strong cohesion)
- complete: the service must work alone.
It is often said that a microservice must be minimal but complete.
The constraints of a microservice architecture
The microservice architecture creates new constraints and difficulties, to allow this weak coupling of microservices.
The best example is database management. Since each microservice has its own database, it is necessary to provide communication between microservices to update its databases and maintain data consistency (via a messaging system such as ActiveMQ or Kafka). Whereas in SOA, an application grouping several services has only one database.
Why implement a microservice architecture?
A monolithic application has a tendency to age badly: each new feature addition or bug fix can lead to regressions. This is due to the fact that some pieces of code or methods are reused by different services.
The monolithic application is also more difficult to test because it requires more prerequisites (LDAP, database, mail ...) than a simple microservice.
The microservice architecture allows each service to be managed independently: its evolution, its delivery and its performance.
What technologies do microservice architectures work with?
One must be careful not to neglect the learning curve of the various concepts and tools required to implement a microservice architecture.
For example:
- the Spring Boot Framework: it facilitates the creation of autonomous applications (not requiring an application server such as JBOSS)
- Apache Kafka: messaging system for communication between microservices
- API gateway: allows management (security, logs) and centralization of microservices
- Logstash / Kibana: allows the centralization of microservices logs
- Docker: allows you to load your microservices on containers to test them
- Devops: allows you to develop, test and deploy your microservices quickly
- Kubernetes: allows you to automate the management of your docker containers.
The transition from SOA to microservices can therefore be a difficult exercise. It involves learning to use new concepts: Kafka, Docker, devops, continuous integration, unit tests and integrations, etc. The transformation involves the tools, via more modern and flexible models, and the project management "culture". As for the migration of a monolithic application into several microservices applications, it is even more difficult: you have to split all the functionalities into independent services, rethink the whole database, add interactions between microservices via messages.
At Blue Soft, we can shed light on this process and bring you our know-how in microservices. Let our Digital Experts accompany you to discuss your project!
