Microservices-2 Introduction (SOA vs Microservices Architecture)

Microservices-1 Introduction (Monolithic vs Microservices Architecture)

A service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. The communication can involve either simple data passing or it could involve two or more services coordinating connecting services to each other.

There are mainly two roles in SOA, a service provider and a service consumer. Below is the basic SOA architecture.

SOA is an architecture framework, it’s more generic. SOA is technology independent. We can implement SOA architecture using Webservices.

An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a SOA. It is an architecture with set of rules for integrating various applications together over a bus-like infrastructure. In this approach we integrate different applications by putting a communication bus between them. This enables applications to talk to the bus. 

ESB decouples systems from each other, allowing them to communicate without dependency on or knowledge of other systems on the bus. The concept of ESB was born out of the need to move away from point-to-point integration, which is difficult to manage.

Advantages of SOA:

1. Flexibility: SOA is quite flexible. Various applications can be developed in different technologies. Since applications are independent of each other there's flexibility to upgrade the technology stack versions. Also, we can incrementally adopt a newer technology without much difficulty.

2. Reliability: SOA services are complete and self-contained programs. This makes it easy for testing, debugging or any form of maintenance.

3. Development speed: Development is fast in SOA. Since the volume of code is quite less as compared to monolithic architecture it’s not difficult for new team members to understand and modify the code. Code quality is maintained well. These factors increase developer’s productivity.

4. Building complex applications: Services are re-usable and so it’s not difficult to build complex applications. Because the services are complete and self-contained applications, they are characterized by their re-usability. Services are re-used in different applications irrespective of the other interacting components in that system.

5. Scalability: The ability of services to be successfully run on different servers within an environment increases the scalability and availability of the service.
Continuous deployment: Agility is possible with SOA to a certain extent.

6. Continuous deployment: Agility is possible with SOA to a certain extent.

So, we can see that most of the features of SOA and Microservices architecture are similar. Both are different from a traditional, monolithic architecture where every service has its own responsibility. Both SOA and Microservices architecture benefit from a certain level of decoupling.  Having said that, there are differences between them which are listed below:


Differences between SOA and Microservices architecture: 

1. Scope and size: The fundamental difference between SOA and microservice architecture lies in the size and scope. In simple words SOA has an enterprise scope, while the microservices architecture has an application scope. 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. Services 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 subsystems.

2. Re-usability vs decoupling (Bounded context): In SOA the prime focus is on re-usability, while Microservice architecture is more focused on decoupling. At an enterprise level arriving at certain level of re-usability is very essential. In microservices architecture, if some services are reused at runtime from various services, it results in dependencies that reduce agility and resilience. In Microservices architecture components generally prefer to reuse by duplicating code to improve decoupling. SOA encourages sharing of components, whereas microservices try to minimize on sharing through "bounded context". A bounded context refers to the coupling of a component including data as a single unit with minimal dependencies. SOA relies on multiple services to fulfill a business request, so systems built on SOA are likely to be slower than microservices.

3. Development: In both SOA and Microservice architectures, services can be developed in different programming languages and technologies, which brings flexibility with the technology diversity into the development team. The development is organized within various teams. In case of SOA, each team needs to know about the common communication mechanism. But with microservices architecture, the services can operate and be deployed independently of other services. So, it is easier to deploy new versions of microservices.

4. Communication: For communication among various services SOA uses Enterprise Service Bus (ESB). SOA supports multiple message protocols. The ESB could become a single point of failure which could impact the entire system. Since all the services communicate through the ESB, in case any of the services slows down, it could clog up the ESB with requests for that service. But in case of Microservice architecture there's no concept of ESB. Microservices are much better in error tolerance. If one microservice is down or clogged, then only that microservice will be affected, and all the other microservices will continue to handle requests regularly. Microservices usually use lightweight protocols such as HTTP, REST or Thrift APIs. ESB is a middleware. So, SOA uses middleware for communication, while microservices use API Gateway.

5. Interoperability: SOA supports multiple heterogeneous protocols through its messaging middleware component. Microservices architecture however, attempts to simplify it by reducing the number of choices for integration.

6. Scalability: In traditional SOA we would buy an ESB, we deploy the ESB, we deploy the individual services on that ESB, but if we need more scalability for an individual service we need to scale up the entire ESB infrastructure, we can’t just scale up individual services. In microservices architecture we can deploy individual services independently and scale up individual services.

7. Data storage: SOA services share the data storage. In Microservice architecture, each microservice is recommended to have an independent data storage.

Why organizations are moving towards Microservices architecture?

1. Microservices architecture is basically an evolution of SOA. Same principle still holds. Microservices architecture solves a lot of the problems that were there in SOA, like configuration issues, scalability issues. With microservices we can scale up features individually.

2. Agile and scrum is the major factor. We need to deliver things quicker.

3. DevOpps is the second factor. There’s a lot of deployments happen these days, so we need a good CICD pipeline for deployment and not rely on old traditional methods. The more we breakdown our application into smaller components the easier it is to push out these individual changes as we don’t have to ship that entire application with that feature.

Having said that, we just can’t simply throw the baby out of the bathtub, and upgrade SOA applications to Microservices. There are lot of really good Java enterprise technologies that are available to the SOA world, like transaction management, messaging, Object relational mapping to the DB, business rule management. All these things need to find their place in the microservices world. Ultimately applications still need to do same kind of operations like read/write from a DB, participate in transactions, and things like that.

In my next post on Microservices series I will write about the various challenges in implementing microservices architecture, we will learn about Spring Cloud and how Spring Cloud helps to overcome the challenges of Microservices architecture.