While we enjoyed many talks on how cloud computing is enabling business, like everything else, there are always some downsides as well. Going to the internet, you can see people’s observation and opinion on cloud downside are primarily centralized with network dependencies, security, compliance, vendor and technology lock-in etc.

This subject deserves a full article, since it is a complex. Today, I am sharing just a portion of the list that deserves leadership attention.

Latency: Cloud requires inevitable travel of data packet from one data center to a few others, depending on how complicate your transaction is. Yes, there are edge computing, content delivery network, local stack (AWS Outpost etc.), and many other ways to reduce the latency. However, a vanilla point to point REST call between two nodes sitting next to each other on the same rack or a few rows apart in the same house will hardly lose to a round trip of cloud. Therefore, study your use case and design, and try not to assume anything. Latency is usually the #1 downside of cloud computing.

You may disagree.

Multiple points of failure: Cloud requires the entire route to function as designed. Network connectives, internet or private links, cloud border and shared network accounts, additional services, their protecting firewalls and many other services come into play. Cloud is no magic. The process of your bytes still happens in a data center nearby. The likelihood of cloud platform failure is no different than traditional ones. A resilient design and a correct implementation can largely mitigate this, but still, when you introduce cloud, you introduce additional integration points. Cloud computing is not a blank check of better resiliency, but a technology stack makes resiliency more possible and easier to implement.

You may disagree.

Shadow IT: You got to love this one. We finally get business compliant with technology department policies and standard, and now they are opening up new space in cloud. Without a strong governance, guardrails and automated detection and prevention, this could quickly spin out of control. Cloud can make business units less dependent on IT, and you may see those old days boxes on the aisle being multiplied easily.

There are many ways to prevent, but it starts from a good governance model.

Loss of control: This is obvious too, and usually be mentioned as one of the cloud drawbacks. Many cloud enthusiasts embrace heavily on “managed services”. While those services are usually a great gain for an organization since it requires no additional workforce skillset, and also provide fast provisioning and ease to use. You are in no business to control them at the granular level you used to be. It is the typical tradeoff you should be aware of.

Some people will say I’d rather not to control it. This is true only when bad thing didn’t happen.

Everything can be expensive: Traditional computing is price bounded. Once a capacity is paid and provision, you can’t over run it. For example, someone’s code is producing errors rather than results, he/she may suffer a VM crash or a downtime, but not a surprising bill. I have seen a missing policy can cause a penny average cloud service incurs thousands of monthly cost. That is 100K times more expensive. A poorly developed Lambda function can be more expensive than a dozen EC2s combined. Please remember, this rule holds true: Errors are definitely more expensive in the cloud. Therefore, cloud computing requires more rigorous software development discipline and enforcement of best practices. Constantly monitoring, alerting, and action taking can all be effective to mitigate surprises. In addition, data move in the cloud could be cost alarming. The bytes going in is free, but every usage could be pricy. Managed peering services among cloud networks can also put a tax on every data that travels. So, please pull a calculator up before you decide a move of “all in”.

Many fascinating stories on cloud cost surprise. Give me a like if you want to hear more.

SLA Creep: What is this? This is service level agreement creep, leading to cost creep. When people come to the cloud, the features and options are abundant and appealing. Some leadership might be under the pressure to “show improvement”. And one wrong way to do it is to promise or up the SLA unnecessarily. For example, changing a daily batch job to real time update. This is potentially breaking the existing logic, or have downstream adverse impact to other programs and services. And in many case, it is also not needed. In another example, changing the daily download amount from previous setting to unlimited. Yes, cloud will allow you to serve your customer without limit, and you will have to pay. I think this category is a highly overlooked one so I put it up for your awareness.

You may disagree.

As a cloud computing leader, this article is a gentle reminder of a few “Don’t do” things. All the potential downsides can be learned, detected, prevented, and mitigated.

Cloud is a beautiful thing when everyone clouds responsibly.