As I begin writing this series, I have to admit I am deeply disappointed with the portrayal of cloud computing by the pundits, analysts and technical media in general. “The Cloud” has quickly become a metaphor for anything that can be accessed on a network and for the network itself. The term is so broadly used it now can mean anything and at the same time – nothing.
Since as a word, a cloud carries the sense of a nebulous, vaguely defined mass – I guess it is apt. That description is certainly what it has become in most peoples’ minds. At the same time, every cloud provider is telling developers that they need to use their services and develop their applications for the cloud. What does that mean? Why would I want to?
Let me begin by defining what I mean in the context of this article when I use the term Cloud. In essence, it is nothing more than virtualized infrastructure. The term includes all the resources necessary to communicate, access, process, and store data – but without having to manage and provision physical hardware. For a long time, ten years or more, virtualization technology has been an enterprise tool; used for managing infrastructure resources in environments that include hundreds of servers.
In enterprise data centers, virtualization is generally used to:
- Lower the implementation time and risk for server deployment.
- Aggregate services to improve total infrastructure utilization.
- Improve and standardize failover and server reliability.
- Improve and standardize server and infrastructure management.
In a pool of many servers, these benefits translate to lowered risk and a lower total cost of operation. Getting those benefits in a large pool of servers generally requires only moderate application configuration and no rewrites.
Let’s compare that to a minimal implementation for a SaaS Application – starting on bare metal (machines with no OS or configuration) so we can see how virtualization will impact operational costs:
As you can see from the diagram, when I say “minimal” – I don’t mean bare bones. This is a basic implementation on either owned, local servers or hosted servers that is redundant and will allow for failover and transparent (to the user) scalability. A bare bones implementation could be just a web server/application server and a database server. But, in that case, every failure, upgrade, change, etc. will take the service offline.
This is an important distinction because SaaS is a cash flow business. Downtime equals lost opportunity. An opportunity lost in a SaaS business is lost forever. Not because you can’t eventually get the prospect back. You can. But in the meantime, you are still spending money to keep your operations running and available. In a SaaS business, operational costs for unused resources (staff, infrastructure, etc.) take away from margin. If taking a server offline means shutting off your service, you will lose opportunities for new business, reliability in the eyes of your clients, and the operating spend for your unused or under-utilized resources.
So, what does a basic redundant and scalable implementation for a SaaS application include?
- 3+ Web/Application servers in a cluster configuration.
- 2+ Database Servers in a replicating cluster to allow for failover.
- 2 Basic Log & Management Service Servers (could be one, but most implementations will use two).
- Firewall, Router, Load Balancer, Network Switch.
- OS, Web/Application Server, Database Server & Associated Licenses.
- Redundant Internet Access.
- Skilled Staff for implementation, maintenance, cluster and performance management.
Before we get to how we’re actually going to host this implementation, let’s also examine the time required. For implementation on bare commodity servers with experienced staff:
- Web/App Server (install OS, web server, application, apply updates, configuration, test, etc.) = 2 days
- Database Server (install OS, SQL database, apply updates, configuration, load database, test, etc.) = 3 Days +
Now most IT people will tell you it would take a little less time if you were setting up machines on a regular basis and you had some configured disk images ready. But we’re considering a small to moderate-size SaaS business, something beyond a beta phase startup, but certainly not a major service. Economies of scale are not available for server implementation in this size business.
While you’re considering the staff costs for an implementation – because you need experienced staff with an Internet-based skill set – you should also realize that these same implementation times will be true when you need to scale your deployment up during regular operation. Ok. We want to avoid as much of that cost as we can so we’ll use a managed server implementation like is available from most hosting companies. This is comparable to having hot standby servers with the OS, standard configuration, updates, and necessary web/app server or database server installations in place and ready. What times are we looking at then?
- Web/App Server (configure for application, install application, test, etc.) = 5 hours +
- Database Server (configure for application, upload database, test, etc.) = 1 day +
In both cases, the time and risk for implementing infrastructure means we will have to scale considerably ahead of need. As a consequence, most SaaS companies will not risk having less infrastructure deployed than is necessary to meet their peak usage requirements. If service performance suffers, user satisfaction drops and churn rises. If the service cannot respond quickly to peak requirements, it is a lost opportunity and cash flow will suffer.
This implementation philosophy is known as Build-To-Peak. What it means is most successful SaaS businesses will be over-provisioned more than half of their total operating time. And remember, in this scenario implementation is a manual operation. Someone skilled has to be available to do the work and be on standby to monitor the server and ensure it is working properly for some period of time after the server is stood up. This also means, we aren’t going to decommission infrastructure on a whim. We’re going to stay scaled to handle what we believe will be peak requirements until we’re very sure our need has dropped considerably and will stay that way for an extended period of time. Otherwise, we’re just throwing money down the drain.
So – what does this cost? Taking into consideration a managed server implementation with any of the major hosting companies (RackSpace, Peer 1, etc.) this implementation would have a cost of about $6,000 per month. That’s steep if you don’t have a lot of customers, but it isn’t even close to all of your operating costs. Let’s assume a minimal staff load to just maintain the service while we hope our total number of clients rises high enough to give us a positive cash flow. What might we need?
In this scenario, I’ve considered that a lot of the staff will either be contractors (part-time) or an outsourcing firm. I haven’t included one-time license costs, office space and equipment, or any payment for the owner/manager. There is no application development cost because that is an investment, not part of operations. There is also no budget for on-going application development and very little or nothing for special promotions or marketing. At $26,900 a month, we are looking at a cost of $322,800/year for operations of a minimal SaaS business.
At this point, you have to step back and ask:
- How much are we charging for this service?
- How many clients will it take to reach positive cash flow and when are we going to get there?
- At what number of clients will our operating costs increase?
That last point is critical to consider. In SaaS, costs tend to increase in jumps.
Imagine: Your customer service and support person is getting too busy. You have to recruit another staff person, train them and get them up to full productivity before you need them or your service will suffer. In SaaS, costs come due ahead of income. That means, in a period of high growth, you are going to need a cash reserve or you will literally run out of cash trying to capture the new business.
You can see – even with a minimal implementation – the total cost of operations in a SaaS business could mean it will take a long time to reach a decent return on investment. If you haven’t modeled your business model properly you may never reach positive cash flow. In SaaS, business scalability is key and operational efficiency isn’t optional.
Now let’s get back to our basic discussion. What will “The Cloud” do to change this? For this size implementation, if we simply move it to virtualized servers on a standard grid-type “cloud” host it will actually cost more to operate per month.
That’s right: On a one-to-one basis, for a full month of usage, a virtualized server will cost more than a traditional, managed server. It will also require IT staff with a more advanced (expensive) skill set. It will do nothing significant to reduce total staff costs.
At this size, and with this kind of application architecture and implementation, the value of cloud hosting is marginal at best. In fact, most of the value mentioned in the bullets at the start of this article is going back to the hosting company that is managing hundreds or thousands of servers. At most, a SaaS company can only hope to shave a few hours off of server implementation and management by moving their application directly to a cloud hosting scenario.
So – why the heck would I say that SaaS companies could be saving 33-50% of their total operating costs by developing for cloud infrastructure?
How on earth can anyone recommend a cloud-based application for anything but the biggest companies?
You’re going to have to read the next segment of this series to find out.
And believe me – if you are planning a SaaS business it is an important lesson…
Recent Comments