Introduction – Disadvantages of Cloud Computing
Estimated reading time: 6 minutes
Disadvantages of Cloud Computing, Episode 2
The remainder of this post is the transcript to the video above
I think the biggest issue in our videos, is coming in from the upbeat music in our intro to someone like me at a much lower energy level talking about cloud. It reminds me of that famous Casey Kasem clip where he was upset at his producers for doing the same thing to him. (visual+audio clip)
Before we get into the disadvantages of cloud, let’s ask an important question– What did the cloud do for us? To answer, Cloud gave us nothing more than the ability to purchase compute in smaller increments than was possible before. Still speaking super high level here but the cloud is like It’s like connecting your home into municipal water. Pay by the gallon, works great for a household but you may get clobbered if you try to water an entire farm using municipal water. If you own a farm, you may need to dig your own well and maintain it yourself. So if you currently use 50 racks of hardware to run your IT, you don’t really need to buy in small increments unless this environment can scale down to almost nothing during off peak hours. Imagine taking your legacy database that requires 1TB RAM and running at 1 GB of RAM. That would probably would lead to bad things happening
While this video covers the disadvantages of cloud computing, don’t despair because we’ll have the advantages of cloud computing video coming soon.
So let’s get started with
Disadvantage #1 – Vendor Lock-in
If you are managing your public cloud environment using the native console of that public cloud, there’s quite a bit of vendor lock-in if you ask me. Take for instance Azure, the steps required to move virtual instances out of Azure are many. You cannot just export your virtual instances even if you move it to a HyperV environment. While we are still talking about portability and vendor lock-in. Take for instance AWS, – you can export your virtual instances but there are many exceptions that will stop you. This list is long so I’ll post it to the screen and also thanks to techgenix for their write-up of the exceptions that are on the list.
At this time, there’s probably some of you throwing things at the screen saying that no one manages these instances using the AWS or Azure console because you’ve pulled management of the environment into an enterprise orchestration app that gives you a single pane of glass type of management. While the single pane of glass management app makes this way better, it’s usually the largest of enterprises using these tools. Many of our mid market clients are still using the actual console. Also, I didn’t mean to pick on just AWS and Azure, just some relatable examples there. But enough about portability and vendor lock-in for now as we move on to disadvantage #2 – instance sprawl. It’s easy to scale up instances in most cloud environments but there’s usually little that pulls those instances back when your work load decreases. Some clouds just don’t go back down, others can be brought back down but to automate this is tricky. We hear the word elastic, we think of snapping back like a waist band, but it’s more like a racket, it only rachets outwards and is locked in a single direction. If we remember the troubles of the world before cloud, we complained about under utilization and building to peak because we feared getting clobbered during heavy times of the year such as the holiday season.
Legacy Scaling issues. A traditional 3 tier architecture is usually more expensive to run in the cloud. This is a topic that needs its own video so I won’t go into details . But quickly, if you can’t scale your database for performance (NOT failover) you are relegated to massive database instances that require TB’s of RAM to run. To get your database into public with the required IOPS – you may need to order a physical server in public cloud so now you’re basically back to private or hybrid cloud with the costs that come along with that. Also, physical servers aren’t elastic.
I think when we initially were exposed to the cloud, we expected a lot of native advantages that would just come with it which gave us a false sense of security. So I have 3 of these false sense of securities but there are probably more. Since I am numbering these disadvantages, I’ll use letters for this sub category: I’ll start with 4a . The cloud isn’t inherently more or less secure but sometimes we feel there’s included additional security layered in there but there’s not. 4b. There’s no inherent disaster recovery by moving to the cloud. While virtualizing instances seemingly makes them more portable, virtualization isn’t something that is exclusive to the cloud and again, there’s still no DR built in. 4c. While perhaps enabling a better DevOps strategy because of market place integrations, the cloud doesn’t come with it’s own DevOps built in unless you built it yourself. Let’s move onto
which deals with Billing formats. These bills from cloud providers appear to be setup for maximum transparency, letting you know of every second of compute you consume over a variety of products, but I find they aren’t human readable and have to be analyzed using software after putting to gather a solid tagging strategy if your cloud provider supports tagging.
With public cloud, we are still in somewhat unchartered territory. Outside of modern coded applications – there’s no super clear , applies to everyone, best practice for public cloud just yet. In the enterprise, we got to a point where we had a very good vision of what best practice looked like between blade servers, good hypervisors, and super fast storage but with the cloud there are so many ways to deploy.
This video, isn’t to disparage public cloud but we needed to outline that public cloud is not a panacea, and that enterprises with non born on cloud applications need to take particular care before moving this major move. Also, stay turned as we are working on a really good video about the advantages of cloud computing that should be out soon. Until next time, thank you for joining me once again.