Getting new features out to customers faster is an ongoing struggle for any company. Taking a customer request through refinement, development, testing, and deployment once took months. However, many forces have combined to reduce that time. Agile methodologies shortened the development and testing pieces while cloud computing has shortened the deployment piece. Continuous integration (CI) and continuous delivery (CD) further improved the time it takes to get a feature to customers. In addition to these, containers can give you a more powerful and flexible solution.
But with all these pieces come additional configuration and complexity. These aren’t unsolvable problems. However, ask yourself if that’s really where you want to spend your time. You’d likely rather be developing new features and getting them out to customers as quickly as possible. How can you best take advantage of tools such as cloud deployments and containers? Containers as a service (CaaS) can bring a good balance of speed and control to your deployments.
In this post, we’ll explore what CaaS can do for you and the benefits of using them for your application. To begin, let’s take a look at “containers as a service” by splitting up the term into two key parts.
We’ll start by looking at containers. Containers are a form of virtualization at the operating-system level. What does this mean? In the past, virtualization typically referred to full emulation of hardware. A virtual machine (VM) used software to emulate all the components of a machine, such as the CPU, memory, hard disk, or network. This provided full isolation between VMs, but at the expense of high processing cost. VMs consumed processing power just to emulate all that hardware. That left less processing available for your application. In addition, it was an inefficient use of storage space. Every running VM required its own operating system installation. If your application was deployed across two VMs, you’d need two OS installations in addition to the space your application took.
Hardware advances were able to speed up the processing VMs needed, but some problems remained. Startup time was a big one. It took much more time to start a VM with the app running on it compared to just starting the app by itself. Since the unit of virtualization was the whole machine, starting it involved starting a (virtual) computer! In addition, the inefficient use of storage remained an unsolved issue. There was no way to get multiple VMs to share a single operating system installation.
Solving Virtual Machine Problems
Containers offer a compelling solution to VM problems. Rather than requiring an operating system per instance, containers share the running instance of the operating system hosting them. OS-level features provide isolation between containers so that one container cannot affect other running containers. As far as each container is concerned, its apps are the only things running on the system. And because there’s less to emulate, their startup time is vastly better than VMs. For example, starting up a Linux container with an application happens in seconds.
This is just a brief introduction to containers. To learn more, you can check out this post on the benefits of containers.
As a Service
With a handle on containers, let’s turn our attention to the “as a service” part of CaaS. Where does that come from?
Infrastructure as a Service
The rise of cloud-based computing has brought about many “as a service” offerings. One of the first of these is “infrastructure as a service” (IaaS). This helps to provide you with infrastructure you don’t have to manange. Rather than keeping a data center full of computer hardware for your application, you use virtual hardware provided by a cloud platform. Some of the common offerings in this category are Azure Virtual Machines from Microsoft or Amazon EC2 instances. When you take advantage of IaaS offerings, you’re still responsible for maintaining what’s installed on the virtual machines themselves. You have to install and maintain the VMs’ operating systems. And you have to decide on a deployment strategy and maintain it. IaaS provides the infrastructure, but it’s up to you to maintain your installation on that infrastructure.
Platform as a Service
While IaaS was able to reduce computer hardware costs, it still required application and OS-level maintenance. Another “as a service” offering that seeks to address this is known as “platform as a service” (PaaS). PaaS not only does away with hardware costs but it also abstracts away the operating system and many deployment concerns. With PaaS, you no longer have to install or maintain a VM’s operating system. The OS is abstracted away from you, and you just deploy your application and it runs. A couple of examples of PaaS offerings are Azure App Service from Microsoft or AWS Elastic Beanstalk from Amazon. While these reduce a lot of the friction associated with deploying and hosting an application, using them ties you to each cloud provider’s platform.
So what’s the answer to easy deployments and hosting without tying yourself to a particular cloud vendor? CaaS sits very neatly in that category.
With CaaS, cloud providers offer a hosted container orchestration engine that’s capable of running many containers, as well as maintaining infrastructure among your running containers. A couple of examples of this are Azure Kubernetes Service from Microsoft or Elastic Container Service from Amazon. With a CaaS offering, you still have cloud-based hosting, which saves you from having to run and maintain your own machines. However, you also have cloud provider independence. Containers provide a standard unit of software deployment so you can deploy your containers to a CaaS offering from provider A or from provider B. In either case, your containers are the same.
Why Consider CaaS?
We’ve dissected CaaS to get a grasp of what it means. Now the question arises, “Why should I consider using it?”
There are benefits to moving to a container-based deployment of your application. Containers are built up from an immutable image. What this means is that your developers and testers are using the same image that gets deployed to production. Gone are the problems that come from having multiple environments with out-of-sync configurations. And as I mentioned earlier, containers have become a standard unit for software deployment. The fact that there are multiple cloud providers offering CaaS is a testament to this fact.
Beyond the benefits of moving to a container-based deployment, many CaaS offerings can make it easy to add recommended instrumentation to your application. Take logging as an example. A container-based application shouldn’t rely on pulling logs from an individual running container. Containers are meant to be recreated as needed. Instead, you should aggregate and centralize your logging. Using CaaS makes it easier to enable things like log aggregation and monitoring for your containers. You can standardize your chosen telemetry and deploy it as an additional container hosted by your CaaS provider. This type of deployment is referred to as a sidecar deployment.
Want to Know More?
Hopefully, by now, you’re eager to discover more about containers as a service. Taking advantage of a CaaS offering can offer a lot of benefits, including deployment standardization, provider independence, and improved monitoring. All of these can bring your application faster and higher-quality deployments. And that in turn helps you deliver customer features faster.
Want to learn more? Scalyr’s webinar on the dev’s guide to CaaS goes into more detail. In it, you’ll see a container demonstration, an example of running multiple containers, and a demonstration of collecting app telemetry.
After you check out the webinar, investigate some of the CaaS offerings. Create a spike where you deploy a container-based application. Kick the virtual tires and take a look at what a CaaS solution can offer you. We’ve looked at some of the benefits already, but you know your particular application best. See what increased deployment speed and better instrumentation can offer your business, and start to drive feature development based on application telemetry.
This post was written by Eric Olsson. Eric was first introduced to programming in high school, and he’s been fascinated by it ever since. Most of his professional experience has been working with C# and other .NET technologies. After being introduced to agile methodologies and practices such as test-driven development, he’s had a particular interest in applying them to the code he writes.