As you can see from the below Google trend graph,there is quite bit of steady increase in adoption towards Microservices architecture pattern since 2014.That’s because, base for Microservices world is Containers. Linux containers has been around since the early 2000s and architected into Linux in 2007. Due to small footprint and portability of containers, the same hardware can support an exponentially larger number of containers than VMs, dramatically reducing infrastructure costs and enabling more apps to deploy faster.But due to usability issues,containers din’t kickoff enough interest until Docker (2013) came into picture.
If you want more details on containers,check out here.
Microservice architecture is a design pattern for developing applications in which complex applications are broken down into smaller, composable services which work together. Each component is developed separately, and the application is then simply the sum of its constituent components. Each service, can live inside of a container, and can be scaled independently of the rest of the application as the need arises.
In this article, we are going to look at introduction to Microservices,its benefits/drawbacks & reference model or components that are required for Microservices application.
What is Microservices?
There are many definitions to Microservices but below one from Martin Fowler is more apt.
The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
To make it simple,we can define Microservice as
- Architecture that structures the application as a set of loosely coupled, collaborating services.
- Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols.
- Each service has its own database in order to be decoupled from other services.
Now lets take an example,For an Amazon like application that takes orders from customers, verifies inventory, if available credit, ships them.As you can visualize,the application would consists of user interface, along with some backend services for checking credit, maintaining inventory and shipping orders.
As you can see below,services has been grouped in to fine grained level e.g., Account Service and each service has its own database and communicates via asynchronous protocols (REST)
Benefits / Drawbacks
Microservices architecture has a number of benefits:
- Each microservice is relatively small,fine-grained
- Its easy for a developer to understand & he can focus only on his work.
- Application starts faster, which makes developers more productive, and speeds up deployments.
- Better testability – services are smaller and faster to test.
- Better deployability – services can be deployed independently (but if there are interactions,you would need deploy related services as well)
- Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests.
- Enables the continuous delivery and deployment of large, complex applications.
- Eliminates any long-term commitment to a technology stack.
There are some disadvantages as well,following are some of them
- Implementing complex use cases that span multiple services without using distributed transactions is difficult.
- In order to ensure loose coupling, each service has its own database. Maintaining data consistency between services is a challenge.
- Decomposition of complex system in to set of Microservices is challenge.
- Deployment complexity.Unless you have proper CI-CD pipeline built,it would be tough to manage the deployments.
Tips on how to decompose monolithic application
Most large scale web sites including Netflix, Amazon and eBay have evolved from a monolithic architecture to a microservice architecture.Here are few tips that would help you to decompose monolithic application.
- Decompose by business capability e.g., if its OMS,you can have order processing,shipping etc., and define services corresponding to business capabilities.
- Decompose by domain-driven design subdomain
- Decompose by use case or function and define services that are responsible for particular actions. e.g. a
Post Processing Servicecan take care of actions post order processing etc.,
Reference Model for Microservices
Below is reference model or set of required components that are needed for defining architecture,this can be used as guideline for developing any Microservice based application.
- As you can see above, services are clearly scoped & smaller (fine grained)
- Use Single Responsibility Principle
- Apply Domain Driven Development
- Bounded Context
- Each service should be Independently Managed
- Run on its processes and embedded runtime like – tomcat, JBoss, jetty..etc
- Clear ownership for each service
To achieve the above principles/guidelines,any Microservices application would have below components
- Central Configuration server – Instead of storing configuration in locally per deployed unit (i.e. microservice) there would be centralized management of configuration.
- Service Discovery – Since there are more number of services, keeping track of what microservices that are deployed currently and on what hosts and ports, we would need service discovery functionality.
- Dynamic Routing and Load Balancer – Routing components can use the service discovery API to lookup where the requested microservice is deployed and load balancing components can decide what instance to route the request to if multiple instances are deployed for the requested service.
- Circuit Breaker – To avoid the chain of failures problem we need to apply the Circuit Breaker pattern
- Monitoring – Given that there are number of components,we would need monitor mechanism to monitor their state and also collect run time statistics from them to get a picture of the health status of the system landscape and its current usage.
- Centralized log analysis – To be able to track messages and detect when they got stuck we need a centralized log analysis function that is capable to reaching out to the servers and collect the log files that each microservice produce.
- Edge Server – To expose the API services externally and to prevent unauthorized access to the internal microservices we need an edge server that all external traffic goes through.
- Securing the end points – To protect the exposed API services ex. apply OAuth2
For list of TOP 20 Microservices design patterns,please check here.
In upcoming posts, we can check how the suggested reference model can be implemented.
Like this post? Don’t forget to share it!
- Microservices.io by Chris Richardson