Everyone's got this cloud figured out! Or do they...? Cloud adoption doubts and questions

I think it was a representative group of industries and individuals, with the audience including CIOs, architects, and SMEs from various sectors. 

Why might it interest you? Because it showed that many people have the same problems with cloud adoption. If you think you’re lagging behind or struggling with the cloud, don’t worry – YOU ARE NOT ALONE!

Here are my conclusions after a week of talks and discussion at this conference: 

1. Many of you (or your peers) are actually early on in the cloud adoption cycle! Not a shocker, but a good reminder of it.
2. The key question is often not “How to use it?” but “Where to start?”, with the pressure to “do something” applied by the business.

If you’re struggling with how to begin or where to start with cloud adoption, it looks like you are in the majority. I’m letting you know about it, as it is easy to fall into a trap of confirmation bias, thinking the world is running away from us, and we’re falling behind. 

It appears it is not always the case. It is still early days; some of us took some steps, but many are still figuring it all out. 

Cloud adoption – the most common questions

Here are the two most often returning questions from three days of Q&A sessions for those who are starting out. I distilled them into questions, short comments, and resources (if any). 

We don’t know where to start. What is your advice, how to begin building our cloud-based skills and a team? 

This is a good one. We all have to start somewhere. It was one of the recurring questions across all discussions, so let’s deal with it first. 

My practical advice here is to start small. I know, I’ve said it before. Your task here is not to become a master of cloud technology but to convince people that it is a viable path to move forward. What you are up against is:

• Their experience telling your team that what was used before always worked
• Fear of the unknown. A team will have to admit that it is a new thing for them where they might not be experts 
• The organization, which is designed to work differently (split into silos in most cases)
• Fear of failure, unknown territory, new technology – what can go wrong? In your team’s view – A LOT! 

My advice here is always:

• Start with a specific, short project to be delivered TO PRODUCTION (yes, the caps are intended – it has to be something to prove it can work in production)
• Assemble a team to deliver it. It has to be a cross-functional team – get someone from infrastructure, networking, applications, and security together. It is important to break boundaries here (see the side note below)
• Remove the fear of failure. Explain that it is a learning experience in a specific timeframe
• Set the goal. A team has to deliver this project in a cloud-ready way. This means defined work, iterated with resource automation.

In a short time, deliver a project to production in the cloud, summarize the learnings and make sure to celebrate it. Congrats! You’ve just created the core of your cloud adoption team. The task is to up-skill and scale it into more teams (each member of the original team will now be your advocate). 

Hint: to remove obstacles that might slow them down, consider getting on-board someone with cloud skills and experience, who will be able to give tips or solve issues quickly. 

Need more tips on cloud strategy? Watch the video!

What should be our approach to multi-cloud with hybrid-cloud and on-premises? We have it all already.  

It seems that everywhere I go, the multi-cloud is looking at me! Let’s deal with it.  

Oh wait, I did already – I wrote about multi-cloud some time ago – here is the link:  Do you really need more than one cloud?

I still stand by my opinion. You will most likely not need a multi-cloud environment. Multi-cloud is an advanced topic. Many big organizations don’t know how to handle it well. 

If you are starting out, especially if you have limited resources, my advice still will be – save it for dessert. Work out one cloud well and then look for others. 

But as always, reality bites. Companies acquire multi-cloud for various reasons:

• Inherited from mergers and acquisitions between companies
• Applications created independently by different teams (sales, marketing, finances) with freedom of choice
• Cherry-picking capabilities across the cloud 
• The approach of spreading the risk and leveraging the multi-cloud environment (in larger organizations).

If you are in this position, you will have to handle it. It’s hard to say: “We’re not doing it because I read this blog post from a guy at Predica.” 

My advice here:

• If possible, do not try to handle all of the clouds simultaneously. Make sure you have operations defined for one and then move to another.
• Read the Microsoft Cloud Adoption Framework or similar document from your cloud vendor of choice. Map the capabilities, roles, and areas you need to cover. Not technically, but as an organization. Remember – all clouds are different but they are the same.
• Once you have a map of capabilities, roles, and skills – map it to specifics in each cloud at technology and services levels. Cost management or rights management is needed in every cloud. The tools are different.
• Create your governance rules to know what the goal is, what the risks are, and how you mitigate them, then map them to technical solutions.

Again – if you don’t have to, do not think about starting with a multi-cloud approach. Save it for dessert. 

5 things to remember during the cloud adoption journey

Here are some more frequently discussed topics, in a nutshell:

Form a core cloud team! 

You will have people with different technical skills across the cloud. Still, it would be best if you had someone who understands your business, your organization, and how it maps to technology. Your Tigers, Center of Excellence, or whatever name you choose for it. 

Do not start by choosing the tools.

It is not that important if you use Terraform or other tools initially. Looking at tools first is a distraction. Look at tasks to do first, then select your toolkit once you have some experience with them. Do not let “tools paralysis” overcome your actions. 

It is more about change in the organization than technology.

One of the recurring themes is how to convince people to work in a new way? How to introduce DevOps as a way of delivering the results and communication? It is about people, not technology, and practice more than specific tools.

Proven direction here – remove the obstacles and fear of the unknown. Organize the first team, give them some training, let them work and experiment. Make an obligation to deliver. Your team needs to see the results independently and learn the benefits.

We had successes with a short, 2-day DevOps Kickstarter workshop (try it!), offered in a controlled environment, changing the entire team’s perspective.

Do not forget about invisible parts. The network is still important.

There are things taken for granted, like “network just works.” The world is not always rosy, and you will not start with a pure, serverless cloud solution (if you are, I want to hear from you, leave a comment below).

One of the hardest things might be getting your networking right between on-premises and the cloud. You know why? Because the network team is often the most isolated from other groups. Get them on-board, make them part of your DevOps teams. They will be happy to learn new things as well.

Learn to understand the cost.

OK, I will not beat the dead horse here again. I did it many times in the previous articles. Here’s a great example of how understanding the cost might affect your actual cloud cost on an instance of Azure Reserved instances – Azure VM Reservations. 

Now for some fun facts and a single piece of advice that will save you money! 

I asked 20+ people in a session if they knew what reserved instances are. None of them knew it. If there is one practical thing from this article that will directly save you money – this is the one. Ensure you know what it is before you go to the cloud with your VMs.