Who’s Pulling the Strings - What is Container Orchestration?
We’ve been talking quite a lot recently about the take-up of orchestration systems in production like Docker Swarm, Google Kubernetes, Mesosphere Mesos, Amazon ECS and Hashicorp Nomad. We think there’s a pretty clear path that takes teams from adopting continuous delivery through to adopting orchestration systems too — because it helps to have something pulling the strings.
Microservices Assemble
Breaking architectures down into decoupled microservices allows organisations to split responsibilities cleanly between groups, each responsible for its own microservice. This, and Conway’s law linking software & team structure, have been extensively written about and discussed by lots of clever people in the DevOps community.
We’re increasingly seeing technical organisations broken into such teams, each responsible for shipping a microservice (or perhaps a few different microservices) on a frequent basis. They may be canary testing, running blue-green deployments, and running split tests independently on their own services.
This gives us a complex scenario with multiple teams shipping multiple versions of code into the same cluster of compute resources. With continuous delivery (or perhaps more specifically, with continuous deployment) these teams could be shipping code to production several times per day, so we need tools that allow multiple changes across a system to be managed more or less simultaneously. Add high availability into the mix for an extra dash of complexity and potential for confusion!
Secret Identities
Traditionally, we deploy known pieces of code to known servers. Many companies still do this even when they have moved to microservices and/or containers. This can have the advantage that a given team has a known set of server resources to work with, and a one-to-one relationship between container and VM is still pretty common, at least if our anecdotal discussions are anything to go by.
The downside of this approach is under-utilization, on a vast scale. We’ve spoken with teams who tell us they’d be surprised if they’re using as much as 5% of the capacity they’re paying for, as the trade-off for a simple mapping between code and servers.
Orchestration systems bring with them the promise of improving this situation dramatically by managing a cluster of servers together.
Trust a Shield
Orchestration engines potentially offer the ability to manage different versions of code running across the deployment, and allow parts of the deployment to be modified independently where necessary. But using an orchestrator requires a significant shift in mindset.
In an orchestrated system, you no longer have direct control over where your applications are running within your compute cluster. You’re letting a piece of software automate when and where each of your services will run. And that takes a certain leap of faith, especially given how new and in flux these tools are.
Arguably, this is a similar shift in thinking as was required for companies to move their processing into the (public) cloud.
It’s a Dangerous World
We think there are three factors that will lead to a big uptake in orchestration over the next few years:
As orchestration systems mature, developers and operations people will get more and more comfortable with the idea that they don’t need to determine exactly where their code is running, just as they got comfortable with the idea that they didn’t need physical access to their servers.
While compute gets ever cheaper it’s not free, and when the message filters through to CFOs that technical teams are paying for a vast amount of under-utilized compute capacity, they will start cutting budgets.
Requirements across the whole compute cluster will get more and more complex, as monoliths are broken into microservices and more teams adopt continuous delivery. Orchestration systems will make it possible to manage these complex requirements.
And as orchestration takes off we’ll need a whole new set of tools to manage, monitor, secure and scale deployments in this new world.
What do you think? Are you adopting microservices but not orchestration?
Or are you adopting orchestration and uncovering issues that you hadn’t anticipated?
Do you care about under-utilization?
This is a multi-faceted conversation and we’d love to hear your views!
by Liz Rice & Anne Currie
Liz Rice is the CEO & Anne Currie is the CTO of Microscaling Systems, home of MicroBadger. We advocate more effective container use with metadata. Let’s organise! At http://microbadger.com & label-schema.org
If you liked this article, please hit the Recommend button below so that others might be more likely to find it. And if you’re using containers, you should definitely check out MicroBadger to explore image metadata.
Follow Microscaling Systems on Twitter
