Much abused Microservices

When an emerging pattern gains lot of attention it is also prone to much abuse. . The Micro Services key word is one such. I have been wanting to write on Micro Services for a while now and haven’t been finding time. . , so without further ado

Definitions: [There is no “one” industry accepted definition]

“Microservices - also known as the Microservice architecture - is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities” – Microservices.io

“Microservices: A Microservice is a physically independent and tightly scoped application component that is independently deployable and scalable. It has a single responsibility and implements an individual feature. If a Microservice manages persistent state, it has exclusive rights to access the data store. To enable the greatest agility, it should be as decoupled as possible and communicate with other components through interface contracts that include both APIs and asynchronous events.” – Gartner

“Microservices architecture (MSA) is an approach for building and delivering service-oriented applications with three primary objectives: agility of delivery, flexibility of deployment and precision of scalability. A supplemental benefit is the ability to choose and update implementation technology on a per-service basis.” – Gartner

“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. 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.” – Martin Fowler.com

“Microservice applications are composed of small, independently versioned, and scalable customer-focused services that communicate with each other over standard protocols with well-defined interfaces” – Microsoft.com

“Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams.” – AWS

Highlighted are some of the important features that define Microservices.

In my view Microservices and SOA vary in the following service characteristic areas:

1. SOA encourages “Sharing architecture”, while Microservice principle is with sharp contrast to this, “Share Nothing architecture”. As an example, SOA encourages business functionality reuse and Microservice principle is bounded context.
2. SOA encourages common governance, languages, tools, patterns and standards, while Microservices encourages “build it like you own it” theory, with freedom of choice in language, deployments, release cycles, etc.

Implementing Microservices is not a trivial undertaking, it brings in disruptive change in the legacy ecosystems.

@DanielStori depicts the complexity involved in the architecture.

Characteristics of Microservice:

[Core]: A must have characteristic

• Single responsibility: Microservice will implement single functional responsibility. Single-purpose
• Module independence
• Loose Coupling
• Self-Contained modules
• Deployment Independence
• Manage related data and decentralized data management
• Organized around Business Capabilities
•  [Non-Core]: A good to have characteristic
• API’s published externally via an API gateway.
• Language independence
• Componentization via Services
• Infrastructure Automation
• Smart endpoints and dumb pipes
• Decentralized Governance
• Design for failure

Who uses this pattern?

• Gartner suggests Dropbox, GE, Goldman Sachs, Google, Netflix, ebay, Airbnb, Twitter, Disney, are on their Microservices journey. Isn’t that justification enough?

Conclusion:

• Where short cuts are taken to leverage a shared persistence layer, where clear domain segregation isn’t created, or where Micro service is a LARGE application this pattern clearly fails.
• Microservice aligns to a share nothing (as little as possible) architecture. Business cares about (surprise!) “Business”, Microservices core principle is much in alignment to the needs of the same, modeling services around the business domain is mandatory.
• Microservice thrives on the “You build it you run it” ideology. Large enterprise which has separate infrastructure teams, which has separate teams managing the CI/CD pipelines find this challenging to implement.
• Smaller, decoupled, self-contained, release plan isolated to the team, independently deployable microservices leads to easier communication, maintenance and thus effectively agile. This absolutely applies to the persistence layer as well.
• Microserivice pattern calls for implementation of a gateway, where cross-cutting concerns such as authentication, non-business related routing, SSL termination needs to be handled. Domain Knowledge should NOT be implemented in the gateway. Shying away from gateway implementations eventually hinders the Microservices implementation.

Cloud implementation is already seeing a surge in serverless, app less deployments, Microservices leads well to these architecture patterns.