When we browse a web page, use a mobile application or perform some action in a computer program, everything seems simple in the palm of our hand or on the computer screen. However, these developments carry almost as much architecture behind them as a Norman Foster or Frank Gehry building. Not an architecture of foundations and buttresses, but of programming languages and developments that try to build robust and durable software architectures.
During the last few years, in the world of information and communication technologies we have heard a lot about the term Microservices. It is attracting the attention of many eyes and generates heated debates among IT teams about the suitability of using this architecture or the SOA architecture. For this reason, in this article we are going to explain what we mean when we talk about SOA and Microservices, and we will delve into their differences and applications to better understand what they consist of.
There is a lot of confusion about aspects such as: are Microservices well-designed SOA services or are they something else? What are Microservices? If I already work with a SOA solution, should I switch to Microservices? We are going to try to shed light on these issues and establish the differences between these two types of IT architectures.
What is SOA?
SOA (Service Oriented Architecture) or service-oriented architecture is a software architecture based on which the different components of the application are related to each other, and provide services to the rest of the components through a network communication protocol. SOA can coordinate or communicate two or more services. SOA-based applications employ loosely coupled components that use an Enterprise Services Bus messaging protocol to communicate with each other.
SOA is an architectural model for distributed systems that pursues the following objectives: improve organizational agility, implement service orientation, and align business objectives and IT department objectives.
SOA develops an application integrating the distributed software components and deploying them separately, unlike Microservices that “modularize” and package the components of each application. SOA operates on the basis of technologies and standards that facilitate cooperation and fluid communication between components. Using SOA may be appropriate when it is not possible to decentralize data repositories.
A bit of history: although SOA emerged in the eighties of the last century, when the first records of its use exist, it was not until the mid-nineties that it became popular throughout the world thanks to the Gartner Group company, which embraced this trend in software architectures and accelerated the growth of this software architecture pattern.
- SOA Features and Applications:
- Maximize the reuse of application services.
In SOA the DevOps movement is not yet the most popular current. If you want to know more about DevOps, check the Bilib blog article “What is DevOps and how does it influence the digital transformation of companies”.
- It focuses on the reuse of business functionalities.
- It uses Enterprise Service Bus (ESB) to establish communications.
- It is capable of supporting multiple message protocols.
- It uses a common platform for all the services deployed in the application.
- The use of containers is not widespread.
- All SOA services share data storage.
What is Microservices?
For its part, Microservices (microservices) understands the development of an application as the implementation of a set of small services. Each of these small services works at the same time, they run in their own process and are in constant communication with each other, using mechanisms that are lighter than SOA.
We could say that Microservices are represented, in a certain way, as a step beyond SOA, therefore, they can be understood as an evolution of the service-oriented architecture. With Microservices we can develop and implement software applications, web or mobile applications based on an architecture that is based on sets of independent services. In fact, Microservices can be classified as such because each service is packaged and deployed completely independently. They are designed as highly autonomous services that do not depend on centralized and synchronized communication.
Microservices run independently and fulfill a single specific function, such as: managing the different users of a website; allow the shopping cart in an online store to work, as well as the search engine or the function of logging into a social network associated with the development, among many others.
Being services that are developed completely independently, they can be written in different programming languages, as well as use different databases. Microservices use HTTP, REST, or Thrift APIs to communicate with each other, and system administration is almost entirely decentralized. These microservices are supported by fully automated machinery and are built regardless of deployment.
Microservices are suitable to be used by companies of different sizes, since we are talking about scalable solutions. Each of these Microservices has a limited associated signature of a module, which allows, as we anticipated, that different services can be written in different programming languages, as well as be managed by different work teams.
A bit of history: but where does the term Microservices come from? The word was coined at a software architects workshop held in 2011 in Venice. It was first used to identify a style of software architecture that workshop attendees had recently been exploring and using. But, although the term was coined in 2011, technology giants such as Microsoft or Amazon were already using microservices, also called “fine-grained SOA”, before this term became general.
Microservices Features and Applications:
- They work autonomously and independently.
- They do not need to participate in distributed transactions.
- They have a limited scope.
- They do not depend on synchronization with other services.
- They are not created to be part of complex service compositions.
- They are governed in a decentralized way and can use different programming languages.
- They use their own data storage.
- They act with communication mechanisms based on messages.
- The Microservices architecture is linked to the DevOps movement and philosophy.
- It uses less elaborate and simple messaging systems compared to SOA.
- It uses lightweight protocols like HTTP, REST or Thrift API.
- Each microservice can have independent data storage.
- Promote team collaboration.
Differences between SOA and Microservices
Both architectures present more similarities than differences. In fact, Martin Fowler, a software engineer and pioneer in the world of microservices, says that we should think of SOA as a super-set of microservices. Therefore, we could say that both architectures complement each other and can be understood as an evolution.
There is no better architecture than another, the choice depends on the objective and purpose of the project to be developed. Generally speaking, SOA is usually more recommended for larger organizations that work on the basis of application integration. Microservices are characterized by being smaller and more fractional systems that allow greater control to the software developer.
An important differentiation between both architectures is the size and scope of each of them. In the microservices system, each service has a unique functionality that executes perfectly. For its part, SOA includes more functionalities and is capable of developing complete systems.
With Microservices, developers have more flexibility by not depending on the global system; With SOA, teams are more “corseted” since they must know the common communication mechanism for all services, which is not the case with Microservices.
With Microservices, each of the services can be implemented independently, contrary to what happens with SOA that works based on the integration of services.
As for system failures, if they occur in SOA they would affect the entire system, unlike Microservices, an architecture with which the failure would affect a single point and not the entire system.
Finally, if we look at the operability, SOA uses multiple heterogeneous protocols, which allows the integration of several systems using different protocols in the same application. Microservices simplifies the architecture pattern and reduces the number of integration options.
In short, both architectures are used today and provide good results, the choice between one or the other depends on the project we want to develop.