Microservices - Why Not Monolithic or SOA/ESB

This post attempts to explore evolution of enterprise architectures from Monolithic Applications to Microservices.

1). Monolithic Applications:

In Monolithic style, all business functionality is clubbed in a single unit. 

In a real use case (Online Retail Application) - Entire application is a collecting of several components as shown. Adding or modifying to a component is extremely complex, due a single unit, any change in one breaks another. Also communication between these components uses proprietary protocol/standards. 

Monolithic style posses below features:

• Design, Developed and Deployed as a Single Unit
• Redeployment requires to change any part of it.
• One stable service brings whole application down.
• All functionalities are built on homogenous technologies/framework, so tough to adopt any new technologies.
• As application grows, due Monolithic nature, application starts taking more time to start up.

As a solution to Monolith drawbacks, SOA & ESB emerged.

2). SOA and ESB

SOA tries to fill up Monolith challenges, by separating functionalities of  Monolith applications into reusable, loosely coupled entities called 'Services', which are accessible over the network.

SOA/ESB style posses below features:

• Service is a well-contained implementation of a well-defined business functionality and loosly coupled.
• Services offers well-defined interfaces that are implementation independent. I.e. Separation from what from it's how part.
• Consumers are only concerned about service interface and do not care about implementation
• Services can be dynamically discovered using service metadata.
• Composite Service can be built from aggregate of other services.

Role of ESB - With the SOA paradigm, services are deployed within an 'Application Server'.

While consumption, you may need to integrate/plumb multiple such services (To create 'Composite Service') and other systems. ESB is used to integrate those services and form Composite Service.  Consumers uses the 'Composite Service' exposed from the Service Layer.

Thus ESB becomes centralized bus that connects all services and systems.    

I.e. At ESB layer, we integrate business capabilities and create composite business capabilities which are then consumed by consumer. 

ESB not just contains a significant portion of the business logic of the entire application - Other cross-cutting concerns such as 'Security', 'Monitoring', 'Analytics' etc.

API Management Layer over SOA/ESB:

Due to the complexity of Web Service-related technologies such as SOAP message format, WS-Security, WSDL etc - Most organizations put a new API Management /API Gateway on top of the existing SOA implementation.

This layer is called as 'API Facade', hides all internal complexity of ESB - All the business functionalities are now being exposed as managed API. This API layer is also responsible for Security, Throttling and Caching.

3). Microservices

With increasing demand for complex business capabilities, it's better to further get rid of the central ESB and break functionalities into each service. Microservice recommends individual services to take care of composition logic and inter-service communication. 

With SOA/ESB, most of the business functionalities are implemented at ESB level thru integration or plumbing of the underlying services and system. 

Microservices architecture introduces a new style of service integration - SMART Endpoints and Dumb Pipes, instead of ESB. With SMART Endpoints and Dumb Pipes, all the business logic resides at microservice level.

The foundation of microservice pattern is about an application as a suite of small and independent services, that are running in their own processes, developed and deployed independently. 

Below depicts microservices design of ESB based design shown above. Here MS got rid of ESB by breaking business functionality into each service, so that each microservice takes care of inter-service communication and business logic. 

    

Key concept of MS architecture is that service has to be designed meeting business functionalities, serving a specific business purpose - Focus on doing one thing and doing it well/complete - I.e. Autonomous Service.

Microservice do not share same execution runtime, rather they are deployed as isolated runtimes using 'Containers'.

This autonomous nature ensure 'Resiliency' as system will have isolated failures along with Service Isolation.

Also these loosely coupled services communicates thru messaging via inter-service communication, using various communication styles (Synchronous/Asynchronous) over the network. 

Hope this helps!!'

Arun Manglick