First, let's define our terms. "Cloud" is one of those lovely marketing terms that everyone has a definition for but no one can really define. While you can talk about the 'Private Cloud' (Like EMC does) or 'Cloud-Based Apps' (Like Salesforce.com does) - and be perfectly correct in doing so - notice that in both those cases the word is either modifying or being modified by some other descriptive term. The cloud concept itself is something separate, and it goes way back to the days when the internet was a newfangled concept that had to be slathered on every piece of marketing. Doesn't that sound familiar? Basically you'd have these architecture diagrams where you'd connect servers and clients and databases with lines and then put another line leading to a cartoon cloud, like a thought-bubble, labeled 'internet'.
(Source credit: http://www.softwareprojects.com/resources/programming/t-converting-a-standalone-server-application-to-a-web-1321.html)
In the years since this practice started we've sliced and diced the term up into a number of broad but distinct concepts, and in only a few of them could you possibly confuse the cloud with the internet. On one end, the private cloud, the term gets mixed up with virtualization; and on the other end, Software as a Service (delivered via the web) does exist on the internet but it is not itself the same thing as the internet.
In any event the first tip for keeping cloud expenses under control is to 1. Clearly define what you mean by cloud in your specific circumstances. This goes beyond keeping job descriptions and department budgets neat and tidy; as is evident in the recent report by the CIO of the United States, Federal Cloud Computing Strategy, it is far too easy to go down the rabbit-hole of leaving terms open-ended and thus finding your end-goals undefined. This leads to equivocation rather than decisionmaking when choices must be made. The paper goes into specific but useful detail regarding the broad concept, and it may be a useful template to you in your migration or management efforts.
2. Keeping old systems and processes is not the same thing as archiving old data. Far too often, because of an insufficiently powerful migration team or a poorly defined reduction goal, companies are stuck with mildly or wildly hybrid cloud solutions because of unwillingness to part with old hardware or software. This may be as simple as keeping the old email server and system even when a new web-based service is brought on, or retaining the old customer relations mamagement system after adopting a cloud software as a service rather than migrating the old data into the new. It may be easier than a data conversion, and since you've already paid for the old hardware/software it may be less costly; but it is never going to be as clean and manageable as having only one system to maintain, and the maintenance price will become a growing and ongoing burden over time.
This is a particular issue when we're talking about moving from a traditional datacenter to a cloud model. Sometimes the talented people doing the labor are beholden to a person in the approval chain who is too fearful to turn off the old storage arrays even after they've been migrated - again, in the interest of 'archival use', and/or out of fear of noncompliance with HIPAA or SOX. if you don't turn off the old stuff, you've only increased your expenses and complexities while reducing your visibility of and control over your data. On the other hand, regulation compliance is no simple matter, and you may have legacy boxes or other special circumstances to deal with. If so, you can usually find a reasonably priced and highly qualified maintenance solution via third-party providers who can handle your existing post end-of-life hardware, even if the original manufacturers would prefer to further complicate things by demanding hardware upgrades first.
3. Avoid cloud for the sake of cloud. The paper cited above from the CIO of the USA arguably gets caught up in this very pitfall, because after citing legitimate but general benefits, the conclusion drawn is that all systems that can be converted to cloud must be converted to cloud. When the initial premise is that everything has to be completely 100% cloud-based, you have to step back and ask why - the benefits of cloud computing are in no way contingent on the incorporation of cloud technologies across the board, and 100% cloud is not the same thing as 100% one-point-of-contact efficiency. Cloud application services may come from dozens of companies, and many cloud storage customers choose a different provider for cloud backup, or opt for a private cloud for one and the public cloud for the other. Instead of choosing a model and then forcing the organization to adapt to it, look for those areas of most inefficiency, highest cost, and least profitability. Those are the priority targets for cloud conversion. If other aspects of the business are operating optimally, there may be little to gain by converting them to a cloud model. In other words, if it's not broke, it's legitimate to at least ask why it's best to fix it, rather than assuming that all things cloud are automatically better in every specific case simply because the cloud has general cost, management, and maintenance advantages.
4. Understand the security and availability levels. You should approach a cloud service or hosting relationship as though you are putting that aspect of your business into the hands of the least qualified, least ethical, least reliable person at that company. When you make this assumption it's often more clear whether you're going to have trouble or not, depending on how complex the relationship is and how dependent on individual personalities rather than impersonal features the service is.
In a traditional data center you hire and assign your own employees, and can dismiss them if they fail to meet your requirements. The people involved have an accountability to the executives which is both an incentive to do a good job (get paid, get raises, get recognition) and a decentive against really fouling things up (get demoted, get fired, get humiliated). None of these things exist between your company and an outsource, and that's the case not just for cloud services but for any outsourcing you may do, from telemarketing to shipping.
It's important to remember this, especially in the RFP and consideration phase, because other subscription-based outsourced tasks are usually commodities. When your only recourse short of major legal action - hardly a quick fix - is to cancel your subscription, you may find yourself uneasy handing over control to an outsource. On the other hand, having a strong business ally and advocate is a relationship worth pursuing. It is imperative that you work closely and comfortably with your choice rather than taking a hands-off route, however.
A key tactic for achieving peace-of-mind is to request that bidders explain in their proposals what practical difficulties may be reasonably expected if the relationship fails or their company is aquired. This goes way beyond contractual wording about responsibilities; you need to know how hard it will be to get control back or transfer control of the service to a different business. Can you securely and immediately retrieve all your current and backup data, or is it lost if you decide to end a cloud relationship with the host or service provider?
Even when the cloud tool is as simple as a CRM or email marketing system, it's critical to maintain a degree of independence because you can only be responsible for, and reasonably confident in, the business practices and long term viability of your own company. Along the same lines, you must be certain that your provider maintains compliance with the regulations that your business had to comply with before moving the service to the cloud. Assuming that your provider understands your company is taking a risk. Hosting businesses are not healthcare businesses, and they do not understand the specific needs of your vertical any better than you understand the specific needs of theirs. Ultimately you should not enter into a long term agreement that leaves you on the side of the curb with hundreds of other disgruntled customers when a provider is acquired or makes a major policy change.
5. Understand the pricing model fully. Especially in the case of services involving a subscription model, it's critical to understand exactly what the breaks are between tiers of payment (and when applicable, tiers of services as well). The time to find out whether your provider is charging by the month, by the record or by the gigabyte is before you've decided on anything, not after you've gotten an invoice that sends accounts payable into the stratosphere. When IT controls these decisions this is simple enough, but is sales responsible for the CRM or the customer database? They need to know what to look for, or your policy should require these kinds of one-off purchases to get IT approval as well if you don't already have a set policy regarding this.
Under normal circumstances this is all part of the proposal consideration phase, but too often all that's noticed then is how the pricing compares to other providers. Pricing should be considered in its own right relative to annual budgets. Ideally, multiple scenarios should be priced out in writing by the provider so that the effects of different circumstances can be seen by all, and so budgeting can be adequate rather than insufficient. Running a scenario also helps to expose potential bottlenecks or hidden cost bloat pitfalls.
Refunds and make-good time for outages should be discussed as well. Cash or free services are the normal compensation in case of an error on the part of the provider. In particular make sure you know what documentation is necessary for reporting a problem that isn't immediately obvious; downtime is not the only thing that might go wrong, and when your hardware is offsite it's much harder for IT teams to identify and correct configuration or reporting problems. Here too it's important to involve employees outside of IT who may be making cloud purchasing decisions when it comes to web-based services for their department.
This list could probably be twice as long, easily. What other things do you think are helpful to keep in mind when trying to manage a cloud migration project in a cost-effective way?
Keyword Tags: cloud efficiency storage Disclaimer: Blog contents express the viewpoints of their independent authors and are not reviewed for correctness or accuracy by Toolbox for IT. Any opinions, comments, solutions or other commentary expressed by blog authors are not endorsed or recommended by Toolbox for IT or any vendor. If you feel a blog entry is inappropriate, click here to notify Toolbox for IT.
I found your post good and informative. I like your article. Thanks for sharing it.
ReplyDeletemicrosoft frontpage 2003