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.

Private cloud IaaS Evolution - Failures were the stepping stones to success

Before we examine cloud computing lets 1^st understand some of the factors that precipitated the need for cloud computing.

Cloud computing started with the Web, allowing  Enterprises to promote their information in a form that could be accessed from anywhere (geographically) and from anything (devices) without needing  any client side software (VPN,…).  Realizing the convenience of the Web,  Enterprise users also wanted access to their private Enterprise information through the Web as well (email, CRM & ERP data, HR data, financial data,…).  

All this external access caused a large headache for the Enterprise IT staff where the carefully articulated rules of the intranet simply did not apply to the internet (capacity planning/scaling, security being under a physical lock and key,…). The Enterprise IT staff had to scramble to meet the requirements of their customers through adhoc scripts and home grown solutions/processes designed to scale and secure their current environment to meet the requirements of the internet. 

The formalization of these processes is what I believe to be one of the fundamental requirements that led to today’s Cloud computing.

But that still leaves the question of what does it offer IT departments?  In its simplest form, the Cloud was attempting to solve 3 fundamental IT problems.  Managing Cost, Risk and Service levels.

 

Though there are many technologies that make up  Cloud Computing, there were 2 fundamental technology building blocks that became the foundation for modern clouds.

1.    Virtualization: In this context, virtualization is an abstract representation of a new resource from the underlying physical resources (compute, storage, network, services).   

Note: There is a common misconception that virtualization involves a single large resource (ex: a physical computer) to be partitioned into smaller pieces (host virtualization like Xen, or, as in the case of OS virtualization like LXC). 

Virtualization can also go the other way, where many smaller resources (physical computers) can be aggregated together to also form a larger single resource (ex: shared memory computing system).

2.   Clustering: Allows the above partitions to re-form into dynamic groups with an interdependency between them.   These interdependency's are basic clustering requirements like heartbeats, quorum, cluster membership, fencing, service management frameworks (another future blog of mine),…. of distributed computing.

Having these 2 disparate capabilities of resource optimization and distributed systems coming together on a single platform/system, enabled a flexible and powerful framework; thus setting the stage for cloud computing. 

It took a long time to adopt cloud computing because Enterprises were justifiably wary of the issues exposed by the public cloud (security, performance, failures,..). and so IT providers scrambled by providing private cloud’s (that’s where the money was).  Early efforts in Private cloud IaaS solutions were also not very successful.  There was a fundamental problem that I saw, essentially,...   

What problem were we really solving for the enterprise through this private cloud IaaS?

IaaS gave Enterprises a consistent way to dynamically and efficiently reuse computing resources at the infrastructure level.  However the Enterprises had already solved this problem though various home grown scripts of their own and were opposed to ripping and replacing their familiar well-orchestrated home grown scripts with another vendor’s solution.  Having no consistent standard between various IT providers, IaaS solutions simply added to the controversy.

A lot of this changed with the emergence of initial standardization efforts (Open Stack, Cloud Stack, AWS,..) to provide a consistent approach towards IaaS. 

 

At least 2 things worked in Open Stack’s favor:

1. Adoption:  Many IT vendors abandoned/aligned their private efforts towards Open Stack.
2. Open development: Unlike the politics of normal standards in the computing industry, Open Stack took a more pragmatic approach by providing Open Source development to everyone in the industry (and then took an aggressive stance in formalizing releases).

Of course, we can always debate the problems with Open Stack (vendors morphying the stack, Open Stack aimed at developer play rather than a deployment ready model, ...), nonetheless Open Stack finally provided the necessary ground swell for the Enterprise data centers to take cloud computing seriously. 

Pioneering the cloud - My personal journey

The cloud like everything else (big data, vitualization, SDN), are not “conceptually”, new ideas. Every future “incarnation” of a past idea does however differ in scope, capability and opportunity.  For over a decade people have been mulling on what “cloud” means.  Not wishing to continue beating a dead horse, I want to instead focus on factors that influenced the concepts that led to what we call as cloud today.   Generally a lot of credit is given to Salesforce and Amazon AWS as trailblazers to cloud computing.  True as it maybe, there is always a story behind the story.  This is my story.

I did not invent this incarnation of the cloud, but I am fortunate to have worked with folks like Khalidi, Hisgen, Penkler, Schroepher, and many others, who helped create the initial concepts.  Most of all, I am deeply privileged to have eventually led pioneering efforts that directly influenced/resulted in cloud computing as we know it today. 

My personal story on cloud computing evolved as a result of work on a single system image (multiple machines running a single operating system across them).  The clustering group at Sun, while building an SSI (single system image), had an epiphany.  Why create a single system image when a “perception” of a single system image may be sufficient to achieve high availability goals?  In doing so, we focused on creating this “perception” by virtualizing OS services (like: devices, file system, network, host applications, ..) across multiple machines.  This virtualization layer later influenced the thinking/foundation of a revolutionary project at Sun called N1.

Its at this point in time when we had another epiphany.  Could we extended this concept of “perception” and “virtualization”, from Sun Cluster into systems management, such that we could manage N systems as though they were 1 (N1)?    In doing so, could we then help balance a customer’s costs, risks and service level in a more optimal way?    Sun then embarked on realizing the dream of N1 (the predecessor to what we now call as IaaS – Infrastructure as a Service).

At the time, other system companies, feeling left out, publicly coined similar concepts: IBM with Autonomic Computing, HP with Adaptive infrastructure, even Microsoft got in on the act with Dynamic Systems Interface.   

While N1 and others, took a ground up approach (IaaS) to building what we call as “private clouds”, a parallel top down effort (SaaS) with ASP like capability was quickly evolving into “public cloud” services.  Then with the launch of Salesforce and Amazon’s AWS services, the term “cloud” got cemented in history.

Though this is not a complete list of offerings, I have attempted to sketch out a very rough time line of this evolution.

I thoroughly enjoyed my time in N1.  Under my watch, back in 2005, we had even demonstrated live migration of fully saturated Oracle instances from one physical machine to another in a matter of minutes.  Sadly, it was way ahead of its time and eventually N1 faded from Sun’s history with parts of it being used in various other initiatives.  Though there were many issues to tackle in the evolution of N1, the biggest problems to overcome had to do with human behavior.