Beware the temptation of cloud pick & mix!

Walking past a traditional sweet shop in Las Vegas during AWS Re: Invent in November made me reflect on how many organisations still feel the urge to fill their stomachs with the digital equivalent of pick & mix during cloud adoption.

Faced with a tempting array of services from cloud providers, it is simply too easy to binge and add them all to a design proposal just because they are available. It’s like filling one of those cinema pick and mix bags to the brim even though you won’t manage to eat all the sweets – and ignoring the damage done to your bank balance and your teeth.

The start of a new year, when many of us are trying to adopt a healthier approach to lifestyle and diet, seems a fitting time to propose a more restrained approach to cloud adoption too. One that doesn’t splurge money on unnecessary cloud services and that has your organisation limbering up for a cloud transformation journey in peak physical health.

Here are my tips for resisting the lure of the sweet shop in the clouds and preparing the ground for a smooth cloud adoption programme:

• Start by creating a technology reference architecture that will keep everyone on task. This is a relatively straightforward activity. Simply list all of your cloud provider’s available services and decide which ones are approved for usage, which ones are contained, and which ones you will leave for future discussions.
• Plan ahead by having a full and frank discussion with everyone involved to agree on who will do what and secure buy-in. All teams need to adapt for the cloud, and spending time on this (as described in the AWS Cloud Adoption Framework, People Perspective) is essential to a smooth transition.
• Nominate a subject matter expert as the lead/go-to person for each service area. As the list of cloud services continues to grow, it’s becoming harder for one person to be expected to get their arms around every single service. For example, in the area of machine learning, one team member may know enough from a high level architecture perspective, but as more services are introduced it would likely require a data scientist with specialist knowledge to help determine which services are right for the organisation.
• Don’t be tempted to get rid of your traditional architecture teams too quickly. Far too frequently organisations let experienced people go, only to realise too late that their expertise and knowledge would have been invaluable during the cloud adoption journey.
• Decide on your starting point for each service and contain the ones you don’t want, or don’t need to touch immediately. It helps to share details of why particular services are contained or approved to ensure everyone is on the same page.
• Detail the process for changing any of those initial decisions for clarity and consistency – for example, the required approvals process, who needs to be updated on agreed changes, and how to onboard and test new services.
• Get buy-in on your initial position from stakeholders, make any required tweaks, and then communicate extensively across your organisation. It helps to include details of how future updates and changes will be managed too, so there is no confusion.
• Within your agreed reference architecture it pays to include details on specific governance designs and standards or guide rails. For example, if you contain the automated code deployment tool AWS CodeDeploy, then refer to what the standard tooling actually is and reference the internal owner in case anyone has questions.
• Review your position periodically. When adding new cloud services, be sure to communicate widely the initial status as well as subsequent updates.

Adding multi-cloud to the (pick ‘n’) mix

While there are definitely well-publicised merits to a multi-cloud approach, go in with your eyes wide open. If your organisation is considering a multi-cloud strategy, create a reference architecture for each cloud platform. And be very clear up front on how you plan to ensure workload portability between cloud platforms as this can be complicated.

Splitting your focus, efforts and money between multiple cloud providers should not be underestimated: “Just in case we ever need to,” is not a valid reason! It’s also advisable to develop an exit plan for each cloud provider at the reference architecture stage.

We recommend identifing the correct tooling for each cloud provider’s APIs so that you do not inadvertently end up with the lowest common denominator services (typically IaaS).

Armed with a comprehensive technology reference architecture document that focuses everyone’s minds and is communicated and updated regularly, your organisation can effect a smooth cloud migration. You can be smug knowing you have avoided that bloated feeling that comes from biting off more cloud services than you can chew.