The overuse of new architectural styles is common within the software industry, and the excitement surrounding microservices is nothing new. According to a recent Gartner report, the number of mentions of “microservices architecture” decreased by 42% between January 2019 and September 2020. The trend is an indicator of a growing disillusionment with microservices architecture.

Some of the best-referenced microservices architectures started with a monolith and transitioned to a microservice architecture knowing the pitfalls and exact requirements, which ideally should be the approach! Below, we’ll explore how to adopt a microservices architectural pattern in a way that attempts to avoid disillusionment. These insights are based on references, personal experience, and stories from peers, most of whom aren’t ready to make the switch yet.

Microservices: Six Well-Known Facts

Referenced from the above Gartner post

Microservices Architecture Improves Agility

Microservices facilitate agile DevOps and continuous delivery practices, enabling software engineering teams to increase the cadence at which they can deploy new features. Some key references are how tech-savvy firms like Netflix and Amazon are investing in DevOps capabilities, enabling them to make releases in seconds, including validations.

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, microservices require a complex design. A good architectural practice of maintaining distributed patterns is one of the key success factors for delivering a microservice program. Each service should have well-defined boundaries concerning functionality, networking, and security.

Microservices Will Not Save You Money

Microservices architecture typically costs more to implement than a monolithic architecture. Monolithic solutions are simple to manage and are cost-effective, yet they miss key objectives of microservices, including modularity, availability, and a scalable design.

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. Breaking down a big mud ball into self-contained services is the key concept behind microservice architecture. Independent services must be integrated using known patterns like API-led architecture.

Microservices Are Not the Same as Containers

Most teams deploy microservices in containers, but you aren’t truly using a microservices architecture unless you also employ design patterns that ensure the independence of the components.

Taking a Step Back: Important Questions to Consider

To start with, it’s logical to answer a certain set of questions against each of the key microservice adoption factors.

DevOps Practices

One must gauge the complexity of microservices architecture and adopt the switch with the right DevOps capabilities. As such, some high-level questions must be addressed first. Although not a holistic list, here are some areas to consider:

• Do you have a mechanism for continuous deployments?
• Are partial deployments an option?
• Is there a uniform mechanism on how releases are managed across a firm?
• Is there a big enough pool of skilled DevOps engineers to manage scale?
• Do you have a mature alerting and failure management capability?

All of the above questions should be addressed as basic checks to understand if they are supported. A firm with immature DevOps should stick to its current setup and focus first on strengthening its DevOps capability.

Code Maintenance and Switching Between the Boundaries

It’s simple to change code in monoliths since, compared to microservices, developers don’t need to worry about making changes to multiple pieces of code. Having a separation of concerns is positive, but it requires a well-thought-out architecture and skillset to support the shift. As such, it’s important to consider:

• How is code change managed?
• Is there a branching strategy in place to manage collaboration within the team?
• Is there a test capability to achieve integration testing?
• How are service boundaries defined for two different pieces of features?

Clearly defining service boundaries and mechanisms is vital before adopting microservices architecture.

Defined Technical Stacks

Since microservices support multiple platforms, one doesn’t have to stick to one specific language or platform. This makes development more flexible.

• Does your firm support multiple platforms?
• Do you have the resources to support key trending skillsets?
• How flexible is your procurement process?

If a firm is aligned to a single platform, programming language, framework, or pattern, this requires a transition and flexibility in bringing in a pool of different platforms and resources.

Reliability Takes Over Availability

One key trade-off with monoliths is that they’re easy to manage — one achieves consistency over availability.

• Does consistency take over availability as a key non-functional requirement?
• How quickly can a deployment failure be fixed?

With monoliths, if anything breaks, everything breaks. The beauty of microservices is that the independence provides better availability. Yet, consistency is more challenging to achieve in a microservices architecture.

Getting Started

As a microservice evangelist, I would rather see the following factors in place before picking microservices as an architectural style.

Set Up Team Structure and Responsibilities

One of the key challenges to adopting microservices is achieving a cultural shift within a firm. Setting up the right team structure and defining their responsibility is key. Some guiding principles that might help here include an API-first strategy, setting up a Center-of-Excellence model, and using professional services.

Adopt Agile and DevOps

Generally, firms with solid agile and DevOps adoptions tend to achieve a working operational model for microservices architectures more easily.

Focus Architectural Practices Around Distributed Computing Patterns

Aligned with the first pointer around a team’s structure, a firm should embrace a strong architectural and engineering practice to help an organization shift to microservices hassle-free. These practices would lay out foundational patterns, tools, governance, and automation to fasten the migration correctly.

Final Thoughts

In short, using an old methodology or architecture is not bad as long as it does the job. It makes sense to switch only after a thorough transformation analysis and validation of any new product or architecture.