Benefits of Microservices

Overall Agility

Agile methodology was created to increase the iterations in Software Development so that one can seek early feedback, fail-fast if necessary and deliver to the market faster than the competitor. This led to the creation of Continuous Integration (CI) wherein the various components built in many iterations by multiple teams are integrated, tested and packaged early in the lifecycle. Then there was a need to do frequent releases of the artifacts, leading to Continuous Delivery (CD) indicating that the artifacts built are tested and stable and hence ready to be deployed to production. This led to chaos as the collaboration between the Development and Operations teams was not streamlined or, more often, completely missing. Remember the famous quote of every development team “it always works in our environment”. So, it was essential to bridge this gap between the Development and Operations teams, leading to DevOps strategy with a set of streamlined processes, frameworks and tools. Remember Agile Methodology’s primary focus was to increase the development iterations and shorten release cycles, but the applications built in a monolith style never complimented this agility. This was the trigger for the creation of Microservices Architecture. Microservices is an architectural phase of Agile progression and considered to be the key phase in the Agile delivery lifecycle to achieve Agility and Continuous Delivery.

Improved Collaboration

Traditionally the teams are separated based on the technical competency such as Business Analysts, Developers, QAs, DBAs and Ops. And when the teams are built that way, they converse technically and not in a domain specific language. This practice does not provide agility as the teams work in silos thus breaking the collaboration. Agile methodology, to an extent addressed this problem by focusing on delivering the project in smaller chunks through multiple iterations but it never empowered the teams with autonomy and responsibilities that could allow the teams to participate in business-driven decisions.

By contrast, the microservices approach emphasizes building the application in smaller units based on business capabilities or domains. This means the teams will now start conversing in a domain specific language, and can collaborate with other teams to achieve the objectives of the Organization. This is transformational as it provides autonomy and improves collaboration within the teams during decision making but comes at the cost of a culture shift that an Organization will have to invest in. See the Challenges section for detailed information on this.

For example, Amazon and Netflix were the pioneers in this when they restructured their teams to align with business capabilities. Each team owned a small part of a system, and managed the whole life-cycle of the services built. Jeff Bezos of Amazon, famously coined the term for this restructuring exercise as “two pizza” teams.

Lightweight but Self-Contained

Microservices are typically lightweight, and each microservice contains all its dependencies; thus the lifecycle and state of various components of a microservice are self-managed. This eliminates the external dependencies and makes microservice self-contained; therefore it is faster and easier to spin up a new microservice.

Polyglot in Nature / Technology Agnostic

When microservices are decomposed based on the domain or functionality, you see every possibility of developing microservices using different technology stacks and persistence types.

For example., a “One Time Password” generation service can use Redis which is a NoSQL based in-memory database to store the temporary password and provide just one RESTful endpoint built on the node.js platform to verify the OTP when the user authenticates. Similarly, another microservice called “email sender” can be built as an asynchronous system using Spring Boot and the Kafka messaging system.

Technology Evolution

As said above, microservices can be polyglot (different programming stack, nosql/sql databases, etc.) in nature which eliminates the long-term commitment to the technology stack that monoliths enforces upon the system. When you develop new service, or re-engineer an existing service, you have the option to consider the latest technology stack that helps to address specific needs. This in the long-run helps to eliminate technical debt that one would have otherwise accumulated over time.

Auto Scalability

Microservice architectures are by default distributed architectures in nature. Distributed architecture provides situational-based and infinite scalability options and hence it is easier to scale-in or scale-out the necessary microservices.

Fault-Tolerant / Stability

In distributed architectures, there is no single point of failure. Therefore, microservices are fault tolerant by default. If one microservice goes down due to memory leak then it doesn’t affect the entire system as it would affect a system based on a monolith architecture.

Resiliency

Only a handful of features are impacted when a given microservice goes down, with no impact on the rest of the whole application/system.