Why SaaS and PaaS will eventually eclipse IaaS?

This is the second article in my “bold, audacious and somewhat outrageous” series. This one is a logical follow up to “Why (public) cloud will eclipse all other forms of IT?”

In this article, I’m going to make a case for:

Prediction #2: Why SaaS and PaaS will eventually eclipse IaaS?

First, some definitions (not the Wikipedia type, which, in an attempt to be technically accurate, end up becoming too hard to parse). I’ll spend more than the usual one-liners on explaining each of the three flavors of cloud by providing examples and alternatives. This'll set the stage for the arguments that follow in support of the core thesis of this article.

SaaS (or Software as a Service)

Essentially, this is any form of IT functionality that you access and use without having to install any application software (and the associated HW infrastructure). Most SaaS offerings are accessed through a browser, but also increasingly through apps and eventually through bots. Most SaaS apps also have their equivalent on-prem counterpart. However, the latter requires you to elaborate software and HW infrastructure on-prem.

The best known enterprise SaaS is perhaps salesforce.com for CRM. Unlike the shrink wrap software of the past which you install on-prem and spend months configuring and customizing, you just open an account and enter/upload your data and you receive a PAYG bill for the services you have used that month. There are several similar examples in the enterprise space, such as Oracle Fusion SaaS, Workday, etc. In the consumer space, Google’s Gsuite which includes Gmail and google docs, and Office 365 are also examples of SaaS. Your alternative to online email will be to install MS Exchange for the server and Outlook for the client, manage all its HW infrastructure, its patches and upgrades etc. If you use Gmail for enterprise, you don’t have to deal with any of that. You get your personalized corporate email and you pay per user. In this respect, Hotmail.com (c. 1995, later acquired by Microsoft and rebranded as live.com) was probably the world’s first SaaS offering.

IaaS (or Infrastructure as a Service)

With IaaS, you get pretty much the same IT experience as on-prem, except that you don’t have to deal with HW (servers, storage, networking, etc.) You do however have to select the type of HW instance (CPU, memory, flash etc.). You can request one of the pre-packaged OS images, or you can create your own with custom patches, custom libraries, custom middleware and custom applications installed on it. The images are spin up/down and scaled on demand and you PAYG, but you still have to manage the entire software stack yourself. You still have to manage your block volumes, file shares or object storage, you have to setup DNS and networking, users and security using the primitives provided by the cloud provider. Pretty much everything you did on-prem, except you never get to see the underlying HW.

AWS EC2 is an example of the compute offering, AWS EBS is a block storage offering, AWS EFS is the file share offering and AWS S3 is the object storage. In addition, AWS also offers LBaaS (Load Balancing as a Service), DNS as a Service and other primitives.  Oracle similarly has its OCI (oracle Cloud Infrastructure) IaaS offering which offers all of those same primitives. While this gives you the maximum flexibility, it also puts the most onus on you to stitch everything together.

PaaS (or Platform as a Service)

Somewhere in between is PaaS, which is probably the most poorly defined and least understood. The idea behind PaaS is to abstract the lower layers of the software stack and the IT infrastructure, and have you focus on the business/application logic. The “platform” (as opposed to the infrastructure) takes care of many/most of the chores of IT that come with IaaS (to varying degrees, as we shall see later). The problem with PaaS is that there is no shared understanding of what it means, much less a common platform. 

Arguably, one of the first implementations of the “platform” was EJBs (Enterprise Java Beans) and its various implementations that were interestingly called middleware, such as BEA WebLogic (acquired by Oracle), IBM WebSphere and Red Hat JBoss. If you are writing your application in Java, then these platforms provide a reasonable option to let you focus on the business logic while the platform takes care of the life cycle services. In the cloud, PaaS can mean a wide range of offerings – from a simple DBaaS (DataBase as a Service, e.g. Oracle DBCS and AWS RDS) to Middleware as a service (e.g. Oracle Java Cloud Service) to Google App engine which provides a bunch of capabilities such as persistent store, reliable messaging, in-mmeory database etc.

At the other end of the spectrum, you have containers, the best known of which is Docker. However, the Docker containers are trying to solve multiple problems at once – packaging, reducing the app footprint, making apps stateless, scalable and resilient. Plus you have to choose among Kubernetes, Docker Swarm, Mesosphere and few others for the orchestration layer which is so essential to delivering on the PaaS promise. While Dockers are certainly an improvement over heavy-weight VMs, you still end up dealing with many of the lower level infrastructure complexities. Then there is a new category called FaaS (or Function as a Service). Examples of this include AWS Lambda (in combination with Beanstalk), Google cloud Functions, Salesforce Heroku and Oracle Fn. These platforms attempt to abstract out lower level details, letting you define only the functionality that you want executed, often in response to pre-defined events. 

IaaS is only a stop-gap:

Customers have huge investments in their IT infrastructures on-prem. They want to take advantage of all things cloud, but often find themselves limited by those on-prem investments. Moving to a SaaS platform, even when identical functionality is available, often means lengthy data migration and risk of disruption to the business. Plus, it requires retraining staff on the new SaaS interface. IaaS offer an alternative by promising to take the HW and the data center off of your hands. You can take your on-prem software environment and, after some modifications, migrate it pretty much as-is to the cloud. If you have VMs running on-prem, you can migrate those VMs to the corresponding HW instances in the cloud. 

However, you are still managing all of those VMs, all of the underlying storage and networking. You still need to know the difference between and pros/cons of SSDs vs NMVe, block vs files vs objects, for example. You still need to take your backups and plan your DR. I guess the only thing that’s different is that you no longer have to rack/stack the HW, worry about HW break/fix and refreshes, and maintain a physical DC facility. So, in this respect, IaaS is the next evolutionary step in the transition from silo’ed on-prem infrastructure to virtual shared infrastructure on-prem (aka private cloud) to MSP (Managed Service Provider) to now IaaS. But it’s not the end point.

If you can choose SaaS, why won’t you?

SaaS to me is the ultimate realization of the promise of the cloud – nothing to install, nothing to manage, access from anywhere, pay as you go and focus on your core competency which is not IT. Of course, the decision isn’t always technical. You may have long term license agreements or support contracts, which is why moving to SaaS is often triggered by a compelling event such as HW refresh or license renewal. You fear the disruption caused during the migration between two vastly dissimilar platforms. This is a valid concern but most SaaS vendors provide tools that help minimize the risk and the disruption. Not all the functionality you need is available in SaaS. This may be solved through a combination of negotiating with the vendor plus some modification to your business processes or even building on top using the APIs provided by the SaaS vendor such as force.com. I’m not trying to trivialize any of these challenges but the payoff from moving to SaaS can well be worth some cost and hassle during migration.

But what if the functionality you need isn’t available in SaaS?

Sometimes the gap between what the enterprise needs (or, is used to) and what’s available in SaaS is too big to bridge. In other situations, the application may have proprietary logic which is actually the core competency of the enterprise (such as trading or a banking application). In both these cases, as attractive as SaaS may be, it’s just not an option. That doesn’t mean, however, that you have to regress all the way back to IaaS. This is where PaaS offers a reasonable alternative. Just like “just add water” in cooking, you can think of PaaS as “just add your business logic” and you have a fully functional, scalable, resilient, and accessible from anywhere application.

This is why I think Docker, despite being superior to VMs in terms of its “weight”, packaging and portability, misses the mark on PaaS. With its emphasis on self-contained and executable images, it still requires you to think about all of the software dependencies, libraries, patches etc. This is also why, while still new and immature, I believe the FaaS genre of platforms (Lambda, Heroku, Fn, GCF, etc.) hold more promise because they tend to abstract more of the underlying infrastructure than Docker containers. The nirvana here would be a microservices platform that allows stateless services embedding modular business logic to be defined and aggregated using a visual interface while the underlying platform takes care of not just the typical HW and OS services (compute, storage, networking), but also higher level services such as auto-scaling, resiliency, upgrades (including version mismatches), persistent data, etc.

Finally, a caveat:

While I don’t doubt SaaS and PaaS will eventually replace IaaS, it is going to take several years to fully materialize. The reasons behind this in many ways are similar to why on-prem IT will have a long tail, just as many of the technologies preceding it (mainframes, RISC servers etc.) continue to do following their decline.

IaaS is an easy alternative that minimizes the disruption from moving to the cloud while still giving you some of the benefits. For that same reason, it also falls short in realizing the full promise of using cloud like a true utility.

SaaS is the ultimate realization of that vision but is limited in choices and causes disruption in migration.

The problem with PaaS today is that there is no shared understanding of what it is. Like the proverbial blind guys trying to figure out an elephant, each PaaS vendor seems to be optimizing for a different subset of requirements. The immaturity of this technology is evident in just the sheer number of alternatives out there and the links I included in the PaaS section (which BTW is by no means an exhaustive list). The fact remains however that the vision behind PaaS, when fully realized, promises to make IT truly accessible like a utility.

As always, let me know what you think. I welcome your comments (agreements and disagreements alike) in the box below.