Enablers of change leading up to Platform as a Service (PaaS)

Recognizing that the computing “services” are the center of attention, PaaS is primarily about using a collaborative platform to increase service efficiency (scale, cost,…) while 

• Developing services.
• Deploying services.

Before getting deeper into PaaS, we should 1^st understand the burning problem that PaaS is addressing.   The answer to this question, interestingly, lies in the evolution of change that led to the creation of Platform as a Service.

While the IT side of the house was keenly interested in scaling service deployments, the developer side of the house was also keenly interested in “scaling” (which means creating more efficiency) in the development of services.

When people loosely talk about a dynamic, flexible and scalable IT environment, they really mean it in reference to services.  What the customer “really” wanted from the cloud (scaling the service) and what the customer really got, from the cloud  (scaling the infrastructure), was an incomplete answer to their services creation and delivery problems.  Platform as a Service, as we know of it “today” enables a solution to address both sides of the customer problem (deployment and development).

• Deployment of services:     The IT side of the house looked at Platform as a Service as the ability to automatically deploy and scale “services” on demand at "internet scale".  At the time, scaling of services was already being addressed through the use of network load balancers, within data centers. While a little more static, the data center model worked well when the capacity of the traffic was better understood. What was not really addressed here was the scaling to the ever changing demands of the “internet” part of the equation.  This required more automation in the data center to automatically use (or release) idle resources as being done in the cloud.  It eventually took the spike in demand from mobile based services to recognize the unquantifiable capacity needs of internet traffic, and to really address the economics of scaling services within a cloud like environment.

• Development of services:    At about the same time another important factor influenced the definition of Platform as a Service as we know of today.  The developer side of the house looked at Platform as a Service quite differently from how the IT and deployment side of the house perceived its value. They (the developer), looked at Platform as a Service as a way to economically address scaling the development of services.  There were many attempts along the way to formalize such efforts (like the one from Sun Labs called Project Caroline, that I am familiar with).   

Moving to Platform as a Service:

 All these early efforts around PaaS suffered from a fundamental problem. The disconnect between the “enterprise” and the “internet” companies on the “constructs” of what constitutes as a service.

The way that services were constructed in the enterprise (using an ESB), was very different in the way that services got constructed by web and internet companies (using the RESTful style of web service construction).  Naturally it was difficult to define a common platform for developing and deploying services if there was no clear agreement on the constructs of a service.  Undeterred, the web and internet companies forged ahead with their definition of services, and created mechanisms leading to an efficient DevOps framework.

Eventually the tepid appreciation for the RESTful style of web services by the enterprise, opened up opportunities to a more commonly acceptable framework for services and the PaaS model emerged.   (For the curious reader, I briefly talk about the evolution of service construction in the footnote below - click the read more button).

Platform as a Service (PaaS):

The principles of DevOps / Continuous Integration, Continuous Delivery, enabled new modern, scalable, distributed, platforms into an integrated framework to develop, test, deploy, modify, and upgrade services in a very efficient, scalable, and agile like environment. 

Using the principles behind the DevOps model and layering a service delivery framework above the IaaS layer in the cloud led to the foundations of what we call today as Platform as a Service. There are many flavors in today’s PaaS offerings, some involving very specific capabilities (which may or may not use Web services, or some of the examples as mentioned above). Some or all of the methodologies mentioned above can be found in today's Platform as a Service frameworks.

In summary: 

As I mentioned in one of my previous pioneering-cloud-my-personal-journey the concepts leading to PaaS are “not conceptually new ideas”.  As an example, while at Sun Micosystems, we had 

• Implemented almost all of the capability mentioned under “continuous development/ continuous deployment” to enable the efficient development/development of Sun Cluster.  While these home grown tools were efficient, they were also expensive to develop and maintain. Developing such home grown capabilities, was not unique to us, with many other enterprises also involved in such expensive endeavors.  What is different today is the efficient use of “standard” tools like Git, Gerrit, Jenkins, Puppet/Chef, Vagrant, Docker,…. which enable a DevOps framework, but were not readily available at the time.  This led us (and everyone else) to develop such home grown tools while also developing the product.  With the adoption of web services in enterprises, such capability quickly got adopted in the development of services, and terms like DevOps/CICD got deeply rooted.  This finally allowed the cost burden to shift into where it should be – in product development.

• The service delivery framework for PaaS as in the case of Open shift and Cloud Foundry are  also remarkably similar in concepts to the HA Service framework that my group had created in multiple versions of Sun cluster.  (Perhaps more in the next blog).

• Recognizing the importance of efficient service delivery, the N1 group at Sun Microsystems had at the time, a general service delivery product “N1-SPS (service provisioning system)" to enable the easy deployment of “services”.   While, this provided some exceptional capabilities as part of the N1 suite of products, it was also too early in the adoption cycle for enterprises.  It also lacked the integration of development—to-deployment as characterized in today’s Platform as a Service.

I am very excited about the future of cloud technology.  For a long time I have held a strong belief that Platform as a Service (PaaS) is really where differentiation in cloud computing will happen.  The dirty little secret in Silicon Valley is that very little is being invented that has not already been done before (in some way form or manner), but, I am hopeful that future technologies will be built bearing in mind any mistakes of the past.