Infrastructure is undergoing a significant paradigm shift. At my first job as a software developer, scaling our infrastructure meant buying a physical machine and installing it in a rack, setting up the system images and base software by hand, configuring the network using some shell scripts, and finally, making it available for developers to install software. Now, with the advent of cloud computing, the same capabilities — installing and running software — are available on-demand.
Although this shift seems straightforward, it can pay dividends to define more clearly what this shift means for software development and infrastructure today. In particular, this article recaps the different models for provisioning software and infrastructure to better understand what infrastructure is today, and to better guide what infrastructure will be in the future.
In this article, I will first review what the terms On-Premises, Infrastructure as a Service, Platform as a Service, and Software as a Service mean. Finally, I will discuss what this means for the infrastructure teams at software development organizations.
On-Premises
On-premises (often abbreviated as “on-prem”) is hardware installed and run on computers on the premises (in the building) of the person or organization using the software, rather than at a remote facility in the cloud. On-premises is characterized by a long lead-time for provisioning new hardware. That lead time is typically due to careful capacity planning and the manual effort required to setup and install each new piece of hardware.
The benefit of on-premises is that you gain complete control over the entire stack that delivers your software to customers. This control means that your uptime and performance is guaranteed directly by your company. The downsides to on-premises are the difficulty of effective capacity planning, the increased lead-time for each new piece of hardware or network resources, and the significant cost in employee training and retention to guarantee your own uptime.
Infrastructure as a Service
The advent of server farms, and later of cloud computing, resulted in the ability to provision infrastructure through API calls rather than through capacity planning and change requests. Infrastructure as a Service, or IaaS, is the term coined to describe this shift, with AWS being the canonical example. Each service offered by Amazon is available for provision and use through API calls and it is up to the application developer to understand which services they need, how they can be provisioned, and how they can be connected to form a working application.
IaaS is an enabler of rapid innovation and delivery by allowing teams to provision what they need, when they need it, with little to no ceremony. The downsides of IaaS are two-fold. First, each software development team assumes some risk in provisioning infrastructure that may not meet their security and compliance requirements, and second, there may be a significant cost explosion as teams provision infrastructure with little to no insight into costing.
Platform as a Service
Whereas IaaS provides direct access to the individual components that make up a running application, a Platform as a Service, or PaaS, offers an end-to-end approach for provisioning infrastructure, including the overall experience of deploying, running, and monitoring applications. Competing PaaS platforms vary in the breadth and depth of functionality that they offer, from a feature-rich but very prescriptive environment like Google’s App Engine or AWS’s Elastic Beanstalk, to a more open-ended approach like Pivotal’s CloudFoundry. The one thing they have in common is that they provide guard rails to application development that reduce the support and operations burden for running the application.
The benefit of a PaaS is that it provides a stable platform for building applications in a prescribed manner. They therefore enable rapid delivery of software, as long as it fits the platform’s mold. The downside is that the platform may be overly prescriptive — only allowing the features and functionality provided within the platform and restricting other use cases, thus reducing our ability to develop innovative solutions.
Software as a Service
Software as a Service, or SaaS, is about licensing, sales and software delivery. With SaaS, instead of packaging and delivering software to a customer’s desktop, the software is licensed on a subscription basis and is installed at a centrally hosted location to be accessed by the customer. Gmail is a great example of a SaaS offering provided directly to customers.
SaaS provides advantages to customers by greatly reducing the time and money spent on tedious tasks such as installing, managing, and upgrading software. It also provides advantages to the software development business by simplifying the software distribution model and in providing a recurring revenue stream through evergreen subscriptions.
Comparison
The difference between these three models can be roughly outlined through the lens of the requirements and responsibility of supporting them. The following diagram provides a visual comparison between different styles of infrastructure management, with particular emphasis on which components are run by an operations group within a company, and which are supported by an external party.
This diagram makes it seem like there is a clear distinction between each of these models, where in reality the situation is more complex — each of these models exists on a continuum and the lines between them are constantly changing as products and cloud services mature. The overarching point of discussing these models is to highlight the options available.
Where does Infrastructure fit in a Software Development Organization?
In many organizations, the software development team and the operations team have separate roles and responsibilities. Traditionally, the operations team was responsible for managing the infrastructure at the organization — including networking, operating systems, security, and the physical or virtual machines. Most software companies are now focused on developing a SaaS product to capture the benefits of recurring revenue and simplified software delivery and maintenance, and the best way to deliver a SaaS is often by leveraging a PaaS or IaaS. This leaves the traditional “infrastructure and operations team” at a software development company with an unknown role. If your organization is developing a SaaS product using cloud computing as a PaaS or IaaS, where does this leave your infrastructure team? Is the infrastructure team developing an IaaS offering that overlaps with AWS? Or are they developing a PaaS that provides a more prescribed developer experience for releasing applications? Are they reinventing the wheel developed by cloud computing companies?
According to the National Institute of Science and Technology defines on-demand self-service is an essential characteristic of cloud computing. [NIST 2018]. This suggests that focusing on providing Infrastructure as a Service is the right model for an infrastructure team to pursue. Unfortunately, the downsides of IaaS include being high risk, and we know that an essential characteristic of many organization’s operating environments is compliance, security, and standardization. These restrictions suggest that a Platform as a Service would be a better fit for an infrastructure team to pursue. Some middle ground seems optimum, and an example of such a middle ground is provided by an unlikely source — the US Federal Government.
In 2017, Jez Humble, one of the founders of the DevOps movement, led a team that developed a set of recommendations for providing cloud-based infrastructure to government agencies. The central recommendation was “that agencies create a multi-tenant cloud platform that implements the majority of the controls required and allows teams that are building and operating information systems to self-service resources” [Humble 2017]. This recommendation led to the creation of cloud.gov, providing self-service infrastructure that implements 296 of the 325 FedRAMP moderate controls. The end result of the cloud.gov project is a clear on-ramp for developing applications that meet federal government requirements. We can use the results of this project to influence the work of infrastructure teams to provide a standard set of components that can be used to develop software in a controlled way.
The goal of an infrastructure team, then, should be to combine a self-service platform that implements a standard set of security and compliance tools, with a desire to leverage as much as possible the IaaS and PaaS offerings available from cloud providers. The desire of this initiative is to eliminate, to the greatest amount possible, the software development effort undertaken by an infrastructure team while providing a stable, well-documented, and industry-standard on-ramp for developers to release a organization-approved applications. Thankfully, each company does not operate in a vacuum, and there exist numerous tools in the industry that we can leverage to provide such a platform that meets the organization’s needs. In particular, Kubernetes and the Kubernetes ecosystem will continue to provide an industry-supported solution for developing and running software. The work now will be to decide how to best fit a tool like Kubernetes into your organization to provide standardization and cost control for development teams.
What that leaves us with is a infrastructure that sits somewhere in between IaaS and PaaS. Infrastructure teams will provide self-service access to as much of the cloud computing infrastructure and supporting tools that they can, but we will also provide that access in a controlled manner by building in tooling and controls to the IaaS or PaaS platform they leverage. The end goal is to leverage existing PaaS platforms to provide a paved road for getting production services out to customers, while also providing mechanisms to go off road when you need to by opening up direct access to the building blocks provided by IaaS.