Private SaaS: Understanding How Cloud will Evolve for Enterprise IT
I recently spoke with Phil Wainewright of ZDNet and had a great conversation regarding private cloud/private SaaS. The focus of the conversation was to help Phil understand some work we’ve been doing at Apprenda with enterprise IT . For anyone that doesn’t know Apprenda and our platform SaaSGrid, I co-founded the company with the intent of solving a major market problem: create a server technology to help independent software vendors (ISVs) build amazing multi-tenant, fully web scalable and commercializable SaaS offerings. Basically, SaaSGrid is a layer that sits underneath an application as an “operating system” middleware that provides a modern distributed runtime solving all major SaaS architecture and operating requirements.
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:
- 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)
- 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.
- 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!
Related Posts
Tags
Share This
