The number of mentions of “microservices architecture” plunged 42% between January 2019 and September 2020, according to a recent Gartner social media analytics study. This trend points to growing disillusionment with microservices architecture — a design paradigm that aims to increase agility, deployment flexibility and precise scalability by applying service-oriented architecture and domain-driven design principles to distributed applications (i.e. microservices).
Gartner defines microservice as an application component that is tightly scoped, strongly encapsulated, loosely coupled, independently deployable and independently scalable. Microservices architecture can deliver great benefits, but success is often elusive due to misconceptions about why, when and how to use it.
Download now: Building a Digital Business Technology Platform
“The two issues that trip up software engineering teams are complexity and cultural disruption,” says Anne Thomas, Distinguished VP Analyst, Gartner. “The complexity comes up because microservices must be rigorously independent to attain the architectural benefits, and developers must adopt new patterns and abide by numerous architectural constraints to ensure that the microservices are actually independent. As for the cultural disruption, success depends on changing team structures, improving distributed computing skills and using mature agile and DevOps practices.”
Microservices architecture can improve agility and increase scalability but isn’t right in all circumstances. In fact, it could be absolutely wrong. To improve the likelihood of success, software engineering leaders should, before setting up a microservices platform, answer three essential questions related to microservices architecture: Why, when and how?
Read more: Upskill Software Developers With a Six-Step Talent Development Program
The ideal answer to “why” will result in a business case with a clear return-on-investment benefit. Software engineers most frequently adopt microservices architecture to enable continuous delivery of new application features. In fact, if you aren’t trying to implement a continuous delivery practice, you are better off using a more coarse-grained architectural model — what Gartner calls “Mesh App and Service Architecture” and “miniservices.”
The following core truths about microservices architecture can help leaders avoid misconceptions as they develop a compelling why:
If your software engineering team has already adopted miniservices and agile DevOps and continuous delivery practices, but you still aren’t able to achieve your software engineering cadence goals, then it may be time to adopt a microservices architecture.
Read More: How Digital Immunity Will Improve Your Software Quality
You will need to be selective, however. The architecture is very complex, and it’s inappropriate to use it indiscriminately. Your teams must be pragmatic, not dogmatic, about when they apply the architecture. Not every aspect of a distributed application should be a microservice. It's vital that teams understand when it is appropriate to decompose functionality into separate, independently deployable services rather than maintaining the functionality in a monolith or coarse-grained module. An overarching principle governing decomposition is, “What changes together should stay together.”
To be successful with microservices, software engineering leaders will need to change or emphasize:
- team structures and responsibilities.
- the operating model.
- knowledge and application of distributed computing architecture patterns.
- agile and DevOps adoption.
Download now: Create a Successful API-Based Ecosystem
Team structures should be aligned to the same business domains as the microservices to allow a single, cross-functional team to take responsibility for the full set of business capabilities and work autonomously to deliver to them. This team structure functions best with a product-oriented operating model, whereby engineering teams have the authority to make product decisions and are measured based on their ability to deliver business outcomes. Success requires team members to be skilled in agile and DevOps practices, and have knowledge of a variety of distributed computing architecture patterns.