The announcements from AWS around deprecating certain services have raised a bunch of questions and concerns in the AWS community.
As Jeff Barr wrote, these are the services:
S3 Select, CloudSearch, Cloud9, SimpleDB, Forecast, Data Pipeline, and CodeCommit.
This post will focus on Cloud9 and CodeCommit … and how I think this announcement impacts the “end to end” developer story for developers on AWS. We’ll also look at how the announcements impacts my “Go-To” services Amazon CodeCatalyst.
It is written from the perspective of a builder that mainly uses AWS tools for smaller side projects and can be seen as a “startup” that needs to quickly be up & running without much hassle.
Introduction
These annoucements, and the way that these deprecations where announced
are in my humble opinion one of the worst possible ways. I know the teams at AWS have seen the feedback and I hope that there will be a clearer communication strategy going forward.
For me the combination of those posts with the assumption of CodeCatalyst being built on top of these services gives a very strange feeling on how much AWS is currently invested into Developers on AWS.
Let’s look at why I see a lot of impact of these announcements for builders and think about alternatives if you are using CodeCommit or Cloud9 for certain aspects today.
Tools required for SDLC
A few weeks ago I even dedicated a complete Shorts-Playlist on all of the Code* tools, looking at their usage and the approach to cover a full Software Development Lifecycle (SDLC) building on AWS.
In this series I drafted the diagram:
AWS Tools part of your SDLC until recent announcements
This being and end-to-end flow, AWS had at least two options to implement this process using their tools:
Either CodeCatalyst or a combination of different AWS Services
When CodeCatalyst was announced, I wrote abouthow CodeCatalyst can be used to cover all parts of your Secure Development Lifecycle (SDLC) process on AWS. Ever since then, there was an alternative on AWS using a combination of different building blocks: CodeCommit, CodeBuild, CodeDeploy, CodePipeline and others.
CodeCommit was a good, reliable managed Git server. For the purposes it solved, there weren’t many features to add. It was a managed service you didn’t need to think about and just “serve its purpose”.
Cloud9 was a hosted IDE, a development environment that users where able to access through their browser. This enabled builders to have a real IDE, even on old or underpowered computers, anywhere — even when being on vacation.
Developers on AWS are still able to use CodeCatalyst to cover for all parts of your product lifecycle or they had the alternative to use the different “building blocks” to compose their SDLC process. Both options gave value and helped AWS customers to solve certain aspects and problems.
Now, officially, only one option is left — CodeCatalyst.
CodeCatalyst is an integrated DevTools service that unites all of the building blocks under an opinionated, structured user interface. It was announced at re:Invent 2022 and went GA in early 2023. With the custom blueprints feature, it also enables builders to create project templates and share them with their team mates or dependend teams. Very powerful possibilities for teams to collaborate better and also share their best practices with other teams.
Those that didn’t need a “reliable managed Git server” where most probably using existing alternatives — that might solve the “job” better than CodeCommit — like Github, Gitlab or Atlassian. These users and AWS customers are not affected by the change.
What has changed with the July 2024 announcements — builders perspective
Now, the system landscape has changed.
Developers can not use Cloud9 anymore to develop software, they need to fallback to alternatives like Github Codespaces, Coder or Gitpod.
Developers cannot store their source code in CodeCommit anymore, they need to fallback to alternatives like Github, Gitlab or Bitbucket.
And given CodeCatalyst might be using CodeCommit under the hood and is using Cloud9 for the DevEnvironments – Can I really build something on top of CodeCatalyst going forward?
So this announcement of deprecation — without a “real” AWS native alternative — puts everyone building and developing software on AWS in the situation of needed to look for alternative setups.
Especially it forces you — if you are a small organization (or a startup) to engage with more than just one vendor as part of your SDLC lifecycle and process. I see this as a critical point to talk about aswell.
And, if you are building software or platforms on AWS where especially CodeCommit is part of application or the deployed architecture itself — You are now left without any option. If you want to integrate a Git server in your application on AWS, you will now need to self-host the git-server instead of using a managed service.
If you “just” needed a Git repository, quickly, fast and reliable — CodeCommit was the way to go. Now, you need to use a 3rd party alternative.
Now: What options on AWS do we have as builders?
What changed with the July 2024 announcements — business perspective
Looking at the announced changes from a different perspective, we need to acknowledge that AWS is a 90+ billion (90.000.000.000) dollar company. It is clear, being a business that aims to “make money”, that AWS needs to focus on services and solutions that are widely used, adapted and earn a good margin.
The reason might be that Cloud9 and CodeCommit where just not profitable enough to drive the expected growth of the business. Especially, as there are other services that do the same job better than Cloud9 and CodeCommit. So it might have been “just” a business decision to stop investing into these services and focus instead on Amazon Q that promises to help developers and builders on AWS.
This raises the question on which other services might soon or in the future be hit by exactly the same challenge. And – how is “success” measured by AWS on services? Is it “just” revenue or are there other points that are being considered?
But still — How this feels for me and questions I have (emotionally)
It feels like AWS has given up the game of engaging with their “Builders” and is now focused on the “Buyers” that “host” their applications on AWS.
If you think about how AWS started and if you look at how much effort AWS has spent this year on making us think that “Amazon Q Developer” is going to make our lives as developers easier…
How can I as an advocate for AWS as a platform be confident that I am valued as “Builder” on AWS? Will other services also disappear if they do not get enough traction?
And how much can I trust in Werner’s “Now, go build“?
How much “trust” can I put in the other Code* (CodeBuild, CodePipeline, …) tools on AWS?
With CodePipeline and CodeBuild getting a lot of notable updates right now (macOS, Github action runners, Stages rollback, …) the outsiders view is that at least these services are there to exist… but how much trust has the AWS team lost with Builders around the globe?
I’m eager to see how the different workshops, best practice documents, open source projects that use either CodeCommit oder Cloud9 (especially also AWS owned) will be adjusted and updated in the next weeks and months.
How much is also CodeCatalyst going to be the central place for Developers on AWS? How much updates will we see there?
How does this affect you – I would love to know!
I am really interested to hear how these announcements have affected your perspective on AWS and your view on the different AWS services.
Please share your thoughts either as a comment to this post or reach out to me personally!
What YOU can do next
You could now follow the advice from AWS and “migrate” away from CodeCommit or Cloud9 — but is this really what you want to do?
If you have a need to have a “Git server” or “Git repository” close to your applications on AWS, how do you do that?
You might need to host your own Git server on AWS….or you need to give up on that premise and fallback to alternative Git providers like Github, Gitlab, …
If you insist on having your own hosted Git within your AWS environment, there a few possible solutions…
…and potentially others that I am not aware of….
In order to host a “simple” Git setup I’ve recently made this repository public that deploys Gitness as a Git Repository on ECS. It will cost you roughly 50 USD/month. See also a relevant blog post.
Inspired by this, Jakub Wolynko did the same thing for Onedev – please see https://github.com/3sky/onedev-on-ecs if you would like to try that out.
As an alternative for Cloud9, you can use vscode.dev, which runs VS Code in the browser or other alternatives that are more integrated and personalized like gitpod.io or Github Codespaces.
But is this REALLY what you want to do if you are working on AWS only?
What I hope to get from the AWS team
As re:Invent is approaching fast and that usually sets the direction for a lot of AWS services, I really hope to get reliable information and roadmap clarifications around the AWS developer tools.
I’d like to understand if I can rely on CodeCatalyst, CodePipeline, CodeBuild, CodeArtifact, CodeDeploy, … and other AWS services that help developers to build software on AWS.
Does anyone know if this page ever mentioned CodeCatalyst? Please let me know!
In addition to that, I would love to get a better and more detailed overview on what the level of support will be that customers of the “deprecated” services will get: Security Updates? Priority Support?
Creating one page that summerizes that for all “deprecated” services would be amazing!
And – last but not least – make sure that Amazong Q knows which services you are deprecating!
Screenshot taken on 6th of September, 4pm CEST
If you’ve read this post until here, I would love to get your view and your feedback on this topic!
Thanks for the feedback I got before publishing this article and while I know you don’t agree with everything I wrote, it’s great to get your feedback, Monika, Raphael, Ran, Markus and others 
Please let me know either in the comments or directly on my social channels — LinkedIn, X being the ones I still use mostly 
Views: 0
Top comments (10)
I use AWS extensively, but for the sake of my productivity (if not my career) I would never try to rely on them 100% for everything. Putting stuff like CodeCommit and Cloud9 on your resume would be ineffective, if not laughable to many. No one respects those tools. But more importantly, those tools aren't the best. Use AWS for what they're good at, but otherwise, focus on industry standard tools like Github or (if not Github, then) Gitlab. Even Bitbucket 🙄.
I agree with most of your points, but I think these ones aren't fair:
My understanding is that if you're using either of these services in your account or AWS organization already, you can keep using them as before and even create new Repos or C9 instances.
Great feedback and comment and I - in general - agree to that aswell.
The challenge being: if you follow best practices and things that you "should do", you would most probably be creating a new AWS account regularly (especially for new services or new deployments....) and thats where you then get into the same problem again.
Obviously, if you do not do that, then you don't get into that problem...
Great article. I have been using AWS's "Code"- services extensively and always found that CodeCommit made sense, which is why I was shocked about their deprecation.
I think $50 for a Git server alternative is too much and most of the devs are familiar with GitHub anyway.
I am also thinking what about the certifications (especially DevOps Pro, SysOps Ass) that still mention CodeCommit and Cloud9... I have the feeling that AWS announcements lately most of the time upset their customer, fans, builders, developers, and whatsoever.
private Github Organisation is just $10 per user per month I think
Excellent article!
Thanks for the feedback, Jotty!
Excellent article and excellent questions. For a long time it seemed like AWS would not go the route of shutting down services but it seems that is over.
Let’s see where this develops…
just avoid the vendor-lock in in the first place.
Build all you web applications as Docker Images (both frontend and backend)
Use Kubernetes to deploy them on AWS/Azure/your other provider