How to avoid shock and horror after your cloud adoption

How to avoid shock and horror after your cloud adoption. Many organisations embark on their cloud adoption journeys because they were told the cloud is where all the competitive businesses are, they were told or thought it was a good idea and they wanted to turn capex into opex.

In other words, they spin up the cloud and then hope for the best. It is not uncommon for the next cloud conversation in the C-suite to be one of shock and horror.

Business decision-makers, those who signed off on the adoption, will often repeat the following things: “We did not know we committed for x amount but consumed it already and are now being billed for the overrun,” or “We did not know that the SLA only gives us 95% up-time, and now we have a critical system that is down,” or “We did not know that we can embark on cost management, we did not know we could optimise the environment, we did not know that this journey was far more than just lifting and shifting our infrastructure and putting it in the cloud”.

Sound familiar? If it does, you are not alone. This is fairly common but it does not need to be like this because there is a better way of doing things, and this is where a highly skilled consultant closes the loop.

Cloud adoption journey 

If we look at a traditional cloud adoption journey, typically there are six pillars, which are governance, network, security and identity, compute and storage, DR and business continuity, and management, maintenance and monitoring (operations).

If we imagine a family car packed and ready for a long journey, we come to the conclusion that it has six wheels. One on every corner to move forward, one in the hand of the driver, and one in the back, called a spare wheel. The problem is that many businesses see the value of the first five and then presume it is safe to drive off without the sixth: management, maintenance and monitoring. This is a big mistake.

Let’s unpack this a little more. Governance is always the first layer and involves discussions around whether the right subscription has been chosen, configured and secured. Once this is complete, the connection takes place, followed by security and identity. Then, typically the build starts. Infrastructure owners and Developers build quickly because it is easy in the cloud, but this is where the pitfall lies because once it is all there, what do you do with it?

Be that as it may, at this stage there are virtual machines or services running and we typically see that people forget about disaster recovery (DR) and backup services. Remember – even though you are in the cloud, it is still dependent on a piece of hardware in a data centre. When something goes down, you can’t quickly run into the basement to plug in a new drive – you rely on the cloud service provider to manage this. It is during this delay, or downtime, or worse – when attacked by cyber criminals – that businesses understand the importance of DR and backup. When this happens, a business decides it never wants to endure that again and only then decides to build DR into the environment.

This is where we get to the sixth wheel, which is seen as “spare”. But considering everything done so far along the journey, ask yourself again: what happens if you continue on this journey without the spare wheel? Something proverbial always hits the fan, and when it does, that spare wheel is the difference between arriving at the destination or sitting on the side of the road helpless.

It is vital that the environment is managed, maintained and monitored.

Management 

Management of the cloud environment entails looking at load balancing, high availability, scalability, DR and recovery, and cost-effectiveness. One must ask: Are we building the right things in the cloud according to our specific needs, or are we just putting a server down because we want to run a piece of software on top of it?

The overwhelming majority of businesses we encounter do not know how to configure a budget in Azure. Instead, the decision-makers will say that they commissioned a build yet do not understand where the additional costs are coming from. Yet, avoiding these nasty surprises is totally avoidable if you budget upfront. You can set up alerts to measure spend versus usage. For example, if I am on day six and have used up 80% of my budget, it is a big red flag telling me to go into the build and find out what is wrong and fix it quickly. On the other hand, if I am on day 28 and have used up 80% of my budget, I am running a well-planned, sized and optimised environment. You avoid the shock and horror by being proactive.

Maintenance 

Perhaps the best way to describe this is through an analogy. There are some components in Azure that you pay for regardless of whether you use them or not. These include things such as setting up a storage account, assigning an IP address, attaching a new disk to a VM, and more. A caveat, thankfully, is that the Azure process has been updated whereby there is now a tick box that provides the option of deleting all associated services when a VM is deleted. Just three months ago this option did not exist.

And so typically, businesses would spin up a server, attach storage to it, attach a public IP access to it, and then decide they don’t need the server. But often they would not clean up the storage account with everything attached to it, and so they would have a number of resources, including things such as backup and recovery, sitting idle and being billed – even if they were not being used!

Proper maintenance is looking at the tenant as a whole and doing an audit of which resources are not being used, and then clearing them. This is an immediate cost-saving.

The other component is looking at resource utilisation. Often we find that businesses utilise a fraction of their machine – in other words, they are paying for a huge machine but using far, far less. We go into the business over a period of 30 days and are able to quickly ascertain this, before right-sizing and building to the actual business need.

Monitoring 

No one is able to look at their Azure portal 24 hours a day, seven days a week. However, just because you are at your child’s sports day on a Saturday morning or sleeping during the night, it does not mean that the environment should be vulnerable. There absolutely must be a monitoring framework in place with notifications and then the ability to trigger the correct actions such as disaster recovery failover.

The truth is that while we always intend for the best, we must plan for the worst because something can, and will, go wrong at some stage.

Partnering to maximise cloud value and minimise shock and horror 

Businesses would do very well to engage with an experienced partner, with the right skills, as early as possible in their cloud journey. However, that being said, it is better late than never. A properly qualified partner will take a magnifying glass to cost, availability and utilisation, as well as modernisation in its entirety, and then advise and guide a business on the best solution for their needs within their budget.

Besides cost management and optimisation, the exercise gives businesses peace of mind that someone is keeping an eye on their environment without them having to watch the dashboard 24/7. This allows them to get on with the business of their business, while the experts extract the most value from their cloud investment.

This article “How to avoid shock and horror after your cloud adoption ” was originally published on TechSmart on the 29th September 2022.

Contact us 

Leave a Reply

Your email address will not be published.