Cloud Fail: Top 10 reasons we fail in the cloud

I am working on my book called Architecting the Cloud: Design Decisions for Cloud Service Models and I need a break from all the seriousness and rigor that goes into writing a technology book. I thought I would try to write something slightly funny to break up the monotony and to get some notes for my book down so I can prepare my next chapter. My third chapter is called Cloud Computing Worst Practices. My book will discuss this topic in more detail and recommend some best practices. Here is my attempt at humor <ducking>!

#10 – I love my vendor with all my heart

If you select your cloud provider based on how much hardware or software licenses you have bought from your favorite vendor in the past and by the number of cool golf shirts and tasty lunches that they bought you, you are doomed to fail. Most hardware vendors’ cloud strategy is to sell you more hardware and call it a private cloud. In fact, most of the demand for private clouds is based on marketing hype driven by myths of public clouds being insecure. I can argue that with the right architecture, public clouds can be more secure than private clouds.

Another common mistake is choosing a cloud vendor based on your software stack. Choosing Google because you code in Python or choosing Azure because you are a .Net shop is not wise. It may be one of many factors but first start by deciding which cloud service model makes sense to build on. If you are building a B2C site that expects millions of users, PaaS is not your answer. Save the technology stack decisions for last.

#9 Know thy customer

IT teams need to work close with product and sales to understand who the target customers are and what their needs are. Certain industries have more of a stomach for public clouds than others.  Some companies flat our refuse to have data leave their premise. Companies outside of the US often run far away from US based public clouds due to the Patriot Act. Know your business. Know the regulatory constraints. Know the privacy policies. Read the CSA Guide and understand what is really required and expected in the cloud. If you are building solutions for consumption by enterprises, expect to meet with a bunch of arm crossed security and architect types and get drilled with questions about privacy, encryption, uptime, SLAs, separation of duties and more. My experience is that cloud service providers are expected to deliver higher levels of security than non-cloud solutions. I have filled out huge RFPs and when clients discover we are using AWS, I get another huge questionnaire from the security team and a bunch of mean stares. Know they customer!!!

#8 Outsourcing security

Some people think that the cloud takes care of security for them.  Just throw the app up in the cloud and we are done. The reality is the complete opposite. Not only does the cloud provider not secure your apps, but there are more security requirements for you to address now that your apps are running in some virtual datacenter co-mingled with numerous other customers. Whether you are using a PaaS or IaaS solution, the vendors supply security tools, APIs, and best practices but it is up to you to put all of that to use and ensure your apps are secure.

#7 The lights are on but nobody is home

When managed correctly, the cloud can be extremely cost effective. When left unchecked, the cloud can give your CFO a heart attack with no advanced warning. The beauty of the cloud is the pay-as-you-go pricing model. When managed correctly your costs trend up only when your revenue trends up. In some cases your cost per “widget” even goes down as your revenue goes up! However, without a strategy and an architecture that focuses on cost containment and cost optimization, your CFO might get a bill many times higher than expected which means somebody is getting taken back behind the woodshed.  With traditional infrastructure, forecasting monthly IT costs are very easy. Procurement cycles take time and you pay for these assets up front or over scheduled installments. With cloud computing, you pay as you consume services. If you go to work and leave all of your lights on in the house, open all the windows, crank the air conditioner and run your sprinklers all day, you are not going to like your utility bill at the end of the month.  If you don’t have a process and tools for monitoring usage, you can quickly be a victim of “server sprawl” and wind up with a ton of virtual compute resources that have business dependencies preventing you from shutting them down. This is especially true if developers can fire up their own resources and then have critical development and testing needs associated with those resources. Once there is a dependency on a cloud resource, the meter runs until you are able to identify and remove that dependency (I have the scars to prove that).

#6 Riding with no hands and no helmet

Remember when we were kids we would ride our bikes down the road with no hands and no helmet? We felt invincible until we hit some loose gravel and did a face palm on the pavement. Well the cloud equivalent of that is not designing for failure. Nothing is more childish than not planning for an outage or service disruption from your cloud vendor. This is true even with SaaS solutions. If you are dependent on a SaaS solution and that service is down, what process can you put in place until the service is recovered? Do you need to implement a manual process? Do you need to communicate to customers? Do you need an under construction page? If your SaaS provider goes out of business, do you have a plan to get your data? We know IaaS & PaaS solutions have outages. Have your anticipated that and architected your solution to fail over to other zones or providers? Shit happens. Put your hands on the handle bars and wear your helmet.

#5 Stupid is as stupid does

If your on-premise architectures suck, the odds are your cloud architectures will suck more. Don’t use people who can’t code their way out of a paper bag to code stuff in the cloud. Doing cloud computing right requires real software engineering. If your IT shop is not known for building sound solutions that scale and are reliable, hire some experts that can. The meter is running in the cloud. Gone are the days of throwing fat apps into the wild and telling users to upgrade to bigger PCs. It is time for old school engineering like back in the day when there were so few compute resources available, developers had to be cognizant of the system limitations and plan accordingly. Those days are back! The difference is now we have unlimited resources but that leads to unlimited costs. Cost should once again be a major design consideration when designing cloud services.

#4 Your menu is too big

There is now a new breed of superstars that automate and manage our clouds. Some call them DevOps and some call them NoOps. No matter what you call them make sure that you have a good balance of tools vs code. If you are not careful you will wind up with 200,000 lines of Ruby code and 300 recipes.  Any restaurant owner knows that the more items you put on the menu the more it costs to run a business. Having a lot of variety on a menu is one thing but managing 100 recipes in IT is another. The more you write the more you maintain the more you pay. Only build what you must and use cloud management tools as much as you can. There are tons of free tools or free versions of paid tools with limited features for those who can’t justify the cost. But who can really justify hundreds of thousands of lines of DevOps code? Unless you have the scale and demands of a Netflix, think twice about building everything yourself.

#3 The great wildebeest migration

Have you ever watched those shows on Animal Planet where a huge herd of wildebeest have to cross a river loaded with huge crocodiles? That is what runs through my mind every time I hear someone talk about migrating to the cloud. Some will make it but many will perish. If you asked the human species to cross that river, after witnessing a few horrific deaths the humans would devise a solution to get them to the other side safely. Don’t be a wildebeest and make a run for it through the hungry crocs. Devise a plan and an architecture that gets you safely to the other side with no casualties.

#2 What’s in it for me?

Resistance to change is often a leading reason for failures. When driving cloud computing initiatives within an organization you are likely to run into various types of people who are against the cloud,  First there are your server huggers. These are the types see the cloud as a threat to their employment instead of embracing the new high paying DevOps/NoOps movement. You have your manage by magazine types who read the hype and myths online and consider that content gospel. You also have people who just like things the way they are and don’t want their life disrupted. There are a lot of negative forces working against any movement to something new. It is critical to have a communication strategy that shows why the cloud makes sense. Maybe it is speed to market. Maybe it is cost. Maybe it is a good backup solution. Whatever the reason, you must be prepared to communicate why and what it means to each person involved. What’s in it for me (WIIFM) is different for every person. The finance people want cost savings. The business wants speed to market. The CIO wants to reduce expenses. System administrators still want to manage systems. Security folks want to make it safe. You get the point.

#1 A cure for cancer and world hunger all in one

Unrealistic expectations are the top reason for failure in my opinion. Even if you build everything right and execute flawlessly you may never meet the expectations that some have. Many non-technical people in the company may think that the cloud is a silver bullet and is really simple to implement because Harry cranked up a demo website in two days. It works great for five users but don’t release that thing into the wild!

They have heard all of the stories of people whipping out their credit card and solving some advanced analytical problem in one day for just a few bucks. Those are nice stories but building enterprise software in the cloud takes some time if you want to do it right. Cost is another killer. There is a perception that the cloud is very cheap. The cost for a virtual machine charged per hour is incredibly low. But how many of them does it take to build a highly reliable and scalable solution that can withstand an outage caused by your cloud provider? It is critical that you set the right expectations up front. If someone compares a simple n-tier on-premise architecture to a highly distributed, highly redundant cloud architecture, make sure they understand why the cloud solution costs more. Apples are apples, oranges are oranges.

Speaking of fail.  I hope you enjoyed my failed attempt at humor.  Now if you excuse me, I have to get back to my book.