Quickly Receive Cloud & Colocation Quotes

Blog

Cloud Computing and Datacenter News

For Now, The Cloud Has Failed Us

Cloud Failure.jpg

[Approximate Reading Time: 7 minutes]

Introduction

Mainstream tech media misses the mark when it comes to cloud computing. Many articles describe positive transformation of their IT due to cloud migrations. These stories have encouraged others to migrate to the cloud when most of them should not be moving at all. Due to scaling incompatibilities, these firms have seen higher costs and lower performance. While there are successes, news organizations should be balancing the discussion with articles where cloud doesn't work out. I hope this article will do a good job of explaining why many firms cannot make the move to cloud at this point. I consult on cloud and colocation projects, so I don't gain by speaking ill of the cloud. It's my hope that this article will be an impartial account of real world projects I've worked on.

With complicated issues in tech news, writers want to simplify matters of cloud for easy consumption. These articles cater to what's popular and don't outline who is able to gain from the cloud. The resulting articles aren't very helpful. Here are some article titles I've seen:

  • Public vs Private Cloud
  • Top 7 tips on how to migrate into the cloud
  • Should you use AWS, Google or Azure for your Cloud services?
  • Top Storage Providers You Should Consider
  • Company X migrates to the cloud, reduces CapEx.

For many legacy applications, the "public vs private cloud" discussion is premature. If your application doesn't fit, there's no discussion of public vs private cloud to be had. It should be a discussion of how these systems scale and will they fit into typical cloud models at all. We've seen a 2-3X increase in costs when legacy systems are moved into the cloud without re-coding.

So born on cloud applications thrive on the cloud because there is no need to adapt the code at all. They scale horizontally and are container based. Startups have applications that fit into the cloud because they use modern coding. They scale horizontally and have the ability to give back unused computing cycles. This article doesn't refer to those "born on cloud" applications. This article addresses legacy applications that still run our larger enterprises.

Who Are You Talking About in This Article Then?

Here are the firms that this article refers to:

  • Enterprises with ERP, Messaging, CRM and 3-tier web applications.

  • Software as a Service firms. Firms who provide their application as a subscription to other firms.

Neither of these examples are able to realize the economies of scale of the cloud. I hope this article guides those wondering "is there something out there better for me?".

So Why Are You Down on Cloud?

The cloud is a great way to deploy complicated systems at a fraction of their previous cost if your app fits. But I have to share the complaints I receive when speaking to folks researching the cloud. Here are the recurring subjects that come up:

  • (After getting quotes) Why is this going to cost more in the Cloud?

  • That virtual is almost more expensive than a physical machine, why is that?

Once migrated (without guidance), I hear these complaints:

  • We are spending more in the cloud than we did with our old environment

  • Our systems run slower in the cloud than they did with old physical servers

  • We started out cheaper but within a few months, it was more expensive when we boosted resources due to poor performance.

  • The tools we have access to are excellent but it comes at a high cost.

So how is it these firms ended up in this situation?

Let's Blame The Media and Marketers!

I don't blame cloud providers for using words like auto-scaling, elastic, and dynamic. For apps using modern architectures, this is a possibility. Most enterprises do not scale in a manner that fits the cloud well. Here's what these marketers aren't talking about when it comes to your legacy application:

  • Auto-scaling works but usually only to increase resources (not decrease).

  • A Microsoft SQL 2016 Clustered database has large needs. You cannot "turn down" RAM from 128GB to 2GB because fewer people are using the application.

  • A heavy cloud virtual instance can cost more than a physical server with similar specs.

I expect these service providers to be upfront about these limitations. If not the service providers then the journalists who cover the cloud should be. I have read a couple of stories in the mainstream press documenting client who didn’t realize the panacea of Cloud with lower costs and better performance who reverted back to physical systems in colocation space which offered them better visibility and control of their costs. 

Let's Blame Online Forums and Tech Communities!

Many get their information from posts in online forums. In reviewing forums online, I was able to understand some of the problem. Here are 2 groups of people speaking about the cloud from different perspectives:

  • technical people who implement

  • business people / excited by the prospects of cloud

The Picture Painted by Technical People

Technical folks share their experiences to help others trying to do similar tasks. When they speak about cloud they outline the tool set and the automation which they really love. Networking, IP allocation, load balancing and cloning server instances are easier. Their posts are academic and written in a way that documents their experiences. They tend to solve technical issues and aren't speaking of fiscal feasibility.

The Picture Painted by Business People

Non-technical people love the promise of the cloud but don't deploy applications themselves. Excited about this booming industry, they advocate for modernization and streamlining. "You are old school if you aren't in the cloud by now!" is an actual quote from a Linkedin forum post. Unfortunately, they aren't able to see the underlying issues I am speaking of in this article. Missing from their discussions are actual implementation experiences.

The Way We Thought the Cloud Should Work

Let's take a utility like electricity. You consume electricity and it's measured in kilowatt hours. Thanks to Save on Energy for the example I'll use below:

Let's say your refrigerator uses 300 watts to run. Let's compute kWh in a months time for this refrigerator:

  • 300 watts X 24 hours = 7,200 watt-hours per day

  • 7,200 watt-hours per day / 1000 = 7.2 kWh per day

  • 7.2 kWh per day X 30 days = 216 kWh per month

  • 216 kWh per month x $0.10 per kWh = $21.60 per month

This refrigerator will always use 300 watts and always cost about $21.60 per month. The refrigerator cannot detect that it's empty and reduce cooling to accommodate. That's a bit like how legacy applications work. There is a base resource level needed to run something like an MS-SQL database even if it has 1 user connected.

A light fixture is a better representation of cloud consumption. Need the light? Turn it on and the billing starts. The moment you turn it off, billing stops.

So we envision cloud computing as a resource like electricity. The trick is that Cloud Computing requires 4 resources:

  • Processing in GHz

  • Memory (RAM)

  • Storage

  • Bandwidth

Cloud providers bill a usage rate per hour for each of these resources for a total of 720 hours per month. Most of our enterprise applications need a minimum configuration of RAM and CPU at all times (think refrigerator). Dialing back a Microsoft SQL database server to 1 vCPU and 1GB of RAM could crash that server. These servers cannot give back resources, so they need consistent levels of RAM and CPU.

So Think of Cloud this Way:

Your Refrigerator is like a legacy app. It will pull 300 watts almost all the time even you have no food in it. The only way to save money on electricity with a fridge would be to completely unplug it. Unplugging a database server from the environment means the application is unusable.

Your lights are similar to modern, horizontally scaling applications. Turn them on and off, when off you pay nothing.

Netflix Runs in the Cloud So it's Good Enough For Us!

Using Netflix as an example is interesting. Netflix has built an ecosystem around Amazon Web Services and they are thriving. They've also made a decision to stay out of the business of infrastructure even at a premium cost. Had they aimed for the best cost per compute unit they would have built their own datacenters. But, they weren't aiming for the lowest cost, they wanted amazing software, delivery, and scaling. Avoiding infrastructure management allowed Netflix to maintain its lead over competitors many argue.

So What Does An Enterprise Do?

The key will be to understand how your application scales and how pricing is computed. Here are important things to consider before taking the plunge into cloud computing:

Can I load balance smaller servers rather than having larger servers?

[why - you will find that many 1CPU+1GB virtual instances will be cheaper than 4CPU+4GB server instances]

Can a virtual instance provide the IOPS needed for the database layer of our application?

[why - having virtual database instances that have 8 vCPU and 64GB of RAM don't perform as well as a physical server with similar specs.]

It's important to understand how the provider scales and prices computing. It would be best to use their calculator to develop pricing models for your app as it exists now and later.

Depending on the way your application scales it may work in the popular public clouds. Having high CPU or RAM needs puts your environment into a category that may not fit well in the cloud. For these cases, traditional service providers offering a mix of physical and virtual instances are ideal.

Should you Modernize Your Application?

It's hard to say. If your current systems are solid and perform well, the justification to recode is hard to make. While many would love to modernize their current code it's not practical for most. Millions in investments have gone into the development and integration of existing applications for many enterprises.

New application projects can be build using modern methods and integrated. A slow transformation to modern code is the approach rather than a complete overhaul.

Self Assess for Cloud Readiness

You can self-assess your environment for cloud readiness. Here are some questions to ask:

  • Can your database cluster with many instances that use light servers and sharding?

  • Can you use a database as a service offering online? (Here are some of the more notable DBaaS')

  • Can you have your application scale back when utilization is low? (On its own).

  • Can you introduce containers, have orchestration or serverless technology?

  • Can use servers that need less than 8GB of RAM?

  • Can you split up tasks to servers that how low CPU and RAM needs but have those tasks load balanced over an array of small instances?

You can ease your way into the cloud if you can perform some of these cloud readiness tasks. If this is difficult it will be time to find a specialized cloud that can mix physical and virtual servers. At this time, many of the popular public clouds cannot give you actual physical devices. They can give an equivalent in vCPU and RAM but this doesn't guarantee IOP performance.

We hope that we've given you enough information to continue this journey. You understand your application best.