Cloud Strategy 101

"What is our cloud strategy?"

Many times have I heard that question, or variations on the theme. My answer generally is a simple one: do cloud, do it well, and do it with one provider. Obviously there’s a lot more to it than that, but here is a brief cheat’s guide, intended for the time-poor, based on some of my own experiences.

Do cloud.

This is the most obvious statement. I’m not aware of any startups or new businesses that are still building data centres and looking to become experts in infrastructure deployment or management. More than ten years ago I was part of an organisation that entertained the idea of being a regional cloud service provider and did a pretty good job at it, but correctly realised that they could not compete with the larger global players and got out. So by saying do cloud, I really mean use cloud (ie someone else’s). If you still have a data centre footprint, there may be opportunities to optimise, but you should move to cloud rather than continue to invest in something that someone else can do much better and cheaper than you can. How and when to move to cloud – that is covered in the next part.

Do cloud well.

Cloud is not magic and does not automatically solve problems that might already exist. Cloud can be cheap, secure and resilient. It can also be expensive, insecure and unreliable. The key thing to understand is that it is a shared responsibility model, and the consumer of the cloud has the primary influence on how successful a cloud deployment is, or isn’t.

The recipe for doing cloud well is readily available from each of the main cloud providers under their “well architected” frameworks. This guidance covers much more than architecture; it also includes financial, operational and cultural aspects, all of which are critical for success.

Getting the foundations correct at the beginning requires investment, but it will pay off in spades. Before going too far, you need to have the right skills. Today that means having people in your business that have done cloud before, that understand what good looks like. The job market is still competitive and those skills are scarce, so one approach to deal with the wider knowledge requirement is to seed technology groups with key skills and set up a learning guild to build knowledge across the organisation.

Success in cloud comes from automation and repeatability so I favour having a centralised function that defines the standards to be adopted across your organisation, and make these templated, automated and enforced. The team that performs this function might vary in size according to how big your organisation is, but this is an essential step to be able to perform cost optimisation, ensure security and minimise technical debt over time. Use this team to generate operational reporting including cost optimisation recommendations.

With the common standards in place for accounts and management, the actual deployment of workloads by application teams should also be following a templated and standardised approach. You should aim to use the fewest number of deployment tools, minimise the number of languages as much as you can. The driver for this approach is that every variant adds overheads in skills/training, administration and commercial management. Using cloud-native tools can save a lot of time, effort and expense even if they don't have all the features of specialist products.

Next, document your enterprise architecture, broken down into functional domains that align to business processes and identify the target state applications that will turn that architecture into a reality. This is the blue print.

Finally, develop the application hosting strategy, using something like the 6R’s approach. If you have an existing DC footprint, the business case for a cloud migration starts here; based on how long you expect to retain existing applications, what new ones you expect to deploy, what your buy vs build appetite is (for applications). Understand that the Cloud Strategy is not the Application Hosting Strategy, but you can’t have one without the other.? ?

Of course, most organisations have some mix of applications being deployed straight to cloud, some in the process of being migrated, and some in the planning phase. Nothing is ever static. So your approval framework for new workloads must evaluate solutions against the target state; tactical variations could be permitted if there is a strong business imperative, but the business case/project funding should include an allowance of money and resources to get to the agreed target state within a reasonable timeframe. The approval forum needs representation from across the business so that unknowns can be highlighted and addressed.

Use One Cloud Provider

How many cloud providers is enough? Multicloud was flavour of the month a few years ago, but has gone from a big debate to a very much smaller reality. There is a place for multicloud, but for most organisations the overheads needed to do cloud well, more than once, outweighs any other potential benefits. For more discussion on this topic, feel free to read my thoughts on it here.

Conclusion

All of the above is not simple to achieve and won’t happen by accident. Some of what I have described may sound like Nirvana, but having an intentional approach and working towards it over time – which may still be many years for some enterprises – but will deliver long term, sustainable results for the business and just as importantly, increased engagement for the people working in this area.