Some times clarity appears when you least expect it. Just this past week it revealed itself again as I was being asked how I thought particular business application systems should be hosted. In each case the choices were:
- DIY – The traditional Do-It-Yourself option of using your own hardware and support staff. Everything is in-house and 100% under your control at all times. You are impervious to fires in tunnels and squirrels electrocuting themselves. You bear 100% of the cost of the hardware and the technical staff needed to support the whole affair.
- SaaS – Software as a Service, where the application vendor either puts up a dedicated instance of the app just for you, or you live inside their multi-tenant environment. You do nothing but pay the bill and use the software, but you do place yourself at the mercy of your network connection and the competence and reliability of your SaaS vendor. You control none of the many moving parts, but you do put your faith in all them to be working when you need them. You also hope when you call for support that 1) a live, competent person fluent in your native language will answer, 2) the answer to every problem will not be “reboot your PC or cable modem”, and 3) the problem will be resolved in a timeframe your business can live with. As a small fish in a big pond, you recognize that you have no leverage (except perhaps a Twitter tirade) when the service goes down and your business goes thermonuclear.
- IaaS – Infrastructure as a Service. An in-between solution where you buy server and storage resources from a cloud hosting provider, but you install and support your application. Like SaaS, you don’t have to worry about the hardware infrastructure. But you again bet the farm on your network connection and your hosting provider’s ability to keep the lights on. Unlike SaaS, you retain complete control over your application, which limits your risk and dependency on the hosting provider.
With all of these things to consider, making a cloud hosting decision might seem like trying to find the alligators in a swamp full of muddy water. Fortuantely, as in many areas of life, perspective and context are the keys to making a good decision. The answers to all of the varioius scenarios thrown in my in-box turned out to be not so much based on cost or technology, but more about the particular business implications of each situation. And it all really boiled down to one simple question:
If this application is unavailable, will my business be unable to transact business, and if not, how long can I put up with that?
Suddenly, the muddy water becomes strikingly clear. If your ability to run your business is dependent on your network connection and a distant data center, are you comfortable with that? To whom would you need to explain the downtime, and what would your customers say? What would be the impact on your bottom line?
For applications that aren’t critical to daily operations, SaaS and IaaS are perfect almost right out of the box. For critical apps, SaaS and IaaS can work if you design redundancy into your network connectivity, and the apps themselves are designed to let you run offline for a period of time. If you don’t have, or don’t want to have any infrastructure or technical staff, then a SaaS strategy “hardened” along these lines may be your best option.
Whether it be commercial or a non-commercial enterpise, the simple question above remains relevant. In churchworld, for example, would you want the Sunday morning presentation software (i.e. the “mission critical app”) to be running only in the cloud? Probably not. But the membership tracking application? Maybe so.
Ultimately, understanding business impacts is prerequisite to making sound technology decisions.
What apps in your business would you consider safe, or not safe to run in the cloud?