AWS Code Commit Ceased Onboarding New Customers | Hacker News Reader

AWS Code Commit Ceased Onboarding New Customers

repost.aws

142 pointskevinslin83 comments

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).

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

> Their blog post about how to rewrite QLDB apps to use Aurora PostgreSQL instead

Straight callback to all the "you don't need a blockchain, you just need a database".

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).

This makes me wonder if Hedera Hashgraph can support this use case...

> 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.

Which no one ever needed.

Well, git is kinda popular.

What about Git rebase -i

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.

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.

This was the perfect use case.

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.

Is this particular blockchain permissioned in such a way that users couldn't continue operating it outside of Amazon?

Yes. As far as I can tell it's effectively an immutable ledger, a bit like a Git repository with signed commits. No proof of work or similar.

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...

Oh, you, thanks for your blog posts, had several in my newsletter so I recognized your name. Thanks again.

Did anyone notice it is being cancelled?

There's a Reddit thread with 38 comments, I couldn't find much else https://www.reddit.com/r/aws/comments/1e6nmy5/goodbye_amazon...

AWS Cloud9 is no longer available for new accounts? That's annoying - it fills a small but important role in some work stuff.

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.

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.

Then, it became popular enough to be promoted from “AWS Samples” to an “AWS Solution” (https://aws.amazon.com/solutions/).

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.

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

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

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).

My BigTech story:

https://news.ycombinator.com/item?id=38474212

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.

https://aws.amazon.com/solutions/implementations/qnabot-on-a...

>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.

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.

The fact that there was no dogfooding in many years here tells everything one needs to know about CodeCommit.

AWS CantCommit

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.

The thing I like about AWS is they're very practical.

Here's a project from AWS using the CDK to setup a CI/CD pipeline with Github actions:

https://github.com/cdklabs/cdk-pipelines-github

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.

> In truth, though, Amazon should have bought gitlab instead.

We would be in very deep shit now.

Software devs fall to hype sometimes. It's not just management. But I guess it's easier to always look for blame elsewhere.

CodeDeploy is kinda good for blue/green deployments to EC2. A little painful to set up, but works flawlessly once you get it going.

> 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 found that blog post: "How to migrate your AWS CodeCommit repository to another Git provider" from 25th July 2024 https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-...

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.

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.

Codebuild is also a real pain.

Permissions are the bane of my AWS experience. Once you figure them out it's simple, but finding what you need in their docs is difficult.

I never NOT thought that CodeCommit and CodePipeline were box checks for strategic AWS customers

Can you describe more of what you mean

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.

Hope unjustified.

AWS can build low level solutions -- EC2, EBS, S3. High level stuff is garbage.

Everyone's and I mean everyone's high level stuff is garbage. Remember when Lotus Notes was the peak. The only thing constant is change etc.

Amazon has a uniquely large spread, in that case.

I use S3, EC2, Route 53, and RDS. That's more or less it. I advise others to do likewise. Not the same set, mind you, but the same mindset.

GitHub is good, yes? And Excel? And Notion? And Datadog?

Lots of companies with excellent user friendly products.

GCP is good in that regard too, minus IAM.

> GCP is good in that regard too, minus IAM.

Care to elaborate why? IMO, GCP's IAM is years ahead of say AWS.

I second that. It's honestly simple. You assign roles (bundling of individual API call permissions) to cloud identities to resources.

I don't think GCP IAM is approachable to the degree that it's other services are. (Better than AWS? Sure.)

A hundreds different "Admin" roles, a bunch of OAuth client stuff, other weird settings.

It's a fundamentally hard problem, but I don't think GCP solved it in an approachable/user-friendly way, which is the topic.

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.

They did: https://codecatalyst.aws/

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.

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

Speaking of unfriendly, I learned recently that unlike S3 buckets, CodeCommit repository URLs are/were not globally unique. That is, something like:

    git clone https://git-codecommit.us-east-2.amazonaws.com/v1/repos/foobar

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

Cue rebrand to “AWS Code Freeze”.

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.

Edit: Just found this

"AWS breaking changes and price increases" - https://github.com/SummitRoute/aws_breaking_changes?tab=read...

Don't know what is going on but now also Cloud9 seems to have a shaky future? Not on-boarding new customers?

AMZN Earnings Release is next Thursday after market close. https://www.nasdaq.com/market-activity/stocks/amzn/earnings

I am going to listen to that earnings call, very carefully....

Gitlab acquisition imminent?

Would be surprised if FTC is allowing that.

FTC allowed to acquire GitHub by Microsoft...

That was a very different enforcement regime.

Would make sense. Good fit.

It's still fun how their proposed solution for using on-prem Bitbucket Server with CodePipeline works: https://aws.amazon.com/blogs/devops/integrating-codepipeline...

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.

I never did liked CodeCommit after testing it about 2 years ago. Just felt like an afterthought.

They better not touch CodePipeline and CodeDeploy though.

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).

Hoping they never disable cloud9 for my account

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.

AWS is now pathologically focused on the GenAI services they're shilling. Services like this fall to the wayside.

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.

Was codecommit like that

The timeout is configurable.

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.

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.

Reply on news.ycombinator.com