System Design Blog: Microservices Architecture

Siva Naik
6 min readNov 23, 2022

Hello Folks!! I hope you are doing amazing. In this blog, I am going to write about Microservices Architecture.

In this blog, you are going to learn

  • Why do companies use Microservices architecture?
  • What are Microservices?
  • How to implement Microservices?
  • What are all the companies leveraging the power of Microservices?

Applications Architecture Patterns

Let’s understand two types of application deployment patterns

  1. Monolith
  2. Microservices

Monoliths — architect application as a single deployable unit

In a monolithic architecture, application tiers can be described as:

  • part of the same unit
  • managed in a single repository
  • sharing existing resources (e.g. CPU and memory)
  • developed in one programming language
  • released using a single binary

A booking application referencing the monolithic architecture

Imagine a team developing a booking application using a monolithic approach. In this case, the UI is the website that the user interacts with. The business logic contains the code that provides the booking functionalities, such as search, booking, payment, and so on. These are written using one programming language (e.g. Java or Go) and stored in a single repository. The data layer contains functions that store and retrieve customer data. All of these components are managed as a unit, and the release is done using a single binary.

Microservices — architect application as multiple small services which are loosely coupled

In a microservice architecture, application tiers are managed independently, as different units. Each unit has the following characteristics:

  • managed in a separate repository
  • own allocated resources (e.g. CPU and memory)
  • well-defined API (Application Programming Interface) for connection to other units
  • implemented using the programming language of choice
  • released using its own binary

A booking application referencing the microservice architecture

Now, let’s imagine the team develops a booking application using a microservice approach.

In this case, the UI remains the website that the user interacts with. However, the business logic is split into smaller, independent units, such as login, payment, confirmation, and many more. These units are stored in separate repositories and are written using the programming language of choice (e.g. Go for the payment service and Python for the login service). To interact with other services, each unit exposes an API. And lastly, the data layer contains functions that store and retrieve customer and order data. As expected, each unit is released using its own binary.

Why Microservices?

Development Complexity

Development complexity represents the effort required to deploy and manage an application.

  • Monoliths — one programming language; one repository; enables sequential development
  • Microservice — multiple programming languages; multiple repositories; enables concurrent development

Scalability

Scalability captures how an application is able to scale up and down, based on the incoming traffic.

  • Monoliths — replication of the entire stack; hence it’s heavy on resource consumption
  • Microservice — replication of a single unit, providing on-demand consumption of resources

Time to Deploy

Time to deploy encapsulates the build of a delivery pipeline that is used to ship features.

  • Monoliths — one delivery pipeline that deploys the entire stack; more risk with each deployment leading to a lower velocity rate
  • Microservice — multiple delivery pipelines that deploy separate units; less risk with each deployment leading to a higher feature development rate

Flexibility

Flexibility implies the ability to adapt to new technologies and introduce new functionalities.

  • Monoliths — low rate, since the entire application stack might need restructuring to incorporate new functionalities
  • Microservice — high rate, since changing an independent unit is straightforward

Operational Cost

Operational cost represents the cost of necessary resources to release a product.

  • Monoliths — low initial cost, since one code base and one pipeline should be managed. However, the cost increases exponentially when the application needs to operate at scale.
  • Microservice — high initial cost, since multiple repositories and pipelines require management. However, at scale, the cost remains proportional to the consumed resources at that point in time.

Reliability

Reliability captures practices for an application to recover from failure and tools to monitor an application.

  • Monoliths — in a failure scenario, the entire stack needs to be recovered. Also, the visibility into each functionality is low, since all the logs and metrics are aggregated together.
  • Microservice — in a failure scenario, only the failed unit needs to be recovered. Also, there is high visibility into the logs and metrics for each unit.

How to implement Microservices?

Image from NGINX Blog
  1. Start with a Monolithic application
  2. Organize the team the right way
  3. Split the monolith to build the microservices
  • Keep communication between services simple with a RESTful API
  • Divide data into bounded contexts or data domains
  • Emphasize monitoring for easy microservices testing
  • Use Continuous Delivery to reduce deployment friction

Usecase of Microservices

  • Modernizing and Refactoring Legacy Applications
  • Big Data Applications
  • Real-time Data Processing
  • Multi-Group Developments
  • The DevOps Model

Companies Leveraging Microservices

Amazon

Amazon Microservices Architecture

One of the first instances where microservices significantly changed the entire business was at Amazon.

When monolith architecture was “the way” to develop IT systems, the global giant experienced extraordinary success.

The retail website Amazon.com was a sizable architectural monolith in 2001.

Rob Brigham, senior manager of product management for Amazon AWS (source)
The services and parts of Amazon’s architecture were closely coupled, despite the fact that it wasn’t exactly a giant monolith. With hundreds of developers dispersed throughout the company, Amazon was no longer able to quickly deploy changes.

Before customers could use any significant code modifications, they were all held up in the deployment pipeline for weeks. Microservices were used by Amazon to streamline and shorten the pipeline. By breaking down larger systems into smaller applications, developers were able to identify bottlenecks and the causes of slowdowns, which helped them rebuild the systems using service-oriented architectures and small teams working on individual services.

Netflix

Netflix is one of the earliest adopters of microservices, and one of the most discussed. The story of Netflix turning towards microservices starts in 2009 when this approach wasn’t known at all. They set up their microservice architecture on AWS. Their transition process progressed in steps: first, they moved movie encoding and other non-customer-facing applications. Then they decoupled customer-facing elements, like account sign-ups, movie selection, device selection, and configuration. Netflix needed 2 years to split its monolith into microservices, and in 2011 announced the end of redesigning its structure and organizing it using microservice architecture.

Today, the Netflix application leverages 500+ microservices and API Gateways that handle over 2 billion API edge requests daily.

Learn more about microservices at Netflix here.

Spotify

By the time Spotify had 75+ million active users monthly, it was looking for a solution that would scale to millions of users, support multiple platforms and handle complex business rules. They wanted to be competitive in a fast-moving market by being fast to react and out-innovative the competition. Their technology teams found a way to meet the above requirements by launching microservices managed by over 90 autonomous full-stack teams organized into tribes.

Kevin Goldsmith describes microservices architecture at Spotify.

Currently, Spotify is running over 810 services. Decoupling their old system allowed Spotify to build flexible structures that are easily scalable, resolve real-world bottlenecks in a short time, test easily, and version different solutions separately. They also became less susceptible to large failures.

Learn more about microservices at Spotify here.

There are a lot of companies that are using microservices to deploy applications.

Thanks for reading!! Let’s Connect

--

--