The cloud awaits... but is your enterprise ready for the jump?
Five ways to find out
I have worked with a number of companies that explored the cloud as an option for their infrastructure, and recently I worked for two that are cloud service providers themselves.
So I have often had conversations in the past few years along the lines of: “Is the cloud suitable for my business?”
A good way to find out if you are ready for the cloud is to start by asking yourself five questions – and answering yourself honestly.
Security fears gone mad
If you are positively paranoid about security, you should admit that you have fallen at the first hurdle. "Security issues" will have you wheedling out of even considering the cloud concept.
It is a bit like people telling me their company is based in Jersey “for tax reasons”. They may be right, but they usually don't know what those reasons actually are. Or when people say they won't tell you something “for data protection reasons”, they often mean “I'm allowed to but I don't want to”.
Large cloud services are in secure data centres to which access is strictly controlled. Only the providers' own staff (and maybe the odd vendor engineer wielding a box of spares) are allowed in.
And you can encrypt your virtual machines' filestores so that the data is available only to the holder of the private key (you), even if a rogue provider staffer manages to access the console.
When it comes to connecting your offices to your cloud installations, even the pickiest auditor will tell you that private circuits set up by reputable telcos are considered secure.
If you choose to use internet connectivity instead of expensive private circuits, IPSec tunnels are perfectly acceptable in this respect so long as you choose your encryption and key length sensibly.
A decent cloud provider typically has much better security than the average corporation, so do get a sense of perspective when thinking about security.
Where is my data?
When faced with the “cloud” buzzword, it is easy to think it is all just an amorphous soup of processing power and storage, and that once you have poured your world into it you will have no idea of what is where.
To dispel this myth in your own mind, try creating a virtual server on, say, Amazon's or Microsoft's cloud services. One of the first things you will be asked is which geographic region you want the data to reside in.
Cloud providers understand that the law constrains what you can do with your data, including where it sits, so they provide you with the tools you need to be sure it stays in a clearly defined physical region.
Data import and export is a big deal. If you don't understand how your data might cross a national border, you could well find yourself unwittingly “exporting” it.
Let's take an example. There is a file on a server in your New York data centre. One of your Irish employees connects to the server from Dublin via Remote Desktop and views the file.
You have just exported that file – even though the file itself hasn't left the data centre.
Incidentally, if the same employee takes a flight, walks into the data centre, fires up a console session and views the file, you have still exported it. Yes, really: viewing a file in the country of origin by a foreign national counts as an export.
You therefore need to understand where you are allowed to put your data. This shouldn't, of course, stop you from putting it in the cloud, as long as you understand the constraints you are under with regard to which providers – and which of their regional operations – you can entrust with your data.
Count the money
We have been talking about security because it is the first subject the finance director usually jumps on when you mention the cloud.
In fact the finance director should be much more concerned about the cost of moving to the cloud. You can't just blindly use the “it is much cheaper” defence.
It is true that the startup cost of a cloud installation is, in my experience, always lower than the startup cost of an on-premise offering.
If, however, you have historically used a co-location arrangement (where you house your own servers within a data centre to ensure they are in a secure, robust, always-on environment) it is a lot less clear cut.
Say you want to run 200 assorted virtual servers: using a cloud provider I just picked at random that would cost you about £5,300 a month, before adding necessities such as storage.
Even at inflated offshore hosting prices I could get a cabinet in each of two data centres with a dedicated Gigabit fibre between them for £2k less than that, leaving me plenty of room over three or four years to buy some blade server hardware and operating system licences.
More importantly, I see many companies where the financial constraint is on operational expenditure, while capital funding is more readily available.
If your company works like this, the fact is that a cloud setup is considered entirely operational while a self-hosted alternative may benefit from capital accounting rules.
Equally importantly, do you understand the charging regime of the cloud provider you are looking for?
To be fair to Amazon and Microsoft, the pricing screens of their services are considerably less obtuse than in the early days, but if you have a complex setup you may want to look at one of the third-party services from the likes of Cloudyn. These help you see your costs clearly – and even do “what if” calculations to see whether you could save by moving to another provider.
Cost transparency is essential because cloud is a pay-as-you-go service and per-minute costs of a few cents soon add up to big bills.
The weakest links
If you are moving to a cloud service for your internal applications, you will need to consider connectivity between your premises and the cloud installation. It is easy to forget any weak links in your LAN, MAN or WAN.
Not long ago I worked on a network which made copying files from on-premise server 'A' to on-premise server 'B' slower than downloading them from their source via the internet because of the way the internal firewalling was done on the company MAN.
When you move to the cloud, you will lighten the load on your internal network thanks to the offloading of server traffic. You will, however, be making the connectivity from your users' desktops to the cloud-based systems a whole lot more critical to your day-to-day business.
An increasingly common scenario is on-premise primary servers replicating to off-premise secondaries to provide failover capability.
If you implement this you need to test the failover regularly and ensure that users can connect satisfactorily to the secondary systems should you activate your disaster recovery plan.
None of this is rocket science, but it is important to ask yourself whether you have truly considered the ins and outs of the user-to-server connectivity, and not just beefed up your flaky little internet link.
Trust me, I'm a provider
When you are choosing among cloud providers, you will be looking at their service-level promises and their time-to-fix predictions for faults. That is fine, but ask yourself this: do I trust them to deliver?
Hint: the correct answer is “no”. If you answer “yes”, slap yourself until you change your mind.
You should be monitoring any service that you use and you should not use a provider's own monitoring tools to do this – not least because an outage in the system may prevent the monitoring system from telling you about the problem.
Consider the criticality of each of your applications and decide where you should monitor them from.
This will often be a combination of on-premise systems (so you can monitor real-life response times as the user would see them) and third-party systems (for example to confirm that internet-facing services are available to the outside world).
Consider also the implications of the service provider missing its service-level agreement. The recompense you receive will be pseudo-financial, taking the form of a few days' discount on your next bill.
The cost to your business of repeated outages could be that it ceases to exist.
Consider also how providers work out their performance averages: the sample size is often so vast that it smooths out even the biggest peaks and troughs.
You don't care about the promise, you care about the reality – and the way to be certain of the reality is to monitor it yourself.
Don't panic about security because you don't really understand it. Do a sensible risk assessment, whether you do it yourself or pay someone more expert to do it.
Find out whether there are any restrictions on where your data can go and look for providers that can accommodate these.
Make sure you price the service properly and make a valid comparison with the alternatives to cloud – even if you have to use a third-party service to understand it best.
Ask if there are any inadequacies in your own infrastructure that will be shown up when you move to the cloud.
Finally, bear in mind that regardless of where your services live, you should always have the ability to monitor them.
But just think for a moment. If you were hosting your services internally, all of the questions we have just been through would apply equally to your in-house setup.
The considerations you need to make for the cloud are pretty much the same as those you need to make for on-premise installations.
So in answer to the main question: yes, there is every chance that your enterprise is indeed ready for the cloud. ®
Sponsored: Are DLP and DTP still an issue?