In writing this up - https://simonwillison.net/2024/Jul/30/aws-codecommit-quietly... - I found out about a much more significant deprecation: Amazon QLDB (Quantum Ledger Database - a blockchain-ish thing they launched in GA in 2019) is being hard-deprecated too! They're shutting it down completely on 31st July 2025, having announced the shutdown a few weeks ago (on July 18th).
It wasn't a blockchain per se. It basically was Amazon's Version of Rich Hickey's Datomic and them pointing people to Aurora for Migration is a bit of a joke. It's a completely different product.
QLDB is an immutable database with allowing you to move back and forward in history and do live streaming of events etc with cryptographic verification built in.
You _can_ set up Postgres like this but it's a lot of hoops and not very user friendly (some monstrosity involving DMS, Kinesis Firehose and what not).
> QLDB is an immutable database with allowing you to move back and forward in history and do live streaming of events etc with cryptographic verification built in.
I used it for a subset of the features. Financial auditing and risk rating of destination banks for a particular network.
Having an immutable database that was able to track fraud ratings, along with when exactly it occurred with the data available at the time was pretty cool. You could probably do it with other tools, but having it all in one product was nice.
The cryptographic verification was helpful for legal defence. I can't think of any other uses so we may have been their only customers.
QLDB is the 'blockchain' businesses need. If you think of blockchain design choices as a set of dip switches, QLDB is the only one with all the correct settings for distributed business transaction value at scale.
Eh, most people would like their apps to provide them with a browsable history of their data, and why the changes happened.
It's just increases scope x100 to get anything done, so few do it... but if the tooling was available, almost all stateful applications would benefit from it.
Most people? There is a Django-history module, and yet it’s not nearly as popular as Django. I’ve used this on two out of 100 projects. No one ever actually wanted the history, it’s there for “just in case of an audit” and compliance, which never comes.
lol no. And the DB isn’t going to tell you who what why without you writing code to support that audit in which case… that special database has solved exactly 0 problems that a traditional RDBMS already solves.
I was addressing the point "nobody wants that". And I disagreed, because: if it existed, almost everyone would want it.
The tooling just doesn't exist. Doing it with half-assed tooling increases the scope of literally every development you'd be doing, so nobody bothers with it. Ive never worked with this particular database, so no idea how it would work in practice here.
It's basically a schema-less database which you could query with SQL-ish syntax (PartiQL) and which provided additional views to let you query the history of changes. Git is a good analogy. I've never used the signing for anything but the ability to query the history makes it trivial to implement things like point in time recovery (essentially equivalent to a git checkout) or audit logs (essentially git blame or git log -p), which would otherwise require a much more complex schema in something like DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/developerg...
Not surprised. CodeCommit was released alongside a stable of other mediocre tools for CI/CD (CodePipeline and CodeDeploy if I recall correctly) that reflected the pinnacle of AWS's mid-to-late 2010s attitude, which is to find something popular and offer an incredibly mediocre alternative to it that will still be used by those teams who want to move as much as possible to AWS. Seems like that stalled out a bit, mostly due to it being so insanely bad that even the most dedicated AWS fanatics didn't bite. I feel like a lot of the recent stuff is just drop-in replacement AWS alternatives to popular tools (like Kafka and Cassandra) with outrageous price tags.
>be used by those teams who want to move as much as possible to AWS
By teams that have been mandated to move as much as possible to AWS by their company's senior leadership, because it simplified accounts/they negotiated a "great contract" etc.
Having been on both sides, it often makes a lot of sense. A lot of companies have surprises requirements in contacts, such as HIPPA or military/classified or whatnot. The cost of adding a new vendor can be astronomical compared to the cost of dealing with CodeCommit.
In truth, though, Amazon should have bought gitlab instead.
Funnily enough when my infra team talked to AWS solution architects about this topic, it seems they were very upfront: don't touch CodeCommit, AWS/Amazon teams mostly use GitLab internally. And we do have a partnership plus discounts conditional to minimum usage volumes.
Slight correction, the sales org uses GitLab, mainly to segregate any “code” they build for customers. Internal AWS/Amazon teams use an internal git-backed UI.
If AWS forced their teams to "dogfood", it would quickly morph into the Testuo blob monster from Akira -- there are too many products/services popping up too quickly, and the amount of time and knowledge lost to the constant changes would be catastrophic.
Dogfooding is for simpler companies. It's also bullshit and best for product managers and sales. Let tech work with what's best for their specific internal environment.
Doesn't it reflect more on the quality of the people involved? These tools came out at the same time as a bunch of other AWS tools that are still used. The platform itself, the company around these teams was the same, so why did Code Commit suck but other AWS products from the same vintage turned out great?
You’ve never been part of a large organization have you?
I have a little insight on how things like CodeCommit fall behind the competition.
I worked at AWS in the Professional Services division. For a little over two years I was on a makeshift team maintaining and improving a very popular open source project in its niche.
The project was hosted on “AWS Samples” (https://github.com/aws-samples). Once approved for the initial release of a project in this Github organization, there is no oversite on updates. In my experience from releasing 8 of my own projects to the repository, it takes about two days to get the initial approval and it’s really based on the honor system as far as following the guidelines after that.
We released features and improvements like gangbusters based on customer demand or if we just wanted to scratch an itch.
Everything slowed to a crawl, releases, approval processes, you had to justify everything you wanted to add based on revenue potential, everything had to be approved by higher ups. We were the sane developers. I dropped out of the project then.
But I saw the storm coming, so my last major contribution before it got transitioned was to introduce “hooks” functionality that allowed you to change the processing pipeline by adding a custom lambda arn to it in settings.
Before it became a “solution” former AWS employees who use to work on the project who were still in the industry would make changes and submit pull requests that we would merge.
But back to CodeCommit, can you imagine how hard it is to convince senior leadership to give you funding for a service that neither gives you a competitive advantage nor is a revenue generator?
Hell they just added support for viewing images inline in markdown from the console this year.
Hey fellow nerd. What project was it? I'm just curious if I came across it. I loved digging through the solutions repositories every quarter or so -- always something new and legitimately useful.
When I mean the people involved I didn't mean mostly the software engineers, like you show they probably have the least contribution to the success of these projects. But the point stands that the products have to exist in the same level of bureocracy and disfunctional leadership, so someone must've been better at dealing with that in the successful products. I definitely had really good experiences as a user of several of AWS's things from the same time. Maybe it's more on product leadership but I was just musing about it. To your original question I haven't worked on such big corporations no, max size I've experienced is ~2k people for ~6 months, other than that 10-400 - so I can see how it's also a different beast.
Bezos was well known for focusing on things that “make the beer taste better”. It didn’t give AWS a competitive advantage or any real revenue by trying to host a git repository.
For years they have been making sure that their other services like CodeBuild and CodePipeline work with other hosted git providers.
Uncharacteristically, they even support creating third party git repositories with CloudFormation
As far as working for large companies, I would rather get a daily anal probe with a cactus than ever work for a large company/“FAANG” again. I’ve repeatedly ignored overtures from Google (GCP), Microsoft (Azure) and even Oracle (OCP).
> find something popular and offer an incredibly mediocre alternative to it that will still be used by those teams who want to move as much as possible to AWS.
Any insights on _why_ they turned out to be mediocre? Is it because of them being released as MVP and staying that way for many years or just a lack of interest afterwards?
> If you would like to use an alternative to AWS CodeCommit given this news, we recommend using GitLab, GitHub, or another third party source provider of your choice. We have written a blog which describes how to migrate your repository to one of these other solutions.
I wonder how long AWS will keep Code Commit running for their customers who are already using it? I'm guessing many, many years.
Weird that there's no announcement anywhere (that I can find) about CodeCommit ceasing to onboard new customers. Apparently it happened on June 6th but this forum post from July 26th is the only thing that comes up in search.
The worst thing about CodeCommit is that repo URLs are not unique, Depending on the AWS account you log in to, you can have a different repo with the same url.
Second worst thing is that it basically refuses to show a diff for any file longer than a few lines.
Third worst thing is you need a login helper and special generated credential to create a login.
Fourth worst thing is the absolute slowness of it. Good riddance.
I once had high hopes Amazon would be able to build a real GitHub competitor. It's a real shame Amazon doesn't seem to be able to build anything that reaches beyond their walled garden.
User friendliness is not AWS moat. Anything that is facing a larger audience other than those that have regular access to their tooling (either cli or UI) is far from being ready for large adoption.
I've tried all of these tools over the last few years as part of vendor due diligence and none of them impressed me. Code Deploy is probably the best of the bunch and it's really just a very opinionated deployment tool that only works on specific use cases well.
CodePipeline is another good example of just horrible user experience. You need a lot of hours of training to figure out all the different permissions required to get it all to work. It is a mess.
I use GitHub Codespaces now for much of my deployment automation.
A lot of cloud providers release hastily built and generally cruddy services whose sole purpose in life is to satisfy the question "does your cloud have X" when customers are doing does-it-tick-the-box comparisons across clouds.
Not surprising the ui is not very friendly and getting code in and out when you are not inside the AWS walled garden (need AWS keys) really restricted it
clones a repository named "foobar" in the namespace of the currently logged-in user. So it can give you completely different results with different credentials.
While this isn't surprising considering how bad it was, it is surprising considering that they recently announced the whole Amazon Q for software development thing. Who's going to trust them with Dev tooling now?
AWS CodePipeline + CodeDeploy are horrors¹ from what I saw at a client.
They had mandated .Net + Javascript for all development, GitHub for versioning, and AWS for all other cloud services.
The different projects they had going were not complex or huge.
Yet it took months to get it up and running.
The last month at least they paid for AWS specialists to come in and
set it up and even they spent weeks.
Throughout it all, any notion of trying a different CI/CD stack were
rudely dismissed.
Once it was up and running nobody dared touch the pipeline
again.
From all the AWS services that the customer used nothing
was ever comparable to the horrors of their CI/CD.
Setting it up with Azure's offerings would have been damned near trivial.
I have however not used those in production so I do not have the
experience to able to say it is a better solution over all.
¹ In fairness, AWS had just recently released the CI/CD offerings
and things may be a lot better now. I havent look at it again
since then.
Are they shutting down CodeCatalyst as well? Or are they just forcing new customers over to CodeCatalyst? It’s weird (for Amazon) they recommend Github and Gitlab over an AWS alternative if they are shifting people over to CodeCatalyst
This is very bad, and the silent deprecation of Amazon QLDB even more shocking. It looks like at AWS the MBA's are fully in charge...
Many in this thread commenting on CodeCommit not being GitHub or GitLab are missing the point.
I don't want to have my companies code with GitHub/Microsoft and being used to train their AI. Also don't want to have to rely on a third party like GitLab, that is a company who makes no money, and whose losses are $55 million dollars a quarter,
and has shaky internal technical governance. Did not forget about their Prod database one man setup....
I don't care about the lack of features of CodeCommit. It's usefulness was essentially providing a managed git server. Did not need more, but needed it as a managed server in the AWS Cloud.
The alternatives now will be the third parties, or the additional effort of running EC2 instances and managing the resilience and architecture.
This does not predict a good future for tools like Amazon CodeGuru Reviewer for Java and Python, CodeArtifact, CodePipeline and CodeBuild. And even if these plus QLDB were probably money losers for AWS, the MBA's are missing the point.
I would not be surprised if these silent decisions, are not reversed shortly, or if the service is just kept forever as is, but not deprecated.
To me it looks like a huge hack (download your code as a zip file just to upload it to CodePipeline) rather than a solution - I'll not be surprised to discover other migtations to look similarly
AWS had and probably still has the least interesting and immature way of investing in new products of any organization with the resources it has. Apart from the early wave of AWS products virtually everything has been a dud. There are so many random AWS products that are live but basically dead because Amazon/AWS never invested enough into them. Totally predictable outcome. I’m not sure why Bezos made Andy Jassy CEO.
Their business models has always been basically MS's strategy: Build out a massive sales and consulting organization, and then build products so that sales people can generate feature matrices to compare themselves with the competition. I'm certain they're keenly aware that they build shit products -- but they know that the majority of their customers are willing to pay a premium for a worse product if it means avoiding talking to finance and ensuring compliance for any external vendor.
This link doesn’t appear to have that information. It’s just an unanswered question about being unable to create CodeCommit repos. Is there an actual announcement somewhere?
It was never great anyway, although I wonder how they will handle some of the AWS stuff that would use it by default (automatically deploying private Lambdas, etc. IIRC).
Very disappointing. CodeCommit had value in its APIs for managing and accessing Git repositories programmatically e.g. from Lambda functions. I've used it to implement simple, Git-compatible version control in some projects by calling the PutFile API. Now it will be much more complicated to achieve something similar.
Every AWS feature requires some stupid aws cli call that gives you 12 hours of usage. So every day depending on how many products you're using, you have stupid shit to run.
No. You could either set it up with SSH or HTTPS credentials (managed via IAM Console or CLI) or use the AWS CLI's credential helper that managed everything automatically. The credential helper was a little weird to set up the first time I used it, but once I wrote up the instructions it was easy enough.
Honestly I've never come across the '12 hours of usage' thing for AWS. But I only use CodeCommit, EC2, S3, SNS, SES, and other low-level services.
The "12 hours" comes from IAM roles... some organizations don't allow folks to use IAM users for security reasons; many are now swapping to a setup like IAM Identity Center where they are granted temporary AWS credentials for an IAM role using an SSO provider.
It's configurable, but outside of having an IAM users with long-term IAM credentials (which is not ideal security-wise), sessions can be max 12 hours long.
QLDB shutdown announcement in the release notes: https://docs.aws.amazon.com/qldb/latest/developerguide/docum...
Their blog post about how to rewrite QLDB apps to use Aurora PostgreSQL instead: https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb...
Hacker News discussion from when QLDB was first announced in 2018: https://news.ycombinator.com/item?id=18553387
I also found this handy community GitHub repo which tracks these breaking AWS changes and lets you subscribe to them via an Atom feed: https://github.com/SummitRoute/aws_breaking_changes