Welcome to this issue of the Tidy Cloud AWS newsletter!
Lately, I have used AWS Copilot to set up serverless container-based infrastructure for a project, and I have a few reflections on that experience. Also, some notes about some AWS approaches to hide CloudFormation.
How AWS tries to eliminate the pain of CloudFormation
It’s rare to find concrete examples in CloudFormation, Terraform, or Pulumi when reading AWS documentation or blog posts. AWS Quickstarts favor CloudFormation, while other places prefer ClickOps-style documentation or AWS CLI examples.
For some services or solution areas, you will instead find a designated command-line tool. There are various tools available for different solutions, such as Amplify CLI, AWS SAM, AWS Copilot, and eksctl.
Most of these command-line tools use CloudFormation under the hood, but it is for the most part, not glaringly visible.
Much as I dislike, AWS is very ClickOps-focused in their documentation and blogs. I also kind of think that plain CloudFormation is a pretty painful experience. It is a good thing to hide it and provide interfaces that still give some benefits of infrastructure-as-code (e.g. version controlled, automated and repeatable infrastructure set-up).
It is possible to build such tools, given that CloudFormation has an API to drive the infrastructure-as-code management. You do not have to run this through an explicit command-line tool like Terraform does. Both Pulumi and CloudFormation support building custom tools and interfaces through automation.
It’s hard to get a coherent story across services from AWS in this area, which is unfortunate. Making it easier to build customer-facing command-line tools would be beneficial for AWS.
Infrastructure as code light - AWS Copilot
Lately, I have been working on a project to help deploy the container-based solution in AWS. The solution uses Docker Compose to run multiple containers for different components locally. The developers have limited experience with AWS, and they are pretty comfortable with docker.
There has been support in docker compose to deploy to ECS (Elastic Container Service) for some years now, but this support is ending in November 2023. Also, the support has been limited in what kind of docker compose configuration is supported.
This is where a tool like AWS Copilot may come into play. It is an opinionated command-line tool to deploy container-based applications with the needed infrastructure, where most of the nitty-gritty details are (somewhat) hidden.
Given the limited experience with AWS and infrastructure-as-code tools from the project members, AWS Copilot looked like a good fit. From a configuration perspective, it is a bit similar to docker compose with YAML-based configuration, although the specific details in the configuration files differ.
It is a command-line tool that deploys container-based solutions to Elastic Container Service (ECS) and AppRunner, and also handles setting up network/VPC, load balancers, autoscaling, backend storage (DynamoDB, Aurora, S3), shared filesystem (EFS). There is also support to set up deployment pipelines for the services.
It is oriented towards deploying container-based web applications. If that is what you build, then AWS Copilot may be a suitable choice.
It is important to understand the overall architecture that AWS Copilot supports. If you try to go outside of that scope, you will end up with mixing in CloudFormation, either directly or generated via AWS CDK, plus you may need a lot of extra effort to work around the constraints set by AWS Copilot.
This can be tricky, since it is not always obvious what these constraints are until to actually run into them…
We have successfully created an environment for our project that has six different container types.. There were a couple of frustrations on the way, but overall the set-up itself was substantially quicker than what it would have been with plain CloudFormation, and probably with AWS CDK as well.
However, I see though that in a not too distant future, we will need to use some CloudFormation-based patching and add-ons, or convert it to a different solution. We are thinking about using AWS managed services to optimize our existing resources and tweak EFS settings.
For the time being, it is good enough, though. If we look at the good, the bad, and the ugly with AWS Copilot, there are a few items that come to mind: - The Good: - easy to get started - works well for some specific use cases - Documentation is ok for some scenarios - Similar level of complexity as docker compose - The Bad: - Can take a long time to deploy. It can be terribly slow. - Wrong config and issue can take a long time to recover from, several minutes and sometimes up to hours. - The Ugly: - Cannot import existing solutions - Not so easy to extend beyond basic capabilities - some updates require delete and setup again, rather than deploy an update
I will definitely consider using AWS Copilot for other projects. But also many projects for which it will not be suitable. The idea of a command-line tool that does most of the work for you is appealing and can inspire other tool builders.
You can find the contents of this bulletin and older ones, and more at Cloudgnosis.org. You will also find other useful articles around AWS automation and infrastructure-as-software.
Until next time,
/Erik