M

…the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

- Martin Fowler, Renowned author, Chief Scientist at ThoughtWorks

The above quote on microservices architecture is often deemed to be the textbook definition. Before we dive into what is a microservice, let’s look at the traditional practice of designing and developing software i.e., as a monolith.

Monolithic Architecture

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

As student developers, we tend to follow this approach with a web framework such as Django or Spring where the UI and business logic are part of one repository. Thus, when we deploy such an application, we need to package the entire application as a single unit. Hence, if multiple people were to contribute on the application, their changes won’t be reflected unless the entire application is deployed again.

Microservices Architecture

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 for connection to other units
• implemented using the programming language of choice
• released using its own binary

To gain agility in the development cycle, several concerns (independent features) of a monolith can be split into microservices that can be developed and deployed individually. With such an architecture, the application becomes fault tolerant as there is no single point of failure - even if one microservice goes down or crashes, other microservices will still work at their concerns are independent.

Trade-offs

• Development Complexity: represents the effort required to deploy and manage an application.
• Scalability: captures how an application is able to scales up and down, based on the incoming traffic.
• Time to Deploy: encapsulates the build of a delivery pipeline that is used to ship features.
• Flexibility: implies the ability to adapt to new technologies and introduce new functionalities.
• Operational Cost: represents the cost of necessary resources to release a product.
• Reliability: captures practices for an application to recover from failure and tools to monitor an application.