There is an old saying, “the definition of insanity is to repeat the same thing over and over and expect a different result.” The way many enterprises are approaching the cloud, insanity would be a great way of classifying it. When we look across most enterprises, we see a collection of technologies from every era of computing. We have just about every vendor solution imaginable—often multiple versions of products from the same vendor—and a hodgepodge of architectures that makes spaghetti look organized.
Enter the Cloud
Now is our chance to fix some of our sins from the past, right? Now we will take a pragmatic approach and analyze our portfolio of applications. We will determine which applications and workloads make sense to run in the cloud. We will determine which cloud service model (IaaS, PaaS, SaaS) makes sense for each workload. We will spend time understanding how to secure applications that run outside of our firewalls. We will analyze our organization structure and the strengths and weaknesses of our culture and our processes. We will transform our culture to a DevOps mindset and break down the silos. We will focus on automation, metrics, and the customer experience.
Right!
Same Old, Same Old
In reality, many enterprise cloud initiatives fail or do not reach their full potential because of one or more of the following issues:
- Won’t invest enough time and/or money upfront
- Were never really good at architecture
- Not enough buy-in from the top
- No clear strategy, chaos reins
- Apply data center mindset to the cloud
- Forklift mindset prevents taking advantage of cloud capabilities.
Time and Money
The Maytag repairman had it right: “You can pay me now, or pay me later.” Too often the cloud initiative is constrained by fixed amounts of time and money. It is a catch-22. Nobody wants a twelve to eighteen-month project during which IT folks go dark and hopefully come out later with some real results. That’s too long and too risky. On the other hand, there are a ton of things that must be considered when building applications in the cloud. Here is a short list:
- Security
- Compliance
- Operations
- SLAs
- Logging
- Monitoring
- Training
- Deployments
- Configuration management
- Patch management
- Cost optimization
- Service catalog
- etc.
There is a lot to plan out, but too often, enterprises allow only enough time and budget for four to five weeks of planning before they want to see applications being built or moved to the cloud. What happens all too often is that teams dive into the cloud undereducated and underprepared. They create or migrate applications that have security and performance issues; do not have the required amount of visibility to manage their applications, as they have in the past; and often do not take advantage of things like elasticity, cost optimization, and the like.
Architecture
If a company is not very good at architecting solutions on-premises, why would it expect to magically become good at it in the cloud? To quote Forrest Gump, “Stupid is what stupid does.” Many companies have built amazing solutions in the cloud, but this didn’t happen by accident. Don’t underestimate the value of architecture when heading to the cloud.
Lack of Buy-in
By now you are probably saying to yourself, “These reasons apply to the failure of any technology initiative.” Exactly my point. Lack of buy-in is a killer. This occurs at various levels. If there is no buy-in at the top, then it is hard to get the resources (time, money, people) to get the job done. If there is no buy-in in the trenches, you wind up with a lot of religious wars about tools, vendors, and best practices, and teams can become unproductive. There often needs to be some level of evangelizing. People need to understand the vision and what is in it for them. Why must they change, and how will it make things better? This step must be addressed, or the infighting will eat you alive.
No Clear Strategy
This is probably the most common issue of them all. Often, cloud initiatives start as grassroots movements. It isn’t until the CIO finds out that he or she already has thirty-five applications running on fifteen different cloud services that it becomes time to put a cloud strategy in place. I can’t tell you how many organizations I have come across with applications that were written by employees no longer working with the company and are running on cloud services with credit-card based payments initiated by such employees. Some enterprises don’t even know how many AWS accounts they have, because so many different people created accounts and built applications that business users now have a dependency on.
Data Center Mindset
Even if an enterprise does all the right things, sometimes it just can’t shift its mindset from data center thinking to cloud thinking. I have seen architectures in the cloud where, instead of building solutions that autoscale, a legacy capacity planning approach is taken. The enterprise reserves two to three times its needed capacity and has the virtual machines powered down and ready to be fired up when needed. In the cloud, you don’t need to plan that way. Instead, you architect the system to provision only what is needed currently, automatically provision more resources when traffic goes up, and de-provision resources when traffic goes down. This way, you only pay for and manage what you need. In the other model, you must manage far more resources. Why patch a bunch of servers that are sitting idle most of the time? Why not just create new, up-to-date images at the moment they are needed? Think cloud, not data center.
Forklift Mindset
Another issue I see in many enterprises is a cloud strategy that is simply: “Move everything to the cloud.” That’s nice, but not all applications make sense to run in a cloud. For the applications for which it does make sense, it often takes a lot of refactoring to make them run appropriately in the cloud. Sometimes an application that gets the “lift and shift” treatment runs worse in the cloud than it did in the data center. Each application should be analyzed first to see what changes it requires instead of simply being dropped in the cloud.
Summary
This is Groundhog Day all over again. Every few years, a new technology, methodology, or process rises to the forefront. Companies are quick to embrace these new breakthroughs, but too often we repeat the same mistakes that we did when we jumped on the last bandwagon. Then the pundits jump in and slam the shiny new object. But let’s not blame the technology. This is a people problem. When will we learn? When will the insanity stop? Let’s take some time up front. Let’s make the appropriate investments. Let’s devote enough time at the start to understand the technology, to prepare and transform our organizations, and to analyze our portfolios so that we can maximize our spend. Otherwise, that mess that we see within our data center will be nothing compared to the mess we will create in the cloud. Let’s stop the insanity.