The Hijacking of PaaS: Cloud Runtimes are the Real McCoy

Nov 29, 2011 by Sinclair Schuller

Platform as a service (PaaS) has been hijacked. PaaS was supposed to be a critical bulwark in protecting cloud computing from the frail models of earlier computing eras, but to many, has become a category to dump anything that is tooling to help with some part of managing and deploying applications on cloud infrastructure. It will take some time to explain, hence the long post. I started thinking about this after reading posts by two cloud evangelists for whom I have tremendous respect and were venting their frustrations with the PaaS space – Krishnan Subramanian and Ben Kepes. Each published posts titled “AppFog Announces Java Support – What The Heck Is Happening In PaaS Space?” and “OpenLogic Announces General Availability of CloudSwing PaaS“, respectively, that delivered well-deserved jabs at the PaaS space. Why were the jabs “well deserved”? Because PaaS is littered with “me too” undifferentiated offerings that focus on “user experience” and “deploying apps”, that’s why. I’m less interested in understanding or claiming that a given vendor suffers from this, but more interested in the discussion of these issues in PaaS at broad. To understand this sentiment, we need to really spend some time to define what PaaS should be and what sort of trap the market is falling into.

To define PaaS, let’s first define an arbitrary collection of “traditional” Operating System (OS) instances on real or emulated hardware and any networking equipment associated with those OS instances as a resource pool. A PaaS’ can be best thought of as a computing platform that acts as a host to “guest” applications and that is layered atop a resource pool such that the details of individual  members of that resource pool are abstracted away and presented as a single logical layer to those guest applications. Guest applications are not privy to, bound to, or dependent on the details of components that are beneath the PaaS layer, thereby creating a rigid boundary. This abstraction reduces the amount of direct control an application has over its host environment, and in exchange, is provided certain functional guarantees and systems services. Furthermore, it could be argued that this PaaS computing platform be accessible to the developers who write guest applications in a self-service or near self-service way.  Up until this point, I think nearly anyone who considers themselves a student of cloud computing would agree. After this point, things seem to fall apart since:

• No one agrees on what PaaS should provide
• Those who do agree on what PaaS should provide tend cluster around certain functional capabilities, where the clustering *seems* (not certain of this yet) to not be motivated by ideology but by a market wide “easy win” mentality
• Hampering of creativity due to other cloud models such as IaaS distracting focus from making revolutionary progress on the more promising end game that is PaaS

The natural question anyone would have is “Sinclair, so what are the feature and functions that define PaaS beyond the systems definition you gave earlier?” I’ll do my best to provide some direction, and then circle back to the title of this post. As I described earlier, PaaS defines a layer that sits above a pool of OS/network resources, but below guest applications in such a way the details and control are abstracted away by the PaaS. As such, a corollary is that at a bare minimum, a PaaS *must* allow developers to deploy and manage applications in-spite of  the loss of control and being abstracted away from detail. This should not be looked at as a value of PaaS, but rather a requirement to achieve some level of fidelity with the pre-PaaS workflows that were part tooling, part developer manual labor, and part luck. No PaaS vendor should be proud of this achievement - it’s the scholarly equivalent of getting a ‘D’ on a test and trying to spin the fact that you barely passed as “100% success at not failing.” Granted, it’s a bit better getting a ‘D’ in that a minimally implemented PaaS at least takes the tedium of manual, time intensive, error prone application deploy and manage processes and automates them in a way that is generally flawless. Things like deploying apps and scaling apps become trivial button push operations on PaaS offerings, pushing application bits to servers and updating load balancers, among some other minor things. Nonetheless, this is not the revolutionary model that cloud computing has promised, at least that’s not what I consider “insanely great” and certainly wasn’t the model I envisioned to be world-changing when I co-founded Apprenda.

Going back to the title of this post, all PaaS’ are NOT created equal. Most “PaaS” offerings’ feature sets amount to the basics I described earlier. You see, PaaS vendors took the low friction approach of building “platforms” that merely stand up stack instances for apps being deployed through them (notice I didn’t say to them; these PaaS offerings do not act as containers to guest applications, but rather as fancy networked installers) and deal with some network component setup. In fact, some do as little as templating VMs with frameworks and stack components so that apps can be deployed with dependencies in place. This has short term sizzle, but in the long term does not provide any meaningful world changing value. What we have is a categorical skewing that sets up a market to conceptually think of something grander when they hear PaaS, only to find something less interesting.

The problem is that most generational shifts in computing were accompanied by new runtime models where the runtime or meta-runtime acts as a host to guest applications. Think OS, or application server, or even a browser’s Javascript engine. Cloud computing is typically broken up into 3 layers: SaaS, PaaS, and IaaS. PaaS was supposed to be the layer where the generational runtime model became defined for cloud computing; the layer that provides higher order intrinsic value peculiar to the new computing paradigm of cloud and resource abstraction. Some of us PaaS vendors share this vision and have started down technical strategy trajectories that define new runtime models for PaaS-based apps, while others have not. Cloud computing changes the computing model enough that to be a “platform” but not build a new runtime is likely to provide trivial value, and as a result, little differentiation among similarly tooled competitors. The lack of differentiation comes from feature convergence that is natural when systems lack a new model that can act as a spring board for differentiated value – which is exactly what a runtime provides. Subramanian and Kepes were likely identifying with this feature convergence, hence their frustration.

So why does a runtime need to exist, anyway? First, let’s level set on one thing: one of the major goals of cloud is to abstract away details of underlying resources. Period. Cloud forces an application-centric model (Thanks goes to James Urquhart for articulating this), and as such, needs to remove distractions created by irrelevant, low-level details. Much like VM-based runtime paradigms such as the JVM and CLR got rid of the need to deal with what integers were stored in what CPU registers, cloud should get rid of the need to worry about execution time details about OS’, network routing, etc. Cloud has done two things: it has raised the ceiling for potential application architecture complexity AND opened the door to new types of previously unavailable value. Without going through a formal proof of sorts, it should be obvious that a PaaS that merely pushes bits onto servers and updates load balancers is incapable of supporting the execution needs of applications that need to deal with abstract resource concepts and new levels of architecture complexity due to the nature of network-distributed resources. It would be akin to thinking that a fancy C++ library could provide pari passu value to the JVM: it simply couldn’t. As a cloud application executes, it needs an underlying active system that is doing constant heavy lifting to make magic happen, and not just waiting on the sidelines for the next app or infrastructure management event. A great PaaS will:

• Provide self-service access to developers
• Provide application management tools and capabilities
• Use a runtime model that sits underneath an application as it executes, but above the infrastructure with the intent of abstracting away non-strategic details
• Provides frameworks and APIs to access higher order value
• Manage the infrastructure in a way that shields the application from as much impact as possible

The last piece of this book-of-a-post is helping identify what a PaaS runtime looks like. An anchoring theme for a PaaS runtime is active participation in the execution of guest application code. As such, you will typically see non-trivial PaaS offerings do some number of the following things:

• Implicit participation in application messaging at various tiers of typical application architectures. Additionally, the PaaS my provide declarative or imperative control to guest applications over application messaging.
• Use “resident code” to instrument behavior into executing application code. Much like traditional runtimes forcibly load libraries into your memory space, PaaS runtimes may load code and data that co-habit your application memory space
• May use code generation to augment guest applications in a way that is orthogonal to the guest applications functions, but in alignment with the PaaS runtimes execution needs. This might be tough to understand if an example is not provided, and the only example I know of is what our Apprenda PaaS does. To simplify the example, let’s consider web services deployed to the Apprenda PaaS. REST and SOAP web services go through a compile phase when they hit our hosting containers. This compile phases adds control end points for direct P2P style communications with any instance of that SOAP or REST service, allowing the “node” to participate in direct control calls from the runtime fabric. The end result is that each node is an independent peer entity on the distributed system that is Apprenda, but is also “stitched in” to fabric behavior.
• Activate behavior autonomously based on what guest applications are doing. For example, on an application crash, detecting the actual error (where possible) and acting on it would be an example of this sort of autonomic management.
• Provide APIs and frameworks to the guest applications that trivialize access to complex architecture value. Think publish/subscribe, map/reduce, and message brokering models.
• Might influence or modify how requests and even threads behave in the application as the application executes.
• Provide general purpose APIs  for runtime services from the platform.

This list is definitely not exhaustive, but you get the picture. This the stuff that makes cloud runtimes real and interesting, and this is what differentiates some PaaS’ as being “insanely great” versus others that, while not bad, don’t provide this level of value. This is the stuff that the future is made of, and hopefully the market evolves quickly enough where Subramanian and Kepes can both agree that innovation and value abound.

read more

The Death of an ISV: How NOT to Succeed in your Move to SaaS

Jul 27, 2011 by Jesse Kliza

It wasn’t curiosity. It was thinking that the “good old” ASP model would cut it. It was thinking that little by little, they’d get away from labor intensive provisioning, manual billing, and some day refactor the Rube Goldberg contraption that made their “hosted” model work. Sound familiar?

Software as a Service has quickly become the preferred method of application delivery and consumption. Why is it that while many ISVs claim to provide some flavor of SaaS today, few are doing it with the same cost of delivery profile and operational agility as SaaS leaders like Salesforce.com, or Taleo?

Join Apprenda and Savvis on August 9th at 1:30PM EST for a webinar covering the most dangerous pitfalls that ISVs fall into time and time again. You’ll learn:

- The unprofitable truth about the ASP model
- Why multi-tenant infrastructure isn’t enough
- The real-world economics of SaaS leaders and laggards
- How to avoid building dozens of custom SaaS operations systems
- Key business and technical pitfalls when making an infrastructure choice

You’ll come away with everything you need to either “save the ship”, or leap frog your competitors with a SaaS strategy that rivals the best of the best.

Date: Tuesday, August 9, 2011
Time: 1:30 PM – 2:30 PM EDT

Register Here>

We hope you’ll join us!

read more

Which Part of the Public vs. Private Cloud Elephant Are You Touching?

Jun 10, 2011 by Sinclair Schuller

The private/public cloud discussion is something that has been getting lots of attention. I think one of the big issues is that different perspectives are causing people to speak differently about the same thing, and confusion around what public vs. private really is (e.g., what is a Private PaaS running on public IaaS) adds fuel to the fire. Maybe a parable can help. One of my favorite (albeit overused) parables is that of the Blind men and an elephant. The story is as follows: four blind men discover an elephant for the first time. Since they have never encountered an elephant before, they each touch a part of the elephant that they are closest to, feeling about so that they can assess what it is they are touching. One man grabs the elephants trunk, and determines that he is clearly touching a snake. Another grabs the tail, and concludes that it is a rope. The third, wrapping his arms around the leg, announces that it is clearly a tree. Last but not least, the fourth blind man runs his hands along the elephants side and determines that they have discovered a wall.

Clearly, they’re each interacting with the elephant, but are also each describing the elephant (based on their individual perspectives) in drastically different ways.

This is extremely relevant to today’s cloud computing discussion. Essentially, the problem we have is that cloud computing is our elephant, and although we are each interacting with cloud computing, we are suffering from the same problem as the four men in the parable; our “perspective blindness” causes us to only base our understanding on what we are capable of assessing, thereby failing to see cloud computing as a whole. This was extremely apparent after I wrote a post for GigaOM. Both in comments and in Twitter, I had people supporting and rejecting the notion of cloud technologies transplanted into private settings (such as deploying private IaaS or private PaaS). Some argued that public cloud provided X, and Y, and Z while private didn’t. At the end of the day, both public and private cloud can provide significant value to the various constituents in enterprise IT. To understand why private cloud might make sense to some and not others, we need to understand the relationships between the various parties in enterprise IT in the context of cloud computing:

(bigger)

Granted, the diagram doesn’t capture the finer grained details of the relationships, but it does define a framework to work off of. Each constituent in enterprise IT has a “primary” role when considering the application as the first class citizen of  the system:

1. Consumption
2. Application Development
3. Infrastructure Management

Each constituent is analogous to one of the blind men touching the elephant that is cloud computing. Let’s look at this more specifically. If you are a business end user that needs to source a certain application X, you can either a) use a solution that the developers within your organization have built on some private cloud or b) use an external SaaS provider (which apparently is  a growing trend in IT). From the business end users perspective, they don’t care if an app is running in a private cloud or public cloud, or is a custom solution coming from LOB developers within the enterprise or an external SaaS provider. They need an app for some specific business function to create value and solve problems. We can find lots of tangential reasoning as to why they should use public cloud only, but from a practical perspective, they just need to know that whatever app they are using fulfills all of their requirements (and constraints). If the app is provided by their own LOB developers and is deployed to the private cloud, that’s fine. If  they are using a public SaaS app, that’s fine too. Some apps might provide additional value in a public form factor, but it shouldn’t be the deciding factor.

Similarly, from the perspective of enterprise developers who build custom apps within the enterprise, they want to know if they can quickly and easily deploy their apps and get functionality from an underlying stack. The current IT model is broken: each dev team builds an app a different way, when it’s time to deploy, they contact IT and wait 30-60 days for a server to be provisioned, they manually configure the app, and manually deal with the app’s lifecycle using the same cumbersome approach that was used to get it up and running. Cloud (particularly PaaS)  presents a very agile model with blazing fast time to market, advanced architecture qualities, and little friction. Developers are simply looking to get past this antiquated approach; they might want to deploy to a public PaaS like Azure, but if central IT offered a private PaaS, they might prefer that because it’s less friction in terms of adoption and from their perspective, they get the same major benefits: upload and deploy apps at a button click, get scalability for free, and get other benefits like distributed caching as services. From the developer’s perspective, they’d get what they need, regardless of the form factor. It gets even more difficult parse if you consider that central IT could deploy a private PaaS to either their own private cloud, or to a public IaaS provider like EC2. Is that a public or private PaaS? Clearly, the IT team owns the Amazon account and is deploying their own PaaS layer to public infrastructure. From the developers perspective, it’s a private PaaS (as in owned by their organization), from central IT’s point of view, they are using public cloud. For me, this is a very real topological distinction since our customers can license SaaSGrid and deploy it to their own bare metal infrastructure and get a private PaaS, on their private virtualization cloud and get private PaaS, or on something like EC2 and expose a PaaS to their internal developers. We don’t necessarily care, but the lines are clearly blurry as to which is “more public”:

1. Private PaaS on Private Cloud
2. Private PaaS on Public IaaS
3. Public PaaS

Is number 2 more public or more private? This highlights the absurdity of the debate that continues to come up in nearly every public/private conversation. At the end of the day: who cares? If the end users in an organization want a specific offering provided in a SaaS fashion: great. If they use an offering built by their LOB developers and deployed to their private PaaS on their private cloud, or their private PaaS deployed on public IaaS, they’d be just as happy.

In some instance, public cloud makes the most sense, in others private cloud. Sometimes, real costs of adopting public cloud severely impact it’s ROI, so private cloud gives some of the benefits with less costs, causing private cloud ROI to be higher. In other cases, public cloud can be adopted using little friction and is the way to go. I think the sooner we recognize that the fierce debate of whether the elephant is a snake, a rope, a wall or a tree is silly, and that we should each be comfortable with the fact that our perspectives might influence or judgment, the sooner we can all focus on extracting value from cloud tech.

Do you agree that both public and private cloud are relevant? Are you passionate that cloud is public only or nothing? If so, why?

read more

Using a Bus to Frame an Understanding for Public Cloud vs. Private Cloud

Jun 6, 2011 by Sinclair Schuller

I recently wrote a piece that was published on GigaOM that uses a bus (as in vehicle) analogy to try and establish a conceptual framework for the public vs. private cloud discussion. Check it out here!

read more

After Amazon’s Stumble Anti-Cloud Rhetoric Is Expected, But Is It Warranted?

Apr 25, 2011 by Matt Ammerman

I like Phil Wainewright of ZDNet’s take on the Amazon incident last week. I like it partially because his post-chaos “seven lessons to learn from Amazon’s outage” reads oddly similar to my recent Transparency in the Cloud series. Mostly, though, I appreciate Phil’s approach because all of his lessons are targeted at the cloud services consumer.

Without a doubt, the blame for last week’s outage falls squarely on Amazon’s shoulders, but the responsibility to understand risk and adjust appropriately is in the hands of those that choose to use cloud-based services either to consume services, or to provide services to other companies.

One thing about centralizing services in the cloud is that it makes everything extremely visible. What was traditionally hidden behind private firewalls is now out in the open for everyone to see. I have a hunch that the aggregate downtime and subsequent hours spent by private IT departments on a regular basis far exceeds even the four days it took Amazon to clean up after this incident.

Which brings me to my point:  There are two things that cost money during outages – 1) lost business, and 2) resolution efforts.

Lost business is a sunk cost, whether the outage is with your website hosting company, your cloud services provider, or inside your own private datacenter. The mere fact that you are in an outage situation means you are losing business. The difference is that in a private outage situation, you are also compounding the loss by shelling out the dollars to fix the problem. In this case, it was Amazon’s software (and/or hardware) that failed, let them foot the cleanup bill (and they happily will)!

Regarding the anti-cloud sentiment that seems to be pouring from mainstream outlets, I’ll borrow from CNN’s sensationalistic metaphor. Did we stop building ocean liners after the Titanic sank? Did everybody start crossing the Atlantic in tiny dinghies because they didn’t trust larger ships?

Smart people who specialized in the things that went wrong with the Titanic figured out how to make those things better and prevent disaster from happening again. Given that we all know there’s inherent value in cloud services, instead of throwing around anti-cloud sentiment, let’s all focus our energy on helping cloud providers like Amazon get better at it. We can do that by learning and applying our own lessons, and contributing our own technologies and talents.

read more

The Cure for the Common Cloud

Apr 20, 2011 by Jesse Kliza

Let’s face it.  There’s a lot of hype around “the cloud.” Lots of promises, lots of claims, lots of vendors, and lots of lackluster results.  All the while, software engineers and architects are getting sick of it.

If you’re a software engineer or architect, what does the cloud do for you? It’s elastic and infinitely scalable, so you just put your app up there and everything magically works, right? The cloud solves all of your scalability challenges, all of your app delivery challenges, and it just plain works, right?

Wrong. You’re the one responsible for building the software that the cloud exists to host and deliver, and you know full well that there’s a lot more to it than that.

What about onboarding new customers or business units to your app?  The individual end-users – how do they get access, and to what are they entitled?  What about charging for different features, or different transactions?  What about managing the application lifecycle, and rolling out updates?  What about the underlying architecture to make use of the cloud in an intelligent way?  To actually take advantage of the raw compute power at your disposal, and not just use the cloud like it’s the late 90′s again and people are throwing their apps online like it’s going out of style.

These are the types of things that software engineers and architects are thinking about.

Haven’t we been through this before?

There are many significant engineering challenges associated with building and delivering applications today.  This is very similar to when we first started developing applications for the desktop PC.  Back then, everyone wrote code to manage memory, to interface with specific hardware, etc.  Then the desktop OS came along, and made all of that complex and time consuming (but CRITICAL) work a thing of the past.

While the challenges themselves were different, they were still challenges that were specific to the delivery method, rather than challenges associated with building the actual software functionality.  Those challenges will always be there, because the passion to innovate and develop applications that help facilitate better business performance, and meet the needs of end users is what drives great engineers/organizations.  HOWEVER, the challenges associated with the delivery method/paradigm go away in time, as layers of abstraction come about to solve those problems for us.

The “Cure for the Common Cloud” is Here

Now let’s get back to today.  Shouldn’t we expect that all of these challenges associated with building and delivering next generation software applications in this new cloud era will become a thing of the past?  Won’t we be able to focus on building great software again, and not worry about all of the complexities of the delivery method?  Someday?  Maybe?

Yes.  We can today!

A large and increasing number of organizations and developers have discovered the “Cure for the Common Cloud“.  They’ve found the abstraction layer that handles all of the complex engineering challenges associated with building and delivery applications today, and truly leveraging private or public cloud infrastructure in an intelligent way.  They’ve found the one technology that decouples apps from infrastructure, developers from IT/Operations, and business execution from IT implementation.

The Cure for the Common Cloud is here.  Do you have it?

read more