Trust… OK we’ve all had problems moving workloads into the cloud or we’ve heard of companies that have. They’ve migrated to the cloud and it performed terribly. Maybe suffered unexplained downtime leaving users with a bad taste in their mouth about cloud.
Can you trust the cloud not to burn you and your workloads?
Why should you trust your provider? Why shouldn’t you trust them? Let’s take a look…
In my role at Zettagrid I’ve spoken to a lot of businesses over the past 7 years about getting workloads into the cloud. I’ve seen and experienced a considerable number of mistakes. I want IT to make informed decisions about moving to the cloud and whether it’s the right time or the right approach for their business.
“Love all, trust a few, do wrong to none.” William Shakespeare
Its all about TRUST
These are the common problems I’m seeing out there in the market;
- The wrong use case/workload was chosen
- Performance wasn’t taken into consideration
- It cost way too much
- The application was sized wrong
- It is just too far away to trust
- Backups and DR weren’t thought of
- Not as resilient as your current environment
- Loss of actual functionality
Let’s dive deeper into how we build trust in the cloud.
1) The wrong use case/workload was chosen
This is a big one when talking to customers about when things went wrong. In the early days, the customers I was talking to were the “early adopters”. They made the leap and moved production into the cloud or a major application of theirs.
Whilst this could’ve had success (and at times it did), too often the customer I spoke with had regret. The application they chose was just too visible to the users in the business. Any outage or incident was just another nail in the coffin for cloud within the business.
Choose a workload that isn’t crucial to the business in the preliminary stages. Consequently the teething problems are then experienced on something that isn’t mission critical.
Most noteworthy, make the mistakes on systems that won’t have a CxO breathing down your neck.
2) Performance wasn’t taken into consideration
When making the selection of whether to go AWS, Azure or Zettagrid, the vendor often leads with a competitive quote. Often the way to do this was to get the customer onto a resource constrained environment. This is to look as economical to the customer as possible.
This reduction in quality often isnt made clear to the customer initially. When the systems in the cloud were put to the test it often became very clear! You were running on cheap/slow disk so the performance wasn’t there and need to open your wallet again.
I came across this a lot unfortunately. Customers thought the brand name of the vendor was enough to ensure the highest performance and it simply isn’t the case.
Choose the best vendor for YOU! Do this by making sure to really consider aspects such as what tier of storage and compute you have.
Get the vendor to sanity check that the application will work as expected on the infrastructure it will be running on. Find out whether they would recommend making any architectural or design changes before going live.
3) It cost way too much
Often when talking about cloud options with customers or partners I’m met with a phrase like “We got an enormous bill and no idea why and don’t want to be held to ransom”.
The cloud often seems to be a “plus plus” world. You start off with a base service that you assume is a complete package only to find out that “oh if you want feature X then you must pay extra”. This left a sour taste and often meant the company left the cloud as they felt tricked or cheated.
When choosing your cloud provider make sure to really get into the details. Consequently, find a provider that can give you a fixed monthly bill so there isn’t any shock month to month.
Get every service or feature you need priced up so you aren’t left with an ever-increasing cloud spend.
4) The application was sized wrong
This happens on two fronts from what I’ve been seeing.
- My VM has 8GB of RAM in prod so it needs 8GB of RAM in the cloud.
- Just put the VMs in the cloud with little thought to what resources they need.
I have often found that when talking to IT Admins about why a VM has 8GB of RAM it’s often the case that they had lots of RAM in prod so why not… This approach is fine if you have resources to spare on premises. In the “pay as you go” cloud world this is could be a costly venture if left unchecked.
The second case meant that often workloads were placed up onto basic resource configurations. Due largely because the IT Admins had little visibility into what resources their current environment required. As a result his meant that some VMs performed and some not so well. It was often left to chance.
Setup a monitoring tool that can determine what resources your workloads require. Size them up or down appropriately such that they have what they need but no more.
Some VMs will be sized down dramatically! Others will require faster storage or more RAM/CPU to prevent bottlenecks that users will impact user performance.
In part 2 tomorrow we will go through the remaining items and recommendations on how to ensure they won’t bite you and your business.