Microservices

Microservices architecture consists of collections of light-weight, loosely-coupled services. Each service implements a single business capability. Ideally, these services should be cohesive enough to develop, test, release, deploy, scale, integrate, and maintain independently.

“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. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”  -James Lewis and Martin Fowler

Defining Characteristics of Microservices

• Each service is a light-weight, independent, and loosely-coupled business unit.
• Each service has its own codebase, managed and developed by a small team (mostly in an agile environment).
• Each service is responsible for a single part of the functionality (business capability), and does it well.
• Each service can pick the best technology stack for its use cases (no need to stick into one framework throughout the entire application).
• Each service has its own DevOp plan (test, release, deploy, scale, integrate, and maintain independently).
• Each service is deployed in a self-contained environment.
• Services communicate with each other by using well-defined APIs (smart endpoints) and simple protocols like REST over HTTP (dumb pipes).
• Each service is responsible for persisting its own data and keeping external state (Only if multiple services consume the same data, such situations are handled in a common data layer).

Benefits of Microservices

Microservice are made to scale large systems. They are great enablers for continuous integration and delivery too.

                The Scale Cube: 3-Dimensional Model for Scalability

• Independent scaling — Microservices architecture supports Scale Cube concept described in the excellent book The Art of Scalability. The Microservices Architecture pattern corresponds to the Y‑axis scaling of the Scale Cube. When developing microservices to achieve functional decomposition, the application automatically scales via Y axis. When the consumption is high, microservices can scale via X axis by cloning with more CPU and memory. For distributing data across multiple machines, large databases can be separated (sharding) into smaller, faster, more easily managed parts enabling Z axis scaling.
• Independent releases and deployments — Bug fixes and feature releases are more manageable and less risky, with microservices. You can update a service without redeploying the entire application, and roll back or roll forward an update if something goes wrong.
• Independent development — Each service has its own codebase, which is developed, tested, and deployed by a small focused team. Developers can focus on one service and relatively-small scope only. This results in enhanced productivity, project velocity, continuous innovation, and quality at source.
• Graceful degradation — If a service goes down, its impact won’t propagate to the rest of application and result in a catastrophic failure of the system, allowing a certain degree of anti-fragility to manifest.
• Decentralized governance — Developers are free to pick the technology stacks and make design standards and implementation decisions that are best suited for their service. Teams do not have to get penalized due to past technology decisions.

Major Drawbacks

• One drawback is the name itself. The term microservice places excessive emphasis on service size, it’s important to remember that they are a means to an end and not the primary goal. The goal of microservices is to sufficiently decompose the application in order to facilitate agile application development and deployment.
• Another major drawback of microservices is the complexity that arises from the fact that a microservices application is a distributed system. Developers need to choose and implement an inter‑process communication mechanism based on either messaging or RPC.
• Another challenge with microservices is the partitioned database architecture. In a microservices‑based application, however, you need to update multiple databases owned by different services.
• Another major challenge with the Microservices Architecture pattern is implementing changes that span multiple services. In contrast, in a Microservices Architecture pattern you need to carefully plan and coordinate the rollout of changes to each of the services.
• Deploying a microservices‑based application is also much more complex. That’s many more moving parts that need to be configured, deployed, scaled, and monitored.

Operational Concerns

Independent services alone cannot form a system. For the true success of microservices architecture, significant investments are required to handle cross-system concerns like:

• Service replication — a mechanism by which services can easily scale based upon metadata
• Service registration and discovery — a mechanism to enables service lookup and finds the endpoint for each service
• Service monitoring and logging — a mechanism to aggregate logs from different microservices and provide a consistent reporting
• Resiliency — a mechanism for services to automatically take corrective actions during failures
• DevOps — a mechanism for handling continuous integration and deployment (CI and CD)
• API gateway — a mechanism for providing an entry point for clients

Summary

Building complex applications is inherently difficult. A Monolithic architecture only makes sense for simple, lightweight applications. You will end up in a world of pain if you use it for complex applications. The Microservices architecture pattern is the better choice for complex, evolving applications despite the drawbacks and implementation challenges.