ServiceMesh

In my Cloud Expo presentation a couple of months ago, I went through a progression of infrastructure provisioning systems over the past decade. I noted that while we have certainly accomplished a lot over that time period, business-unit (BU) users are increasingly discovering that they don’t want to provision and access resources at the infrastructure level (IaaS).

The fact is, we have been victims of blindly automating historical processes and procedures. In the old, old days, BU users asked IT for “servers.” Over the past few years, we turned all those “servers” into cloud-based VMs. Now, we can fulfill the old requests faster, but the real question is, are BU users asking for the right thing? As BU users ponder that question, the answer is increasingly, “No.”

IaaS is the lowest common denominator of “the cloud.” You can use it to build just about anything you want. But for BU users, it’s the as-a-service equivalent to programming in assembly language. The user controls everything from the operating system on up, but that also means that the user is responsible for installing, configuring, and maintaining everything from the operating system on up. And most of the time, that’s just needless work. BU users are increasingly turning to PaaS to gain greater leverage. Like a high-level programming language (e.g., Java), PaaS implements a lot of the rote application logic that is common in most applications.

For instance, if your application needs a database, then with IaaS you would have to install and configure something like MySQL. If you wanted a high-availability configuration, you’d need to create that yourself. If your application was running slowly, you’d need to hire a DBA to tune the database install. Similarly, if you needed a message bus or web server, you’d be responsible for selecting those, installing them, and tuning them. The good news with IaaS is that you have complete flexibility; the bad news is that you have complete responsibility.

In contrast, a PaaS system will implement a lot of that middleware functionality for the programmer. PaaS systems typically include databases, message busses, web servers, and other common components out of the box. The PaaS API dictates how the programmer accesses the functionality. The tradeoff here is that the programmer doesn’t get to choose all the underlying components (MySQL vs. PostgreSQL, for instance) but they are already pre-configured, maintained, and optimized by others. This allows the programmer to focus on the unique logic that defines the application, rather than getting bogged down with system administration tasks.

There are several good PaaS platforms out there. Microsoft has Azure; Google has App Engine; Salesforce.com as Force.com and Heroku; VMware has Cloud Foundry; etc. These are all fine public, multi-tenant solutions, built to operate at web-scale.

Unfortunately, there is a downside to everything. While PaaS certainly increases developer productivity, public PaaS offerings suffer from a number of inherent problems. In a following post, I’ll discuss some of the downsides with public PaaS and offer an alternative — enterprise private PaaS.