The 10 biggest mistakes made when moving (or considering a move!) to the cloud

I wanted to share this with you all, courtesy of David Cartright at CloudPro, as further justification that “Cloud”, the current buzzword and trend, is not for everyone, and if not managed correctly will not deliver the economies of scale originally intended.

The 10 biggest mistakes made when moving (or considering a move!) to the cloud.

There are some compelling reasons to move to the cloud but it’s easy to make mistakes too. Here’s ten of the most common…

Cloud computing can, of course, be a hugely satisfying thing to do. It can be cost-effective and straightforward whilst at the same time de-risking your organisation through the sheer reliability and high-end support of the remote infrastructure. This doesn’t mean that it’s a trivial thing to do, however, and it’s easy to make simple mistakes. Let’s look at the top ten.

1. Making the wrong decision to use the cloud

The first mistake that one can make is to choose the cloud when it doesn’t really suit the application or your organisation (or both).

Of course as we all know, cloud services can bring vast benefits to an organisation’s computing capability, but as with any technology there are times when it just doesn’t fit no matter how hard you try to persuade yourself it’s a good idea. Particularly if you’re a small company with no need for super-resilience, no knowledge of managing vendors and/or very simple requirements, you can spend more time and money administering a cloud infrastructure than you would if you had a handful of inexpensive servers in house.

2. Choosing the wrong machine for the job

In the cloud it’s just as easy to choose the wrong tool for the job as it is in an in-house application. Just because you use, say, Windows Server 2008 R2 for your in-house finance system, this doesn’t mean you should just map it onto a Windows installation in the cloud. Perhaps you chose a Windows platform internally because that’s the skillset you have; in the cloud someone else will manage the OS for you so why not consider, say, Linux? And of course if you take it a step further you can even decide to go for a fully managed application: given the choice of, say, a fully managed Oracle app on a fully managed Linux box, why wouldn’t you go for that if it’s faster than a Windows installation?

3. Bodging your user access

When you run applications in the cloud, user access can be easy or hard. And if it’s hard, the chances are because you made it that way. What’s one of the key difficulties with in-house systems? Maintaining a collection of disparate user databases is one of the world’s greatest pains in the backside, and with a cloud setup there’s nothing different. Yes, it can take a little bit of effort to integrate the cloud service with your own directory service; and yes, it might take you a few minutes to persuade the higher-ups in the company that to do so isn’t a hideous security risk from Hell. But properly integrated user access is an absolute god-send – not least because it’s the only way you can be sure that when staff leave the organisation and you want to be sure their access has been properly curtailed.

4. Disregarding geography

As we all know, putting an application in the cloud doesn’t mean that it’ll end up on arbitrary servers in random locations. The thing is, though, we don’t necessarily all know this – many newcomers to the concept think that you have to place your application at the mercy of the supplier’s load balancing and auto-failover engines. Consider your geography carefully, and consider the legalities of where your data sits and the logic of how close the app and the data are to the users.

5. Losing control of costs

It can’t be denied that the economics of cloud computing are compelling. When you look at the cost of a powerful server in the cloud and compare it with the price of buying the physical hardware, the argument for outsourcing is compelling.

It’s very easy, however, to lose track of the virtual machines, storage, IP addresses, load balancing and applications that you’ve set up (a fact which isn’t helped by the less-than-great user interfaces on some services). This can become very expensive, because although you don’t pay very much for each component, it soon adds up when you have several of each and you’re not careful to keep track and decommission unused entities.

6. Thinking the service manages itself

In a cloud service the servers, storage, networking and such like are all managed for you – unlike an in-house application that you need to employ people to look after. It’s easy to forget, however, that managed services can go wrong – so you’ll still want to monitor the service even though it’s not necessarily your problem to fix it. Fair enough, if you’re using a managed application service then the management task is minimal, but even then you’ll want to look at things like log file growth, database transaction file growth and such like because otherwise the cost of your back-end storage will quickly begin to approach infinity.

7. Running up too many virtual machines

When you have to buy physical equipment, you tend to be a bit sparing when it comes to doing so. The moment you start virtualising, however, that concept goes out of the window – even in an in-house virtual farm let alone a cloud one.

But why is that? Fair enough, the kit isn’t costing you anything, but you’re paying for an extra OS and even though the virtualisation layer lets you oversubscribe your RAM, disk and CPU you still have the overhead of context-switching between the various VMs. Oh, and more servers equals more stuff to manage. Back in the old days of physical kit one would run multiple applications on a single server – and there’s no reason you shouldn’t do so in a cloud world.

8. Thinking you don’t need backups

Cloud services tend to be multiply resilient – dual identical systems that can invisibly fail over in many cases, plus a third machine with similar configuration that’s used for seamless software upgrades. This doesn’t mean that you don’t want to back up your data and configuration from time to time, though.

While it’s likely that the service will never die and your world will be infinitely reliable, can you really put your hand on your heart and say it’s 100 percent certain? And don’t forget, although the big providers are unlikely to go pear-shaped in a hurry, you absolutely need to mitigate the risk of a smaller provider going to the wall and taking your crown jewels with it.

9. Missing the skills change requirement

The skills required for managing a cloud installation are radically different from handling an in-house setup. One of the big culture shocks of moving to the cloud is that the hands-on technical requirement will reduce and the vendor management aspect will ramp up noticeably.

You’ll also have something of a learning curve with regard to understanding the various technical offerings from the provider (RAM, CPU and disk are easy but when you get into virtual IP addresses and load balancing that ceases to be true) and the user interface will be a new discovery for you. It’s an easy mistake to think it’ll be easy, when actually it certainly isn’t.

10. Not cleaning up after yourself

Just as we told you to think about how many virtual machines you run, you also need to revisit this resource consideration frequently. Idle virtual machines and unused IP addresses cost money for no tangible benefit, so why pour money into a black hole by leaving them doing nothing? Just as you should employ the right combination of virtual hardware in the first place, so you should also ensure that you give up resources – even temporarily – if they’re likely to be unused for more than a modest period.

 

I am not a Cloud sceptic – far from it. However I am somewhat more pragmatic than the current crop of “Cloud Evangelists” who are completely indiscriminate when promoting their solutions. Think very carefully before making a costly and possibly irreversible mistake. As I’ve said before it’s not for everyone.