As Andy Jassy takes over the CEO role at Amazon, the question is asked, “Does it matter who takes over at AWS, the position Jassy is vacating?” The idea is that AWS is such a dominant force in public cloud, an untrained monkey could sit at the helm and AWS would continue printing billions of dollars. So who cares who replaces Jassy? Whoever the new human is, they can’t get it wrong.
That might be exactly right, but for the thought exercise, I decided to go a different direction. For purposes of this opinion article, I choose to entertain the idea that Jassy’s replacement does matter, and matters a lot.
Growing A Gargantuan Gorilla
We can all agree that AWS is the 800 pound gorilla of public cloud. However, I believe AWS will see increasing pressure from all quarters. By way of comparison, let’s consider Cisco Systems of the last ten years.
Cisco has dominated the networking space in a variety of categories for a very long time. The last decade has seen them as the target all of their competitors aim at. In that context, did it matter who replaced John Chambers when he moved on? You bet. Chuck Robbins had (and still has) the undesirable job of unifying competing business units, unifying a diverse set of network operating systems, and developing new automation tech that makes them money instead of eliminating their differentiators. And that’s just in the core networking business.
Oh, and while Cisco is making all of those changes to the underlying product set and culture, they need to continue shifting their revenue strategy to recurring subscription cash, retain customers who are finding an ever-increasing number of viable alternatives, and still find ways to innovate so that those customers stay engaged.
Chuck Robbins knows what he’s doing. By most accounts, he was a solid choice to replace John Chambers. Yet, even in the glow of all that competence, the changes at Cisco are taking time.
I see parallels between AWS and Cisco. Jassy is going out on a high note. “New Jassy” has to cope with maintaining revenue growth, retaining customers, and acquiring new customers all while developing new products that will actually be used and not just an obscure footnote at the next re:Invent.
Where AWS Is At Right Now
Let’s take that last point head on. One challenge AWS faces is complexity in the product set. There are so many products, most of which aren’t useful to most public cloud consumers. That’s okay, don’t get me wrong. Not everyone needs everything sold at the local Wal-Mart, either. But for technologists trying to ramp up on AWS’s offering, the sheer magnitude of services is overwhelming. If we look just at compute, networking, and storage, there are 32 AWS service offerings to consider. That’s just 3 major categories. There are 23 other major categories containing other AWS service offerings. Oh my. Simply understanding the AWS world is a complex task.
Anecdotally, EC2 & S3 are the most used AWS services. I can’t find a reference URL to support this, but I have heard this from any number of folks–and it rings true. These services are relatively simple to comprehend as they are analogous to enterprise IT. “I want to run a workload.” Okay. Create an EC2 instance. “I need object storage.” Okay. S3 is an obvious choice. EC2 and S3 feel like technology that infrastructure engineers have been operating for a long time–not a big leap.
But that’s the problem. Services like EC2 and S3 cater to the lift-and-shift strategy that has been proven to be more expensive for enterprises than running those same workloads in-house. Economics matter to many companies. In fact, it’s only in the last couple of years that companies are finally grasping that shutting down a data center and standing up a VPC doesn’t equal savings. Companies need an actual plan around IT operational transformation to fully realize public cloud’s promises.
Companies are comprehending this issue now, though. And that’s a challenge for New Jassy. What enterprises need are modern application architectures that leverage cloud-native for the economics to make sense. That idea has been echoed in so many podcasts and blogs that it’s almost trite to bring up. It’s not even interesting, because knowledge of cloud economics is no longer the problem. The problem is how to get to a cost-effective cloud consumption model.
Enterprises need a path to cloud-native, which is great for AWS. AWS wants to make their customers sticky, and cloud-native operations is a fantastic way to do that. But in the transition time between legacy operations and cloud-native, several other services can get a company’s attention. Azure is potentially a big threat here. The Microsoft relationship is strong in the enterprise. Google Cloud keeps making noises more folks are finding attractive. Oracle Cloud might be good for a cheap laugh among podcast pundits (I might know one), but it’s backed by too large of an organization with too large of a customer base to ignore.
And those are just public cloud players. If you add in SaaS distractions, PaaS options, and endless APIs democratizing infrastructure choices, and all of a sudden, AWS is just another option in a sea of options.
Come For The Lift-And-Shift, Stay For The Cloud Native
AWS needs a path to serve not just the huge operations out there who are used to operating at scale, but also the medium and small enterprises who aren’t. Cloud native operations are driven in part by organizations with applications that must be always available. They’ve written their applications to survive failure. In fact, an assumption of failure is built into how they design their apps and the tradeoffs they are willing to make. Those tradeoffs are a required, conscious choice of distributed computing. Smaller shops? Many of them have been getting away with scaling up and not scaling out. Probably they’ve got some load balancers in a data center, so scale out isn’t a foreign concept. But adding caching layers? CDN? Elastic scaling? Lifecycle management? Probably not. These folks aren’t ready for cloud-native infrastructure and operations without proper training and a clear roadmap.
This is a problem AWS can solve that they don’t solve today. This is an opportunity for New Jassy. AWS is good at offering services. AWS is even good at explaining those services at a high level. AWS isn’t so good at making it clear just how to bring an application from wherever it is to AWS.
Let’s consider WordPress as an example. WordPress is a typical web application. There’s an HTTP engine. There’s a lot of PHP code that runs to render pages. There’s a backend SQL database. If you want to host WP on AWS, you can do that. How? Lots of different ways. You could do it all on the cheap with LightSail, essentially a VPS offering that hides the cloud-native complexity from you. Arguably pointless, but at least LightSail is quickly understandable.
If LightSail seems a little too light, you could get into hosting the various WordPress required components in various AWS services. Put the database in RDS. Create a managed PHP platform via Elastic Beanstalk…which creates EC2 instances for you. Layer on a CDN with CloudFront. Layer on security with WAF and Shield for a CloudFlare-like experience. Profit. Or not profit, as a configuration of this magnitude will cost a reassuringly expensive amount of money. Every. Single. Month.
Or maybe run the PHP via Lambda to save some dollars. That’s a design with some tough tradeoffs related to system maintenance, but people have done it.
Did you choose the right architecture for your business needs? Did you need to configure all of those services and incur all of those AWS charges? Hard to say, which is where New Jassy comes in. Enterprises need help understanding not merely what services AWS offers. Enterprises need help understanding why they should deploy their applications using a particular mix of AWS services. When comparing different AWS architectures that can support an application, what are the tradeoffs of one vs. the other? What are the risks? What are the real costs? Yes, AWS offers their Pricing Calculator, but that’s not especially useful for computing firm budget numbers.
I see the AWS multi-billion dollar opportunity as consulting services that analyze existing applications, map out business requirements for that app when it’s running in the cloud, describe a cloud native architecture to meet those requirements, and then create explicit roadmaps to transform apps from legacy to cloud native operations. Such a service reduces the problem of cloud repatriation. Put another way, an application re-architected for cloud native operations being delivered by AWS services make the relationship sticky. Sticky is good. Sticky is a lifetime customer. Sticky is more revenue landed, and additional services expanded over time. Every repatriated workload represents lost revenue and a fractured, tenuous relationship.
About now, you’re howling about the AWS partner network. I understand that objection, but I’m a pragmatist. I’ve worked for various channel partners and managed some vendor partner relationships. I’ve also worked with my share of VARs. My view is that if you get the right AWS partner, and if that partner pairs you with the right team, and if that team has the experience you need, and if the team members haven’t been worked into the ground by their project managers (they have been), then I suppose you’ll have a great AWS partner experience. My snark aside, that can certainly happen. There are some fantastic AWS partners and consultants out there. But if AWS is taking customer acquisition seriously, I believe they need to own the relationship directly.
New Jassy needs a vision where cloud newcomers start with AWS. AWS first. Once there, that business is retained for every new cloud deployment. AWS only. I think AWS has the “AWS first” part of the equation mostly sorted. But AWS only? Market share notwithstanding, nope. Not even close.
Why AWS Stands To Lose
I’m arguing that the Jassy replacement matters, like John Chambers being replaced by Chuck Robbins mattered. AWS stands to lose their dominant position over time. Being first to market has been an advantage for them, but pumping out new services isn’t going to keep away all the others. The growth will come in making a viable economic play to truly shut down small data centers and tiny computer rooms the world over. Show enterprises the money.
As I view the market, AWS’s failure in this area has already resulted in a loss of potential market share.
- Consider hybrid cloud. Companies aren’t keeping all their platforms in-house anymore, but they aren’t giving all the business to AWS, either.
- Consider multi-cloud. Just the fact that multi-cloud exists is a testament that AWS isn’t winning all the hearts and minds in every situation. Competing public clouds are winning the business at times.
From an operational standpoint, both hybrid cloud and multi-cloud horrify me. I’m a believer in keeping operations the same wherever possible. Standardize processes. Go deep on a specific tech. Lean into in-house product interoperability from a vendor. There are assuredly tradeoffs to this “one hand to shake” approach with flexibility, functionality, and cost. But the benefits tend to help satisfy core business requirements of IT stability–resilience and uptime paired with a reduction in humans screwing up.
But as New Jassy no doubt already knows, the AWS first and only world simply doesn’t exist. Enterprises are spread all over the cloud landscape. I suspect Microsoft Azure is the number one threat, but the number two threat likely comes from Google Cloud Platform–yet another juggernaut. A wildcard third juggernaut is Oracle Cloud, which is increasingly being taken seriously as more than just a cloudy place friendly to your Oracle apps. Huge dollars have built huge clouds to take on AWS. These aren’t scrappy VC-backed startups, although plenty of startups filling cloudy niches exist, too.
Yet another threat to AWS is platform abstraction from provisioning tools like Terraform. Who cares what the underlying cloud is if computing technology needs are simple and Terraform has a provider? Admittedly, that is a somewhat specious argument. Terraform providers are not least common denominators, but rather explicit to the resources being provisioned. The point remains that standardizing operations on a tool like Terraform makes multi-cloud operations more palatable. Yes, an ops team might have to learn the quirks of Azure, et al. But if Terraform is there to do the heavy lifting, the procedure manual is still going to say “terraform apply” at the bottom, no matter which cloud the resources are being provisioned in.
AWS faces another challenge in the form of Kubernetes. At this point in the hype cycle, Kubernetes is a wildcard. It’s application orchestration. It’s the best thing for container deployment at scale. It’s too complicated for its own good. Too many features, not enough stability. Some are even calling K8s an operating system. The argument is that developers interact with Kubernetes, and Kubernetes puts container workloads wherever it thinks is best. The cloud platform barely matters. And since developers would be interacting with K8s, they think about K8s first and foremost–not the cloud platform K8s might be using to deploy pods. The actual infrastructure is an ops problem, and there’s still a contingent of devs out there that don’t want to get any ops on them. I read their opinions in Hacker News often. Devs just want the workloads to run. They don’t want to run the workloads.
I posited Kubernetes as a wildcard because K8s as the great cloud abstraction layer is not a thing yet. It’s still too hard to just throw workloads around pubic clouds willy-nilly. There is network connectivity, security, resiliency and more standard application architecture fare to be considered. Even so, it’s conceivable that if K8s gets away from a steady cadence of alpha features and settles into a mature, maintenance cycle release, enterprises might build on it more confidently.
Is VMware another wildcard impacting the AWS future? I see VMware as an AWS frenemy today. VMware needs the VMC on AWS product right now, because that’s a product that matches where many VMware customers are in their cloud transition. Their operations need the entrenched VMware way of managing their computing environments, but also need a cloud strategy they can act on today. Oh, and let’s not forget–VMC isn’t exclusive to AWS as a platform. I view VMC on AWS (or wherever else) as a transitional strategy for enterprises, and a stopgap for VMware. If you look at where VMware is going with recent acquisitions, VMware is trying hard to turn their battleship and retain their customer spends. Spends that, ideally, don’t involve AWS. I guess that’s a problem for New Gelsinger to solve, and New Jassy to keep a close eye on.
Jassy’s Replacement Really Does Matter
I think New Jassy can foster relationship building with the enterprises that need AWS. AWS needs to grow beyond a platform that’s happy to accept a credit card swipe, and into one that engages with companies to help them transform to cloud-native first. Then, AWS has a customer for life, and not just temporary workloads while enterprises try to figure out cloud.
AWS can champion reference models for cloud-native transformation. Show companies the way. “You’re here now, company. You need to be here in the future or the economics will be all wrong. Here’s a model to follow to help you modernize your infrastructure.” AWS needs to offer an application transformation easy button that helps a company get it right the first time. You might argue that such a thing is impossible, because all applications are snowflakes. I argue that most application architectures are more alike than different, and cloud-native is best suited to a cookie-cutter approach. Corner cases will always exist, but we shouldn’t let them make the rules for everyone else.
If AWS can help enterprises in this way, they can own the application transformation experience end-to-end. Right now, AWS has leaned into their partner network to offer enterprise consulting services, and I’m not suggesting that go away. Channel partners are always fraught relationships, though. If AWS built an affordable services organization to guarantee successful outcomes, it would serve as an on-boarding tool where customers stay for life because they deployed correctly the first time.
By “deployed correctly”, I mean that costs would be optimized, designs would be appropriately resilient, and cloud-native technologies would be leveraged–making a sticky customer. A customer will be hard-pressed to move to a different cloud if they are up to their digital armpits in proprietary AWS magic, and not just EC2 and S3.
I think New Jassy should also consider taking abstraction tools out of play. Identify and acquire. AWS presumably has the war chest for any acquisition they find interesting, whether that’s to make a technology part of their product set or to help direct dollars their way they might otherwise lose–as is already happening. That’s pesky capitalism rearing its head, but logically AWS needs to get serious about the players that are making it easier for customers to use AWS + something else and nuke it. Anti-competitive? You bet. But “AWS Terraform” has a certain ring to it. “No, because CloudFormation!” I know, I know. Still. This wouldn’t be the first time AWS had similar-yet-different services standing next to each other.
Another play New Jassy could make is turning privacy into a brand-associated word. While this might be mostly a marketing exercise, AWS could lean into privacy for the enterprise like Apple has for the consumer. Talking about privacy at this point might seem like a non sequitur, but hear me out. Social media services and the Amazon brand (not AWS specifically) are increasingly looked at with suspicion. The general public has become aware that Google is mining their users’ data. Amazon mines through shopping habits and Alexa interactions. Etc. What happens when enterprises start looking cross-eyed at AWS, wondering what AWS is doing with their data? On the one hand, it’s a silly question for those who understand data architecture. On the other hand, it’s not hard to make a suspicious association from a point of ignorance. “Gosh golly. Since Amazon is tracking me closely as I shop from home, I wonder what are they doing with my enterprise data I host on their cloud?”
In that context, AWS can go hard on how private your data is when hosted in the AWS cloud. Yes, it’s conflating the Amazon cloud business with the global Amazon brand, but there’s a powerful advantage AWS could play here that makes C-levels think that AWS is a extra secure and private place to put their company’s data. If AWS plays this right, it’s theoretically worth billions, even if it’s not actually a differentiator–and it isn’t in any way that leaps to mind.
Best of luck to you, New Jassy. We’ll be watching your career with great interest.
You can listen to Ethan Banks talking cloud with Ned Bellavance and industry guests on the weekly Day Two Cloud podcast, part of the Packet Pushers podcast network of engineering shows for IT professionals.