The end of the Everything Cloud
Why is AWS deprecating a bunch of services all of a sudden, and what does it mean for you?
Longtime customers know there are two distinct categories of AWS services.
Category 1 contains the gold-plated, inner-circle, first-ballot Hall-of-Fame services like EC2, S3, DynamoDB, etc. These are the moneymakers, the heavy hitters, the Babe Ruth and Willie Mays of the cloud. If one of them falls over, the entire internet has a bad day.
Category 2 contains … everything else.
Just as Amazon is the Everything Store, AWS is the Everything Cloud. Did you know AWS has a service for spatial simulations (SimSpace Weaver)? An analytics service for capital markets (FinSpace)? Can you articulate the difference between Forecast and Timestream, or between CodeStar and CodeCatalyst?
For the past 10 years or so, AWS has been rolling out these peripheral services at an astonishing rate, dozens every year. A few get traction, most don’t—but they all stick around, undead zombies behind impressive-looking marketing pages, because historically AWS just doesn’t make many breaking changes. That’s been the unspoken commitment between AWS and its customers. If we roll it out, no matter how silly or misguided, we will keep it running forever.
Until the end of the internet … or not
There is, however, a new sheriff in town at AWS. His name is Matt Garman, he’s got sales experience as well as engineering on his resume, and he seems to have this weird idea that AWS’s products should make money.
Sticking with the baseball Hall of Fame analogy: if S3 is Babe Ruth, these Category 2 services are more like Sunny Jim Bottomley. Yes, he technically has a plaque in the Hall of Fame, but nobody’s paying admission to see him.
And, all of a sudden, some of those Sunny Jim-tier services are having their Hall of Fame plaques stripped. (In fairness, this started even before Garman took over.)
The estimable Scott Piper maintains a list of the services to have been deprecated over the last few months. CodeStar has been memory-holed. Cloud9, AWS’s IDE in the cloud, no longer accepts new signups. Workdocs will delete all remaining data sometime next year. CloudSearch is going away. About a dozen services have been deprecated so far, and I’m hearing rumblings of more to come. All are “Category 2” services without significant adoption, and most are developer-experience services that simply aren’t competitive with more popular third-party alternatives.
Is this betrayal?
First let’s make it clear what’s not going on here. This is not an indication that AWS is turning into GCP, who has inherited from broader Google a deserved reputation for pulling the rug out from under users by killing services with wide adoption. As a GCP user, you’ve always got in the back of your mind a suspicion that no service is too critical for Google to get bored with it and move on. If Google ran the baseball Hall of Fame, they’d have kicked out Babe Ruth by now because they were tired of dusting his statue.
I haven’t heard too many complaints from actual users of the services AWS is turning off, because in most cases, there just aren’t any users.1 Nobody has chosen CloudSearch on purpose in years; it’s long since been replaced by OpenSearch. These services have been in maintenance-only mode for some time. At some point, having a glob of undernourished services that you are only pretending to offer—when every serious customer knows they are dead in all but name and will never be worth adopting—has got to be worse for AWS’s brand than just ripping off the bandaid and shutting them down.
So I get what AWS is doing. I think it’s necessary. I hope they can redirect the teams and dollars that were wasted keeping the lights on for CodeStar and Workdocs into making their Babe Ruth-caliber services even more amazing.
The problem
AWS made this mess for themselves by rushing all sorts of half-baked services to market. The mess had to be cleaned up at some point, and they’re doing that. But now they’ve explicitly revealed something to customers: The new stuff we release isn’t guaranteed to stick around.
This is a problem when you are trying to sweatily convince everyone that Amazon Q is the last best hope of mankind. Is Amazon Q like EC2, a Willie Mays-level legend that will never die? Or is it like Harold Baines, who got into the Hall of Fame via backroom shenanigans although nobody really believes he was one of the all-time greats?
I don’t know and you don’t know, because AWS can’t possibly tell us. It’s a prisoner’s dilemma. They need us to believe Q is here to stay, because only then will people adopt it. But if people don’t adopt it, AWS is now signaling that they will eventually be forced to kill it. Don’t forget, they’ve already memory-holed Q’s predecessor CodeWhisperer.
Again, this isn’t as bad as GCP’s perception problem—nobody thinks AWS would kill a service capriciously if it was seeing great uptake. But it’s certainly confusing. AWS is dribbling out these service deprecations erratically, piecemeal, without explaining the overall rationale behind what they’re doing. And that is increasingly sowing doubt and discord in the community.
What to do?
The Something Cloud
I think AWS needs to express a public conviction on what kind of cloud they intend to be.
They’re not the Everything Cloud anymore. By junking this pile of failed services, they’ve tacitly acknowledged that it’s not worth their while to be in the business of running loss-leader developer tools (CodeCommit, Cloud9, Honeycode) or random business apps (Workdocs) or exotic vanity projects (QLDB) or whatever FinSpace Dataset Browser was/wasn’t.
So what is their business?
This would probably be a terrible PR move, but I would certainly respect it if Chief Evangelist Jeff Barr came out with a blog post saying something like this:
At AWS, we are committed to running the best cloud primitives on the planet. That’s compute, networking, storage, data, identity. We are putting a massive amount of investment into maintaining, securing, and innovating those infrastructure-as-a-service primitives every day.
Over the past few years, we’ve also released a number of developer-experience tools built on top of our primitives. Tools like App Composer, CodeCatalyst, the Serverless App Repo, basically anything with the word “App” or “Code” in it.
This made sense in the past, but we’ve now seen that the wider AWS ecosystem is innovating beautifully on great new AWS-centric developer experiences.
So we’re going to “cut once, cut deep” and sunset {this list of 30-40 “App-” and “Code-” prefixed services} from the AWS console and APIs. It doesn’t look like very many of you are using them anyway, but if you are, here is a centralized location where you can find clear deprecation timelines and migration instructions for every affected service.
The people who were working on those services will be reassigned to help make our infrastructure even better.
We don’t expect to do this again. From now on, when we make a service or feature generally available, it’s because it fits into our core mission to be the best infrastructure cloud in history.
Oh and also Amazon Q is the last best hope of mankind. All hail Generative AI!
That last bullet point I think is the mandated signoff for all AWS blogs. But the rest … I mean, of course AWS would never say any of that. But I think it’d be great if they said it. Because, whether they’re forthcoming about it or not, it sure looks like they’re culling their Hall of Fame to double down on what they do best.
And, to be honest, I don’t hate it.
Cartoon of the day
CodeCommit, a notional git repository service, is the only service some people are mourning. While it was never a serious competitor to GitHub, it did have a certain utility for internal plumbing in all-AWS CI/CD solutions. It probably didn’t make much money, but in my days as an AWS consultant the presence of CodeCommit in somebody’s stack was usually a signal that the customer in question was making some VERY expensive choices elsewhere on AWS.
Every single technology that has been around for years has periods of deprecation, this is a natural as technology and times change and needs change. Even solid products that have been around for 10+ years have deprecation cycles, and they should. Businesses cannot support products with little usage forever economically.
AWS deprecating services is a good thing. Done well it doesn't erode confidence in choosing AWS or AWS services. Teams should be evaluating every choice they make for what they build their product on top of, and AWS is an excellent choice. Their recent push to charge more for deprecated/out of date products and services is a very good incentive system for their customers. Instead of a one time deep cut, I'd rather see communication and transparency.
I went from supporting an enterprise AWS tenant to supporting a GCP one a few years ago and I remember be struck by how much I took for granted that AWS would have a managed service for pretty much anything (e.g. Kafka) compared to GCP. As far as CodeCommit, AWS foisted a CodeCommit-based solution on us for managing security and IAM policies. I could probably write a novel length rant about AWS account management problems- don’t know how large enterprises do it.