No-Bullshit Guide To Microservices

Traditionally, web applications are monolithic in nature, meaning they are built as a single application separated internally through some kind of Model-View-Controller pattern. This is okayish for small applications. But as the application grows, or the application is complex, it becomes hard to maintain because:

  1. Only one central codebase — multiple teams working on entirely different things share the same codebase — ‘he broke it’ like scenarios can arise.
  2. Small changes could require the entire application to be redeployed — increased application down time during maintenance operations.
  3. Issues related to maintaining a single large codebase — multiple branches, access restrictions, separation of concerns and a whole lot of others.

In simple terms, Microservices are nothing but tiny(or ‘effing huge) self contained applications that are designed to perform a single(ideally) function in a large application. Microservices are not to be confused with Service Oriented Architecture(SOA) Pattern even though they seem to mean the same thing. Netflix is one of the largest known adopter of Microservices architecture, their entire offering is built around thousands of microservices running and operating in harmony. Microservices offer many benefits over multi tier monolithic applications. Significant ones are the following:

  1. Each micro service is a self contained application — Developer team responsible for a service is at liberty to choose the programming language(Ployglot Programming), database to use and the OS environment to deploy. Just the service interfaces have to be agreed.
  2. Less down time during deployments — just deploy the updated services rather than redeploying an entire application
  3. Separate codebase means no crashes due to “they changed this without our knowledge”
  4. Choosing best tools for the job ensures better performing apps
  5. Good fit for multi skilled organisations

Even though they’re adopted extensively, maintaining them can be hard because they are designed to be stateless(Ideally, microservices doesn’t have State) and it is extremely hard to trace calls between services if the design is not thought through.

Since each service is isolated, they could be on different machines or even on different clouds. But they all need to communicate in harmony for the application to work — services call other services to get things done, remember? How services know about each other ? Hard coding addresses is one temporary solution, but will be pointless once the application starts to scale and different addresses are assigned (microservice may scale independently depending on the load). This is solved by using something called Service Discovery. It is nothing but a microservice (yes, another microservice!) that keeps the info about all other microservices in the application. A Service discovery is responsible for keeping track of the IP addresses and other interface information required to invoke microservices in an application(Service Registry). When individual microservices scale, they may notify the service discovery microservice about the details(Self-Registration). Also, a load balancer may query the Service Discovery microservice to know about the microservices for distributing loads dynamically across scaled versions.

In above illustration, both the mobile & web apps are calling different APIs which are microservices. They in-turn call another microservice auth to authenticate requests. Front end apps can call some microservices directly like in this case, but most of the time microservices call other microservices to get things done. Usually, an API gateway will be in between microservices and front end apps. In the above example, auth service maybe written in GoLang while the others in Nodejs, auth server may use redis to cache DB calls while other do not use any caching. Services are independent of each other and communicate over REST API or Apache Thrift. Each individual service may scale according to load, for example a new sales campaign for mobile users can load up the mobile API server with requests while the web API service is sitting idle. The mobile API server may scale up, notify the service discovery and continue serving requests.

Microservice architecture require a well thought through design process to reap the benefits of it. Converting a perfectly fine monolith to Microservice based application without actually making the effort to evaluate can negatively affect the application.

In a coming article, we’ll discuss how and where to use Microservices along with event driven programming to build an analytics platform.