Deploying Modern Applications: a summary
What exactly is a ‘Deployment Technology?’
Who doesn’t love technical jargon? One thing that can be intimidating to new developers approaching web development is the number of terms dropped casually when discussing the development process. For example, a part of this process which is an absolute necessity in order to take code from a fun demo that ‘runs on my machine’ to an actual application is deployment. When we talk about modern deployment technologies, we are just talking about the technologies that support and describe the ways developers take applications and make them available to consumers.
Of course, there are many ways, physical and digital, to accomplish the deployment of software. Trying to cover all of these solutions in a single blog post would be a silly, somewhat Sisyphean task. But one common, recently developed solution to the deployment of applications, and particularly webapps, involves the use of containers. But what is a container? How does it work? And how are containers managed? All of these are important questions, essential to understanding and deploying containerized software. In order to address these points, we need to cover three topics essential to the process: the platform which runs the container, the container itself, and the many options for the infrastructure used to orchestrate multiple containers.
Docker, the most popular container framework, still needs to run inside of a host OS. Though containers, as will be described later, allow for the configuration of many contextual details, there still must be an environment to configure: this is where the platform comes in.
Docker itself, as well as Rocket, run on top of an OS called CoreOS. Put simply, CoreOS is a barebones operating system, built with the idea of running scalable containerized applications in mind. Actually a fork of ChromeOS, CoreOS focuses on providing the bare minimum for running containerized applications, in order to conserve computational resources and aid in the scalability, reliability, and security of those applications. It provides certain things, like service discovery and an interface for communication, that are useful specifically for running clustered cloud applications, while omitting many traditional OS features, like package managers, for the sake of compute- and space-efficiency.
Containers are a simple way of encapsulating an application and its dependencies, intended to be run in an isolated namespace ensuring resource isolation, while sharing system-critical components like the kernel with other containers. This is not actually a new idea. Starting with FreeBSD Jails and Solaris Zones, the idea of tunable but small application specific environments has appealed to developers for quite some time. Docker itself is built on top of LXC, or Linux Containers. Unlike more heavyweight solutions such as hypervisors, running a group of containers generally involves a stack of lean virtual machines running atop a shared kernel in order to preserve system resources. This allows for a number of benefits over heftier solutions, like improved startup times, flexibility, and portability, at the cost of a certain amount of security: a shared kernel can become a liability. There are currently two main technologies competing as container solutions: Docker and Rocket.
Docker was created to ease the process of distributing applications for deployment by offering a way to configure the local context. Isolation features of the Linux Kernel allow multiple Docker containers to run in unique contexts without requiring the overhead of spinning up an entire virtual machine for each one. This is particularly important when considering the logistics of distributing and supporting applications to the cloud. By running concurrent application containers instead of full VMs, cloud resources can be used more efficiently, allowing providers of web services to get more bang for their buck.
Following up on claims that Docker has gone from being the lightweight and portable container technology that was promised at its inception to ‘bloated’ solution for containerization, coming packaged with features that many users may not need or want, the team at CoreOS has designed a competitor called Rocket. Though Rocket provides many of the same things as Docker, it goes about providing these things in a different way. For example, while Docker runs a central daemon process which executes within a Docker namespace, Rocket runs under the system in which it is initialized. Ultimately, where Docker is tending closer to becoming a platform in-and-of-itself, with all the commiserate tooling, Rocket intends to provide composable, secure container units, true to the manifesto written in the early days of Docker, while keeping development an open process.
Though containers offer many benefits when compared to traditional PaaS solutions, they does not cover the operational aspects of code deployment . There are a number of operational considerations, like balancing workloads and dealing robustly with failure, that still need to be managed. This is where container orchestration technologies like Kubernetes, Swarm and Panamax come in. Further, in addition to technologies intended specifically for use with containers, there are other, more general-purpose technologies, like Ansible and Mesos, which are intended for managing and configuring distributed computational resources.
Perhaps the most simple of the solutions listed here, Docker’s own Swarm service is a very simple way of grouping hosts into a single virtual host. This ‘swarm’ of hosts still communicates through the same Docker API, making this clustering of containers invisible to the outside user, and providing one simplified interface for communicating across multiple hosts. Ultimately, this is a very limited solution, and is intended for simple use cases, and to be easily swapped out with more robust solutions like Kubernetes and Mesos.
Kubernetes is an orchestration system for Docker, developed by Google, intended for distributing containers across clusters of compute resources (like physical computers or VMs) in a way that meets a declarative set of user constraints. Basically, Kubernetes provides a framework for supporting management of and interaction with containers.
One concept central to the architecture of Kubernetes is the ‘pod,’ which is a group of tightly coupled containers meant to be served together. This ensures that, depending on the requirements of the application, separate docker containers can be run consistently on the same machine, sharing resources and allowing for performant communication. Pods are be further grouped into ‘Services,’ a useful abstraction of functionality performed by pods allowing for a simplified API. One could imagine a service intended for operating a web server - while Kubernetes may internally run multiple pods, each consisting of multiple containers, in order to ensure reliability and redundancy of a service, an outside user simply interacts with an abstracted interface for that service, without needing to understand the details of how that service is internally provided.
Kubernetes also provides an interface for things like container-to-container communication, without requiring overly complex workarounds to account for things like dynamic port allocation, and optimistic distributed concurrency, obviating the need for acquiring distributed locks. Further, a declarative interface for stating constraints ensures that developer-specifications are consistently met, doing things like keeping a certain number of server instances up and running, and balancing containers to minimize vulnerability to any particular point of failure. Fundamentally though, Kubernetes tries to provide a ‘unified computation substrate’, abstracting away the details of the multiple resources across which containers must be distributed and providing a simpler and more functional interface.
Much like Kubernetes, Ansible is a deployment management system providing a declarative interface, intended for managing and configuring multiple computing nodes. Unlike Kubernetes, Ansible is not intended to work specifically with containers (though it does include support for Docker containers) , but more broadly to ensure the general consistency applications running on computing resources with constraints declared by the developer. Rather than containers, Ansible depends on ‘Ansible Modules’, allowing the specification of certain resources and their desirable states (like requiring a web service to always be up). Machines are divided into ‘playbooks’ based on operations intended to be executed, so that computing resources can be divided among the variety of tasks necessary to run a particular application. This allows for a clearly understandable and configurable separation of concerns, and the modularization of both development and resource management.
Apache Mesos has a similarly minded, but somewhat more abstract goal than the platforms listed above. Fundamentally, Mesos sets out to abstract the resources of multiple computers or clusters (like RAM, CPU, etc) away from the physical machines they are resident of. By so doing, it provides an abstracted interface to manage the general execution of a number of services, including containers but also more traditional cluster-oriented applications such as Hadoop, Spark, etc. across a scalable number of machines. Essentially Mesos is a distributed kernel, providing many of the same features for a cluster that a traditional kernel would for a single machine. It also provides features for things like resource isolation and rack locality, and has a common interface for accessing cluster resources. But it is less opinionated about the way these distributed applications should be structured and run than the other platforms in this post, for better or for worse: Mesos is a bit less optimized for running containers and is a heavier weight solution than something more targeted, like Kubernetes. The technologies can actually be used together - with Kubernetes handling the configuration and management of container pods and Mesos handling the distribution of computational resources to those pods.
Panamax takes abstraction one step back from a framework like Kubernetes, and is intended to handle the orchestration of not just containers, but also existing Linux resource orchestration systems. This includes frameworks like Kubernetes and Apache’s Mesos. Marketed as ‘Docker Management for Humans’, Panamax offers a much friendlier UI for management of Docker containers, giving developers who might not be interested in learning the minutiae of command-line container management access to a simpler set of tools. Panamax is a free and open-source project, intended to help developers understand and deploy multi-container apps without requiring the mastery of the multiple technologies typically involved.
Software deployment is a necessary part of any software development process, and one often overlooked. Containers and the requisite infrastructure to manage and support them provide one means of accomplishing this goal, but are far from the only way to go about it. Among other solutions are things like hypervisors, software intended to handle the management of multiple machines and applications in a slightly less abstracted way than the software written above. Nonetheless, containers can contribute strongly to the scalability, performance, and reliability of modern applications, and provide an intuitive interface for constructing modern applications running on the cloud. As ever, each solution involves a number of tradeoffs, and the choice of which technology to use should always involve consideration of your own project’s requirements.
