After last week’s announcement of dotCloud going GA, a few persons asked me how such an approach differentiates from other PaaS.
In summary, while I think dotCloud’s offering has merit and solves some interesting use cases, it actually lives closer to the IaaS layer than being a real "PaaS".
What is a PaaS?
As I wrote a few months back , a PaaS should really aim at i) improving developer’s productivity and ii) provide them with a layer of abstraction to the IT infrastructure so that they can focus on what they are good at (and paid for): building quality applications. This shouldn’t be about servers, SSH and IP addresses, this should be about applications, continuous integration, load testing, etc.
A PaaS reaches that goal by making sure it efficiently solves the most typical use cases a developer will face while developing, building, testing, deploying, scaling and maintaining an application.
What is dotCloud?
dotCloud can be seen as a "Chef-on-steroïds ” (and is probably how Opscode should have monetized Chef in the first place). As such, it allows you to easily create new virtual machines based on some "recipes" (called "Build Files") that will match typical scenarios such as "I want a VM with PHP and MySQL installed", or "I want a VM with node.js installed". You can then customize the resulting VM (by running shell scripts), access it over SSH, etc. It is really a VM-automation service.
Where is the mismatch?
While dotCloud solves some interesting problems (see next section), it simply is not a PaaS. dotCloud is a solution that will help you build typical software stack as virtual machines and instantiate them in the cloud. While the resulting VM can be used by a developer, this is no different than if an IT operation team had setup this machine for him: developers will not gain any productivity in doing so, nor will their code, build, test, deploy, scale and maintain use cases be helped in any way shape or form by using dotCloud. Developers will still have to decide where and how they will store their code, where and how they will build and test it, on what application server they’ll deploy it, how that application server will need to be configured, tuned and setup on the operating system, how they are going to setup clustering, how to rollback their application in case something goes wrong, how they can transparently live-update their application running in production with no service interruption, how will the application server be patched in real time by the PaaS provider, etc. None of that is solved by dotCloud.
dotCloud is really a service that will help you build and run virtual machines, not applications.
So, is dotCloud useless?
Useless? Certainly not, especially as a number of on-premise enterprise systems do not have a "cloud-equivalent" yet.
Companies will typically want to leverage a best-of-breed PaaS for their applications in order to get true productivity gains, yet will typically have a number of "legacy" systems that rely on a typical software stack that have to run in a traditional fashion inside a VM. In that case, the dotCloud approach is very elegant as it provides an easy way to define what your stack looks like and provision it in the cloud – process which would be much more complicated if you were to directly rely on EC2 VMs.
Once this dotCloud VM is up and running, it can be consumed by any client, including by applications running on a true-PaaS.
If you have a number of legacy systems that are infrastructure-centric that you want to run in the cloud, dotCloud provides an easy way to instantiate such VMs. However, if you are a developer and you are looking for ways to boost your productivity and solve your typical development use cases, what you need is a true-PaaS - such as CloudBees if you are developing on top of a Java Virtual Machine.
If you want to experience it by yourself, why don’t you sign up for free and deploy a test application?
Sacha Labourey, CEO
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.