Go Beyond IaaS: Deliver PaaS and CaaS

This blog, is my final installment in my “Seven Things That IT Must Do…” series (see list of prior blogs at the bottom of this blog) and focuses on the idea that IT must Integrate IaaS with PaaS and CaaS (Platform as a Service and Container as a Service) as part of their Cloud service delivery strategy.  While most IT organizations are just now becoming proficient at delivering IaaS, what is abundantly clear to anyone in the industry, is that developers don’t care about infrastructure.  What they care about is writing good code that helps their organizations address their core mission, whatever that mission is. The mission of IT as it relates to developers is to help them accomplish their mission.

Delivering “frictionless IaaS”, IaaS that provides a public cloud like experience, whether on premise or on the Public Cloud, is a good start but more and more, IT teams need to be looking beyond this in terms of how they support App Dev initiatives.  IT teams supporting developers, especially developers who are embracing DevOps principles, need to start thinking about how they can provide some version of PaaS to their developers.  I say some version of the PaaS because PaaS has become one of those things that is all things to all people.

For some App Dev teams, PaaS means having access to a platform that delivers traditional middleware components on demand.  For other groups, it is a platform that delivers containers on demand (commonly called Containers as a Service).  For others, it is about having access to a full-fledged developer platform that includes developer tools that help them develop either traditional apps or cloud native apps.  The truth is that there is a glut of diversity that IT teams need to contend with as they begin to move beyond IaaS to provide higher levels of value to the App Dev teams they support.

Automating Delivery of 2nd Gen Apps

When it comes to automating the delivery of the middleware necessary to support application development, many development teams are using configuration management tools such as Puppet, Ansible, Chef and Salt.  These configuration management tools make it easy to codify the process of building the middleware stacks that developers routinely integrate into their software projects.   Another benefit of using configuration management tools is being able to use these tools to audit already provisioned configurations and to remediate configurations that deviate from approved standards.

Because of these benefits, many organizations now have large investments in the codified representations of the middleware stacks they use most often.   To support App Dev teams looking to simplify the building of combined infrastructure and application stacks, IT organizations should consider integrating configuration management tools with whatever capabilities they have deployed for automating the delivery of IaaS.

Integrating an existing IaaS solution with one or more existing configuration management tools is the easiest and most natural way to deliver more complete software stacks to end users.  The alternative approach to develop more complete software stack representations generally requires rewriting lots of code associated with provisioning the middleware most commonly used by the enterprise.  App Dev teams are loathed to cooperate in such efforts if they have already created tons of these representations using configuration management tools.  So if you want to extend IaaS to include middleware, figuring out how to leverage existing representations that are already sitting in configuration files from solutions like Puppet, Ansible, Chef and Salt is going to be your best path forward.

Automating Delivery of 3rd Gen Apps

Containers are becoming the predominant choice for organizations creating net new applications. While containers can run on bare metal, most of the marketplace is leveraging containers on virtualized compute environments such as vSphere.  Containers allow organizations to build applications in a way that makes them highly portable across cloud environments.   Containers are also a great fit for applications that must be updated frequently.

While not new, containers have gained tremendous popularity in the last few years’ thanks in part to the ease of creating them using Docker. The popularity of containers in turn has given rise to many container-related technologies, many of these open source, many leveraging Kubernetes, that can be easily downloaded by developers to their laptop.

While there are dozens of tools targeting the use of containers for development, tools that support the scaling up of container-based operations and moving containers to production are not as easy to find.   Most of the containers solutions on the market today exhibit some level of deficiency when it comes to addressing production level requirements for things such as performance, availability, security, or data persistence.  Most solutions also fail to address in a enterprise grade way requirements related to things like role based access, resource entitlements, approvals, or other governance related items.

Another deficit many of these solutions exhibit is in the area of integrating container based application components with traditional, 2nd generation applications.   Turns out most enterprises think this capability is pretty important.  My team recently did a market research project around containers and one of the core findings was that a majority of respondents believe their organizations will have a need to run applications that are a mix of both traditional and container based applications in the future.  Helping App Dev teams address these deficiencies so they can successfully move container based applications to production is something that IT teams will need to master in the future to maintain their relevance – especially with groups focused on cloud native, container based applications.

Integrating 2nd and 3rd Gen Apps with CMPs Doing IaaS

Many IT organizations are using some form of Cloud Management Platform (CMP) to deliver IaaS.  In some cases this CMP is only used for services delivered on premise.  In other cases, the organization is using their CMP to provision across both an on-premise environment and a public cloud.   However your CMP is being used, from an IT relevance perspective, the cloud management solution your organization is using needs to be able to move up the capability ladder to handle the inclusion of both 2nd gen and 3rd gen application level services.

Given the diversity of solutions available for provisioning both 2nd and 3rd gen applications, a CMP needs to have an ability to “snap in” existing solutions.  CMPs must provide a framework that makes it easy to extend beyond IaaS so that IT teams can snap in configuration management tools or container as a service solutions.  Your CMP should make it easy to take advantage of the investment the App Dev teams have already made in solutions to provision both 2nd and 3rd gen applications.

Summing Up

The approach outlined above gives App Dev teams the ability to use the solutions of their choice for provisioning application level components.  This will make them happy and help move the perception of IT out of the “always NO” camp and into the “they can do anything” camp.  But it will also allow IT to easily move applications from developer laptop into production in a way that meets enterprise grade requirements.   That’s a win/win for everyone and a one of those “must do” things that helps IT to maintain its relevance in a fast-changing world.

The Blog Series Recap

  1. IT Teams Need To Finally Implement Self-Service Automation
  2. Marketing Internal IT to Line-of-Business
  3. IT As Developer Of Infrastructure As Code
  4. IT Must Adopt DevOps with SDN To Drive Relevance

Learn More


One comment has been added so far

  1. Thanks David. My favorite installment yet. We’ve found that integrating our vRA based CMP with Ansible, Puppet, Foreman, and Satellite have been the most crucial step in attracting our dev teams to the platform. So glad that VMware has partnered with SovLabs to make these integrations easy without having to jump into vRO. Also helpful that these only required vRA Advanced version. The SovLabs Docker container integration was pretty slick too, but I’m not getting too deep into containers yet.

    Great series, David!

Leave a Reply

Your email address will not be published.