Architecture comparison: Microservices vs SOA

There are two modern architecture approaches that are increasingly being used for information system software and these are the Microservices Architecture (MSA) and the Service-Oriented Architecture (SOA).

In our previous article, we explore microservices architecture in detail. Here, our purpose is to compare both MSA and SOA to discover which architecture works best for your unique information system needs.

Many industry experts consider the microservices architecture as the natural and organic evolution of SOA, but if we look at it from a different standpoint, MSA should be considered as an independent architecture style with its own concept to build effective information system software.

Web service architectures: decomposition and monolithic architecture

Decomposition is a very popular methodology to solve large scale problems as it helps to avoid having to build monster-like monolithic architecture systems, which can be hard to maintain and extend.

At the same time,  decomposition generates numerous objects and a corresponding connection between all of them, which may generate problems in terms of a more complex relationship and communication between several parts of the system.

In the classical approach, as described in the book The Art of Scalability, decomposition can have three directions:

• Horizontal duplication: scale by cloning similar components and using load balancing.
• Functional decomposition: scale by dividing different logical parts of the system.
• Data partitioning: scale by splitting non-dependent similar data.

For the MSA architecture, functional decomposition is much like an entry point to analyze requirements and define the list of necessary microservices.

The main goal of decomposition is to define low-connected parts of the system while trying to avoid “spaghetti” interconnections between all components. This will keep the system well organized and minimize the latency of data exchange between parts of your system.

Advantages and disadvantages of the SOA architecture

Advantages of the SOA architecture

• The application is designed as monoliths and works as a single service.
• The startup time is minimal as SOA typically works in one physical server.
• The use of the Enterprise Service Bus (USB) for large scale organizations allows users to document and analyze information flows.

Disadvantages of the SOA architecture.

• Applications become complex due to the volume of functionalities combined in one monolithic architecture.
• It is difficult to scale specific parts of the application.
• Problems of reliability in one part of the service may cause the entire application to halt.
• It is difficult to use Agile development strategies.

Advantages of the Microservices Architecture.

• Applications work as a number of independent and modular components.
• It is easy to develop and understand the single component functionality.
• It is easy to test the functionality of a specific microservice.
• It is easy to maintain a single component.
• Each microservice can be managed as a separate SCRUM project.
• Low grain and mid-size grain modularity of the system allows splitting the system into pragmatic interconnected components.

Disadvantages of the Microservices Architecture.

• The Microservices Architecture complex interconnections between a large number of microservices.
• It is hard to support multiple databases and transaction management.
• Deploying and versioning of proper microservices are a difficult procedure.
• Testing of the integrity of the microservices system is not a simple task.
• Typically, it’s required to use an orchestration manager for microservices.

When is the Microservices Architecture more effective than SOA architecture

The Microservices architecture will be the most effective solution if your information system is well divided by components from the beginning.

The microservices architecture will be effective in the following scenarios:

• If your project uses different technology stacks and needs to aggregate different existing solutions with a variety of programming languages (PHP, RoR, Java, C#, and more).
• If your project already includes a defined list of APIs for individual services and the team understands information exchange procedures between all the system components.
• If your project has a team with a well-established Agile process.
• If you have a great continuous integration strategy and experience.
• If you plan to use cloud systems for your microservices architecture system.
• If you know how to use containers by considering how many microservices will be placed inside one container (see Fig. 1).

Take a look at the very detailed article on "How to determine when and why to use microservices" which describes most of the typical ways to keep a reasonable mind when building your microservices architecture.

When the Microservices Architecture is not the best fit

If you have a complex, unstructured project or a system with a small number of components, then it will be difficult to divide it into the proper microservices architecture. If that’s the case, SOA is a better fit for you.

Sometimes, microservices are misused instead of calling a provided or disclosed service through the web-based API service.

The main purpose of the API is to encapsulate the implementation of the service, which may be a microservice or SOA services. As an API user, you are not required to know or take interest into which architecture the service provider uses. You can find more information here.

Additionally, many experts link the Microservices Architecture with an Agile approach in the Software Development Lifecycle (SDLC). Thus, it is very challenging to simultaneously reorganize your system and project management style.

In this well-known article, Dave Kerr describes in detail his take on the demystification of the Microservices Architecture prowess.

Using cloud solutions and containers for microservices maintenance

Most cloud providers now have a very comprehensive support offering for the containerization of microservices. Containers enable the isolation of a microservice runtime environment. Containers do not mix different microservices in one physical instance, which helps avoid problems when different versions of technology stacks are required for sets of microservices.

A very good example involves theEureka and Heroku cloud services, as shown in this article. With a simple strategy, Eureka is able to create a server and a client in the Dynos cloud, which works very well. 

Using Continuous Integration and Continuous Deployment will help to deploy and maintain the microservices architecture in cloud systems. A good example of SOA architecture in cloud computing is the Open Service Gateway Initiative (OSGI) bundle for Java technology. A few, great tools for modern information system software include the docker-compose for management multi-container systems and the Apache ServiceComb as a full-stack microservice solution.

Microservices and containers add a new possibility of mixing two powerful technologies for real-life systems and solutions.

And the winner is...

There is no specific or precise answer when it comes to deciding when the Microservices Architecture is better than SOA architecture.

The Microservices Architecture is the logical evolution from solid SOA to something smaller and easy to design and maintain. If you start a new project from scratch, then it is highly recommended to analyze the possibility of looking into the microservices architecture. If you are using SOA and you are satisfied with it, just plan how you can transfer some part of the system to microservices and estimate the pros and cons for your unique needs.

Why Svitla?

Svitla Systems provides comprehensive services to develop SOA and microservices solutions, along with expert advice on how to create the best system for your business needs and how to support it.

For more in-depth information about our solutions, fill out the form below and our sales team will contact you shortly.