Introduction to Microservices

As you can see from the below Google trend graph, there is quite a bit of steady increase in adoption towards Microservices architecture pattern since 2014. That’s because it enables the continuous delivery/deployment of large, complex applications.

The base for the Microservices world is Containers. Linux containers have been around since the early 2000s and architected into Linux in 2007. Due to the 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 didn’t kickoff enough interest until Docker (2013) came into the picture.

If you’re looking for the introduction 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 that 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 the introduction to Microservices, its benefits/drawbacks & the reference model or components that are required for Microservices application.

#1. What is Microservices?

There are many definitions of 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 the 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 let’s 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 consist of user interface, along with some backend services for checking credit, maintaining inventory, and shipping orders.

As you can see below, services have been grouped into fine-grained level e.g., Account Service and each service has its own database and communicates via asynchronous protocols (REST)

#2.Benefits / Drawbacks

Microservices architecture has a number of benefits:

• Each microservice is relatively small,fine-grained
  • It is 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 to 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, the 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.
• The decomposition of complex systems into a set of Microservices is challenge.
• Deployment complexity. Unless you have a proper CI-CD pipeline built,it would be tough to manage the deployments.

#3.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 a few tips that would help you to decompose monolithic application.

1. Decompose by business capability e.g., if its OMS, you can have order processing, shipping etc., and define services corresponding to business capabilities.
2. Decompose by domain-driven design subdomain
3. Decompose by use case or function and define services that are responsible for particular actions. e.g. a Post Processing Service can take care of actions post order processing etc.,

#4.Reference Model for Microservices

Below is the reference model or set of required components that are needed for defining the architecture, this can be used as a 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 is a number of services, keeping track of what microservices 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 is a 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 reach out to the servers and collect the log files that each microservice produces.
• 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 endpoints – To protect the exposed API services ex. apply OAuth2

In upcoming posts, we can check how the suggested reference model can be implemented.

Like this post? Don’t forget to share it!

#5.Useful Resources :

• TOP 20 Microservices Design Patterns
• Take a free course on Building Scalable Java Microservices with Spring Boot and Spring Cloud
• How to maintain data consistency across Microservices?
• When Should You Go for Microservice Architecture?
• ULTIMATE GUIDE to Coursera Specializations That Will Make Your Career Better (Over 100+ Specializations covered)
• Google Cloud Courses Collection
• IBM Courses Collection

References : 

• Microservices.io by Chris Richardson