Myself and the gang have been talking about Cloud a lot recently as we are embarking on a multi-year journey. Cloud is fashionable but is this another cool toy for the techies? As an architect I think the most powerful question in my toolbox is “why”.
- Why are we doing this?
- Does it add business value?
- What are we trying to achieve?
As IT folk it’s instinctive to go straight into the “how” but its the “why” that is the really important question. Get that right and how to do it should be relatively easy. A solution is much easier to put in place if you’ve really captured and understood what it is you are trying to accomplish. I think there are 8 reasons why companies commonly move the Cloud – I’m specifically thinking about IaaS and PaaS here but I guess this also could apply to SaaS in parts.
The massive amounts of processing power or data storage that public Cloud offerings can achieve would be difficult to achieve building your own solutions (certainly at any kind of realistic price point).
Elasticity
The ability to expand and contract resources (such as compute) depending on your requirements. Traditional IT departments buy capacity in advance which is unused until it is required. The elasticity of Cloud allows us to buy what we want, when we need it and not be constrained by fixed overheads.
Cost saving/model
One insurance company I know said they did some calculations and Cloud was 3x more expensive than on-premise. I’ve seen Cloud companies boast that IaaS is 3x cheaper than on-premise. You should do some due diligence on the cost of Cloud of course. However, in my eyes it’s too complicated and fuzzy to create a compelling story at the moment. Does this mean you shouldn’t move to the Cloud? Absolutely not – but focus on the other benefits too as cost alone is too difficult to accurately determine. The move from CapEx to OpEx is also a difficult question for many and really needs to be thought about. How do you accurately budget for a service if you are using the elasticity and scale features of the Cloud for example?
The rate of new features hitting Cloud providers is pretty astounding. AWS for example have over 450 services now and more hit the shelves every month. You probably won’t need the majority of these features now but what about in the future? As an IT department we can’t predict the future but we can help to respond to it. Why build it yourself when you can buy it as a commodity?
Time to market
With Cloud being pre-packaged and largely automated the time to market for adopting resources is often significantly lower than doing it yourself. You might have a really neat automated server build at your company but chances are you still need to wait for the storage guy or the network guy to do something. Often its not even the time waiting for something to be spun up – its the time waiting for a person to become available in order to press the button to spin it up. For example, in my company it takes 2 hours to build a VM. However I might not be able to book a resource to kick the process off for 2-3 weeks depending on their availability. I don’t think this is a problem that only public Cloud can remedy but again why build it internally?
Resilience
This is a bit contentious but bear with me. Cloud outages happen. On-premise outages happen. However, I would argue that due to the scale of some of things like Azure (and the ease of employing it) that cloud is more resilient than traditionally hosted IT. But…. Only if your application is written/configured in such a way to take advantage of the multiple availability zones and the resilient functionality that Cloud providers…..errrm….provide. If you simply lift and shift from on-premise to Cloud you are just moving the problem. If you treat Cloud just like another data centre you’ll get just another data centre with much the same problems as you currently have. Perhaps even worse. At least in your data centre if there is a problem you are in charge of your infrastructure guys and can prioritise (shout at) them. What is going to happen when you are speck on the Azure infrastructure? Is your voice going to get heard? Is it heck.
Increasing competitive advantage
Although there is value getting your IT teams to run infrastructure (it’s likely your business couldn’t operate without it), does they offer competitive advantage? What competitive advantage do you realistically gain over your rivals by running your own SAN, servers etc? Wouldn’t it be better if your teams were concentrating on high-value tasks that separate you from competitors rather than undifferentiated heavy lifting? Competitive advantage can be realised through such things as…
- Lowering costs
- Improving quality
- Increasing the pace of change
- Improving end user support
- Innovation
- Spending more time understanding the business
Wouldn’t you want your teams spending time on the above rather than worrying about provisioning blades and making sure backup tapes get revolved?
Geographic reach
As companies grow and their worldwide reach increases (customers and internally) then it means getting data closer to the end user.
- Your Google ranking is probably going to suffer in the US if you are serving your website from the UK.
- Your Citrix session is likely to be “sub-optimal” if you are sat in London trying to access your VDI farm in Australia.
- How do you organise downtime for maintenance when your worldwide presence is open 24×7 because of your global reach?
The global reach of public Cloud companies enables to provision resources nearer the people that need them.
A word of warning
In order to fully realise the benefits of the Cloud (such as scale, resilience) applications need to be architected accordingly. You are unlikely to realise the benefits I’ve talked about simply through “lift and shift”. It’s also worth mentioning that people, process, technology, culture all need to be addressed as part of the a Cloud adoption. This isn’t just a technical exercise and nor is Cloud a panacea for all of the challenges that face IT.
