When and Why for Microservices

Thanks to Thomas Leuthard for the base image CC BY 2.0

Microservices are difficult. Don’t believe me? Let’s read a quote from Chris Richardson, the founder of CloudFoundry:

When developing the first version of an application, you often do not have the problems that [the microservices] approach solves. Moreover, using an elaborate, distributed architecture will slow down development. This can be a major problem for startups whose biggest challenge is often how to rapidly evolve the business model and accompanying application.

Oh. Microservices are difficult. So, why is everyone so excited about them? To answer, I’m going to do something controversial: link to a TED talk.

The video in question is from Alex Wissner-Gross. He starts with a question can programs be intelligent?, quotes Djikstra, and hops into a demonstration. His conclusion? Intelligence strongly correlates to cognizance of future opportunities, and one’s ability to keep them open.

The demo runs through a few use cases. Optimal strategies in the game Go,  The demo goodness starts about 6 minutes in:

In short, maximize future freedom of action. This heuristic also answers the when and why questions for microservices.

To prove it, let’s start with Sprott & Wilkes on SOA. Wait, Service Oriented Architecture? SOA is microservices loving parent. The philosophy trickles down:

When the service is abstracted from the implementation it is possible to consider various alternative options for delivery and collaboration models. […] It is entirely realistic to assume that certain services will be acquired from external sources because it is more appropriate to acquire them. For example authentication services, a good example of third party commodity services that can deliver a superior service because of specialization, and the benefits of using a trusted external agency to improve authentication.

In other words, service orientation maximizes future freedom of action.

For microservices to make sense, they also need to maximize freedom of action. So, do they? In Kent Beck’s words, “It depends”.

[tweet id=596007846887628801]

Other’s have said it better, but it’s worth repeating: microservices are a trade of one kind of complexity, for another. Mo’ services, mo’ problems. More moving parts, more opportunities for failure. Naturally, the ops work is a bit different, too.

But, with those downsides comes the freedom to…

• Work in whatever language you desire. Polyglots, rejoice!
• Introduce new team members and make them productive, quick. The upsides of modularity.
• Develop and deploy independently.

To loop this all together, microservices are difficult. One of the hardest parts is figuring out when it’s intelligent to make the switch. Factors like product, team size, code complexity, etc, means there’s no simple answer for when. Instead of agonizing over why’s and why-not’s, try the heuristic:

“Will microservices maximize my future freedom of action?”

If so, go for it!