A year ago, AWS launched a preview of CodeCatalyst during re:Invent 2022. In April, it was made generally available, albeit only in one region (us-west-1). Since then, AWS has silently released CodeCatalyst in eu-west-1.
As a result, I’ve decided to give it a spin. In this post, I’ll give a brief overview of what CodeCatalyst is and some of its quirks that you should be aware of.
What is CodeCatalyst?
CodeCatalyst is a remote development and collaboration space. It’s a platform that allows you to store and version your code, quickly spin up cloud development environments, and track issues for your application. In other words: it’s an AWS product that’s competing with GitHub, GitPod, and other CDE vendors.
I’ve used some of the services within the AWS Code family before (Cloud9, CodePipeline, CodeCommit, CodeBuild, and CodeDeploy) which already allow you to do most of these things. So why release another service?
My guess is that Amazon has realized that the CDE space has been getting traction in recent years, as Gergely Orosz from the Pragmatic Engineer newsletter shows. While Amazon has its own CDE offering, Cloud9, it is not nearly as popular as the products from other vendors. This is likely because it lacks discoverability, isn’t documented well and is locked behind the AWS console.
Amazon seems to have learned from these mistakes: CodeCatalyst can be accessed through its own website. Apart from granting some IAM permissions, project administration is handled through its own portal. The niche that CodeCatalyst is likely trying to fill is providing development and collaboration tools that integrate tightly with the AWS ecosystem.
If you’re interested in how CodeCatalyst works under the hood, I did some digging in the remote development environments and CI/CD workflows that CodeCatalyst offers. It looks like CodeCatalyst utilizes the Code family under the hood, providing a unified interface. In addition, if you spin up a Dev Environment, we can call the ECS metadata service from within the environment, showing that our container is running on a Fargate task.
Some caveats
Now that we’ve explored what CodeCatalyst is, let’s move on to some caveats that you should be aware of before you decide to use CodeCatalyst in production.
First of all, I noticed that there is limited support to deploy CodeCatalyst components with Infrastructure as Code (IaC). Terraform can be used to create only a few resources, and CloudFormation does not support CodeCatalyst at all! As it’s not on the CloudFormation roadmap, it feels like CodeCatalyst is going to be a tough sell to teams that are currently already deploying their repositories and pipelines with CloudFormation, SAM, or CDK.
Secondly, users are managed within the CodeCatalyst portal. I believe that this is probably the biggest blocker for anyone looking to use CodeCatalyst in an enterprise setting. There is no support for external identity providers - only AWS builder accounts can be used to log in. In addition, there are no IAM roles that users can assume, because builder accounts are not true IAM entities.
Finally, the configuration of development environments is still quite limited. CodeCatalyst uses the devfile standard to create environments. However, it doesn’t support many of its features yet. For example, let’s say you have a web server application that is exposed on port 3000. According to the specification you should be able to expose that port and open it in your browser, but this isn’t possible yet in CodeCatalyst.
Nevertheless, once you have a CodeCatalyst accounts set up, the overall user experience is actually quite smooth - clearly much effort has gone into optimizing the user interface. Similarly, while the configuration options for dev environments are limited, creating one is extremely easy. You can launch a container from any branch, and the AWS Toolkit plugin in your IDE will handle the rest.
Conclusion
CodeCatalyst is in a bit of an awkward spot. It aims to serve developers who deploy their applications on AWS, yet it doesn’t offer AWS IAM Identity Center (AWS SSO) support. For most engineers, this will prevent them from using it in their workplace. In addition, the lack of IaC support means that while CodeCatalyst is able to present a unified interface for the AWS Code family, it doesn’t offer the same benefits that the services do individually.
Despite its shortcomings, I enjoyed working with CodeCatalyst, and would still encourage individual developers and small teams that use AWS to give it a try and see if they like it. If the CodeCatalyst team adds external IdP support, I can see it becoming the default managed choice for those who already use CodeCommit and CodePipeline for their projects.