Micro-Sprawl: How To Manage the Coming Microservices Explosion?

Micro-services are all the rage, but one downside is that they replace existing applications with a loosely-coupled collection of dozens, or possibly hundreds, of micro-services.
In an enterprise with hundreds, sometimes thousands, of applications, the prospect of managing several thousand loosely-coupled micro-services sounds like an operational nightmare, but a startup company named Shippable believes they have the solution.

For those not already strapped firmly to the bandwagon currently careening through large piles of investor money, let me have a stab at explaining what all the excitement is about.

Some years ago, a few bright people had the idea of using virtual machines on the x86 chip architecture, though virtual machines had been around since at least the 1970s, mostly on VMware is built on the concept. It helped people to more efficiently use physical resources by sharing them between multiple logical workloads. You could load multiple versions of Windows (or Linux, or whatever x86 compatible OS you chose) on the same physical server instead of having to buy a new box every time you wanted a new copy of the operating system.

This made deploying a new operating system instance much faster, because it was just software instead of physically moving hardware around, and the efficiency gains in both operational and capital expenses were substantial. It saved a lot of people a lot of money, and quite a bit of it made its way to VMware.

There was much rejoicing.

The thing about operating systems, particularly ones that are tied pretty tightly to a graphical user interface (GUI), is that they're, well, big. Making the windows shiny and transparent takes quite a bit of code, and deploying that code takes up a lot of room.

Around 2013, some different bright people pondered “what if we shared this base operating system stuff between multiple environments, just like virtual machines do with the physical hardware?” which again wasn't a new idea, but it had a new name–containers–and so people became excited about it. Enter Docker.

The core principle with containers is that instead of deploying an operating system that gets patched and upgraded over time, containers are throw-away items. You don't upgrade them, you just throw them away and replace them with a newer, shinier version. A bit like iPhones.

Each container is small, and the ideal is to have one application, or service, per container. Unlike a virtual machine, which could be running multiple applications at once, a container shouldn't. In fact, with modern applications, the goal is to have each container be part of a micro-service, a small piece of code that does just one thing. That one thing could be handling when you click ‘like' on an app, or fetching the latest price for a product, or telling you what time it is.

Existing application design, using a monolithic collection of functions, is thus replaced by a cloud-native design that consists of a collection of micro-services, each running in a container (or several for scale), which are deployed in virtual machines running in The Cloud. To upgrade what happens when you click ‘like' or ‘get-price', you don't upgrade the application, you just replace the specific micro-service that provides the functionality by destroying its containers and re-deploying the new ones.

But how to manage this proliferation of containers and their associated micro-services? Even a relatively simple application could have dozens of micro-services, and large enterprise applications could contain hundreds.

Shippable uses a combination of a configuration management database style concept and a development pipeline integration platform to handle the complexity.

“If your application knows which server it's running on, you're probably not using modern application development methods,” says Shippable CEO Avi Cavale. Instead, Cavale sees applications being assembled in production from a set of components built in assembly-line fashion.

As developers build or update components, they run through a series of testing and verification steps before being deployed into production, replacing the existing parts with new, upgraded functionality, all managed by Shippable. “You start seeing the benefits of the platform as you move into micro-services and have to start building thirty or fifty pipelines to manage your application,” he says.

Shippable is clearly designed for the new world of developer-led, scale-out applications, where infrastructure is an abstraction of cloud services, and the application functionality is what matters. The power of disposable, composable parts comes with an increase in complexity that requires new tools to help manage it. Just as we moved from simple code revision systems to continuous integration and distributed version control as state-of-the-art, Shippable believes it is ready for the new, container based future.

All that remains to be seen is if developers agree and follow Shippable's lead.

This article first appeared in Forbes.com here.