We already know that we don't need servers to run software, right? We're all about serverless and IaC here. But what about the software and supporting applications that we need to actually ship that software out of the door?
With the rise of AI driven, online generation code and AWS pushing it's browser-based Console experience to new levels - such as improving the UI and incorporating a VSCode-like experience directly into the Lambda Code tab - has there ever been a better time to move to developing 100% using just your browser?
Perhaps. But, what AWS has giveth it can also taketh, and it has. Some development-friendly tools, like the Cloud9, CodeCommit and CodeStar being axed by AWS without notice can indicate that this might not be a priority for them. Yes, they are sort-of being integrated into CodeCatalyst, which is more managed and should be easier to use, but to me it feels more focused on DevOps (or, maybe, Platform Engineering) teams and not for individual developers. AWS even states it's an "Integrated DevOps Service".
We will explore two of the available options, the native CodeCatalyst and it's popular rival GitHub, discuss their pros and cons so that you can choose the option (or combination of multiple options) that works best for you.
Quick side note about AWS Proton, which I feel like people sometimes compare to CodeCatalyst. While some features do seem similar, AWS Proton is really more of an infrastructure to deploy & run your code as a service on AWS - which might be exactly what you want - and less a suite for project development.
The AWS Way
Since it feels like AWS wants to pull you away from the Code<*> service pack, let's take a look at what they offer as an alternative. AWS CodeCatalyst is a fairly new service, about 2 years of age, and it offers a complete way to mange your codebase, build and deploy your applications (or just infrastructure) on one or more AWS accounts, and in one or more environments (i.e. dev, staging and production).
We should first take note that AWS treats this as an external service. just look at the URL - "codecatalyst.aws". This is because you connect your existing resources to it, such as GitHub repositories and AWS accounts to it. It's just managing them.
So the first thing you need to do is to create a new project in CodeCatalyst. We are all about serverless here, so lets use the serverless application blueprint for the sake of this demo.
You can configure some options for your selected project, like which language you want tom develop in. For more complicated blueprints that have databases, for example, you have more robust configuration options, like schemas or even the type of provisioned database you want to use.
!
Like I said, this is an external service to AWS, and when you link an AWS account to be used as a resource - all you will see in your AWS account is some information about it being used in a CodeCatalyst "space". All of the orchestration is done from the CodeCatalyst console.
I'm not sure why that is. Maybe AWS thinks that DevOps are afraid of the Console?
After your project is created, you can access your repositories, browse them, create pull requests and review them, merge, track branches and even - God forbid- clone them to your local code editor. All the usual things you might expect from a Git tracker. You can also setup remove development environments if you're into that kind of a thing. Strangely, here Cloud9 is still one of the options.
Now, after you have got your pull request approved and merged to your Main branch, it's time to build, test and deploy!
AWS CodeCatalyst supports drag-and-drop, editable workflow steps that you can arrange to look much like the ones you are probably familiar with from the Blue Ocean view in Jenkins.
It allows you to build, test, deploy (in stages) to your environments, test between deployments and even automate actions that are to be carried out in case of failures in any of the stages. The AWS integration here is remarkable and the level of fine-grained control offered is amazing.
For example, you can track per-commit changes to your deployments and rollback or sync specific deployment environments to other (successful) deployments. I mean, for Ops personnel - this is like learning magic spells.
The GitHub Way
Now lets take a look at what your life might look like if you choose GitHub - but still would like you deploy your infrastructure on AWS. When working in GitHub you can choose any number of targets for your deployment, but for an apples-to-apples comparison, we will choose AWS (and also because I am an AWS Serverless Builder).
I would wager that the vast majority of you know how a GitHub project looks like. This familiar interface packs all of the actions that you might want from a Git provider, but without any of the AWS-specific features of CodeCatalyst, like per-role management of access or pull request approval. That might be an upside or a downside for you, depending on how much you are integrated into AWS and how comfortable you are with managing your collaborator's Roles.
The GitHub code editor (immediately accessible by changing the ".com" to ".dev" in your browser URL, in case you didn't know) is miles, leagues ahead of what AWS has to offer. It has a full, working version of vscode.dev, which is pretty much the same as github.dev those days, I hear. It will allow you to install supported extensions, do some code completion, run your tests - and even has a shell! You can't install Copilot extension for that sweet AI-assisted programming, though.
However, this is the best experience for a web-based IDE that I've seen, and is the closest to an actual IDE running on your machine locally.
There is also an option for remote and collaboration development environments, just like the AWS CodeCatalyst, called Codespaces.
As for the Ops side of things, GitHub has Actions and Security tabs to help with that. The Security tab includes built-in scanners. which are ready-to-use tools you can run to check your repository for potential risks. It's a great feature because it simplifies security and puts it front and center. Be honest, though - how often do you think about security when you're in the middle of developing?
As for the Actions, these are runnable, YAML-based workflows that you can trigger on events. There isn't a fancy UI interface for creating or editing them, but GitHub does provide a simple text editor with syntax highlighting and some starter templates. The runtime interface is somewhat similar to what you get in CodeCatalyst.
You can build, test, and deploy with GitHub Actions as well, but here you're missing the seamless AWS integration. You'll need to manage your deployments, stages, and AWS secrets for your accounts manually (there's a "Secrets" tab for that in GitHub). You'll also have to handle any failed deployments, either by coding in the logic or addressing them manually.
Final Thoughts
If you are building your project on AWS, and do not have a full-fledged DevOps group, you can't go wrong with using CodeCatalyst for your deployments. The integration and the level of abstraction they achieved is something special, and other cloud providers should really take notes here.
With that being said, it just can't compare to GitHub when it comes to coding. GitHub's VSCode web offer is so much more advanced and can even accommodate small to medium sized teams, if you ask me.
Luckily, you can connect your GitHub project as a source repository to AWS CodeCatalyst and enjoy the best of both worlds. You can even use some of the built-in security scanners in GitHub and some of the pre-made Actions, while CodeCatalyst will manage your AWS account resources, environments and deployments. It's a setup that, in my opinion, is hard to beat, and it should serve you well whether you're building a small project or launching a startup on AWS.
As always, thanks and love to my beautiful wife and talented DevOps Architect Yafit Tupman, who helps me navigate the strange and scary world of modern build platforms.
Top comments (0)