Why I don’t like the “Cloud”

This question comes up a lot with my customers… “should I put my data in the cloud?”  When it does, I recount the following story:

Years ago when I started working with computers, all the local school districts had software from the same company.  We’ll call them OldCo (obviously not their real name) for the purposes of this discussion.  OldCo also sold software targeted at city governments, and I had a few city customers using some of those products.

OldCo’s software was all DOS based.  They started a project to convert their school accounting and student records programs to Windows.  Just as they were about to begin beta testing of their Windows accounting software, the database vendor they were using went out of business.

So they couldn’t buy the necessary licenses to resell to their customers.

They started all over at that point, essentially scrapping the entire project, and switched to an entirely Microsoft-oriented codebase, using SQL server as their backend.  This put them way behind their planned deployment schedule, not to mention costing them a bunch of money.

Along came another company, which we’ll call OSC (Other Software Company).  They were another major player in the school software business, and their software supported Windows already.  OSC bought out OldCo to get their customer base (a sound strategy I’m sure), and pushed all those schools into switching to their student records software.  They didn’t have a school accounting program, but that was okay with them… they kept the OldCo staffers who understood that program and continued to maintain and sell it.

Who’s missing here?  The city government customers.  OSC notified them that they would not be supporting or selling OldCo city government software any more, and no, they wouldn’t really help anyone extract their data from it either.

Those city government customers were cut off from support, but at least they could keep using the programs.  If their data was stored in someone else’s cloud, and that someone else closed their service for any reason, where would they be then?

This is why I don’t like the Cloud.

2 thoughts on Why I don’t like the “Cloud”

  1. I think what is being used here is a very loose definition of “cloud” and it has unfortunately resulted in a skewed opinion of cloud services.

    Like any other decision regarding the direction of an IT infrastructure, you have to do your research and remember the fundamental rule that you get what you pay for. That being said, there is a great big black line to be drawn between cloud service providers and software companies that have a hosted offering. It sounds like you had a nasty run-in with the later of the two.

    Like anything else related to IT your decision is essentially an exercise in risk assessment and cost/benefit analysis. Some critical points to consider when making the jump to the cloud, in no particular order:
    .) How critical is the application that I’m considering placing in the cloud? If my access goes down, what does that mean to my organization? What is my level of tolerance for that event?

    .) Who owns the data? Does it belong to the cloud service provider as a by-product of the service I purchased or do I actually retain the rights to the data?

    .) What is the service level agreement (SLA)? How many “nines” of uptime am I guaranteed? (5 “nines” = 99.999% uptime, 4 “nines = 99.99% uptime, etc.) How often is SLA measured? (Daily, Monthly, etc.) Is there monetary remedy if the provider does not meet the SLA?

    .) What are my obligations as the consumer? What am I responsible for v. what is the provider responsible for in terms of maintenance, backup, deployment, etc. Can I access the application using my existing internet connection or does it require a private access such as VPN or MPLS that would require more costly hardware?

    .) What is the length of the contract? What is the cost for the service and the length of the contract v. having to own and manage the software using my own resources?

    .) What is the support agreement? What is the support SLA for standard incident response? What is the guarantee for P1 (total outage) emergency response? During what hours is support available? (24/7, 8/5)

    .) What is the fault tolerance capability of the provider? Are they virtualized? Do they maintain fault tolerance in the event of server outage? Are they geo-diversified in the event of datacenter outage?

    .) What are my State/Federal compliance obligations that accompany my data (HIPPA, PCI, ISO, SSAE-16)? Does this provider meet those standards? Are they independently certified and verified or do they require me to bring my own certification? Does it meet my independent audit standards?

    .) Does moving to the cloud solve any problems that I have today or simply relocate them?

    .) Check references? Who are the other clients that they service that you can talk to and get feedback on their experience?

    .) What are the providers’ demographics and where does your organization fit in? Are you their largest? Smallest? This may have an impact on the quality of service you receive, although in a perfect world it shouldn’t.

    .) What is the exit strategy if I choose later to go with a different provider or take the application (back) in-house?

    .) What types of standardized processes and procedures can the provider share so that I know what I can expect from my services?

    These are just a few of the considerations that you have to take into account when evaluating cloud services. Getting answers to some of these question, or even just the providers’ ability to answer these questions will help you “separate the men from the boys” when it comes to making the choice to jump to the cloud.

    Bringing it back to your particular experience, when it comes to government sponsored IT, you’re looking at a wholly different ball game. Government organizations (read as: schools, local/county/state/federal departments, etc.) tend to be very underfunded in terms of IT and are often required to maximize the return on investment at a blistering rate. The requirements of how much they have to accomplish on so little is bordering on absurdity. That said, even for a small organization, there are tools available (some open source even) that can help to build out a production-level datacenter environment to host multi-tenant applications in a way that meets both the operational needs of the client and also preserve some kind of profit margin. The key to maximizing both in making the investment up front to set it up correctly for longevity, and making the the commitment to stay that course as a provider. You can’t chicken out when it gets tough and you can’t be afraid to take on a customer that is perhaps a little out of your league. That’s how you grow.

    The cloud isn’t the right solution for every organizations’ application needs, but by doing a proper evaluation of the options available, you can determine if a move to a cloud-based solution is the right move for you and safeguard against the negative experience you encountered with the provider you had.

    (Footnote: Cloud services are a relatively new endeavor for most software companies right now. Many of them are making the investment in cloud-based services to gain a foothold in their respective markets. The good news for you is that this has created a buyers’ market! There is almost no part of a “cloud” contract that isn’t negotiable to some degree. When sitting down and making a buying decision with a cloud provider you hold the most power at the negotiating table because they need your business much more than you need their service, especially if you already a customer of their premise-based solution. Don’t be afraid to negotiate for the best possible terms.)

  2. Wow, that’s a comment and then some! Let me point a couple of things out:

    First, non-IT people (the decision makers in the schools and companies I work with) don’t understand 10% of what you just said. This leaves me with a heck of a job to do, to explain the issues; telling the story I recounted in my post tends to do as good a job as trying to go into details they just don’t get.

    In particular, the difference between something like Amazon’s services and SaaS offerings is outside their understanding. This is made worse by the fact that all the vendors use the word “cloud” to mean, well, whatever they want it to mean; about the only consistent thing is that the cloud puts your data somewhere outside your direct reach.

    Having an exit strategy is important. Even if you have the rights to the data, a raw data dump (in SQL format, for instance) is hardly useful without the business logic. This is a failing of SaaS providers, practically all of whom use the word “cloud” to describe their services.

    Perhaps I should consider it an oversight of my own that I didn’t address that last bit directly… the fact that “cloud” is practically useless as a description of a service.

    (And yes, as you said on Facebook, you should reboot your blog… I’d be interested in what you have to say. Send me a link if you do.)

Leave a Reply

Your email address will not be published. Required fields are marked *