It’s no secret that AWS is big and getting bigger. If you take a look at its quarterly results over the past three years, they show enormous growth. AWS is a $5 billion per quarter business, growing at 40+%. Its CFO says AWS is a $20 billion per year business. Let that sink in for a minute. $20 billion. 40+%. There has never been an enterprise technology company with these kind of numbers. It’s clear that AWS is a huge factor in the tech industry.
A large part of AWS adoption and use is within enterprise IT organizations. Notwithstanding the high profile of companies like Airbnb or Netflix, the vast preponderance of money spent on information technology is spent within enterprise IT. And increasingly, those organizations are embracing AWS.
However, many of them are doing it wrong. During my decade-plus of cloud computing, I’ve worked with many enterprises as they make the transition to AWS. A few have taken to AWS fantastically; some eventually achieve their hoped-for results; a huge number flail and never accomplish their objectives.
So what separates the champions from the never-happened? In my experience, failed AWS initiatives show these five mistakes:
Mistake #1: Treat AWS as an outsourced data center
AWS operates data centers, yes. It offers computing services, of course. But the services it offers differ from traditional data center capabilities like the ways a cheetah differs from a house cat.
The easy way to understand how AWS is different than a traditional data center is to look at the NIST cloud computing definition. It identifies five characteristics of cloud computing:
- On-demand self service
- Broad network access (i.e., API control of services)
- Shared resource pool
- Resource elasticity
- Cost based on fine-grained resource consumption
None of those sound like how a traditional data center operates but many IT organizations insist on treating AWS like it is one. They front end AWS with a trouble ticket request mechanism. Everything flows through an operations group. Users are limited in how much computing they can request. Any change to the computing environment is controlled by manual processes. And users have no visibility or control of cost, since they just get a quarterly lump sum cost assignment.
One definition of insanity is repeatedly doing the same old thing and expecting different results. Unfortunately, many users do just that and wonder why their AWS results are unsatisfactory. Thinking of AWS a just a data center at the end of a wire prevents IT organizations from understanding the potential of cloud computing.
Mistake #2: Maintain Established Architecture Patterns
Cloud computing can enable scalable applications that are resilient in the face of resource failure. Achieving this requires a change from traditional application design patterns that assume static infrastructure that never fails. Until it does.
Building applications with single points of failure (SPOF) just means one thing: when the underlying resources fail (and they will), the application will go down and remain down until an emergency swap is executed via an operations fire drill.
AWS deals with that reality in a vastly different way. It tells you resources fail and you should plan for it. Its “Well-Architected Framework” white paper promotes the use of redundant resources. It also recommends that applications incorporate autoscaling to deal with erratic traffic loads.
Too many IT organizations fail to follow this advice, and transfer their existing application design patterns wholesale into AWS. And then when infrastructure resources fail, the same fire drill occurs. Until IT learns that the benefit of AWS is that it allows application patterns that were unaffordable in on-prem environments, life with AWS will look a lot like life with a traditional data center: fragile applications with poor uptime statistics.
Mistake #3: Don’t Change the Development Process
I’ve seen a ton of enterprise IT organizations enthusiastically adopt AWS. They’re excited by the prospect of gaining access to computing resources in minutes instead of months. But then they get frustrated when applications don’t get rolled out any faster and can’t be updated any quicker.
That’s because they continue running their application development process unchanged. Warren Buffett has a funny saying about risky investments: you never know who’s swimming naked until the tide goes out. In other words, when the investment environment changes, then you learn who hasn’t been prudent in their practices.
The same thing goes for AWS adoption. Because it used to take forever to get infrastructure resources, inefficient application practices weren’t exposed. It took a few days to get a build done? So what? A couple of weeks to fix all the integration issues? No big deal. And then a month or so to get the updates through the change control board and installed in the production system? Yeah, it could be faster, but really, that’s not our biggest problem. Until AWS comes on the scene. Then all those delays get exposed and look terrible.
I call AWS a forcing function for DevOps. Once users get used to the cadence of fast resource availability, they want everything to move at that speed. Keeping the existing development process after you move to AWS causes endless headaches and dissatisfaction. A far better approach is to treat AWS adoption as an opportunity to reevaluate every part of the IT value chain and modify it to move at cloud speed.
Mistake #4: Don’t Address the Legacy Application Portfolio Monster
These days, many IT organizations have a cloud-first policy. They assume — or even mandate — new applications will be deployed in AWS.
However, that doesn’t address the legacy application portfolio monster. It’s a simple fact that 80% of most IT budgets is spent maintaining existing applications. You know, those applications with poor resiliency, that take forever to update, and can’t respond to changing load patterns? Yeah, those.
Going forward, companies won’t be able to afford a two-tier system, with a sliver of the overall application portfolio residing in AWS and the majority of it suffering under the old conditions.
Difficult as it might seem, all of those old applications are going to need to be migrated to AWS and rewritten at some point to take advantage of AWS’s cloud capabilities. Failing to do so is like putting a weekend jogger into Usain Bolt’s sneakers: the equipment is there but nothing else is ready to take advantage of it.
Mistake #5: Don’t Equip Your People with Cloud Skills
Mistakes #1 through #4 reflect failures to really embrace AWS and cloud computing. They’re attempts to treat AWS just like a traditional data center and use the same practices that always worked in legacy environments. I hope you’ve been convinced that each of these mistakes, while understandable, leave IT organizations vastly underperforming.
Mistake #5 is different. It deals with people. The people who will need to do the work to fix the first four mistakes. It isn’t fair to expect them to get the job done with the skills they’ve used in your traditional IT environment. And it’s not fair to expect them to somehow pick up necessary skills out of thin air. They need to be trained in the AWS and cloud computing so that they can help take the IT organization to the next level through the use of AWS and cloud computing.
Putting staff through a common training program ensures everyone is on the same page when designing applications, choosing AWS services, and operating production environments. Recognize how broadly you’ll need to educate throughout the entire organization, based on the need to address both new and legacy applications.
There’s no substitute for knowledge, so put AWS education in your cloud adoption roadmap. The only way to solve Mistakes #1 through #4 is to address old problems with new solutions. Give your people the right tools and they’ll do the job.
I can help with Mistake #5. You can get a 90% discount on my Udemy course “The Ultimate AWS Certified Solutions Architect Associate.” Use this code to get started on your AWS journey. Once you’re trained, be sure to address Mistakes #1 through #4, and you’ll be well on your way to AWS success.