Organizations face the perpetual challenge of deploying and managing applications. It's a challenge as old as computing. But today, there are more alternatives than ever for developers and business leaders to consider. Two emerging alternatives are PaaS and containers. Both are significantly different in terms of underlying technology and use cases, but there is increasing overlap between the two.
What's the difference between PaaS and containers?
Let's start with a quick review of both technologies. A PaaS is typically a suite of cloud-based applications that organizations can use to accomplish specific sets of tasks. PaaS is most often associated with software development tasks such as coding, testing, packaging and deployment. Because the PaaS provider handles all the software tool deployments, management and updating, organizations can shed those elements of their local infrastructure and support -- ideally simplifying their IT environment.
A container is a type of virtual entity that enables an organization to run code, usually in the form of smaller applications or modular software components. Containers share a common OS and offer quick spinup, launch and stop times, making containers fast and convenient for running virtualized, highly scalable and highly orchestrated enterprise workloads.
At first glance, it seems that there is no direct relationship between PaaS and containers, but the story doesn't end there.
How are PaaS and containers used today?
Once we look a little deeper, we realize that containers often have a vital role in any PaaS. Consider that a PaaS might need to spawn software tools for users to work within, and a PaaS typically enables users to deploy applications such as web applications and custom services -- whatever the PaaS users create.
However, those deployments need some underlying mechanism to provision and configure computing and storage resources for application deployment. Because PaaS providers don't use human IT staff to handle all those deployment and scaling processes, the PaaS provider will opt for an efficient, highly automated infrastructure for such tasks. In short, a PaaS typically uses containers for PaaS software deployments.
Thus, containers -- such as those running on the Docker engine -- are frequently considered to be a central building block, and even an enabler, of modern PaaS.
Containers aren't limited to PaaS. Organizations often use containers in the local data center for the exact same benefits; enabling users to easily deploy and spawn applications within containers. Local containers would also rely on an established service such as Docker, Apache Mesos or another container engine to support containers, while using an orchestration engine such as Kubernetes to automate many of the tasks involved with container deployment and management.
What is containers as a service?
PaaS technology enables countless different types of platforms. Most platforms focus on activities such as software development and include a limited variety of deployment mechanisms designed to launch and host the applications created by the platform. Such deployment mechanisms often rely on containers to provide the underlying application deployment infrastructure.
But such use cases are relatively narrow, and the PaaS provider establishes the environment for any containers -- such as the base OS. Today, an increasing number of platforms focus specifically on containers as deployment mechanisms in the form of containers as a service (CaaS). Thus, CaaS handles the automated deployment and hosting of containerized software. The CaaS provider supplies the infrastructure and engines needed to deploy, manage and monitor containers and the underlying deployment environment. In this context, CaaS is offered as a specific type or subset of PaaS.
The mechanisms used to create a CaaS offering can be virtually identical to those mechanisms used to support software deployments in containers through other types of PaaS. But CaaS expands the available options and potential sophistication of the container environment and can be a better fit for complex container environments, such as microservices applications, where each container deployed to a CaaS might encapsulate a different OS and other dependencies.
So, if the goal is to develop and deploy software, a PaaS might be the better choice. If the goal is to deploy and manage large numbers of containers in complex arrangements, CaaS might be better.
Pros and cons of PaaS
PaaS is attractive for many organizations because it can jumpstart and support a wide array of projects -- an organization can jump in and access top-tier tools and resources without the cost or complexity involved in creating and maintaining those tools, resources and other infrastructure in-house. An organization can focus on their core business and competencies without supplying the underlying infrastructure. So, the benefits of PaaS include the following:
- Time savings. An organization can start using PaaS in a matter of minutes.
- Cost savings. An organization saves the cost of software and hardware needed to create the environment.
- Accelerated time to market (value). The time and cost savings can help get apps and other platforms to market faster -- adding value to the organization.
- Flexibility. Organizations can often customize the PaaS offerings and add/link custom tools.
- Scalability. PaaS resources and infrastructure can scale to meet business needs.
- Managed. The PaaS provider manages the infrastructure and maintains the tools and services.
PaaS also presents a number of potential challenges and disadvantages organizations should consider, such as the following:
- Vendor roadmap. A PaaS is defined by the suite of capabilities and services supplied by the vendor, so needed features and functionality might be absent, slow to arrive or be deprecated with few alternatives.
- Vendor lock-in. The organization becomes dependent on the PaaS -- and the provider; migrating to another PaaS provider can be difficult or impossible.
- Compatibility issues. The PaaS might not be compatible with other development tools or platforms.
Pros and cons of containers
As with VMs, virtual containers have brought an array of benefits to organizations and application developers, such as the following:
- Speed and scalability. Containers are small virtual instances and can appear or disappear quickly, allowing for far more containers on the same infrastructure and fast adjustment for changing operational conditions.
- Consistency. The container image files that launch and run within containers include all of the components and dependencies needed to make the code run, enabling the container to be operated in any suitable container environment anywhere.
- Automation. Containers are so numerous and ephemeral that some form of automation and orchestration is required to manage a container environment effectively, and tools such as Kubernetes are readily available to assist with those tasks.
But containers are far from perfect, and organizations that opt to work with containers must contend with several disadvantages, including the following:
- Container complexity. Containers are image files that include the application code as well as an array of dependencies -- all of which must be organized and packaged before the container image can be deployed. Any changes require the image to be updated and repackaged -- and often redeployed. This can make container use more complicated than traditional VMs.
- Operational complexity. The sheer volume of containers that can exist in a typical data center environment can easily number into the thousands, making container management and monitoring particularly vital and difficult.
- Security. One core issue with containers is the common OS that all containers share. Any vulnerability or fault in the OS can potentially jeopardize the containers running on that system.
How to choose between PaaS and containers
The choice between PaaS and containers usually isn't a deliberate one. Containers are a typical deployment avenue for many PaaS offerings -- container use might be unavoidable when selecting a PaaS. Fortunately, most PaaS providers have made great strides in simplifying and automating their container infrastructure. A PaaS using containers is often the fastest and easiest choice when speed and convenience are high priorities for business users.
If control and oversight are the highest priorities for an organization, it might make more sense to forego a PaaS and build a container infrastructure in the local data center. This requires IT support with significant expertise in container technologies, starting with the underlying container engine, such as Docker, and automation and orchestration tools, such as Kubernetes. In-house containers are undoubtedly more complex and costly but might be necessary when business needs and goals dictate.
CaaS presents a third choice, enabling organizations to use container services for large and complex container deployments while eliminating much of the infrastructure and software platforms involved in container support. CaaS can be a suitable choice when an organization needs the speed and scalability of PaaS, but the focus is on containers and container-based application deployments.
As always, it's important for IT and business leaders to understand the needs, costs, reliability, availability, portability, features and functionality of all alternatives before making a commitment to any technology or provider.
What is the future of PaaS and containers?
Organizations can expect to see a tighter relationship between containers, clouds and cloud platforms (PaaS) in the years ahead. Consider some of the following current relationships:
- Current PaaS is typically provided through a cloud or is built as a public cloud.
- Containers can provide fast and dynamic deployment mechanisms for modern application components.
- Containers are an integral element of many PaaS offerings.
- Public clouds are already well-suited to container deployment and management.
- Public clouds already provide container management and orchestration as a service -- Kubernetes in the cloud.
Over time, the distinction between these three technologies is likely to blur and eventually become indistinguishable or irrelevant as more organizations seek to shed IT infrastructure and manage costs to focus on core business activities.