Unfortunately, the negative potential of lock-in has increased in severity due to cloud, and more specifically, due to PaaS. Lock-in risk in PaaS is defined as the sum of two components: a static lock-in risk that is the same in nature (as described earlier) as the platforms of prior computing paradigms and dynamic lock-in risk that is dependent on a set of constantly changing assumptions. When one decides to build apps on a PaaS, they should be evaluating two things:

1. How good is the ‘P’ part of PaaS – the platform itself? This is an evaluation of the actual runtime, APIs, frameworks, management capabilities, and engineering value I can extract when I write code targeting the platform. Additionally, how proprietary is all of this to the PaaS provider (i.e. how severe is the lock-in requirement to get access to this value? Is it just APIs, runtime behavior, etc. or a new, proprietary and non-standard language?)
2. How good is the ‘S’ part of PaaS – that is, the service. This is an evaluation of the stability, cost, performance, and quality of the hosting capabilities of the PaaS.

Evaluating P is relatively easy because you can experiment with it and get a feel for the value and whether you are willing to trade that value for some lock-in. Additionally, P lock-in is much more static in nature which means that you likely don’t need to worry about significant changes in expectations. The S is scary. Hosting quality, service levels, performance, and price could be one thing today, and something very different tomorrow. You might deploy to a PaaS and say “Wow, things are running so smooth and fast, and the price is just right,” only to have the rug pulled out from under you without notice, or worse. If the P is high/non-standard lock-in and the S is limited or no choice, you’re screwed.

Why does this happen? The short of it is that if a PaaS provider is the exclusive vendor of both P and S, any lock-in to P translates directly into lock-in at S. That is my code can only run where my PaaS vendor tells me it can run. For most PaaS vendors, this means that you can run it on the service provided by – wait for it – the PaaS vendor alone! This is some really dangerous stuff and a tremendous amount of business risk. Having mission critical apps coupled to a hosting layer that needs to prove itself each minute of each day and has a very dynamic nature both in terms of quality and price is not good. How do you protect against this? Some of us (Apprenda, CloudFoundry, Cumulogic, among others) have decided that the P part of PaaS is the high value layer, and that S should be commodity and flexible, and frankly, irrelevant so long as it delivers on basic promises. This ‘Open PaaS’ model is one where rather than having P coupled to a single S, you might have dozens or even hundreds of services that offer the platform, essentially giving the developer choice of where to deploy apps while getting the full value of the platform; a “no lock-in” hosting model. This portable PaaS form factor is here to stay. Not only can one deploy to any service provider that is offering a (hopefully) differentiated instance of that particular PaaS, but the PaaS software is likely downloadable so that you can even download the PaaS software and run it on your laptop. This decoupling of the P from the S is what can bring lock-in down from the clouds (cheesy pun intended), and back to some sense of normalcy. Sure, you still need to commit to the PaaS and adopt its APIs and will grow dependent on its runtime capabilities, but as a customer of ours put it: “I’m OK committing to a platform, I’m not OK being locked into a service provider.”

I’ve even drawn this myself (and will continue to do so in the context of market education). The problem is that this diagram is intended to communicate a conceptual, “lay of the land” hierarchy that describes a cloud-only stack where all layers are dependent only on other cloud layers. Clearly, there are tons (dare I say even a majority) of SaaS vendors that do not fit this at all. Some have neither PaaS nor IaaS below them, and some have only IaaS below them. Some SaaS vendors didn’t have these options at their disposal when they built their SaaS offerings. If they were starting today, I would encourage them to use a PaaS layer for a number of reasons. PaaS is no different in that one could be built without depending on IaaS. The one difference between PaaS and SaaS, however, is that I wouldn’t encourage anyone to build a PaaS that explicitly depends on an IaaS layer.

PaaS is typically built in one of two ways:

1. With infrastructure multi-tenancy, where each guest application is isolated from other guest applications by using virtual machines. Each application gets its own dedicated OS instances, so the PaaS isn’t really multi-tenant, but instead, relies on multi-tenancy one layer down. In this case, the PaaS is a fancy packaging system and VM template manager with some load balancer bells and whistles.
2.  With true PaaS multi-tenancy, where the PaaS manages pools of OS resources and co-habits applications on shard OS instances. This is typically achieved using something like process level isolation to safely segregate different guest applications from one another. In this model, there is no inherent functional dependency on virtualization (IaaS or otherwise) because the PaaS does some complex leg work to do its own higher density multi-tenancy.

In architecture 1, there is an absolute dependency on either an IaaS or some hypervisor technology. For a variety of reasons, I do not consider this an optimal PaaS architecture. Architecture 2, which I do consider a real PaaS, is doing work inside of the OS rather than outside of the OS. It achieves multi-tenancy using a much different technique. This technique can be layered on any pool of OS resources, physical or virtual. Nothing about architecture 2 creates a hard dependency on virtualization or IaaS.

If a PaaS is built using architecture 2 (which is what we’ve done with the Apprenda PaaS), it should purposely avoid acknowledging the existing of a hypervisor technology. In fact, it should assume that everything is a standard OS instance. This does three things:

• It promotes implementation behavior that prevents the PaaS from being locked into underlying expectations
• It ensures that the PaaS provider writes an appropriate systems architecture so that interaction with an IaaS/hypervisor layer can be bolted on as an optimization to ease management of the PaaS. For example, if I am operating the PaaS and I need to provision more capacity on the fly, it would be nice if the PaaS could detect it is running on EC2 and spawn new VMs to include as PaaS capacity, or do the same if it is running in a private cloud environment atop of virtual machines on <insert your favorite hypervisor here>.
• Allows a PaaS to be deployed in a reduced complexity and lower cost environment where no virtualization exists. Let’s assume that 10 years from now, an enterprise or public PaaS provider achieves 100% penetration (all new apps going forward only on the PaaS), why keep virtualization around? The apps don’t care about virtualization, and certainly, the PaaS provides the elasticity and insulation from effects of the underlying hardware but at a new layer.

The end result is a highly flexible PaaS environment that can be run on any environment (on-premises or in the cloud), and that can still provide integration tooling to optimize deployments on environments where the PaaS has the knowledge and ability to do so.

At CloudExpo 2011 in Santa Clara, there was an expert panel on PaaS that answered a question from the moderator that implied IaaS/virtualization had to exist in order for PaaS to exist. I decide to ask the question of whether the panelists felt PaaS requires the existence of virtualization, and one of my favorite Cloud evangelists, James Watters from CloudFoundry, had a good answer, which I will paraphrase here: “no, but the dominant design principle applies and virtualization has enough inertia that it will be an intimate part of PaaS anyway”. This doesn’t mean that PaaS is dependent on IaaS/virtualization from an implementation point of view, and PaaS providers who have built that explicit dependency are either using virtualization for multi-tenancy, or unnecessarily knee-capping flexibility. For the customers’ sake, leave virtualization down a layer, and stop letting it become a leaky abstraction to what should be a cleaner systems architecture. If you build PaaS without a dependency on virtualization, you can then introduce integrations to IaaS layers as an optimization rather than a requirement. No one likes lock-in, particularly in the context of an operating layer.

As a cloud fanatic and CEO of PaaS company Apprenda, Sinclair focuses his efforts on helping move both public and private PaaS into the mainstream of enterprise IT. Before co-founding Apprenda, Sinclair held positions at Morgan Stanley, Eden Communications, and the State University of New York (SUNY). Sinclair holds a dual Bachelor of Science in Computer Science & Mathematics from Rensselaer Polytechnic Institute, where he graduated Summa Cum Laude.

Building a PaaS is no different than making music. You can one-man band the hell out of programming languages and stack runtimes, but you’re just going to be making noise that sounds OK and gets eyeballs on the street. What you’ve done doesn’t have durable, legendary potential. It seems that lately, every PaaS provider wants to add as many languages as possible as quickly as possible. A week doesn’t go by where there isn’t a press release that is written in the stock format “<Insert Favorite PaaS Here> introduces game-changing, atom-smashing, world class support for <Insert Whatever Language the Other PaaS Said They Support Here>” This is a recipe for disaster both for the market in general, as well as for customers. There is an easy framework for understanding why this is bad business, and it all starts with being a real PaaS rather some heavily diluted manifestation of PaaS.

Building a PaaS the right way means that you’ve either:

• Invented a brand new language and execution runtime, or
• extended an existing runtime (JVM, CLR, etc.) into a new higher order runtime and systems architecture

In either case, the PaaS is doing some intimate, lower level heavy lifting and likely building a host of “base services” that are highly dependent on the language and/or underlying runtime. Those base services are exposed as APIs and are part of provided frameworks, or are capabilities that are instrumented into guest applications of the PaaS. Building all of this is non-trivial and takes a long time to build, but provides extremely rich next generation value to customers.  This is the true meaning of “supporting” a language.

Much like the one-man band, when a PaaS starts laying claim to supporting its 37^th language, they’re juggling too many things to properly be an expert at any one, and their version of “I’m good at the guitar” is not Eric Clapton’s version of the same statement. This statement redefinition and implied level of expertise is a good parlor trick, but can’t stand the test of time. The way PaaS providers achieve this is that they define “support” as deploying and loosely managing apps of that newfangled language or runtime type, but don’t provide any uniquely differentiated, high quality value. When a PaaS provider says they support a new language, they likely mean that they can move some pile of indistinguishable bits to a new underlying target application server and issue a “Website Start” command to whatever that target is (e.g. Tomcat, IIS, etc.) If that’s “next generation value”, then I’m in the wrong industry.

The huge downside to this multi-language craziness is that it creates a tremendous amount of market noise and distraction, and robs customers of time and value. Up front, a customer gets excited when they see “support” for so many languages. Some customers might not yet understand what the real potential and long term value of PaaS is. They’ll be satisfied with that PaaS, at least for a while. Once they starting building more complex cloud apps and realize that the PaaS does nothing to help them with this because it isn’t a runtime, then they walk away disenfranchised. For customers with more up-front sophistication, they see “support” as woefully inadequate out of the gate and began to get frustrated with PaaS as a concept in general.

A PaaS releasing support for language after language is a bad smell. It typically (I can’t claim always) means that they don’t have a sufficiently valuable piece of machinery under the hood, and they are likely not offering a runtime model.  If they did, supporting the N+1th language would be hard work, and I would hypothesize that each N+1th language would take more time to support than the Nth language (rationale is fodder for another post). Now, to temper my sentiment, I do believe it is possible to support multiple languages/runtimes, but it has to be done correctly. The result is likely being able to support a small number of languages, rather than all of them.

If you’re an observer, practitioner, or customer in the PaaS space, don’t get distracted by the one-man band on the side of the street while walking to the rock concert – that would be a terrible reason to reach the ticket counter and hear the words “Sorry, we’re sold out.” If you’re a PaaS vendor, please, do it the right way and stop being distracted by shiny objects: support very few languages very well, rather than all languages very poorly. And remember, you might hire a one-man band to work your 8 year olds birthday party, but people pay lots of money and wear their finest clothes and jewelry for one night out at the symphony.

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.

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?

No particular event has motivated this post; instead, this post is the result of a number of conversations and miscommunications. A while back, I started noticing some disturbing trends in the market, and more specifically, in vendor pitches. Let me use a real world example of what I mean. Frequently, the sales team at Apprenda ends up in the following type of conversation at some point in our sales cycle (clearly, this is distilled for brevity):

Prospect: “I saw that SaaSGrid offers multi-tenancy.”

Apprenda: “That’s right; SaaSGrid gives your application access to various types of multi-tenancy using the same code base and application assets. It’s actually amazingly unique and takes significant effort out of your R&D.”

Prospect: “Yeah, but doesn’t <insert your favorite PaaS/IaaS here> offer multi-tenancy?”  or “Well, the folks over at <insert your favorite PaaS/IaaS here> said they offer multi-tenancy too.”

Apprenda: “That’s different. Those technologies are themselves multi-tenant. SaaSGrid is a server technology that allows your single-tenant application to be multi-tenant at all application tiers without the huge effort typically associated with going multi-tenant.

Prospect: “Wait, but that’s exactly what I heard <insert your favorite PaaS/IaaS here> say. You’re saying that they don’t do the same thing as you.”

Apprenda: “Correct. Most, if not all, cloud platform vendors that refer to multi-tenancy are references to their own architectures, meaning they can efficiently pack their customers onto shared hardware/OS instances and offer you better service and a low price point. What you’re asking is how you can be multi-tenant and offer the same to your customers. Others in the cloud can’t help you with that.

Prospect: “OK, so using their service doesn’t make sense then?”

Apprenda: “That’s hard to answer, but it usually makes sense in conjunction with something like SaaSGrid. Clearly, being on something like EC2 (which is multi-tenant at the infrastructure tier) has advantages to you. Using SaaSGrid means you can really lower your internal cost of offering your service to your customers, and either put the savings to the bottom line or pass it along to your customers.”

Prospect: “What SaaSGrid does seems pretty magical now that I’ve cut through the marketing BS, how do you do it?”

Apprenda: “SaaSGrid is a runtime. When deployed to SaaSGrid, your application is transformed and new capabilities are instrumented into all tiers of your application. When running on SaaSGrid, these transformations and runtime instrumentations ‘inject’ SaaS architecture DNA into your non-SaaS web application.”

As you can see, this sort of conversation is a distraction. Whether it’s a conversation with an analyst, industry pundit, or potential customer, I’ve found that the most important thing to do upfront is to level-set on what both sides mean/understand when they say “multi-tenant.” Why so much confusion? I think it’s due to two factors:

1. The marketing pitch offered up by vendors and how those marketing sound-bites are contexualized
2. The general overloading of the term “multi-tenant”

On the marketing side, vendors do a good job of highlighting multi-tenancy. The problem is that the lack of context around the “feature” of multi-tenancy causes significant miscommunication. From a marketing perspective, vendors are sucked into the Green Crystals Marketing described by Bob Warfield a couple of years ago. Most cloud vendors are touting that they are multi-tenant; they want you to understand that they have a cost-effective and safe mechanism to isolate their customers from one another. To understand this better, I’ve taken the liberty to copy and paste (with references, of course) some content related to multi-tenancy from various cloud vendors:

The AppFabric Container provides base-level application infrastructure such as automatically ensuring scale out, availability, multi-tenancy and sandboxing of your application components. (Microsoft, Windows Azure)

Cloud-enabling infrastructure to allow secure multi-tenant deployments, including fully integrated management, monitoring, metering and billing infrastructure (CloudBees)

If you are running numerous applications/application instances, XAP’s fine-grained multi-tenancy allows you to share them across all available machines, instead of running only one instance per machine. This allows you to support more users on each machine. (GigaSpaces)

There a few others to use as examples, but this is fine for now. I’m not going to debate whether advertising that you are multi-tenant is an effective use of marketing real-estate. all of these snippets of text highlight multi-tenancy, but what is unclear is the context. For example, the first two indicate multi-tenancy at the platform tier; that is, multiple, unrelated code assets can share common OS instances. While this is powerful in its own right, it’s easy to understand how someone reading this text might walk away thinking “Excellent. Our requirements for our new SaaS project call for multi-tenancy. I can check that off our list.” The fact is, while ambiguous in terms of presentation, these technologies do not endow your application with multi-tenancy, they let you run in a multi-tenant environment. If you’re looking to build a multi-tenant app, you need to still architect multi-tenancy (‘architect’ is a verb according to the Oxford English Dictionary). In the gigaspaces case, although they refer to multi-tenancy in a way that lends itself to an “endowment” interpretation, it seems that they are focusing more on a grid approach of scaling the app to support more end users. While this is also valuable, it does not deal with segregation and isolation of logical groups of tenants (which is what multi-tenancy really is). At Apprenda, we even dealt with this definition in problem in our FAQ. This leads me to the next issue: term overloading.

Multi-tenancy is valid in 3 common computing contexts:

1. Infrastructure: This is multi-tenancy the way someone like Amazon might refer to multi-tenancy on EC2. In the IaaS context, multi-tenancy means that multiple OS instances can run on the same physical hardware through hypervisor technology.
2. Platform: PaaS multi-tenancy means that, like a Heroku or a CloudBees, the platform can isolate code from different apps/vendors on the same OS instance (usually by commingling processes and databases on OS instances). This removes the need to allocate a whole VM per application stack component, improving efficiency.
3. Application: SaaS multi-tenancy, at least at the highest level of isolation, means that single runtime stack component instances are shared across multiple customers. For example, a single database might commingle data rows for thousands of customers while preserving isolation and performance.

Clearly, multi-tenancy means different things in all of these scenarios. There is nothing wrong with overloading, but it certainly doesn’t help the already high levels of confusion that exist around the word. If you’re an app developer in the Cloud looking to see what tech can help you, having a sense of clarity is most useful. Make sure you ask simple questions like:

1. When you say ‘multi-tenant’, what do you mean?
2. If multi-tenancy is a feature of your IaaS/PaaS, does that mean my app automatically becomes multi-tenant and I get to reap efficiencies from it?
3. If I want my app to be multi-tenant on your IaaS/PaaS, will I have to still architect the app to be multi-tenant?

If you get answers of “I don’t know” or “No”, then clearly, you’re on your own if you want to build a multi-tenant SaaS app from the ground up.

Do you feel multi-tenancy is thrown around too often by the wrong parties? Is multi-tenancy confusing to you?

Before co-founding Apprenda, Sinclair held positions at Morgan Stanley, Eden Communications, and the State University of New York (SUNY). Sinclair holds a dual Bachelor of Science in Computer Science & Mathematics from Rensselaer Polytechnic Institute, where he graduated Summa Cum Laude. Sinclair excels in understanding the economics of SaaS platforms and ecosystems, and is a frequent speaker and panelist at industry events

As Apprenda evolved, we started realizing that ISVs weren’t the only entities trying to deliver their software  to thousands (or even millions) of customers via a services model instead of a shipped bits model. We found that huge numbers of home built enterprise IT apps were essentially being written as SaaS offerings because of the simplified delivery and consumption model.Enterprise IT could write an application, deploy it as a their own “private” SaaS offerings, and have internal end users, partners, vendors, and even external customers, use those applications. For example, imagine a custom supply chain management application used by the employees of a large, global logistics company, or an HR app deployed to multiple lines of business within the enterprise. We also found that a cloud application architecture is not something that solves problems unique to ISVs, but that we could give the same or more value to enterprise IT. Furthermore, we started noticing that enterprises are building private clouds, essentially IaaS offerings within the enterprise, allowing for flexible access to massive pools of resources. This solves a number of IT problems, but now developers are aching for access to higher order value: essentially, a platform like SaaSGrid that could be deployed ontop of that IaaS to rapidly build complex cloud architectures and deploy those architectures to their private clouds. My conversation with Wainewright really honed in on understanding how and why enterprise architects are adopting cloud architectures for internally built custom applications.

Wainewright wrote up a great post entitled “The OEMing of SaaS: build or buy?” that describes private SaaS in good detail. At the end of his post, he posits that “…the case [is] against ‘private’ SaaS and in favor of having the provider run the platform” I don’t think this is necessarily a good position, at least in terms of a coherent taxonomy. First, we need to make sure we don’t confound Cloud topic areas. Where an application lives and it’s “visibility” are two different things. A Cloud application has a few attributes associated with it:

1. Where it’s hosted (yes, I’m using the word hosted. Cloud does not mean apps still aren’t hosted, they’re just virtually hosted)
2. It’s visibility, or in other words, who is allowed to use it (anyone who pays, anyone who pays but restricted to a defined group, no payment required but not for general consumption). Think of Salesforce.com as ‘public’ while something like an app written by my former employer Morgan Stanley for their own investment bankers as ‘private.’ Public and private need not have the same meaning in the SaaS context as they do in the infrastructure context.
3. What architecture dependencies (if any) the application has

Being ‘against’ private SaaS, at least by how we define it (where again, ‘private’ is a visibility construct that helps determine who is allowed to consume the app) has nothing to do with where it runs (the provider running the platform). For example, if an enterprise chooses to use a Cloud platform like SaaSGrid, they are choosing to use it because it solves some very tricky architecture and operations problems. Morgan Stanley, for example, might choose to build a multi-tenant app for it’s thousands of retail banking branches on something like SaaSGrid to solve distribution, scale, provisioning, and entitlements problems through multi-tenancy and infrastructure abstraction, but still run it on something like EC2. Running the app on EC2 doesn’t make the application ‘public’; it’s still only privately accessible but running on a ‘public’ cloud. That said, there is also nothing wrong with someone like Morgan Stanley deploying a their private SaaS app on their own infrastructure, or with building a private Cloud stack with something like SaaSGrid running atop their internal IaaS offering. There are huge advantages to this as well.

This leads me to a brief discussion of the evolution of Cloud in the context of enterprise IT (and maybe even the broader market in general). First, I think we’ll always have two distinct stack layers: IaaS and PaaS. The state of PaaS as a Cloud layer is important to understand. To date, most PaaS offerings have not focused on the changed software consumption paradigm where thousands or millions of people plan on consuming a centralized service. That’s still an architecture that most developers have to deal with.

Offerings like Heroku, which was referenced by Wainewright, abstract away the infrastructure and provide a package, deploy and run model for arbitrary applications. These platforms do little to nothing for the applications’ fundamental architecture qualities and runtime behavior, and merely simply part of the build, configuration and release process, and remove the need to deal with IT staff. In this case, forklifting an application off of a PaaS to another PaaS, or even to IaaS, is easy and requires no code changes. Unfortunately, these types of PaaS offerings are uninteresting from an advanced application architecture and engineering point of view (don’t misinterpret this as uninteresting in general. I find PaaS offerings to be amazingly valuable, just not in terms of solving challenging architecture and engineering problems like multi-tenancy, which are still dealt with “by hand”) If someone chooses a platform (PaaS or cloud-focused architecture platform) that provides a modern, advanced Cloud architecture out of the box and that provides your application with significant runtime value, you won’t think about  forklifting the same codebase from the platform to something like IaaS or some deploy-focused PaaS offering because you will lose all the architectural value you were after in the first place. This means that the Cloud  runtime, to prevent operational lock-in, must be decoupled from the provider. If it is not, you are in grave danger of being operationally beholden to the provider for fundamental architecture needs. This is extremely risky.

Enterprise IT faces extremely complex engineering challenges; they don’t build “websites”, they build sophisticated web applications that need to deal with challenging problems. The Cloud will evolve to acknowledge Cloud architectures as a topic separate from Cloud “hosting”, and that the two layers should be decoupled as a rationale step to ensuring freedom and openness. What I expect to see is that enterprise will adopt Cloud runtimes to solve their engineering challenges, and whether an app built on that runtime is deployed in their private cloud or  in the public cloud will be dictated by an entirely different set of parameters. Any external providers that think they can have people write code that will run in their Cloud and only their Cloud will not succeed in the long run.

Have you worked on private SaaS projects built by your enterprise IT organization? Do you think the Cloud will evolve into a runtime and hosting tier, or will you be forced to choose a runtime that is locked in to a single provider? I’d love to hear your thoughts!

Before co-founding Apprenda, Sinclair held positions at Morgan Stanley, Eden Communications, and the State University of New York (SUNY). Sinclair holds a dual Bachelor of Science in Computer Science & Mathematics from Rensselaer Polytechnic Institute, where he graduated Summa Cum Laude. Sinclair excels in understanding the economics of SaaS platforms and ecosystems, and is a frequent speaker and panelist at industry events

My experiences have been the same: for the most part, cloud has provided tremendous value in creating a highly flexible datacenter abstraction, democratizing access to high end infrastructure offerings, and trivializing a number of deployment and management issues (think PaaS). Most of this is something that network engineers love (I don’t believe it’s a pari passu displacement of IT staff – Cloud has created a set of more interesting, higher value challenges that modern IT operators need to tackle) Additionally, the Cloud has provide some basic value to software engineers through some highly available and scalable nuts and bolts services (like blob storage solutions, etc.), but the problem domain of building Cloud/SaaS offerings has not been directly addressed by most Cloud providers since the focus has been entrenched at this network and virtualization tier. Cloud at the infrastructure tier is absolutely necessary, but the development community needs more Cloud value that solves modern software architecture problems. The Cloud, with its vast elasticity and democratization of software access to end users, has created challenging software delivery problems like cost efficiency delivery, scalability, and the need for codification of critical operating workflows. These are things that Cloud tech to date has predominantly shied away from.

Historically, middleware/infrastructure software has provided a common layer that acts as a single point of interest shared by IT network level operators and software developers. Think IIS, WebSphere, database servers, etc. These infrastructure software products typically provide a wealth of tooling to network folks in support of applications written by developers that use the pattern and practice productization value captured by these “application servers” to ease use case specific software engineering burdens. When the developers finish building something, the network ops teams can communicate in a familiar way with the same product, but through a different lens.

Looking at the state of the Cloud, it seems pretty obvious to me that we are at an inflection point. The “great divide in cloud computing” is something that can, should, and will be filled by modern middleware purpose-built for the Cloud. This middleware is what can act as the intermediary between the new architecture pressures that software developers must face and the Cloud management requirements of the IT staff. Without middleware handling this, we fundamentally have a better way to host software, which is hardly a catalyst for continued innovation.

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3600+ members and is growing every day; make sure you’ re not missing out and join today!

Read hit the nail on the head. Throwing an app onto some servers, whether on-premises or in the Cloud on something like Amazon’s EC2, is not SaaS. I’ve written many times about what it means to truly offer a business offering in the Cloud, but this article captures a real world example of the effort required to move to SaaS.

Read goes on to highlight data volunteered by Michael McCloskey, FrontRange’s CEO that provides an interesting data point: FrontRange “…spent two years re-architecting from scratch a new platform for the SaaS environment” Two years! (Notice the emphasis – I clearly care about this number) I don’t know the hard dollar investments made by FrontRange, but one must imagine that their SaaS platform project had a good number of developers working on it, and that the investment was, with a high probability, in the seven figure category (probably a few developers and architects, as these projects go, with a fully loaded average cost of somewhere in the $90K to $150K range per year working for two years). So a proper product to SaaS transition is a combination of 24 months of SaaS specific effort, seven figures in hard dollar costs (probably), resulting opportunity costs, and ongoing R&D maintenance costs (someone needs to fix the SaaS specific bugs and evolve the platform) – Holy smokes!

I seem surprised, but I’m really not. I’ve been in the thick of this very scenario, and responded by channeling all my effort into Apprenda. Apprenda was built on the premise that a high end SaaS architecture and operating tool-set could be productized into an application server. We built SaaSGrid to do just that – productize a world class SaaS platform so that applications running on it could inherit and give a company a sustainable short and long term solution with tremendous ROI. SaaSGrid was kicked-off as a product knowing full well the costs of a real SaaS architecture with things like multi-tenancy, provisioning, billing etc.

The scenario highlighted in this FrontRange scenario is in fact very much like the ROI analysis we go through with prospects and customers. Someone like McCloskey, faced with a SaaS decision (regardless of whether its a new application or a migration) needs to compare those build figures to investing in technology that they can buy that solves these problems out of the box. Fundamentally, you start to ask yourself:

1. Does a 12 or 24 month time to market loss result in significant competitive disadvantage? (i.e. Am I liable to lose significant market share or position by letting competitors beat me to the punch?)
2. What opportunity costs is associated with a competency distraction of this magnitude on the R&D side?
3. We haven’t built this sort of architecture before, what risk level am I willing to absorb?
4. Could an additional 12-24 month investment in the product functionality and not the SaaS platform give me access to new markets and revenue streams?
5. If a home-grown SaaS platform is going to cost $1-$3 million to materialize, what investments am I giving up to make this happen?
6. Are we going to be able to lend resources to the SaaS platform over time and evolve it despite it being orthogonal to the product, and if not, what untapped value are we leaving on the table?

If you add up the hard dollar costs of the above questions, you start to realize that millions of dollars are required, and the soft dollar costs add many more millions. SaaS is a strategic advantage, but the cost of that advantage is whats in question. Clearly, I do not think that building is a sustainable or strategic overall approach – it’s expensive and distracting. Thats not to say a company can’t be successful (just ask Salesforce.com), but the probability of success goes down while risk goes up when you build. We’ve seen this before – most companies don’t go out and build relational database servers because its not their core competency. Instead they download or license an RDBMS. A SaaS stack is of the same complexity level and same level of orthogonality, so why build? Our goal with SaaSGrid was to let people focus all of their energy on their offering – the stuff that your customers care about – and not on SaaS. My bet is that Cloud build vs buy cases like this will one day define a Harvard Business Review case study or two;-)

How do you feel about this  - does building make sense, or is the ROI not there?  Do circumstances exist where building is warranted, and if so, what are they? What other costs can you think of that should be factored in the SaaS platform build vs. buy?

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3600+ members and is growing every day; make sure you’ re not missing out and join today!