When public clouds first began gaining popularity, it seemed that
\nproviders were quick to append the phrase \u201cas a service\u201d to everything
\nimaginable, as a way of indicating that a given application, service, or
\ninfrastructure component was designed to run in the cloud. It should
\ntherefore come as no surprise that Container as a Service, or CaaS,
\nrefers to a cloud-based container environment. But there is a bit more
\nto the CaaS story than this. CaaS is not just a marketing fad. Below, I
\nexplain what CaaS means, and why it\u2019s valuable.<\/p>\n
Container as a Service offerings are often about more than just giving
\nIT pros a way of running their containerized applications in the cloud.
\nEach cloud provider is free to create its own flavor of CaaS\u2014and some
\nCaaS platforms don\u2019t run in a major public cloud. There are two main
\nareas in which CaaS providers try to differentiate their offerings.
\nFirst, there is the user interface. On-premises container environments
\ntend to be managed through the Docker command line. However, some IT
\npros prefer a GUI-based management interface over the command line. As
\nsuch, some cloud providers allow subscribers to point-and-click their
\nway through container creation and management. A second key
\ndifferentiator between CaaS providers is orchestration, and the
\nsupplementary services that are attached to the orchestration engine. A
\nprovider may use an orchestration engine, for example, to achieve
\nautomatic scaling for containerized workloads, based on the parameters
\nthat the administrator has established. Similarly, a cloud provider\u2019s
\norchestration engine may be used to handle container lifecycle
\nmanagement tasks, or the creation of container-related reports. It is
\nworth noting that public cloud container services can be somewhat rigid
\nwith regard to orchestrator selection. Microsoft Azure, for example,
\nallows you to choose between DC\/OS, Kubernetes, and Swarm. No other
\nselections are available. In contrast, other container management
\nplatforms, such as Rancher, are designed to be modular rather than
\nlimiting you to using a few pre-defined choices.<\/p>\n
Many of the advantages that CaaS brings to the table are similar to the
\nbenefits of general container usage. However, there are at least two
\nextra benefits that CaaS provides. The first of these benefits is that
\nCaaS makes it much easier to run applications in the cloud than it might
\notherwise be. Applications that were designed for on-premises use do not
\nalways behave as expected when installed on a cloud-based virtual
\nmachine. Because containers allow for true application portability,
\nhowever, it is possible to create an application container, test the
\nnewly containerized application on-premises, and then upload the
\napplication to the public cloud. The containerized application should
\nwork in the same way in the cloud as it does on-premises. Another
\nadvantage to using CaaS is that doing so allows organizations to achieve
\na greater degree of agility. Agility is one of those overused IT
\nbuzzwords that has kind of lost its meaning. However, I tend to think of
\nagility as the ability to roll out a new production workload as quickly
\nas possible. Given this definition, CaaS definitely delivers. Imagine
\nfor a moment that an organization\u2019s development staff is building a new
\napplication, and that there is a pressing need for the application to be
\nrolled out quickly. The developers could containerize the application,
\nbut what if the organization is not yet using containers in production?
\nBetter still, what happens if the organization\u2019s container environment
\nlacks the capacity to host the application? This is where CaaS really
\nshines. Public cloud providers usually let you deploy a container
\nenvironment with just a few mouse clicks. This eliminates time-consuming
\ntasks such as deploying container hosts, building clusters, or testing
\nthe container infrastructure. Cloud providers use automation to
\nprovision for their subscribers\u2019 container environments that have been
\nproven to be configured correctly. This automation eliminates the
\ntime-consuming setup and testing process, and therefore allows the
\norganization to begin rolling out containerized applications almost
\nimmediately.<\/p>\n
Although it is tempting to think of CaaS as solely being a service that
\na cloud provider offers to its customers, it is becoming increasingly
\ncommon for organizations to host containers on multiple clouds. Doing so
\ncan help with resilience to failure, and with load balancing. Yet
\nhosting containers on multiple clouds also introduces significant
\nchallenges related to cross-cloud container management, and cross-cloud
\nworkload scaling. These challenges can be addressed by using management
\ntools such as those from Rancher<\/a>, which can
\nmanage containers both on-premises and in the cloud. Brien Posey is a
\nFixate IO contributor, and a 16-time Microsoft MVP with over two decades
\nof IT experience. Prior to going freelance, Brien was CIO for a national
\nchain of hospitals and healthcare facilities. He also served as lead
\nnetwork engineer for the United States Department of Defense at Fort
\nKnox. Brien has also worked as a network administrator for some of the
\nlargest insurance companies in America. In addition to his continued
\nwork in IT, Brien has spent the last three years training as a
\nCommercial Scientist-Astronaut Candidate for a mission to study polar
\nmesospheric clouds from space. You can follow Posey\u2019s spaceflight
\ntraining at www.brienposey.com\/space<\/a>.<\/p>\n