The Microservices Paradox

On Sept. 12, I had the privilege of participating in a panel discussion at API World on the topic of microservices. When I first got the invitation to be a panel member, I was ambivalent — to me, a discussion about microservices is bound to head into the same murky swamp that discussions about DevOps and Agile do. There seems to be a general understanding of all those concepts but no science around how to implement and sustain them.

But hey, that’s the fun of it, right? And when I realized that I would be sharing the stage with a varied but brilliant set of people, it was too intriguing to pass up. Along with me, the panel consisted of Ronnie Mitra from CA’s API Academy; Josh McKenty from Pivotal Software and Cloud Foundry; Jakub Nesetril from Apiary; and Medhi Medjaoui from Oauth.io and APIDays.

Audience Profile

The audience for this session was split between Product Management, Operations and Development, for the most part. Some were well on their way in the microservices journey, while others were just exploring the concept.

What is the Definition of ‘Microservices’?

Mehdi kicked off the discussion by asking the most awkward question of all: what is your definition of microservices? This is, of course, a trick question because the definitions are varied and nuanced.

As with any good panel, we all had a different perspective based on our experiences and careers. We did generally agree that there is both a business and technical aspect to microservices.

It’s a business term!

Generally, we saw microservices as being driven by business needs:

o Rapid Delivery
Being competitive in most marketplaces these days means turning around new features or services rapidly and with little overhead. If you are running a monolithic application or one with large interwoven components, feature changes can be risky and complicated. Deploying large-scale applications can also impact features and components that haven’t been changed because everything has to be deployed together.

With their narrow focus and separate data stores, microservices can be created and deployed independently and quickly. This allows new business requirements to be met in a matter of weeks or days rather than months or (ack!) years.

o Low Maintenance
Many advocates for microservices actually advocate for ‘no’ maintenance. Their theory is that if you need to modify a microservice, you should actually just throw it away and build a new one. The intent is to prevent a microservice from developing overhead — let the service meet a need then build a new one when the needs change.

Whether you adhere to that line of thought or not, the reality is that microservices are intended to be as low maintenance as possible. This allows teams to remain dexterous and available when new or evolving business requirements come in.

“Increase your rate of change and all the other stuff will follow.” — Ronnie Mitra, Director of API Design at CA’s API Academy, panel member

It’s a technical term!

As with many such concepts, microservices is also a technical implementation that serves the business need. The panel agreed that there are some basic technical considerations for creating microservices, including:

o Boundaries
This is key to building successful and easily-managed microservices. The boundaries serve as the limiting factor that prevents a microservice from becoming a macro service. As with any other architectural construct, you have to understand the whole application context then determine where the lines can be drawn for individual microservices.

A microservice’s boundaries can be drawn along task lines (i.e., this microservice does this one function and no other) or along data lines (i.e., this microservice accesses and manages this chunk of data and no other) or along any other lines that make sense in your application’s context. When you clearly define the boundaries, you can more easily determine when and where you need to add more services. But be careful of Conway’s Law! The panel continued to reference this sand trap because it is very easy to design your microservices based on your team structures rather than the other way around.

o Continuous Deployment
The whole point of a microservice is to allow rapid development. If you are not combining microservices with continuous deployment, you’ve lost a majority of the benefit. Having the right process and tools in place for Continuous Integration/Continuous Deployment (CICD) is an essential technical consideration for microservices.

“Continuous delivery is essential in order to speed up the ability to introduce APIs and there is a lot of tooling available on both sides.” — Jakub Nesetril, Founder and CEO of Apiary, panel member

No, it’s an organizational term!

In the end, whether the panel members were leaning toward the term being a technical or business term, we all agreed that it requires organizational considerations. At a minimum, an organization adopting a microservices lifestyle needs to include:

o Small discrete teams
These can be ephemeral in nature — forming to build a service then rearranging to build a different service. But we all agreed that to be truly effective, teams need to follow the “two pizza” rule. Otherwise, you compromise both speed and focus.

o DevOps mentality
Like microservices, DevOps can be implemented for various reasons and in various ways. But the philosophy behind it that breaks down the barriers between functions is essential to delivering high quality and manageable microservices. “You build it, you own it” is a key principle.

o Flexibility
One of the inherent joys of microservices is that they are so discrete, they can stand on their own. This means that each team can adopt the framework and language they like without having to worry about corporate standards. Because they are also supposed to live a short lifespan with little to no requirement for maintenance, you don’t have to worry about handing the code off to a maintenance team.

“Microservices is more of a philosophy, like REST or other architectural principles… It’s a business, technical, and cultural thing.” — Mehdi Medjaoui, Co-founder of Oauth.io, panel moderator

Three Key Takeaways from the Panel Discussion

There are a few key takeaways from the discussion that emphasize the paradoxical nature of microservice implementation.

Monoliths make the best starting point

As an industry, we tend to use ‘monolith’ as a negative description. However, in many cases, an application should be a monolith. If the application is discrete enough and clean enough, monolithic architecture is fine. But when you find you are running into difficulties with rapid change and continuous deployment, it might be time to break into microservices.

“The big takeaway is use continuous delivery as your measure for organizational smell.“ — Mike Amundsen, Director of API Architecture at API Academy, audience member

The best microservice architectures derive from monoliths that become too unwieldy to manage. Having the initial monolith helps you understand your microservice boundaries better as well.

Smaller services result in simplicity and complexity at the same time

When you build small discrete services, those individual services can be very simple to describe, build and maintain. But the overall complexity of a broader infrastructure comprised of small services can become costly by itself. Consider some of the pitfalls before you implement microservices enterprise-wide:

o Many communication paths
Each microservice has a communication path to other microservices, which makes your overall system a complex network of conversations.

o Multiple failure points
As you consider all of those conversations, imagine the tangle of failure points if any of those conversations fail. Troubleshooting a microservices system can be cumbersome and difficult without robust monitoring and notifications in place.

o Multiple versions can co-exist
In fact, for Josh McKenty, one of the panel members, this is a key requirement for microservices. If you can run multiple versions of the same microservice in production at the same time, you have succeeded, according to Josh (who has extensive experience in this area).

Microservices can lead to proliferation, which may lead to better things

A panel that always agrees is a boring panel, right? One of the areas where we disagreed was the tendency for enterprise silo organizations to proliferate services. Well, we agreed that they proliferate, but we disagreed about whether this was a good thing. In one sense, a proliferation of services that do the same thing is wasted work and duplication of effort; in another sense, the culture that allows freedom to build what is required without constraints can lead to massive innovation.

In Summary

While opinions and perspectives may differ about microservices, it’s clear that they solve specific problems and need to be implemented across business, technical and organizational boundaries. If your rate of change is high and fast deployment is your goal, microservices may be your answer — just be prepared to invest in them cross-functionally.

DISCLOSURE: The opinions in this blog are the opinions of the authors/interviewees and not necessarily the opinions of Capital One. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This blog post is © 2016 Capital One.