Understanding the "as a Service" Revolution
For those interested, an article I wrote was published on GigaOM that gives a high level description of the bare necessities required to become an on-demand player. I won’t rehash the details here, so definitely check it out!
read more
When thinking of the cloud, there are two sides to the coin: those who build SaaS offerings and those who consume them. For those who build SaaS applications, we’ve seen a glut of tools crop up to help engineer, architect and deploy SaaS offerings. Some are “horizontally” aligned (think EC2 on the IaaS side, SaaSGrid on the application server side, etc.) while others are “vertically” aligned holistic silos (think Force.com on the PaaS side – even with the recent VMForce announcement) and some are in a mid-silo middle (think Google’s AppEngine and Microsoft’s Azure, both “up to the runtime” PaaS stacks).
Given that there is so much velocity, tumultuousness and general confusion (acronym hell coupled with taxonomical conflation – aka the “everything and everyone is a platform” syndrome), we’re bound to see some order evolve in the future where the evolution will be motivated by what people actually use and adopt rather than the current landscape which is driven by who can yell the loudest.
The big question is what will the future of cloud architecture look like: a stack of interchangeable layers that allow one to choose best of breed or a group of incompatible but highly specialized “holistic silos?”
Looking at the history of infrastructure middleware, the answer seems to be quite clear. Typically, the trend has been that layering functional best of breeds into stacks provides the best combination of “lowest common denominator” coupled with the necessary functional value to “get things done” and keep risk minimal. For example, I can choose servers made by HP, a Windows OS, Java and JBoss, and build a killer enterprise app. If I so decided, I could have swapped Windows for Linux and essentially had a compatible stack experience. Why, then, are silos cropping up in the market?
Silos like Force.com have their appeal. They promise a world where all your needs, ranging from hosting and execution runtimes in the cloud all the way through development frameworks and distribution channels. The problem, however, is that the software market cannot be addressed as a broad stroke.
The needs of software companies vary wildly: ISVs in the healthcare space may care more about hosting certifications than someone in the CRM space, while those in business intelligence need low latency, high compute availability and the others who altogether care very little about the hosting and it’s all about what middleware they are going to use. The number of needs permutations is staggering.
To think that Platform as a Service vendors that own the full stack, from hosting through runtime and even UI components, can ever optimize for each of these scenarios is ludicrous. Furthermore, the silo providers ask for something huge in return for a suboptimal solution: control of the ISVs destiny in all regards. That’s a high price to pay for a promise that can’t be fulfilled.
| Cloud Stack | “Half Stack” | Cloud Silo | |
| Operations Management | SaaSGrid | Force.com, Quickbase | |
| SaaS Middleware | Microsoft Azure, Google AppEngine | ||
| On-Premises Runtimes | .NET, Java, etc. | ||
| Cloud Infrastructure | EC2, Rackspace Cloud, GoGrid |
I’m a firm believer that most if not all software will be delivered online. It’s the only way to achieve true ubiquity, and it requires superior delivery. Each ISV is going to have to make lots of decisions as they move to the SaaS delivery model. Those decisions are going to focus on how to best solve all the critical problems associated with becoming a service provider. The only logical conclusion is that each ISV will look for best of breed tiers in a stack form that would allow them to create an optimized outcome. I don’t see a grand future unfolding where thousands of ISVs worldwide commit to incompatible silos that require taking on relationships that amount to single points of failure and risk. As a stack becomes more vertically consolidated (i.e., more siloed), the higher the risk grows for an ISV. If ISVs take on piece-meal stacks composed of highly compatible tiers, the walk away with the best of both worlds.
What do you think? Do you think that the next generation of business applications will be split across walled silos, or will the market adopt levels of commonality by converging to a stack approach with solutions provided by a few key companies at each layer, allowing for a “composable” stack approach that we’ve grown accustomed to?
read more
If you haven’t heard, Salesforce.com and VMWare plan on making a joint product announcement on April 27th at http://www.vmforce.com. Clearly, this piqued the curiosity of many, including myself. Thinking about Force.com, Salesforce.com’s strategy around the platform to date, and VMWare’s activity and intent to become more entrenched in the Cloud, my best guess is that it’s an Infrastructure as a Service (IaaS) offering, and maybe some sort of Spring-based framework layer that’s tightly integrated with Salesforce.com. Furthermore, it might even offer the ability to run native Force.com code/apps on top of it (I could see something like Spring being used to create a harness of sorts to load Force.com apps on a native Java runtime)
Force.com is a high order abstraction requiring the use of a new programming language and a heavily diluted (read crippled) runtime. As a platform for extending the CRM functionality of Salesforce.com, it’s an amazing platform. As a general purpose platform for business applications, I think it’s too trivial of a runtime (anyone who’s read this blog before knows my position on this). Most mid-large ISVs solve complex problems addressable only through mature, expressive languages and complete runtimes and stacks. VMForce might be a step in the right direction – so let’s wait and see!
PS: For the literalists out there, one thing I noticed is that VMForce.com describes it as a “product announcement” instead of “service announcement”. Maybe it’s some sort of special VMWare on-premises integration to the Salesforce.com Cloud?
What do you think VMForce is all about? Any drastically different theories?
read more
Yes! How’s that for a quick answer? In all seriousness, I believe this to be a “no brainer,” but I think the burden of proof is on me to describe why. I think it’s important to set context and work our way backwards to conclude that an axiomatic ‘yes’ answers the question “Does ‘Self Provisioning’ Make Sense for Your SaaS Company?” Where do we start: at the definition of service, an understanding of conceptual dynamics at play, and agreement on the effect of competitiveness on distribution, of course!
Service. Let’s assume that “service” can be broken down into three main processes: engagement, implementation and execution. Engagement is the act of committing to use a service (e.g., signing a home builder to build your next home or remodel your existing home), implementation is overhead required to initiate use of a service, and execution is the process whereby the service provider performs its intended “statement of work” to yield an expected, implicitly or explicitly agreed upon result. I’ll use these process labels in my little analysis of what I see in SaaS.
If we dig in more, when we think of “service” we usually think of scenarios where, for a fee, some external entity completes a task or series of tasks on our behalf and produces some intended result. Second, I would say that it is generally understood that the service provider and the customer have a fundamental point of “equilibrium” with respect to knowledge required to provide the service and the knowledge required to engage a service. Yes, the knowledge can be skewed in one direction or another (As a trivialized example, a customer who is a Hollywood Socialite simply stating “I want a nice house” vs. anyone else stating “I want a two-story colonial with a basement, geo-thermal heating/cooling, solar power, and manufactured with a steel frame” places a heftier knowledge burden on the contractor that will ultimately build the house, while also increasing the contractor’s probability of failure since no clear requirements were presented.)
Rarely do we think of scenarios that require significant amounts of effort on the customer’s part to kick-off the engagement. For example, which is more typical:
OR
Ok, I know, some contractors do that, but what was your first thought? That’s right: “I’m planning on hiring and paying you and you want me to do what?!?!” Same goes for almost any service. Furthermore, we don’t couple the act of engaging the contractor with implementation; that is, we don’t tie the decision to use a contractor with the act of going out with that contractor to a supply store to pick out construction materials like wood, nails, and insulation. In fact, if a contractor ever said “Well, while we’re working on a contract together, let’s go out and start selecting what we’re going to use” we’d run for the hills simply because of the sheer idiocy of the request on the contractor’s part.
We expect that the engagement phase will be as trivial as is common for that type of service; we understand what the service intends to do, we have either an implicit knowledge of what implementation entails or have explicitly extracted it from the service provider, and intend to commit to that service provider. For example, a contractor would be ecstatic if he/she could post an ad for a set of pricing tiers for kitchen remodeling based on kitchen size and style, provide evidence regarding quality of service and accept signed contracts from consumers who were looking for kitchen remodeling. Furthermore, if it was common knowledge that kitchen remodeling required that the customer gets involved to a certain level of depth (picking out appliances), no one would have issue with the implementation phase since it was expected and generally accepted as protocol.
Notice how I hedged with the wording “as is common.” Frequently, product and service providers feel that their customers are a completely naïve group that lack the necessary crystalline knowledge and fluid intelligence to comprehend what they offer. Usually what this means is that your product or service has not been distilled to the correct level and cannot be digested by prospective customers without your help.
I bump into lots of folks in my SaaS discussions and travels, and I frequently hear “well, we’re not really worrying about self provisioning at this point. Our offering is too complex anyway.” What seems to be the case in most of these situations is that the SaaS provider has not identified a clear separation between engagement and implementation. In most cases (there are a few exceptions) engagement is not a complex process, even if implementation is. Without a clear distinction however, the complexities of implementation bleed into engagement, giving the service provider a false signal. In the SaaS business, a customer engages with a service by discovering the service and committing to use it. One can commit to use the service (signing a contract, paying some money) without being able to necessarily use the full functional set of the service immediately (since they may need complex implementation). Provisioning is just a synonym for pursuing and following engagement through to the end. If you’ve clearly separated engagement from implementation in your application and workflows, I’d say there is little reason to not allow self-provisioning. With SaaSGrid, we built a system that could take any application and provide an out of the box “storefront” and self provisioning capability because of this belief. You want to leverage point in time emotions your prospects have. When a prospect browses your corporate site, and they think “Hey, I really think this is the right system for us,” to lose that positive momentum because you didn’t think about or build a self-provisioning system would be a terrible loss. Do you have a complex implementation that would require the customer to migrate data, go through specific tailoring and setup? Fine. Do it after they engaged and committed to your service.
Do you agree that nearly all SaaS offerings, if cleanly partitioned into engagement and provisioning pieces, should offer self-provisioning? Do you see significant advantages to not offering a self-provisioning model?
read more
One question that has popped up in some blog posts recently is whether the notion of “private cloud” is a misnomer or if it conceptually even makes sense. Some of the conversation started when Andrew Conry-Murray posted that the term “private cloud” is bunk and no such thing exists. I have to completely disagree with Conry-Murray. His dismissal of “private cloud” comes from using too narrow of a scope and too restrictive of an understanding of a “cloud’s” applicability, intent, and history.
It’s important to first understand where the term “cloud” originated, as it should really be used in a constructive approach to arriving at the definition of “private cloud” and the determination of how accurate of a term it really is. The term “cloud” originates from a scary place: network diagrams. Have you ever used Visio or a similar tool for modeling diagrams? If so, and if you’ve ever created diagrams that required some sort abstract network, you’ve undoubtedly used the “cloud icon” (which looks kind of like the dust-balls that the Road Runner would leave behind when being chased by Wiley Coyote). This icon was used to denote an abstract network at some responsibility boundary.
Ok, so the history of the term cloud is somewhat rooted in telephony, but we definitely adopted the icon for broader use in general network diagrams. Point being, the origins of the term “cloud”" had nothing to do with the public Internet, and I’d argue it still doesn’t. A cloud is simply an abstraction of network and resource responsibilities that one can leverage in support of some other functional tier or silo. The network diagrams that we’ve all created never restricted the use of the icon to the Internet, but rather remained open to use in any situation where you had to clump non-specific, potentially unidentifiable (but conceptually understood) resources into a dependency.
Given the history of the term and its typical usage, what makes the term “private cloud” so broken? Nothing. An enterprise can use Internet architectures to create internal, “private” resource abstractions. These are private clouds that can be used in a variety of capacities. Granted, larger enterprises are better positioned to leverage private clouds, but that doesn’t mean smaller enterprises won’t build them as well.
All this said, I do distinguish the Cloud, as a proper noun, from a general cloud. The proper noun Cloud should be used to identify the public internet.
How do you feel about the term private cloud? Does history not matter when it comes to best understanding the term? Let me know!
read more
