Should Your Team Be Using Microservice Architectures?

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

Why?

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:

• Microservices architecture improves agility. It facilitates agile DevOps and continuous delivery practices, enabling software engineering teams to increase the cadence at which they can deploy new features.
• Microservices architecture is complex. Given its focus on implementing functionality as a set of distributed components that can be independently developed, tested, deployed, scaled and updated, it requires complex design.
• Microservices will not save you money. It typically costs more to implement than a monolithic architecture.
• Microservices are not the same as APIs. Microservices architecture is one way to implement the functionality behind an API, but it is distinct from the API itself.
• Microservices should not be shared. Independence is key to achieving the agility goals of a microservice architecture.
• Microservices are not the same as containers. Most teams deploy microservices in containers, but you aren’t using microservices architecture unless you also employ design patterns that ensure the independence of the components.

When?

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.”

How?

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.