Some of you may have noticed earlier this week that CodeCommit started preventing the creation of new repositories suddenly and seemingly without warning. You were not alone – including yours truly. There was some speculation last week that something was afoot when a very prescriptive blog suddenly appeared on AWS blogs providing guidance on how to migrate from CodeCommit to another git-provider. That blog can be found here. This is also linked at the top of the product page too:
While this was surprising (given the lack of formal communication – very much out of character for AWS with such changes), this was not the only shock announcement. Several other services are also in the firing line. One of those services happens to be Cloud9. This is also unavailable to new customers with a banner on its product page too:
Why This Happened
The official line is that AWS is starting to wind down these and other services which are affecting new customers – existing customers already utilising them are unaffected.
While official reasoning has not yet been formally announced, reading between the lines is that this is due to lack of uptake of these services at scale. To be fair, there are few customers I have worked with who use either of these services in daily activities, however some do. Additionally, both services are heavily utilised in the AWS Workshops, solution accelerators, training, and even prescriptive guidance. While existing customers are not officially affected, it is expected that they will be in the future.
What Is CodeCommit and Cloud9
Before we talk about the sunsetting of CodeCommit, we must first understand what it does.
CodeCommit
The AWS CodeCommit service is a version control (git) repository for hosting code for applications and infrastructure. The service provides a private Git repository and forms a crucial piece for automation in the software and infrastructure as code as part of Continuous Integration (CI). With continuous integration, developers frequently commit to a shared repository using a version control system such as Git. While many disliked the use of CodeCommit over 3rd-party alternatives, with the installation of the CodeCommit helper – it mostly behaved like any other standard Git integration tool using standard Git commands.
Benefits of CodeCommit
A benefit of CodeCommit is that it is deeply ingrained in many AWS Continuous Delivery and Continuous Deployment (CD) services while also being guard-railed through AWS access control mechanisms such as Identity Access Management (IAM) and the ability to take advantage of Role-Based Access Control (RBAC) and identity policies. As a cloud-native tool, it formed a part of the AWS “Code Family” of tools. It also kept all code inside AWS and prevented customers from entering additional 3rd-party commercial agreements.
Problem With Sunsetting CodeCommit
The CodeCommit service is integrated into many of AWS’ solution accelerators as the default code repository for automation such as Landing Zone Accelerator (LZA). Crucially, these accelerators are not yet equipped to support integration with 3rd-party Git repository solutions for configuration management. There is now a scramble to develop and build 3rd-party integration into these tools which caught many internal product development teams off-guard. It also forces organisations into 3rd-party commercial agreements they may not have had to use previously.
Additionally, a large number of AWS Workshops and training material made heavy use of CodeCommit with step-by-step prescriptive guidance for students to follow a bouncing ball. Without this prescriptive guidance, many Workshops will be difficult for students to follow (especially those new to AWS and other DevOps focused tooling). This creates a barrier to entry for many students to gain crucial hands-on tools experience.
What Is Continuous Integration, Continuous Delivery and Continuous Deployment (CI/CD)?
To understand the solutions and alternatives to CodeCommit, we must first understand what CI/CD actually is beyond the buzzwords.
Continuous Integration (CI)
Continuous integration is a DevOps software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run. Continuous integration most often refers to the build or integration stage of the software release process and entails both an automation component (for example a CI or build service) and a cultural component (for example learning to integrate frequently).
Continuous Delivery and Continuous Deployment (CD)
Continuous delivery is a software development practice where code changes are automatically prepared for a release to production. A pillar of modern application development, continuous delivery expands upon continuous integration by deploying all code changes to a testing environment and/or a production environment after the build stage.
With continuous delivery, every code change is built, tested, and then pushed to a non-production testing or staging environment. The difference between continuous delivery and continuous deployment is the presence of a manual approval to update to production. With continuous deployment, production happens automatically without explicit approval. Below we can see the overall picture of a CI/CD process (including the manual approval step associated with Continuous Delivery).
Solutions and Alternatives to CodeCommit
The AWS native CI/CD tools for CodeBuild, CodeDeploy and CodePipeline can integrate with various coverage of 3rd-party solutions including GitHub, GitLab, Bitbucket and Azure DevOps as well as other tools such as Jenkins. The GitHub Importer allows migration of other repositories into GitHub repositories. CodeBuild allows integration into GitHub and Bitbucket using access tokens and OAuth authentication methods. CodePipeline supports GitHub connections into GitHub hosted repositories also and leverages webhooks for allowing pipelines to be automatically run when changes occur in the remote repository.
Workshops Experience
In my own personal experience, I simply stopped following the workshops explicit instructions and followed the guidance provided above along with some trial and error to get these integrations working with an existing GitHub repository I had created for each workshop. This meant some time was spent solving problems instead of running through the lab. That said, this form of learning is the best as you learn to solve real-world problems and develop sharp troubleshooting skills in the process. It just is not for everyone.
Development Environments – Why They Are Important
Have you ever heard of the phrase “it worked fine on my machine” – indicating that something differed between two entities? Many challenges are faced when developers use their own local computers for testing. Most of these challenges revolve around inconsistent tooling, environments, and software dependencies. It is extremely important to ensure that development is consistent as part of an end-to-end software development and infrastructure as code lifecycle.
This is where the initial idea of containers originated to allow consistency and portability across environments. A development environment ensures that we remove inconsistencies by isolating dependencies and creating consistent environments for development of code.
What Is Cloud9?
AWS Cloud9 is a cloud-based integrated development environment (IDE) that lets you write, run, and debug your code with just a browser. It includes a code editor, debugger, and terminal. Cloud9 comes prepackaged with essential tools for popular programming languages, including JavaScript, Python, PHP, and more, so you do not need to install files or configure your development machine to start new projects. AWS Cloud9 comes with a terminal that includes sudo privileges to the managed Amazon EC2 instance that is hosting your development environment and a pre-authenticated AWS Command Line Interface. This makes it easy for you to quickly run commands and directly access AWS services.
Cloud9 Development Environments
The beauty of Cloud9 was the ability to develop without the need to build containers or have any local tooling installed – leaving the local machine or device untouched. Each environment could be made persistent or treated as ephemeral. Anyone with the correct access rights, a web browser and console access could use it from any device. Everyone using it had the same experience and it saved money by turning off the EC2 instances automatically after a configurable timeout period. You could also preview web pages right in the console without the need to leave the environment and it used the console login as the user rights to carry out tasks. This allowed tight control of what developers could do on the AWS environment using existing IAM permissions.
Problem With Sunsetting Cloud9
Without the availability of Cloud9, there is a need for students to seek alternative solutions to how they handle development environments. They can no longer follow workshops and training guides or training content that uses Cloud9 development environments. Changes to Docker licensing mean that using Docker containers may be a barrier to creating consistent development environments for local testing and release lifecycle management.
Solutions to Cloud9 Development Environments
There are some alternative solutions including Vagrant and Dev Containers which can be integrated into tools such as VSCode however these solutions have a prerequisite knowledge of containers for students to first understand. Docker is of course also an option however there are also commercial considerations for that in organisations as well. End-User computing solutions that keep everything contained inside AWS include using Virtual Desktops such as Workspaces or Application Streaming using AppStream. There are currently no AWS-guided workshops for setting up a development environment. This guidance will need to come from AWS Partners and community contributors.
Conclusion
We as a community need to all pitch in to fill the void these tools had. This puts the onus on the community to find solutions that we were not required previously to solve as AWS had these wonderful solutions for us. In addition, 3rd-party and AWS’ own Skill Builder courses will need to be extensively updated for any labs being developed. Even AWS’ own product development teams are now scrambling to develop guidance and alternatives to fill the gaps for critical solutions and accelerators, while many affected customers are desperately seeking help.
The AWS teams who painstakingly wrote step-by-step instructions and took screenshots for use in Workshops will also need to update the large library in addition to prescriptive guidance documentation that utilised these tools. To all those affected by these changes – we are here to help. It is now up to the community to come together and embrace the changes, adapt to the challenges, and develop solutions to help.
