CoreOS Fest Post-Mortem

Last week I attended
the inaugural CoreOS Fest.
It was a fantastic event which brought together some of the best minds in
distributed systems and celebrated the vibrant open source community CoreOS has
fostered. Given this somewhat seminal moment, I thought it’d be a good
opportunity to share a few observations from the conference and reflect on the
state of industry, so here goes:

The
pace of innovation in enterprise IT has never been faster.
It’s been just over two years since the
initial release of Docker and it’s amazing how quickly an
ecosystem has coalesced around Linux containers and, more broadly, distributed
systems infrastructure. By any metric – contributors and contributions to open
source repos, companies founded and funded, support and partnerships from
incumbent infrastructure vendors, etc. – there is a now a fully-formed,
distributed computing stack and accompanying value chain. This rapid innovation
cycle has compressed release cycles.

got the industry comfortable with a
new vSphere release every year. Then the OpenStack Foundation promised releases
every six months. With Docker, CoreOS and others we’re seeing releases every
three months, if not faster. Customers barely have time to blink. There’s an
even bigger implication for startups competing in this space: you will not
succeed by plugging gaps in the stack – think bigger.

etcd is CoreOS’s crown jewel. While CoreOS itself and Rkt
get a lot of the buzz, I’d argue etcd is the company’s most strategic project.
A quick refresher: etcd is an open source, distributed key-value store that
serves as the backbone and single source of truth of a cluster, coordinating
communication and service discovery between nodes and managing cluster state. etcd
is a critical building block in the distributed systems stack – CloudFoundry
and Kubernetes, for instance, are built on top of etcd – with tentacles that
extend down to physical/virtual infrastructure and up to the application; hence
why it’s so strategic and was featured in so many session at the conference. For
a great primer on etcd check out The New Stack’s write-up here.

We’re
no closer to a standard container spec.
CoreOS continues to bang the Rkt and Appc
drum (“App Container Spec Technical Panel” was the first session after the Day
1 keynote), but it appears that, at least in the short-term, image format
fragmentation is an inevitability. Another quick refresher: a container is
comprised of an image format, a set of files which specifies all the facilities
surrounding a container and includes the bits necessary to execute an
application, and the container runtime which defines and manages processes,
isolation and the environment in which containers are executed.

In December 2014, CoreOS announced Rkt and Appc as a more open – both
technologically and in their development model – alternative to Docker. The
issue however, is the introduction of multiple different image and package
formats introduces ecosystem fragmentation which slows momentum. As the folks
at Red Hat point out, we’re in the early midst of a massive
shift from “the traditional model of a single-instance, monolithic, UNIX user
space in favor of a multi-instance, multi-version environment using containers
and aggregate packaging,” and there are still a lot of moving parts related to
namespaces, security, syscalls, dependencies and more that need to be figured
out. Given all this, it would be much better for the industry if Docker and
CoreOS collaborated on a standardized common spec and image format. That,
however, doesn’t seem to be coming soon.

A
battle is unfolding over cluster management and orchestration.
While a lot has been made of Docker vs.
Rkt, the real competition is over who owns the cluster management and
orchestration layer. You can see why this layer is so strategic in the following
two slides from Google’s Kubernetes Lead Engineer Brendan Burns:

There is
handful of established physical/virtual hardware platforms (AWS, Google
Compute, Microsoft Azure, VMware, OpenStack) which promise to be commoditized
given the inherent (but still theoretical) portability of containers. The role
of cluster managers and orchestrators is to take heterogeneous compute
resources (potentially across different clouds) and present them as a
homogenous, unified compute substrate. You can think of these tools as a
datacenter hypervisor which aggregates all CPUs and then manages resources,
schedules tasks and orchestrates application containers. What this implies is
there is a platform opportunity at the cluster manager / orchestration layer. Today
Mesos (Mesosphere), Kubernetes (Google and CoreOS), Swarm (Docker) and the rest of field
are all playing nice; it’s been more co-opetition and true competition,
particularly between Mesos and Kubernetes. But as these respective projects and
companies mature, you can be certain that lines will be drawn.

But
what about the adoption?
It appears the rapid pace of development and lack of
industry agreement on a standard container spec has come at the expense of the
customer. Maybe it was coincidence, but a majority of folks I spoke with at the
conference who deployed some CoreOS or container technology were just beginning
to experiment. Most often, these tended to by devs and DevOps engineers at mid-stage
startups using these tools in conjunction with a continuous deployment initiative
or in test/QA environments. With that said, for as nascent as these
technologies are, the interest from enterprise buyers is real, and I’m curious
to see how CoreOS’s recently announced Tectonic
offering does in market.