The concept of containers as a service, or CaaS, is compelling. CaaS provides container development, deployment, and operations as a service, with support for single, hybrid, and multi-cloud architectures
The goal of containers is to write once, then run on any cloud. CaaS solutions are built on top of IaaS platforms such as AWS, Microsoft Azure, Google, Red Hat OpenShift, Docker Cloud. Many enterprises have steered in this direction, both via the as-a-service model and with on-premises containers and container clusters.
There are a few trends in CaaS that are good to understand. These include the rise of container orchestration as a service, such as Kubernetes and others, and better integration with the larger public IaaS cloud infrastructure.
Container orchestration is important in 2018 because it allows applications built upon CaaS to scale. Containers, by themselves, run in single-threaded states. While this is okay for small applications that deal with a few users, most container applications must support thousands of simultaneous users who are running variable types of workloads.
The ability to scale is largely provided by the container orchestration engine. It provides scheduling and cluster management support, which allows the applications to run as clusters of containers that can work and play well together. This in turn allows the container-based applications to scale.
This is not a new trick, considering that containers are self-contained platforms, operating systems, and applications. However, it’s a pretty nifty trick to use lightweight virtualization and cluster management to provide container-based applications that provide the benefits we listed above.
In 2018 we’re seeing more focus on container orchestration engines that are part of the CaaS platform. This trend will likely continue into 2019 as the concept and surrounding features of containers—orchestration, management, security—stabilize.
Here's what your team needs to know about the state of containers as a service.
Tighter coupling with cloud vendors
One major trend is tighter integration with the IaaS providers that deliver the CaaS services.
In the past, most IaaS providers offered CaaS as something that was loosely coupled to the core platform. In many cases, the technology was NIH (not invented here), such as the Google-developed Kubernetes, which is now leveraged by both Microsoft and AWS.
These days the story is a bit different. IaaS providers are now incentivized to provide tight coupling with underlying infrastructure, such as storage, databases, and compute. Indeed, the core play here is for IaaS providers to sell more cloud service hours. CaaS attracts the use cases, and thus the workloads.
So what kind of tight integration can you expect? Using CaaS on an IaaS provider blurs the line. Where does the container development and deployment platform end, and where does the IaaS system begin? What benefits and downsides are involved? There are two of each.
One core benefit is that there is much tighter integration with the DevOps capabilities that the cloud provider offers. This includes the ability to leverage tool pipelines for continuous development, improvement, integration, testing, and deployment.
This means that the developer need not drop out of the CaaS system to do things such as check in code, run automated test, or deploy containers into production. This tight integration with containers is something that you’ll find not only on public IaaS clouds, but with on-premises DevOps as well. Again, the theme here is to blur the lines between the containers and the underlying infrastructure, as a service or not.
The second core benefit is synergy around costs and cost controls. In many respects, blurring the line between CaaS and IaaS causes many development organizations to go off the rails, in terms of cost and cost control. When costs are neither monitored nor governed, the results are very high CaaS and IaaS cloud bills, strained budgets, and frazzled nerves.
With today’s tighter integration, developers can better project how much they’re spending on cloud servers. With the right integration, you deal with a single holistic service where CaaS is a mere subcomponent; you no longer need to worry about a confusing split of the cloud costs between two abstract services.
The downsides of CaaS
However, there are downsides. First, when you leverage CaaS and containers, you’re attempting to separate the container development and the container deployment from the underlying IaaS cloud. Separation provides portability across clouds. But if you’re more tightly coupled to a single IaaS cloud provider, you’re more likely to leverage native features over features found in the CaaS platforms, which are part of the IaaS clouds.
For example, while you could leverage abstracted storage using CaaS APIs from the containers, they may move to native storage APIs, which provide better performance and are easier to use from the applications. Indeed, most native APIs provide some advantage over the APIs found within containers, or CaaS, but they have the tradeoff of limiting portability.
The answer to this downside is often having the discipline to avoid any cloud-native development as part of building and running containers on CaaS platforms. However, the allure of leveraging cloud-native features might be too much for time-strapped developers to pass up, especially if they are trying to optimize their container-based applications and don’t plan to move off the IaaS cloud provider in the near future.
The second downside is that deployment and operations on IaaS clouds limit portability. This is due to the fact that you have to leverage the native IaaS monitoring and management tools.
While some tools are a part of the CaaS platform, others push you out to the IaaS management and monitoring systems, which are unique to the IaaS cloud provider. This by itself does not lock you into an IaaS cloud provider, as a rule. However, the operations that are specific to an IaaS cloud provider, and the amount of time and risk it takes to move to another provider, mean functional lock-in.
This refers to the degree of difficulty in moving from one IaaS provider to another. While the containers will port without a problem, the container ops processes and tools won’t go along. There are risks, costs, and barriers to portability.
The business benefits of CaaS
With a strong case to be made for the benefits of CaaS, enterprises still need to consider the downsides. CaaS is a good fit most of the time, but not always. Enterprises need to study the core benefits and tradeoffs mentioned earlier, and consider how those features align with the needs of the business.
In 2018, we understand a few things about the business value of using CaaS, which includes:
- The ability to address the needs of developers as well as operations in better ways than traditional IT development and deployment. CaaS breaks down the walls between development and operations and supports concepts such as continuous improvement of applications.
- The ability to better support all stages of the software development lifecycle. There is no need to standardize on technology that’s quickly outdated; you can abstract yourself away from the changes in technology.
- The ability to build software systems using any language. This abstracts the developers from the constant volatility of development languages and approaches.
- The ability to deal with data in a consistent way. We leverage data outside of the containers and with a common set of APIs. This hides the differences in the database models and physical data storage from the developers, who want to deal with just the abstract data.
- The ability to deploy on any platform and operating system, as well as on most IaaS public clouds, including AWS, Microsoft, Google, etc. This ensures that multi-cloud and hybrid cloud architectures will be able to leverage any container.
- The ability to support built-in distributed computing services, including open APIs and a “pluggable architecture.” Developers are better able to take advantage of the features of multi-cloud computing, such as different platforms that are best for running different patterns of containers.
- Growing ecosystems, including standard and nonstandard technology. CaaS depends upon a large ecosystem of vendors that provide different types of value-added solutions. You don’t have to depend solely upon the CaaS provider for the core technology.
What about CaaS in 2019?
The outlook for CaaS revolves around the continuance of CaaS on IaaS platforms, and the ability and desire for IaaS providers to grow those platforms moving forward. A few core drivers that will expand the growth of CaaS include:
- The continued growth of multi-cloud, or complex cloud architecture, which means that the ability to distribute applications and support portability becomes more important, if not downright mandatory.
- The continued move to DevOps, which includes leveraging containers as the common platform for development, deployment, and operations.
- The success of enterprises that have moved to CaaS. The IaaS providers sell these success-story use cases in the market and will continue to do so. It seems many leverage CaaS as the jumping-off point for the use of other IaaS services, such as storage, computing, and databases.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
