Microservices

Microservices

What is a microservice?

Do one thing, and do it well.

Microservices are an architectural and organizational approach to software development designed to speed up deployment cycles to ensure faster time to market, foster innovation, and help improve the scalability of software applications.

Using a microservices approach, software is composed of small independent services that communicate over well-defined APIs. These services are owned by small self-contained teams.

A microservice is an isolated, loosely-coupled unit of development that adddresses a single feature/concern. Microservices aim to avoid interdependencies.

Design Check: if one microservice has a requirement for other microservices, then go back to the whiteboard and see if it makes sense to make them all part of the same unit. Avoiding interdependency is the key to designing a viable microservices driven architecture.

Reading list: The Twelve-Factor App

Microservices Building Blocks

All microservices architecture share some common building blocks. It's important to understand these and leverage them in building your architecture

  1. Do one thing well - Design around business capabilities instead of around technology.
  2. Independent - Component driven architecture gives the ability to replace parts of a system as and when needed.
  3. Polyglot - The goal is to have a distributed system with a decentralized data management. Challenge “one size fits all” approach. Choose the best tool for their specific problems leading to a polyglot approach.
  4. Decentralized - Each microservice operates in its own environment without having to share a data model and force fit itself into the available data model. They are developed, deployed and managed in a decentralized manner.
  5. API interfaces - Microservices hide the complexity within and expose well defined API's for communication with other entities
  6. DevOps - Typically, the team responsible for building the microservice also takes the responsibility for operating and maintaining it in production. You build it; You run it

Why Microservices?

  • Agility: Small independent teams that take ownership of their services and operate on well-understood bounded context. They are empowered to work independently and faster, thus reducing the time to market.
  • Scalability: The polyglot approach allows choosing the appropriate and optimal technologies for a specific service and is fine-tuned with the best performing service configurations. Properly decoupled services can be scaled horizontally and independently from each other. Horizontal scaling, which is adding more nodes to the existing cluster, is highly dynamic and can be automated. The resiliency of the application can be improved because failing components can be easily and automatically replaced.
  • Innovation: Since each team is handling only a piece of the entire software, they can exercise a larger autonomy in the technology decisions, they can focus on innovating and optimizing the microservice they are responsible for. These teams can now innovate and leverage newer technologies to optimize their microservice offering.
  • Availablity: Microservices architectures make it easier to implement failure isolation. Techniques such as health-checking, caching, replication allows you to reduce the blast radius of a failing component.

Microservices challenges

As much as I would like to paint a rosy picture around microservices, as with all the architecture styles, microservices too, have their own challenges.

  • Takes a village - Microservices and organization structure are very closely tied. Adopting a microservices architecture requires a paradigm shift on how the teams are organized. DevOps culture needs to built and adopted in the organization.
  • Boundaries - Separation of concern or in other words how to determine a logical boundary for a particular microservice is IMHO the most difficult task.
  • Migration - Moving from a monolithic architecture to microservices architecture would need evaluation at every level of the application and this can be exhaustive code reviews and code redesign.
  • Fallacies of distributed computing - A naive operating assumption of unlimited bandwidth, network availability and zero latency could be misleading.
  • Architectural complexity - In monolithic architectures, the complexity resides at the code level. With microservices architecture, the complexity moves to the interactions of these independent services
  • Provisioning - In a microservices environment, you are running multiple services and provisioning infrastructure which is scalable and cost-efficient is very critical to the overall success of the architectural style.

Having said that, most of these challenges are handled by the cloud providers and the benefits of adopting microservices can outplay the challenges.




The best thing about microservices architecture is that it can force you into domain driven architecture. However, there are certain team design principles that muat be followed to ensure success in a domain driven world.

To view or add a comment, sign in

Others also viewed

Explore content categories