Delivering business value with Microservices Architecture

Is it time to look for a successor to Microservices Architecture? If recent emergence of Macro and Mini services is any indication, we may soon have an acceptable alternative to developing applications in a cloud-native world. A nascent concept in 2005, microservices propelled to the peak of inflated expectations over the last decade. In recent months, the industry experts and authors of books on the very subject are sharing alternate views. It is time to adjust how we look at microservices as the only way to architect software. A couple of interesting questions arise: when should a service be decomposed into a separate deployable unit, a key decision that is difficult to rollback after initial implementation. Second, how can the expected business value be quantified. Predominantly, expert judgement is relied upon to answer both of these questions. However, a documented list of decision factors can serve as heuristics to create a framework which is consistent, repetitable and devoid of emotions.

Image credit (see usage rights @): File:Gartner Hype Cycle.svg

Framework for evaluating Microservices use-cases:

Scaling factor. Consider a typical e-commerce application which starts out with a browse experience, proceeds to a shopping cart page before taking the customer to the final checkout. Only a small fraction of browsing converts to a sale because a subset of customers abandon the process at each step. With help of analytics tools, we can measure this sales conversion rate for our application. To implement this shopping experience, we can decompose the system into micro-services such as Catalog, Shopping Cart, Payment and Order. Assuming a conversion rate of 10%, we know that Catalog service will have 10x more usage than Order Service. We can use this data to set a unique scaling factor for each microservice depending on its usage. If this was a monolith system, we would have to scale the entire system as the number of customers grows.

Deployment frequency Microservices allow the ability to iterate and deploy one service much more frequently than others. Since an individual microservice is much finer-grained than the overall system, the testing scope becomes narrower. The shortening of testing effort means we can deploy more often and achieve continuous delivery objectives easily.

Reduced Blast Radius As we accelerate the deployment rate with microservices, the risk that a new deployment will break something in production also increases. The extent to which a fault in the system can render the system unuseable is called the blast radius. Microservices have a much shorter blast radius than monoliths. A memory leak in a microservice will only impact a subset of the system whereas the same leak will impact the entire system if left unchecked.

Cognitive load Web applications can grow to a million SLOC or more. The size of the system starts to become an impediment for the team to deliver software quickly and easily. New developers joining the team take longer to onboard as they must setup, learn and test the entire system locally on their laptops. With microservices architecture in place, the developer can pick up a single microservice and get the local environment setup finished much faster.

Business alignment With online privacy expectations changing, governments have responded with privacy laws such as GDPR and CCPA. Some of these laws require the service providers to store customer data locally within a geographical boundary. For e-commerce, the products data might be public but the customer profile and order history data might have stringent privacy requirements. Microservices ease the challenge of compliance since each one has its own database and contains data specific to its functionality.

Getting ready for adoption

Software engineering discipline If microservices are like building blocks, the blocks must lend themselves to be composed in several ways to create new structures. The challenge is to design the block in such a way that it is composable and does not enforce unnecessary assumptions on the clients. This requires a good sense of what future use cases might require. Without a thoughtful analysis, the number of microservices starts to grow substantially with each team creating a set for their own use cases.

Reliability engineeringWhen each service runs on a separate host, they communicate over the network to process the business transaction. We cannot assume the network will always be reliable, homogenous or have zero latency. If a microservice makes a call to another service, it must be coded to ensure that it can handle unexpected network latency, an increase in service response time due to load and an unavailability due to an ongoing deployment. Software libraries such as Hysterix provide capabilities to implement circuit breakers, re-tries, graceful degradation and other capabilities to solve the challenges brought forth by microservice implementations.

Chaos engineering - With more moving parts in a microservices implementation, failure is more likely to happen. Inducing failure purposefully and studying the system behavior under failure conditions helps the developers build fault tolerance in the system. Netflix Simian Army and Gremlin can help automate chaos engineering tests.

DevOps maturity - With more services to deploy, any manual step in software deployment becomes a bottleneck. High degree of automation becomes a key capability for building, scanning and packaging build artifacts. SOX controls for recording changes to systems must be automated as well. For the promise of continuous deployment to be fulfilled, a robust DevOps toolchain becomes a necessity.

Return on investment

Cloud cost optimization - Vertical Scaling Over provisioned resources are major contributors to a typical cloud usage bill. Cloud providers such as AWS and Azure offer compute services of varying sizes and types. Significant cost savings can be realized by selecting an appropriate size of the instance. Same applies for the type of instance selected. Some of the popular types are memory/cpu optimized, GPU support or instances with SSD disk support. Since microservices are fine grained to solve a specific domain problem, the ability to fine tune a right-sized service is much greater than with a monolith system. For a monolith to scale vertically, you select an instance size based on the needs of the entire system.

Horizontal Scaling Microservices outperform monoliths in the horizontal scaling category as well. For each microservice, you can select a specific maximum auto-scaling factor based on the estimate of maximum concurrent users the service is designed to support. Typically, there will be variance in the number of concurrent users for each microservice. Use this to set a carefully selected maximum limit.

Use-case Fit Some services are only used during certain times of the day and users may be okay with occasional higher than normal latency. For these use cases, scale-to-zero capability with containers can be used as a cost-saving measure. For microservices with laxed uptime SLA and a capacity to pause and restart work, spot instances can deliver significant savings.

Developer productivity Each microservice can use its own programming language and a unique development stack. A front-end developer might decide to use NodeJS to implement a REST API. They can use their existing Javascript knowledge to be productive in an area outside of their expertise. A Java developer might decide to use co-routines to implement a high concurrency solution in GoLang instead of Java concurrency utils. A team can experiment with new technologies on a single non-mission critical microservice thereby reducing the risk involved while gaining confidence and experience.

Speed of innovation Innovation requires rapid experimentation to establish a product-market fit. Innovation is messy, expensive and has dead-ends that must be recovered from quickly. Frequent iteration is involved based on customer feedback from the last build-measure-learn cycle. Microservices enable the speed and agility required by allowing development teams to change one small service at a time.

Each architectural decision has trade-offs. To maximize business value, the team must make design decisions by carefully analyzing benefits in relation to the costs. When each microservice has the same scaling factor, infrastructure needs and is deployed at the same rate, a macro-service or service-based architecture should be considered.

References: