The Cloud as a Tectonic Shift in IT: The Irrelevance of Infrastructure as a Service (IaaS)
This is the second in a series of four blogs about The Cloud as a Tectonic Shift in IT, authored by Sacha Labourey, CEO, CloudBees. In the series, Sacha examines the huge disruption happening across the IT industry today, looks at the effect it is having on traditional IT concepts and reviews the new IT service and consumption models that have emerged as a result of the cloud. Finally, Sacha makes some predictions about where this tectonic shift will lead us in the future.
The move to the cloud represents one of the largest paradigm shifts to ever affect IT. More than just a simple technology evolution, the cloud fundamentally changes many of the cornerstones on which IT evolved. From redefining the concepts of operating systems and middleware, to revolutionizing the way IT services are built and consumed, the cloud is ushering in an era of change unlike any we have ever seen.
In Part 1: The Industrialization of IT, Sacha examined the evolution of electricity and the development of standards for operating and using it. He then compared the evolution of grid delivery, instant-on access and pay-as-you-go models in the power industry with the parallel evolution occurring now in IT service delivery.
In Part 2 (below), Sacha takes a closer look at Infrastructure as a Service (IaaS).
The Irrelevance of Infrastructure as a Service (IaaS)
Because they are not a straightforward evolution, true paradigm shifts make it hard to foresee what’s to come. Yet, when facing such drastic change, the natural response is to try to replicate what we know and have done to date in the new environment.
One of IT’s occupations is to build software stacks, which often include virtualization technologies, OS, middleware, databases and more. The stack is capable of evolving over time and integrating new software versions and patches with as little disruption as possible. While there is a lot of science to it, there is also quite a bit of art in there.
Consequently, when discovering the cloud, IT initially tried mimicking what they had been doing for decades: Pick a server, install an OS and some additional software and configure, manage, patch and monitor it. But when it comes to the cloud, the server was not a recognizable, brand name server running in a private data center. Instead, it is a “no-name,” standardized virtual server running in Amazon’s worldwide data center infrastructure. So if the brand doesn’t matter at all, why not just cut and paste our last 30 years of blueprints and apply them to the cloud? With no CAPEX investment required and very little time needed to provision new servers, it’s a change for the better. However, this scenario fails to capitalize on all the cloud has to offer. Here, it is merely an evolution of the traditional on-premise model, not a real paradigm shift.
Initially applied to servers, under the name Infrastructure as a Service (IaaS), the founding attributes of the cloud – elastic, on-demand, pay-as-you-go capabilities – can actually be applied to other layers of the stack. Two of those layers are Platform as a Service (PaaS) and Software as a Service (SaaS). Let’s examine how IaaS, PaaS and SaaS all relate to each other.
IaaS vs. PaaS vs. SaaS
IaaS sits at one extreme of the cloud continuum. It provides a way for users to consume the basic building blocks of IT – the compute, network and storage layers – as a service. This is probably the most flexible layer of all, but also the most complex. It is flexible because access to a bare-bones server allows you to install whatever you want on that machine, including a specific OS, a specific version of that OS, low-level drivers and more. With IaaS, you are really working with systems – not just applications or data, but a full-fledged stack of software.
But in doing so, you end-up performing a lot of low-level IT tasks. Worse yet, executing these in the cloud is typically harder than doing it on-premise. Cloud environments are implemented based on the assumption that they might come and go. To take advantage of elasticity, new servers must be spawned automatically, requiring that all of the typical IT tasks be highly automated – not just the setup of new instances, but also the synchronization of those resources with each other.
For example, using the underlying IaaS-API, the provisioning logic must be able to dynamically update load-balancers whenever clusters get modified, discover and collect under-used resources and so on. And while you are not in charge of the hardware maintenance, you are still very much in charge of patching, upgrades and other software maintenance. The typical audience for IaaS consists of system operation and DevOps engineers who are replicating the on-premise art of IT in the cloud. If you are interested in migrating an existing system – and not just a specific application – from an on-premise server to the cloud, you will want to use IaaS.
At the other extreme of the continuum sits SaaS. Whenever a business need is generic enough, chances are high that you’ll find a company providing the solution as a ready-to-use service. Typical examples include CRM, ERP, support portals and collaboration tools. If you can find a SaaS deployment that fits your requirements, you will realize that they typically offer a huge productivity boost. They can often be customized to fit specific requirements, but if you have other requirements that are not covered by the solution, you may be stuck.
It is important to note that a growing number of SaaS solutions have started offering a set of APIs that will automate specific tasks through an external script instead of, for example, having to rely purely on a human clicking on a GUI. This capability becomes very important as the number of SaaS solutions being consumed grows, as companies will need these APIs to synchronize and/or integrate some areas of their SaaS solutions.
Yet, those APIs will typically not be able to change the behavior of the solution per se, but only impact it at its periphery. Consequently, SaaS solutions typically deliver great productivity gains as long as they offer what you need. The typical audience for SaaS can be any business end user but you’ll also find a number of solutions, such as e-mail gateways and source code analysis, aimed at more technically minded end users, like developers.
In between IaaS and SaaS sits PaaS. If you are interested in developing and deploying custom applications, then PaaS is for you. You can see PaaS as “the middleware of the cloud.” It provides an abstraction layer over low-level IT elements, including servers, storage and networking, and enables software developers to work with such concepts as “applications,” “databases,” “source-code building” and “application testing.” With PaaS, you don’t have to worry about setting up servers, firewalls, build farms, load-balancers or databases. You’ll only have to focus on your business needs and what your application needs to do; the PaaS vendor provides the rest.
This is a very important distinction that might not seem obvious at first: IaaS focuses on hosting full system stacks, while PaaS focuses on applications. The PaaS provider delivers a set of pre-defined, state-of-the-art application runtimes following the best practices in that space, which developers use to deploy their applications. PaaS users should never have to care about what OS, load-balancer and configuration is being used, or whether or not it should be upgraded. Those are the concerns of the PaaS provider. And while it might be more efficient to request an 80-volt plug for a toaster – or a customized runtime environment for just one specific application – this is what kills the ability for a provider to offer a high-quality service at a highly competitive price.
The typical audience for PaaS consists of software developers and architects.
So, Which One Should I Use?
The big question that many businesses face as they move to the cloud revolves around which layer they should be using.
Most companies are already using some sort of SaaS solution, such as Google Mail, Salesforce.com or Zendesk. But, whenever the need for “custom” work arises, they’ll typically adopt an IaaS solution. The reason is simple: building software stacks is what they are doing today on-premise. This is really the evolutionary approach that helps a company change, while remaining in a comfort zone. But they quickly realize that while the first steps are trivial, building a fully automated, scalable and resilient infrastructure is more complex than doing it on-premise – and requires different, quite specialized technical talents.
If a company is interested in running existing legacy systems, then this might be the right solution. Whenever you want to customize a system at a relatively low level, you need to have full access to the server – as well as specific drivers and a specific version of the file system or database. But remember that in this case, the IaaS provider will only help you by maintaining the hardware equipment and environment – you won’t receive any help detecting issues with your stack, or patching and upgrading it. All of these activities remain in your hands.
Should you really move existing systems “as-is” to the cloud? This is not always the best choice. A better course of action is to leave the existing legacy systems and stacks that require a specific configuration on-premise. So, the next time you have a new business problem to solve, ask yourself a very simple question: Can I find a SaaS solution that fits my needs? If the answer is “yes,” then take it – you’ll get the biggest productivity gain by using an already implemented, already tested, fully maintained offering.
But if the answer is “no,” it probably means you must implement some custom service. In that case, you will want to use PaaS, not IaaS. As a company, your added value lies in your ability to create new services that help you differentiate from the competition – not managing servers, firewalls and load-balancers.
The bottom line is that 5 to 10 years from now, existing systems will be de-provisioned and replaced by SaaS solutions, and new custom applications will be developed and deployed on PaaS. IaaS will be comparatively too complex to use and require sophisticated – and hard to recruit – talents.
Will IaaS Disappear?
Much like power plants are not likely to disappear, IaaS is here to stay. However, PaaS and SaaS vendors will emerge as the dominant visible species – and a number of SaaS solutions will actually be delivered using PaaS.
PaaS and SaaS vendors will be the ones caring about the infrastructure layers, as well as servers, load-balancing, backup and maintenance. You won’t.
Does this mean that IT consumers should not care about what IaaS framework their PaaS/SaaS solution is based on? Not at all. But they should care for different reasons.
First of all, customers will want to make sure some applications are co-located for latency reasons and they will want to make sure that others are hosted in a reputable country, typically for legal reasons.
Customers will also want to know what uptime SLA the IaaS solution is held to, as they will not directly manage this relationship nor use these resources. Instead, they will use a PaaS vendor as a proxy to address these underlying concerns.
Last but not least, all IaaS solutions are not created equal. Some offer services that go well beyond the mere renting of computing and storage resources – such as offering a Content Delivery Network (CDN) or providing access to sophisticated database engines. When running on such an IaaS architecture, the PaaS/SaaS provider could resell those additional services, provide the end customer with an abstract interface to access them in a vendor-neutral fashion, or, more simply, let the customer use them. In the latter case, the customer will want to make sure it is running on that particular IaaS, despite delegating systems and software stacks to a PaaS/SaaS provider.
As we’ve seen, “the cloud” is actually composed of several distinct layers, each providing value in a very different fashion to certain audiences. In particular, IaaS, through vendors like Amazon, catalyzes the adoption of the cloud and is getting an enormous amount of attention. But as cloud layers mature and enterprises become more educated about them, focus will shift away from IaaS and move towards PaaS and SaaS, the more directly actionable layers. Therefore, unless you are a PaaS vendor yourself, chances are you won’t directly care about IaaS; you’ll just move right to PaaS and SaaS solutions.
Up next in the blog series: The Death of Operating Systems (as we know them).
To learn more:
- Get the white paper, to read the complete blog series
- Watch Sacha’s presentation, The Cloud as a Tectonic Shift in IT, on video
The Cloud as a Tectonic Shift in IT:
- Part 1, The Industrialization of IT, Sacha compares the evolution of electricity and its delivery with the evolution of IT. He draws parallels between the instant-on access and pay-as-you-go models in the power industry with the evolution occurring now in IT service delivery.
- Part 2, The Irrelevance of Infrastructure as a Service (IaaS), see above
- Part 3, The Death of Operating Systems (as We Know Them), Sacha talks about how the operating system will evolve under the new IT service paradigms
- Part 4, The Death of Middleware, Sacha looks at the impact of PaaS on traditional middleware