In an industry where buzzwords thrive on the periphery of the field of action before they transform into action, it’s imperative that we take a closer look at any emergent phenomenon before placing big bets on it. One such proposition is the Microservices architecture.
From the expert to the enthusiast, everyone talks of the Internet of Things (IoT). Even those who merely discussed things on the internet are now thinking of the world in IoT terms. But few from the business world are aware of one architecture that would be integral to most radical transformations in the tech world going forward. Although it’s gained prominence more in the context of IoT, its indisputable value prop soars high on its own merit. The Amazons and the Netflixes of the world have reaped rich rewards of scale and scope, thanks to the incredible support of Microservices that extends to the diverse worlds of web, mobile and other devices and comes with the promise of cost-effectiveness, rapid innovation, risk mitigation, and high flexibility. Closer home, the Wipros, Infosyses, Cognizants and TCSes are flaunting their Microservices philosophies in some depth. Industry body Nasscom hosted a focused workshop on Microservices Architecture last year for the benefit of Senior Developers, Solution Architects, Technical Architects and Tech managers.
It’s a good idea to be aware of the specifics of this architecture even for business stakeholders as it would only help spot the Next-gen winners from the software universe placing faith on this architecture before placing long term bets on their perceived propositions.
So, what are Microservices?
To answer that, we must first establish the litmus test of Enterprise Technology. It is the supreme quality of Change-readiness. In modern-day business, change is constant and instant and tech teams of established setups also need to be in start-up mode. Markets are getting wider, scaling out is the new norm, so is the adoption of emerging technology, which is no longer a matter of choice.
On the other hand, shrinking Time-to-Market calls for rapid development in distributed environments backed by continuous deployment.
Given that preface, let’s turn to the core value prop of Microservices which is its Change-friendliness. Their contexts and boundaries are defined in terms of distinct business capabilities.
They are right-sized, invariably small (think scope of service, not lines of code)
They are independently deployable in line with business needs: for instance, a new feature or a bug fix would be deployed immediately as also tracked for performance and behaviour.
Deployment decisions are choreographed in collaboration with service owners eliminating the need for orchestration across multiple teams which is invariably arduous. Service owners are free to choose the technologies and persistence mechanisms for building and operating individual services with consensus agreement on cross team parameters like log aggregation, monitoring and error-diagnosis. Services collaborate with each other using technology-agnostic network calls. They offer a cost-effective and low-risk test bed for evaluating the effectiveness of new technologies in production environments.
One may be tempted to ask, what does all that mean for business?
A lot really! Among other things, scaling of operations now becomes ‘on-demand’ and cost-effective, exactly in line with business needs. Independent deployment, with quick failure isolation and rollbacks, ensures quick value delivery to the market. Ready-to-deploy business capabilities make customer engagement more holistic across different channels.
A lot really! Among other things, scaling of operations now becomes ‘on-demand’ and cost-effective, exactly in line with business needs. Independent deployment, with quick failure isolation and rollbacks, ensures quick value delivery to the market. Ready-to-deploy business capabilities make customer engagement more holistic across different channels.
Smaller codebase means significantly lower risk and cost of replacing or rewiring software (vis-à-vis the typical monolith compromise of coping with core modules running on redundant technologies)
Microservices: The deal
How they deal with change in business requirements?
Unlike in monoliths, responsibilities are decomposed in respective services defined by business capabilities, hence change affects only the given module, data segments are API-encapsulated while service overlaps are mapped through higher-order services or hypermedia.
How they deal with business capability enhancements or modifications?
Bounded contexts enable independent deployment of the impacted service(s) without disturbing business capabilities residing in other services. This eliminates the need for time-consuming and costly regression tests of the monolith universe.
How they deal with situations where business abstractions are dependent on low-level services outside their bounded contexts?
‘API gateway’ inverts the dependencies between clients and microservices in this scenario. The secondary abstraction is declared by the high-level abstraction within its service interface and is implemented by the dependant collaborating services through several means - reducing network chattiness, performing protocol translations, concurrently aggregating service responses and transforming service responses in specific end-user formats.
A closer look at API gateways
In the microservice universe, a client’s RESTful HTTP request to individual services can be a painful user experience given the plethora of requests to different services.
Enter the API gateway which tailors APIs to client’s network capabilities.
For instance, a desktop client may make multiple calls while mobile client would make a single request. The API gateway will proxy finely-grained desktop requests to corresponding services while handling coarse-grained mobile requests by aggregating multiple service call results.
Outcome: optimized communication between clients and applications while encapsulation of microservice details. API Gateways ease the evolution of microservices: whether two microservices merge or one is partitioned into two, updation would be made at the API gateway-level, the clients on the other side of the gateway would be impervious to the change.
Why Microservices call for Continuous Deployment?
Microservices are highly amenable to change and continuous deployment makes it rapid and reliable. Microservices make deployment easier, so that it becomes faster and frequent. Faster deployment ensures faster feedback from the market.
Faster feedback ensures timely improvements – making it more responsive and secure.
Why Microservices and Polyglot Persistence go together?
The microservice approach of multiple teams managing discrete services naturally implies database capability within each service, else coupling at the data level would defeat the very purpose of autonomy.
Using multiple data stores invites eventual consistency which is a known compromise in most businesses. Even relational databases settle for eventual consistency when data is sent to or read from remote systems like value chain databases.
Like how RDBMS uses event streams for constructing reliable views, the microservice world uses event sourcing for triggering service updates from ‘events to log’. The trade-off in favour of high availability becomes even more acceptable when compared to the Multi-Version Concurrency Control issues of the relational world.
Embracing Microservices: No cookbook in the kitchen
Every organization is different – you can’t mirror success stories, or even failures for that matter. How to ensure whether microservices are fit for purpose. Microservices demand a paradigm shift - Cultural, Structural and Functional.
Compelling benefits come bundled with significant complexities.
The Adoption challenge
For Greenfield projects
When businesses need to evolve rapidly, the monolith environment may work best for managing small number of applications to deliver the firm’s competitive edge. Microservices however would be helpful to startups in building a minimum viable product.
For Brownfield projects
When established businesses need to scale rapidly across large, complex applications, microservices becomes fit for purpose but given the tangled dependencies between applications, an incremental approach to the evolution is highly advisable:
Getting in microservice mode calls for:
Defining core business capabilities for decomposition into services
Dissecting services in terms of business, processes, constraints, channels and data behaviours to be able to ‘group those things that change for the same reason’
Identifying capabilities to bridge skill gaps of technical team on emerging technologies and best practices
Questions that demand credible answers… a partial list
How does one move forward in the absence of standards?
How does one form the Microservice team – domain experts, technical architects, emerging tech champions, networking wizards…How does one bridge the skill gap?
How does one choose technologies, techniques, protocols, frameworks, and tools?
How does one approach design, development and deployment?
How does one identify services?
How does one define service boundaries?
How does one chip off services from the monolith structure?
Why and when does one split services, merge them, or create new services?
How does one deal with service interfaces?
Is there a way to ensure a uniform way to call services?
How does one ensure the quality of code bases given the fact that small doesn’t automatically guarantee quality?
How does one build coherence and reusability across different components?
How does one tackle the accidents post the ‘first version’ release?
How does one avoid versioning nightmares?
How does one adopt a culture of individual deployment s before evolving into continuous deployment mode: given the monolith legacy of single unit deployments and regression tests?
Summing up
Microservices are an evolutionary phenomenon, not a ready-to-deploy solution. They will ensure measurable value to an organization only if they are Fit for Purpose – irrespective of whether the project is Greenfield or Brownfield. Microservices Vs. Monolith is not a black and white David Vs. Goliath scenario. Both have distinct value props. Precisely why Microservice trade-offs should be guided by respective trade realities, not merely by the experiences of other organizations.