SOA vs Microservices
In order to distinguish this two types of architectures and the question “Is it a difference at all?”. To go deeper in this matter that raised thousands of debates, I will briefly define both architectures (SOA and Microservices) and further they are going to be compared.
Service Oriented Architecture
Service Oriented Architecture is a software architecture which components communicate with each other using communications protocol over the network. The type of communication involved in this architecture could involve simple data transportation, service mediation, service orchestrations. This services, in fact, represent small functions such as: create a new cliente, validate a credit card payment, or login a user.
You could think SOA is how to compose an application by integrate components in distributed environment. This strategy can be enable by using low coupled standards / technologies that make easier to communicate with each other over the network.
A corporation called Gartner Group in the mid 90s, saw this new trend and popularized the name SOA to the world. By doing this they make this architecture style more visible to the world and speed up the adoption and evolution of this architecture.
Microservices
Microservices, in a way, are the next step in the evolution of Service Oriented Architectures. Basically, this architecture type is a particular way of developing software as suites of independent services — a.k.a microservices. These services are created to serve only one specific business function, such as Credit Cards, Baking Accounts, Wish List, Credit Score, Social Media Logins, etc. Furthermore, they are low coupled, high cohesion, completely independent of each other, this means that they can be build with any kind of technologies / language / data storage. Centralized services management is almost nonexistent and the microservices use lightweight HTTP, REST, Lightweight messaging to communicate with each other.
In a software architects workshop held near Venice May 2011 the used of ther “microservice” term was used for the first time. The term was used to describe a architecture style the many of architects were exploring / studying. In may 2012, this group decided the the “microserevice” was the appropriate name. You could think, that this kind of architecture was used by major tech companies like: Amazon, Netflix and Facebook, but the term was not popularized. Some people called this architecture style as “Micro WebServices” or “Fine-Grained SOA”.
It might seem that we are talking about SOA itself. However, Martin Flower a pioneer in the world of microservices, who once said that we should think about SOA as a superset of microservices.
You could think of the Microservices Architectural Style as a specialization of SOA. Don’t forget that one of the accepted views is that all SOA really is, is four sentences:
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- Service compatibility is based on policy
This brings us to the canonical definition of microservices, from Lewis/Fowler:
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralised management of these services, which may be written in different programming languages and use different data storage technologies.
Comparing
SOA
- Maximizes application reusability
- A systematic change requires modifying the monolith (Legacy Systems)
- DevOps and Continuous Delivery are not mainstream
- Focused on business functionality reuse
- For communication it uses Enterprise Service Bus — Monolith Structure
- Supports multiple message protocols
- Use of a common platform for all services deployed to it
- Use of containers (such as Docker) is less popular
- SOA services share the data storage
- Common governance and standards
Microservices
- Decoupling
- A systematic change is to create a new service
- DevOps and Continuous Delivery as core value
- More importance on the concept of “bounded context” — Products over Projects
- For communication uses less elaborate and simple messaging systems
- Uses lightweight protocols such as HTTP, REST, and Ligthweight Messaging
- Application Servers are not really used, it’s common to use cloud platforms
- Containers work very well with microservices
- Each microservice can have an independent data storage
- Decentralized governance, with greater focus on teams collaboration and freedom of choice
Development
In both architectures, services can be developed in different programming languages and tools, which brings technology diversity into the development team. The development can be organized within multiple teams, however, in SOA, each team needs to know about the common communication mechanism. On the other hand, with microservices, the services can operate and be deployed independently of other services. So, it is easier to deploy new versions of microservices frequently or scale a service independently.
Bounded Context
SOA encourages sharing of components, whereas microservices try to minimize on sharing through low coupling and high cohesion (bounded context). A bounded context refers to the coupling of a component and its data as a single unit with minimal dependencies. As SOA relies on multiple services to fulfill a business request, systems built on SOA are likely to be slower than microservices.
Communication
In SOA, the ESB could become a single point of failure which impacts the entire system. Since every service is communicating through the ESB, if one of the services slows down, it could slow down the entire ESB with requests for that service. Microservices are much better as resilient systems because the have thier own execution environment.
Size
The main difference between SOA and microservices lies in scope and size. The prefix “micro” in microservices refers to the granularity of the internal components, meaning they have to be significantly smaller than what SOA tends to be. Service components within microservices generally have a single purpose and they do that one thing really well. On the other hand, in SOA services usually include much more business functionality, and they are often implemented as complete system.
Conclusion
We can not say that one architecture is better than the other. It mainly depends on the purpose of the application you are building. SOA is better suited for larger, complex enterprise application environments that require integration with many other applications (legacy systems). Smaller applications are not a good fit for SOA as they don’t need a messaging middleware component. We can think SOA could be the Monolith Legacy System Decopling first step.
Microservices, on the other hand, are better suited for smaller and well-partitioned, web-based systems. Also, if you are developing a mobile or web application, then microservices give you much greater control as a developer.
