Has SaaS & Cloud forced the server operating system into irrelevance?

Jul 6, 2010 by Sinclair Schuller

read more

Do We Need Cloud API Standards?

Jun 26, 2010 by Sinclair Schuller

I was on a panel entitled “HYBRID CLOUDS — THE BEST OF BOTH WORLDS?” at the Structure 2010 conference this past week. (Check out a recording of the panel) For those readers who are unfamiliar with the concept of the “hybrid” cloud, essentially, it’s the idea that one logical infrastructure cloud can be composed from two or more clouds of different deployment locale (on-premises vs. elsewhere) or visibility levels (public vs. private)

I was lucky enough to be on this panel with a number of very intelligent people who had some amazing insight into the topic. One of the questions posed to the panel really struck a chord. Essentially, the question was something along the lines of “Are standards necessary for the hybrid cloud to become a reality?” (Roughly minute 29:07 in the recording) The standards being referred to are standards that would abstract the command and control of virtual infrastructure. Each cloud provider (e.g., Amazon through EC2, GoGrid, etc.) typically provides an API by which one can control the deployment and ongoing operations of a virtual resource. Since each cloud provider has a different API, there is a form of lock-in that rears its head since, although each cloud might provide a similar container (say, a Windows 2008 Server), your code for managing and leveraging that cloud is non-portable.

Mårten Mickos, CEO of Eucalyptus, fielded the question stating that standards are necessary for hybrid cloud to really take off and that a standard would accelerate adoption significantly. I agree with the spirit behind Mårten’s view, but not with the idea of formal standards (and as you’ll read, I think Eucalyptus is poised to do some amazing things). Now when we discuss “standards” we mean an industry standard sponsored by a standards body or some sort of consortium. Others on the panel respectfully disagreed with Mårten’s position. Joe Weinman responded that standards aren’t necessary, and that different providers need to be free to evolve solutions that best fit the problem domain and customer need. My position was somewhat in alignment with Joe’s; standards, by definition, must cater to lowest common denominator subsystems which can bias efforts towards standardization rather than on new techniques to solve new problems in the cloud. It’s important to understand why this is the case, and also why it doesn’t mean that although a formal standard shouldn’t be pursued in the near term, generalization should absolutely be pursued.

In some instances, “formal” standards can stifle innovation or distract focus from solving specific problems by becoming abstract enough to be standards compliant, but not specific enough to solve a problem as well as possible. For example, if some cloud provider comes up with a novel way to address something new, they can still conform to the standard, but any uniqueness they bring to the table will be lost behind the abstraction. Just think of the SQL-92 standard. Most every DB vendor has some level of conformity, but various RDBMS’ do something amazingly useful things outside of the SQL-92 standard. If you leverage those proprietary pieces, you can no longer benefit (at least not by much) from the standard itself since you’ve broken conformity. Furthermore, any standards that have evolved in the past have typically fragmented into many sub-standards, dialects, etc. (just like the SQL case)

Now, does this mean that we shouldn’t pursue standardization? Well, if we’re talking about a “formal” standard, we probably don’t need to rush it. Technological generalization, however, is a different story. We’re at a point in the cloud’s evolution that requires organizations like Eucalyptus to focus on providing a coherent means to manage multiple specific cloud implementations. This is amazingly powerful and valuable and doesn’t require a formal standard. Eucalyptus has focused generalizing the Amazon EC2 API as a standard API that could be applied against any other cloud system. Overall, EC2 is a wise choice since it has the broadest market penetration and the most generally applicable API when looking from an abstraction point of view. Eucalyptus is doing some amazing work to make sure that you can leverage API expectations to work with a variety of virtualization clouds. Their efforts will undoubtedly boost adoptability, reduce adoption risk, and increase the viability of private and hybrid cloud deployments. Given Amazon’s API penetration, a market “gold standard” has been created just by shear adoption, and I think people will naturally flock to a proper abstraction like Eucalyptus because of sheer necessity to ensure compatibility with the gold standard while preserving the ability to experiment with new solutions. By choosing EC2, Eucalyptus’ approach provides a standards-like advantage without the baggage since the standard is chasing the market leader, rather than creating a standard and trying to enforce it. Kudos to Mårten and Eucalyptus for helping catalyze adoption of the cloud!

Do you feel that formal API standardization will be absolutely required in order for cloud, private cloud, or hybrid cloud to work, or will things organically tend to a relatively standard oligopoly of well known abstractions without a formal standard in place? Do standards create stifle and slow down innovation by always focusing on the lowest common denominator, or does it promote innovation by guaranteeing a baseline?

read more

The Cost of Sustained Market Leadership as a SaaS Company – New Whitepaper

Jun 17, 2010 by Jesse Kliza

Hi everyone,

We just yesterday released a brand new white paper entitled “Understanding the Cost of Becoming a Sustained Market Leader in the Software Business Through Software as a Service”, that we thought the community might be interested in. It’s vendor neutral, no product pushing, etc, and we’ve gotten great feedback thus far.  As always, we’d love to hear your thoughts, so please speak up! :-)

You can access the full white paper here.

Topics covered include:

- What it means to be a SaaS provider
- The importance of highly efficient SaaS architecture
- Optimal strategies for achieving the SaaS stack maturity necessary to become a sustained market leader

The paper begins with an overview of providing a SaaS offering, the primary infrastructure and delivery costs, and the requirements for market leadership before proceeding into the complexities and benefits of single-instance multi-tenancy and a critique of several compensatory strategies. The paper then concludes with an explanation on how cloud middleware can solve these architectural problems thereby achieving the benefits of building your own multi-tenant stack without the onerous upfront R&D costs and long time-to-market or the poor customer management and lock-in deficiencies normally associated with leveraging Platform as a Service (PaaS) offerings.

Here’s the link again to access the full white paper.

Should you have any questions or feedback on the whitepaper, please let us know.  We hope you find it to be a useful and informative read!

- Jesse

read more

SaaS for the ISV Masses through SaaSGrid Express

Jun 7, 2010 by Sinclair Schuller

When my partners and I co-founded Apprenda, we had a number of very specific goals when it came to SaaS enablement and we wanted SaaSGrid to embody those goals. My co-founders and I all came from technical backgrounds where we were responsible for SaaS engineering efforts. We learned early on that when a SaaS application is engineered properly, its architecture is drastically different than plain old web applications (think multi-tenancy and scale-out) and that a huge number of auxilliary tools and subsystems (think billing, application life-cycle management, infrastructure management, subscriptions, identity federation, etc. and then some) are necessary for managing and operating a SaaS offering and business.

When you combined these “SaaS specific” aspects of a SaaS offering, the upfront and ongoing time and money investment required far eclipsed that of the application itself (the actual thing your customers want to pay you for!), and causes huge competency distraction. Taking on the build out and maintenance of a mature “SaaS stack” is akin to a software company deciding that it’s in their best interest to build and maintain their own DB technology in support of their business application.  Surely, most people buy RDBMS tech (like SQL Server) or download it (like PostgreSQL) to help ensure succcess, and firmly believe that they need not build their own. When we created SaaSGrid, we had some very specific things we wanted it to do:

1. Allow for the use of traditional stacks (in our case, the Microsoft .NET platform) and the wealth of tools and components already in existence for these stacks. New languages are best created in support of new modeling paradigms or changes in the ways we capture solutions, and not in support of a new delivery model. Traditional runtimes simply needed to be “enhanced” to really sing in an on-demand scenario.
2. Have it be comprehensive and not require a “paper mâché” approach to piecing together disjointed capabilities. Imagine that an operating system required that you find your networking substack from here, and a graphics subsystem from there, and then require that you mash them together. That would be sub-optimal in many ways.
3. Have SaaSGrid provide even the most complex capabilities, like multi-tenancy, as transparently as possible to the application code that runs on top of it. As technologists, we hate having technologies adulterate our code, so to the extent possible, we wanted SaaSGrid to be as low impact as possible.

We accomplished our goals and some, and our customers benefit wildly from SaaSGrid. But late last year, we were thinking about a number of things related to the market and to SaaSGrid. As a company, we’re committed to not only supporting the transition to SaaS, but to catalyzing it. I think great strides have been made with respect to software company adoption of the new delivery model, but the fact of the matter is, most ISVs are still not SaaS. Furthermore, those that want to become serious SaaS players have a tough time understanding how they can get there and what tools are available to them.

Enter SaaSGrid Express!

Anyone that follows my company Apprenda knows that we recently made a new product announcement with SaaSGrid Express. SaaSGrid Express is a freely downloadable application server that captures nearly all of the value of our tried and true SaaSGrid, and that can be used by anyone just to experiment or even to build a revenue producing business. Our goal with SaaSGrid Express is to let everyone experience the value that SaaSGrid has to offer, and more importantly, to democratize a highly complex SaaS architecture in hopes of moving the industry forward.

Phil Wainewright recently offered some excellent insight in his recent blog post regarding SaaSGrid Express; the goal of democratization also means that some people might get there hands on a technology but are simply not prepared to build their own clouds. But as Wainewright went on to point out, those same people would have gone down that path with or without SaaSGrid, so we’re happy that they’ll be able to walk away with such a robust starting point. Giving SaaSGrid Express to the world means that more people than ever before can experiment with and commit to a proper SaaS architecture, which will definitely help satisfy our vision of catalyzing the space. As Dana Gardner suggested, SaaSGrid Express opens up the potential for a “cloud standard” architecture and SaaS stack. If we accomplish that sort of de-facto standard, then the industry is definitely off to a good start. Having a de-facto SaaS stack means that people are not focusing on complex architectures, but on business value for their customers – which would be a huge win for everyone.

Something Special for YOU!

For those loyal SaaSBlogs readers that have an interest in downloading SaaSGrid Express and building an application, we’d like to offer you something special:

For the first 5 SaaSBlogs readers that sign up for SaaSGrid Express with the intention of building an application, or migrating your existing .NET offering, we’ll commit 1 hour of time from one of our engineers to personally work with you, and get you up and running with your project!

Just mention that you’d like to take us up on this special SaaSBlogs community offer in the comments section of the sign up form.

read more

Does “Self Provisioning” Make Sense for Your SaaS Company?

Mar 31, 2010 by Sinclair Schuller

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:

• Having a contractor come to your house to provide you a work estimate based on his/her measurements and discussions with local officials.

OR

• Having the contractor come to your house and tell you “Great, nice house. All I need next is for you to go off and take measurements of your house, identify any new structural components and provide measurements for those as well, take care of architectural drawings, and deal with the town all by yourself regarding requisite approvals, and then I’ll give you an estimate.”

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

Great Interview on the Benefits of Multi-tenancy

Feb 5, 2010 by Devon Watson

This is a very good podcast of Phil Wainewright from The Connected Web interviewing Rick Nucci, CTO of SaaS integration vendor Boomi on the impact of multi-tenant architecture on the operational cost of delivering software in a SaaS fashion.

Two choice excerpts:

“SuccessFactors recently gave a speech, [by CEO] Lars [Dalgaard], talking about their architecture and their approach. They have something like over a thousand customers per physical server when you net it all out and aggregate it. Andthat‘s the marginal utility, that’s the scale that you need to get to — because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it’s not going to happen if you’re doing a per-customer expenditure.”

“And that‘s the marginal utility, that’s the scale that you need to get to — because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it’s not going to happen if you’re doing a per-customer expenditure.”

Continue reading the transcript or listen to the podcast here.

read more