How to Be a Cloud Computing Vendor

Honestly, it seems like anything and everything using hardware virtualization automatically forms a Cloud and so everybody offers one. Trying to understand cloud computing is not the easiest task since all the heavy jargon confuses things even more.

As a result, it becomes increasingly important to deal with the confusion of cloud computing or hardware virtualization as it relates to Software as a Service (SaaS). And more importantly, SaaS platforms.

I want to touch on a couple of the things that SaaS vendors need to deal with so that we can better understand where I’m coming from. But before I do that first let me clarify something: all software delivered over the Internet is not created equal, but in fact falls into a “purity spectrum.”

Delivering software over the Internet is nothing new, but some of the purest, most robust forms of delivering software over the Internet are, in fact, new and are much better than traditional mechanisms. The idea of consuming software over the Internet has existed for a long time – if you remember we used to call the previous iteration “The ASP model.”

What really differentiates the old ASP model (at the less efficient end of the spectrum) from modern SaaS applications (at the more efficient end of the spectrum) is the architecture of the applications themselves.

Let me explain: SaaS is really just a game of numbers, and if you want to win the game or even play long enough to actually enjoy it, then you have to be as good as possible at fine tuning those numbers. Arguably, the most important number in this game is the cost of delivering a SaaS offering to your customer.

We generally refer to this as ‘Cost of Service.’ Essentially, it’s analogous to ‘Cost of Goods Sold’ in a product world; it takes a dollar amount of variable material input per dollar amount of revenue: the better the ratio, the better the margins.

In SaaS, having an inexpensive means to deliver your services (a good ratio) means that the odds of becoming and remaining profitable skyrocket. The reason why the ASP model failed and SaaS companies are gaining steam today is because SaaS companies figured out a much more efficient way to deliver software over the Internet.

As you’ll come to appreciate, the efficiencies in Cost of Service are directly related to how efficiently the software is delivered, which is directly related to how the application itself is engineered.

To continue the theme of efficient delivery, it really is all about how well you can utilize the resources available at your disposal; whether they are hardware resources or human resources or both.

The real magic is captured in two key words: customer density and automation. Customer density is essentially a measure of how many customers can be serviced from some well-known set of resources. For instance, if it takes one server or virtual machine instance to service a single customer (a throwback to the days of ASP), we have a 1:1 density. If my application is architected in a fashion where 50 customers can be serviced from one server or virtual machine, I’ve achieved a much more efficient density.

The denser you can run your application on the hardware resources you have available, the more efficient you’ll be at delivering the software and hence the better you will be at those numbers!

The next important measure, automation, describes how efficiently a SaaS company can grow and manage density on a well-known set of resources.

For example, an automated customer provisioning system allows a SaaS company to move from X:1 density to (X+1):1 density without a fixed, manually driven cost. This means that the application needs to become intimately involved with its own delivery by explicitly dealing with the density and automation problems within its own architecture.

ASP attempted to ignore this by sacrificing density and automation for ease of architecture, leading to its rapid (and thankful) demise. Looking at today’s SaaS enablement and “SaaS platform” landscape, it seems that some of ASP’s mistakes are being evangelized, but it’s the same unsatisfying gift with new wrapping paper.

Some in today’s SaaS landscape propose, for example, that virtualization in the cloud solves the multi-tenancy problems in SaaS, therefore categorizing their virtualization in the cloud solutions as a “SaaS platforms.” At the end of the day, however, a virtualized approach might solve some of the automation issues, but has negligible impact on the density equation.

What does that mean? A higher cost of service, of course!

SaaS vendors have many things to worry about; among them, issues like:

• Multi-tenancy.

• Provisioning new customers to grant them access to the application in a timely manner.

• Providing ongoing support for their usage of the application.

• Billing and metering of the application for every customer on a recurring basis.

• Introducing new functionality with minimal disruption to the existing customer base.

• Reacting to market needs to continuously deliver the best that your customers demand.

So a SaaS application is two initiatives in one: the application core responsible for the functionality your customers care about, and the SaaS delivery stack that captures the delivery model in code.

When architecting a modern SaaS application (or even if you already have a SaaS application and are considering future versions), every action that you can take to improve density and automation is key to help you improve the odds of winning the game.

There are a couple of options when it comes to achieving high marks in the categories of density and automation. Identify and architect these complicated topics into your applications architecture or leverage a cloud platform.

When deciding, a couple of key takeaways should be identified:

• Architecting a true SaaS architecture is a non-trivial task. Be wary of anyone that tells you otherwise. The “SaaS plumbing” can take as much as 40% to 70% of your application development time and money only to build a rudimentary platform.

• Don’t get trapped into thinking that you can architect SaaS into your application and forget about it. SaaS is not just an upfront expense. Maintaining the delivery model part of your application architecture will require a disproportionate (and costly!) amount of effort.

• Good SaaS platforms exist that do not significantly limit what your application can do. There really should be very little reason why you can’t write your application on top of the existing platforms that are available in the market today.

You should ask yourself the same question you would if you were delivering a regular on-premises application. I can pretty much guarantee that you are not going to write the operating system for your application as well as the application itself, but you will instead write your application on top of a platform like Windows or Linux or Mac or some other well established platform.

These key points should help identify some steering questions when it comes to delivering SaaS. It should also prompt you to really understand what someone is delivering when they claim to offer a “SaaS Platform” that you can leverage in your SaaS journey. If a supposed platform doesn’t intimately become part of your application’s architecture to significantly (and positively) impact density and automation, it’s probably not a “SaaS Platform.”

I believe that there is a very real need for many of today’s cloud providers. But just make sure you know where they stand. Cloud-based virtualization is virtualization, while “what you see is what you get” editors (WYSIWYG) are just that, and real SaaS Platforms solve the architecture problems we described.

Honest companies like Amazon.com don’t call their services a “SaaS Platform”; they simply openly acknowledge what their value proposition is and call it what it is, so let’s stop confusing a rock for a hammer and call things for what they are. And if you are going to call yourself a SaaS Platform, or if you are going to suggest one for that matter, make sure you are using the right tool for the right job and don’t assume that “all Clouds are created equal.”

When you are choosing an implementation path for SaaS and for your business, make sure you are considering these questions and all of the components that you will need to tackle as a SaaS business. Choose wisely!

Abraham Sultan is VP of Engineering at Apprenda.