Why adopting microservices is easy in theory, but not reality

Enterprise CTOs have microservices on the mind. After relying for years on monolithic stacks, these IT leaders are trading in their old architectures for independently deployable systems and granular, lightweight services.

Speed and agility are what these CTOs are after, and microservices can deliver—phenomenally, in fact. Microservices can empower companies to leave behind large, slow-moving teams and complex deployments, and to shift to agile, independent teams delivering on their own cadences. The opportunity is huge.

But while adopting microservices is easy in theory, practical reality is often less straightforward. Microservices resources and tools have grown abundant, and CTOs can look to success stories ranging from Netflix’s architecture to the open-source Kubernetes project to Brazilian retailer Magazine Luiza’s digital reinvention. This variety makes it easy to think, “I can do that.”  

This is often where the trouble starts.

What makes a microservices architecture so powerful is also what can make it challenging for large enterprises to adopt: it’s not just another technology but rather an entirely new model that can impact virtually all aspects of business operations.

I’ve seen many companies navigate this transition, and, when it breaks down, it is often for the same reasons. The difficult and surprising parts don’t always involve technology—they often involve cultural and organizational change.

Typically, if a large enterprise is going to implement microservices the right way, it needs to first transform the heart of its organizational culture. This challenging prerequisite can be traced to the fact that microservices are largely designed for (and by) small teams. There’s a certain organizational inertia within larger enterprises that can be at odds with this granular approach.

Microservices: Solving 3 common challenges

1. Speed vs. uniformity The first stumbling block large enterprises frequently run into when adopting microservices is balancing independence versus control. There is a tendency to say, “Do what is right for you,” and to then follow it up by asking, “How many vendors and skills should we manage?” This can happen because large organizations tend to be prescriptive by default. While this is not necessarily a bad thing, it relegates true microservices to the realm of theoretical discussion.

Ultimately, there is no silver bullet. But when in doubt, it is often beneficial to favor speed over uniformity—within bounds. (Do you really need three NoSQL databases? Not likely.) If your microservices are wrapped with clean APIs (see the third point, below), even better—uniformity can always come later. After all, with clean APIs, implementations can change.

2. The dreaded DevOps requirement Another organizational challenge large enterprises often have to overcome is resistance to the additional skills and duties microservices impose on teams—namely, the dreaded DevOps requirement.

If Team A builds a microservice, then it is truly their job to keep it up and running. Unfortunately, DevOps is not an acquired skill. It is not even a learnt skill, so to speak. Unlike programming languages, for instance, DevOps is an “experience” skill—one that only comes with the passage of time.

Two practical design principles can help you prevail: (a) invest in tools that simplify operations, and (b) for some really difficult things (such as managing a NoSQL database like Cassandra), have a separate team that can focus on those skills specifically.

3. Chaotic contracts A third common issue relates to implementation. Devising and holding a contract with downstream teams is very different than walking over to the other team and hashing out the special features they need.

In the first scenario, you have a well-chosen contract (manifested in a well-documented API) that does not strive toward special interests of the “loudest” downstream team. The contract is therefore 1:N, and with N teams, there are O(N) contracts. In the second, you end up getting extensions that are bespoke and brittle. The contract is 1:1, and therefore, with N teams, we get O(N^2) contracts. For an organization with 1,000 services, that is a difference between 1,000 and 1,000,000 interfaces!  

While the theory is perfectly clear (“fewer is better”), organizational dynamics can prevent its application. Enterprises facing this problem should explore an “open to all” approach to APIs.

All APIs and their documentation should be published, and all interactions between microservices should go through a registration process. As long as there are no side contracts, having too many APIs shouldn’t be a problem—periodic pruning based on observation of use can prevent any issues that crop up from getting out of hand. Openness with periodic reviews should be all you need.

Microservices: More than a tech implementation

Organizational challenges aside, microservices are likely here to stay. This architecture reflects the way software should be written. But to do it right, leadership should first understand that adopting microservices involves more than a mere technology implementation. In the end, it is an organizational change that gets down to the very fundamentals of independence and empowerment.