From Silos to Services: Cloud Computing for the Enterprise

Mar 10 2017   2:41PM GMT

The Evolution of Container Platforms

Brian Gracely Brian Gracely Profile: Brian Gracely

Cloud Foundry
Google Cloud

I get asked all the time about the differences and benefits of the various container technologies, especially on the orchestration side – often called the “container platform”. At some point, it’s better to write down the answer than to keep repeating it, so here goes.


Even though most people only think about containers in the context of Docker (circa 2014), containers and container platforms have been around for quite a while. But lets start with the modern-day platforms that most people know – Heroku, Google AppEngine, Cloud Foundry, OpenShift, AWS Beanstalk, dotCloud.

The Early PaaS Days

Around 2009-2011, most of these platforms came into the market with the goal of making is easy for application developers to “just push code into production”. By most definitions, these platforms were known as Platform-as-a-Service (PaaS). To some extent, these platforms did a great job of making things simple for developers, by hiding all the complexity of IaaS and associated services (LBaaS, DBaaS, Authentication, etc). And under the covers, most of these platforms used some variant of Linux containers to isolate and run the developer’s applications. These were the original homegrown/DIY container schedulers/orchestrators.

But these early platforms also had some limitations:

  • Some of them only ran in a specific cloud environment
  • Some of them only supported 1 or 2 languages
  • Some of them were open-source, while others were various levels of proprietary software.
  • Most of the open-source platforms didn’t have large community support.

So in the 2011-2013 timeframe, there were plenty of articles written about the death of PaaS and how it hadn’t gained the massive adoption.

The Open Standards Emerge

And around 2014, two very important things happened. dotCloud went out of business, but it spun out the docker project, simplifying how containers could be used by developers to package their applications. Usage of docker for container packaging took off, and the market now had a pseudo-standard for packaging applications. In addition, Google decided to open source the Kubernetes project and the Mesos project spun out of work at Twitter and UC Berkeley. This provided the market with choices about open source container schedulers/orchestrators that had web-scale DNA built-in. These three activities helped developers know where to focus their energies in building scalable container platforms.

Open Container Platforms Everywhere

As a move into 2016-2017, the market has evolved quite a bit since the early 2009-2011 platforms. Almost every major platform (or public cloud) is now supporting either Kubernetes or Mesos as the scheduler/orchestrator, and the docker project as the format for container image and runtime. The Open Container Initiative (OCI) is further standardizing the container image and runtime formats into standards that are less aligned with a single company. Kubernetes has gained almost 4x the developer support of alternative container schedulers/orchestrators, mostly because of the openness of the community and because it supports many application types with the default scheduler.

Moving Forward…

The future moving forward will continue to accelerate at a rapid pace. With all of the community focus on open frameworks and standards, businesses can feel much more confident in the platform decisions they are making for the next 5-10 years.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: