In my recent post on OpenStack “Do I Need OpenStack if I Use Docker?” I covered the confusion that has emerged around one area of disruption that Docker has created. In this post, I’d like to segue into another similar topic that has emerged around the same concept where I sense similar disruption and confusion: the use of PaaS in its traditional form vs using a straight Docker approach.
Background
PaaS in its simplest form is a platform that enables developers to develop and deploy web applications into production fast by abstracting many details of the underlying infrastructure, whereas Docker provides a generic container for packaging software stacks in a portable way.
A Traditional PaaS Stack
Many of the traditional PaaS implementations use Docker or LXC as the underlying container to enable multi-tenant applications on a shared infrastructure. Usually PaaS relies on web containers that are specific to a certain language (Tomcat, Jetty/Java, modephp/PHP, Rails/Ruby, Django/Python,NodeJS/JavaScript…..) to host the user’s code, and Docker or LXC containers as lightweight VMs that hold these web containers, and provides the required isolation level between the various web containers. This architecture lends itself nicely into simple web applications which are often built out of a web front-end, and a database as a backend persistent model. As far as I know, Docker actually initially emerged from one of the PaaS’ provided by DotCloud, and evolved into its current incarnation.
The introduction of Docker as a simple abstraction to containers, has turned Docker into a portable software container that isn’t tied to a specific language or framework. It can not only be used as a web container, but also as a more general purpose software container for all sorts of applications such as microservices, big data analytics, stream processing, as well as legacy applications.
Some PaaS implementations, such as CloudFoundry, have already started to offer support for running Docker containers as one of the software components that are supported by the platform.
Having said that, PaaS provides a fairly opinionated model for the way we should model and package our applications. Often times, our packaging is too limiting as we start to grow to more scalable models, such as microservices.
This causes many users today to question whether there is enough added value in PaaS in order to justify these limitations, when users can simply run their software directly on Docker.
Using Docker as an Alternative to PaaS
Using Docker with a combination of orchestrations engines such as Kubernetes (in the case of GCE), Heat in the case of OpenStack, or Cloudify (for multiple clouds such as OpenStack, VMware, AWS, as well as bare metal)
can provide a relatively simple way to package, deploy and manage applications in an automated fashion.
Unlike the traditional PaaS stack - it doesn’t force a specific opinionated architecture for deploying apps although it does lend itself very nicely into both web applications and microservices architecture.
My Take
The main promise of PaaS is in the speed of development and simplicity. Traditional PaaS implementations achieve that goal through extreme abstraction of the underlying infrastructure, as well as by promoting an opinionated architecture, which provides a fairly optimized and consistent deployment experience for applications that fit into that model. The combination of the two ultimately does help achieve this promise, but for a fairly limited set of applications.
Using Docker coupled with orchestration as an alternative provides a more general purpose platform for achieving a similar goal. Unlike the traditional PaaS approach, this use of Docker with an orchestration engine does expose the user to more knobs and infrastructure details, which makes the user experience for developing and deploying simple web apps more complex than with the PaaS alternative, however it does provide the added benefit of flexibility - like with the onset of OpenStack, and open source cloud in general..
The right way to think of PaaS and Docker
In my opinion, the right way to think of the two is in a layered approach in which both the PaaS containers and Docker fit together as outlined in the diagram below.
As seen in the diagram above, PaaS becomes one use case for deploying simple web apps. For more complex application deployments, it makes more sense to use Docker directly. In this context orchestration becomes a central piece for managing both use cases. Orchestration also provides a layer of abstraction between the application components and the underlying infrastructure.
The important realization is that in this context the role of PaaS as we know it becomes more of a niche role, yet still remains a fairly common and important use case. It is also important to note that the two models are not mutually exclusive. An application that runs on a PaaS container could interact with services that are managed directly through a Docker container, just as you would use other cloud services such as database as a service, load balancer as a service or any other on-demand resource.
Another important note is that the combination of Docker and orchestration opens a new path to manage dynamic workloads not just on an IaaS environment, but also directly on bare metal. I’m starting to see more use cases where this option becomes more popular, specifically for managing dev and testing environments where the use of a full blown cloud infrastructure may just be overkill.
Final Note
When we started the journey into the cloud world a few years ago, the underlying cloud infrastructure was very complicated. As a result, the only way possible to simplify the application deployment experience was to take extreme measures in the level of abstraction, as well as by forcing an opinionated architecture to ensure that the application fits into typical cloud architecture. As the underlying infrastructure and tooling evolves, those extreme measures are no longer needed for all use cases. What we’re now seeing is basically a shift of of pieces in the PaaS architecture that was previously embedded within the "PaaS Box" such as containers and orchestration that have becomes more generic, along with independent services that have their own right to exist.
The good news in all this, is that as users we are finally beginning to receive the simplicity of PaaS, that was previously limited only to greenfield web applications, for use with a much broader spectrum of applications and architecture styles.
So to answer the question from the opening note, do i need PaaS if i use Docker? The answer is, yes. It makes sense to have the two combined, but the role of PaaS as we know it has narrowed down significantly.
