Microservices architectural style

December 05, 2017

Microservices architectural style

Introduction

As traditional enterprises work to embrace business deployment agility of new age internet companies and innovations in engineering practices, the modern application development has grown increasingly complex. The large, monolithic codebases that traditionally power enterprise applications make it difficult to quickly launch new business capabilities. The application users are empowered and more demanding than ever – the modern enterprises need to scale effectively and enable continuous deployments to ensure customers are provided with high performance with the seamless user experience.

Due to these trends, there is a demand for a new software architecture pattern/style that can address the requirements of the modern age enterprise apps. The Microservices architecture style is the answer to business agility in the form of scalability, modularity and rapid deployments.

What Is Microservices?

It is an architectural style to develop a small/coarse grained services separated by business boundaries. Thus each service is autonomous in nature and can scale independently. Each service can communicate each other via REST APIs and can be deployed remotely or locally.

Monolithic pain points

Before Microservices, a common approach to design an application was to use a monolithic architecture. In this mode of development, the application is deployed as a single deployment artifact. Following are pain points associated with classic monolithic codebases.

1. Large monolithic code base will have the challenge to release new services and also difficulty in maintaining large code base
2. Modules can’t scale independently
3. Enable / Disable services without affecting existing features will be always a challenge
4. Any small change in the code will introduce many regression testing/complex deployment scenarios.
5. Will have challenges in continuous deployments

Difference with SOA

At outset, both architecture styles look similar. But there are subtle differences, the noteworthy are:

1. SOA uses ESBs while Microservices can leverage lightweight message gateways
2. Microservices are stateless implemented via REST APIs while SOA can be stateful
3. SOA focuses on reusability wherein Microservices is for decoupling

Tool support

Lightweight containers like Docker will provide provides a runtime environment for deployment and provides isolation with other services. There is many open sources / COTS tooling support available for Microservices enablement.

Pros / Cons

Following table summarizes briefly about Microservices advantages/disadvantages. The Microservices architecture can’t be suited for each app. The recommended approach is to gradually convert highly customer facing modules to Microservices, stabilize the rapid deployment cycle and gain the experience by maintaining these services over the period of time. This will have less impact on development teams/organization change management activities as teams have to adopt new way of developing the apps.

Advantages:

1. Decoupled services can have isolated life cycle
2. Faster time to market; less regressions
3. Modular in nature, hence flexible development and deployment plans
4. Can scale independently

Disadvantages:

1. Monitoring the many services
2. Developer skill set – For example: Microservices are distributed in nature. Hence there will be added complexity such as network latency, network unreliability, also understanding the DevOps culture
3. Technology learning curve – new set of tools to learn