In the past few weeks, three great, new Platform as a Service offerings have been announced, using Docker as a base technology. We couldn’t be more thrilled. These include:
- Voxoz an Erlang Based PaaS
- Flynn an Open Source PaaS powered by Docker
- Deis an open source PaaS that makes it easy to deploy and scale LXC containers and Chef nodes used to host applications, databases, middleware and other services.
dotCloud itself started life as public Platform as a Service provider, offering one of the first, multi-language PaaS solutions. Docker grew out of that experience, and while we see Docker as having applications far beyond PaaS, we clearly have a great deal of interest in how the PaaS market is developing. In our mind, there are four, big trends emerging in the market:
- The recognition that there is not – and probably never will be – a one-size, fits all PaaS
- The increasing demand by users of any PaaS to expand both the number of languages/frameworks supported and the number of deployment platforms supported
- The demand for PaaS-like environments inside and between enterprises
- The blurring of the boundaries between Public PaaS, Private PaaS, DevOps tools, etc. (See State Of The Platform As A Service Market, A Discussion For Deploycon for a good analysis by Alex Williams and Krishnan Subramanian on this)
Ultimately, the goal of any PaaS is to make it easy for developers to create and deploy applications, ensuring that the underlying services interact properly both with each other and the underlying hardware infrastructure. This is true regardless of whether the service provider is an independent entity like Heroku, AppFog or dotCloud, a public infrastructure provider like Azure or AWS, or an enterprise that is looking to provide a more PaaS-like environment for their developers.
In previous posts, we’ve spoken about “The Matrix from Hell,” which is the challenge of making an ever increasing set of applications/language/frameworks/etc. interact properly with an ever increasing set of hardware environments. To some extent, every company offering PaaS encounters this matrix… and must limit their offerings to a particular combination of rows and columns.
The first generation of public PaaS offerings generally limited themselves to a few rows of the matrix, running on one particular column (e.g., enabling Ruby on a public infrastructure such as AWS). Dotcloud and others then introduced support for a far greater set of rows by offering multi-lingual PaaS.
More recently, given the desire to create PaaS-like environments inside the enterprise, we’ve seen private PaaS offerings (CloudFoundry, OpenShift) attempt to make a broad set of rows work for columns where the service provider is an internal IT operation. And, some public PaaS operators are inevitably moving to support multi-cloud back ends, hybrid cloud deployments, etc.
PaaS offerings can extend the number of rows and columns they support. But, they must inevitably limit them if they are to make the add-ons (monitoring, provisioning, billing, etc.) work properly.
Of course, the ideal combination of rows and columns differs widely from application to application, from developer to developer, and from organization to organization. The ideal PaaS for a web developer who codes in Python and is comfortable hosting entirely in the public cloud is far different from the ideal PaaS for the person developing .Net enterprise apps for deployment inside their own data center. The ideal combination also changes over time, as enterprises may look to expand their deployment strategy, integrate with new tools, move to or away from the public cloud, etc. Given the need for any PaaS to limit rows and columns, there can never be a single PaaS that can meet the needs of all individuals.
We introduced Docker to help eliminate the matrix, by separating the concerns of developers and operators. Developers can focus on packaging applications and dependencies as containers, without worrying about underlying infrastructure. Operators can focus on managing containers, without worrying about the contents of those containers.
While we intend to use Docker in the dotCloud PaaS, since no single PaaS can meet the needs of all individuals, we are actively encouraging the use of Docker as a way to make all PaaS services both more effective and more interoperable. As an open source project, we are excited to see a new generation of PaaS offerings (including Deis, Flynn, and Voxoz) leveraging Docker. And, we are actively engaged in conversations with some existing PaaS providers to integrate Docker into their environment. Ultimately, we hope that this can make all PaaS offerings better, and make it easier for developers and sys admins to move between environments quickly and cost effectively.