Documentation of over-arching design decisions

[aidansteele]

Hi,

I love the tool and love that it's being developed out in the open. As a person who is keen to contribute, here a couple of things holding me back, where it would be useful to have some clarity.

1. The first question I had was: why v2? Why didn't the team choose to continue iterating on v1? I assume there were probably good reasons for this, but without some docs explaining why, I'd be reluctant to propose features that were in v1 but not v2 - maybe they're not there for a reason!

The same goes for:

2. Why this in addition to the Fargate CLI? To be honest, I had never even heard of it until I saw it mentioned in an issue elsewhere here. And now I wonder: why wasn't that enhanced instead? Again, probably a good reason, but without knowing the why I feel like I don't really understand the project's vision.

3. Why are templates generated client-side rather than server-side like the AWS::Serverless-2016-10-31 transform? I can guess at why, but an explanation would help clarify what's driving the team's decisions.

4. What features have the team currently explicitly decided against? I imagine there's an intention to avoid so much feature creep that the tool loses the simplicity that is a key selling point. Having a list of "we thought about this, but have decided against it for now because X" would be so useful.

5. Some philosophical ones, like: is using GitHub Actions on the table? @clareliguori has done some 💯 work on the AWS-provided actions, so AWS clearly isn't ignoring them - but this project is currently using CodeBuild for CI checks. When I submit a PR I get a ✔️ / ╳, but I can't view what failed due to not having access to the CodeBuild logs.

Thanks for considering these! Any light you can shed would help build confidence in my ability to make meaningful contributions to the project.

[kohidave]

I want to answer all of these, but i'll just take a stab at #5 tonight, and will get to the rest tomorrow.

I've actually been using this tool for GH Actions for a while. It's a little cumbersome right now, but my workflow file looks like the one pasted below. I'd love to make this trivial to add as a CI step.

on: push
jobs:
  deploy:
    name: Deploy Changes to ECS
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-west-2
    - name: Download ECS CLI V2
      run: |
        wget https://ecs-cli-v2-release.s3.amazonaws.com/ecs-preview-linux-v0.0.6
        mv ./ecs-preview-linux-v0.0.6 ./ecs-preview
        chmod +x ecs-preview
    - name: ECS CLI V2 Deploy To Test
      run: |
        ./ecs-preview app deploy --env test

[bwarren2]

Bump! I would be interested in the other answers here.

[kohidave]

Hello! Ok, let me take a stab at answering some of these

1. The first question I had was: why v2? Why didn't the team choose to continue iterating on v1? I assume there were probably good reasons for this, but without some docs explaining why, I'd be reluctant to propose features that were in v1 but not v2 - maybe they're not there for a reason!

I can answer this now a little easier - so as you may have noticed, we've renamed from ecs-cli v2 to copilot. The reason being that we've decided to solve different problem than v1. V1 was good at letting you take a compose file, and run it on ECS. That's helpful - but we've found that ECS provides the most value when it works in concert with other AWS tools like loadbalancers, service discovery, auto-scaling, etc. We also wanted to focus at a higher level on the entire developer workflow - CI/CD, operations, setting up and deploying additional infrastructure. We decided to start from scratch to try and meet those aims :D

At the same time, earlier this year we started work with Docker to support deploying to ECS directly from a Docker Compose file - from the compose CLI. We felt this was a much better experience for customers - to not have to use and learn a new CLI just for AWS when they just wanted to quickly see their app on AWS. I (who worked quite a bit on Copilot 🎉) also worked with our friends at Docker to help design the ECS/AWS infrastructure - so we were able to bring a lot of the lessons from Copilot to the compose integration. The compose integration is awesome for a lot of folks. We see both sets of tools, Copilot and Compose as serving different uses. Compose is amazing at taking an existing compose file, and seeing that app running on AWS - but it's a little more difficult to take advantage of other AWS resources. Copilot is really great at integrating with AWS services - do you want to add a database to your service without having to worry about updating your service role and figuring out when and how to deploy it in relationship to your service? Want to set up multiple environments across different accounts and regions, then set up a pipeline to deploy to them? Copilot is really awesome at those types of problems 🌈

2. Why this in addition to the Fargate CLI? To be honest, I had never even heard of it until I saw it mentioned in an issue elsewhere here. And now I wonder: why wasn't that enhanced instead? Again, probably a good reason, but without knowing the why I feel like I don't really understand the project's vision.

The Fargate CLI is deprecated now - but we're folding its features into Copilot. Our task run feature, for example, was directly inspired from the Fargate CLI. We chose not to build ontop of the Fargate CLI because we want to keep the door open to other AWS technologies, and with Copilot, we're able to do that a little easier :D We also want to - at some point, support EC2.

Fargate CLI was still kind of at a lower level of abstraction than Copilot. It's really focused on what you can do with Fargate - whereas Copilot is really interested on your app as a whole.

3. Why are templates generated client-side rather than server-side like the AWS::Serverless-2016-10-31 transform? I can guess at why, but an explanation would help clarify what's driving the team's decisions.

So we thought about this a lot. There are a couple of reasons we decided to go this route. Let me rattle off a few. The first is, we know that containers customers tend to have a wider set of options and knobs they want to toggle. We tried to hit a good balance with Copilot - but we didn't want people to feel "locked in" if they needed to change a setting that we hid behind our transform. Having the full CloudFormation makes that easier. If you want to move on from Copilot tomorrow, you have the full CF templates for your services available and can tweak it to your heart's content.

We were also aware of cool features like CDK's import - which lets customers import existing CloudFormation stacks into the CDK. We feel like the CDK is a great graduation path for customers who discover they want more control. This would be a much more cumbersome path if we modeled our patterns as transforms.

Copilot also does some pretty cool stuff which involves template introspection. For example, we'll inject your addon infrastructure values directly into your service as environment variables. This is a rad feature that we couldn't really do with transforms.

We're certainly learning and listening to customers so it's possible that, if in the future folks just want dead simple cloudformation resources, we could totally see building those. In some regards Copilot is a bit of a test of our assumptions about what customers want and need in terms of abstraction on top of their container app development - so we're definitely taking the learnings from this and piping them into other parts of the ECS ecosystem :D

4. What features have the team currently explicitly decided against? I imagine there's an intention to avoid so much feature creep that the tool loses the simplicity that is a key selling point. Having a list of "we thought about this, but have decided against it for now because X" would be so useful.

EC2 comes to mind. I think we could have built a really nice experience ontop of EC2 instances - but I think there's a difference between building an "abstraction" around ECS / Fargate and building an "illusion" around ECS / EC2. What I mean by that is that if we created the illusion of a fully hands off EC2 experience, customers might be surprised that they are expected to be in charge of patching and security maintenance of those instances. This isn't something that Copilot, a CLI can really automate for people (realistically). We're still trying to figure out a good way to expose EC2 to folks - but we definitely see Fargate as the future.

We haven't really decided against this - but one thing I want to mention is one of our design philosophies. So one thing we want to do is make setting up and running the most common architectures dead simple and that comes at the expense of full flexibility. We're working on and constantly thinking about how can we expose more attributes of all the myriad infrastructure to folks without overwhelming them at the same time. This balance is hard - so we decided to be comfortable saying "I'm sorry - Copilot can't do that right now." to some features ("ah - you want to set up a service with multiple target groups? I understand - but I don't think Copilot is the tool for you right now" - as an example). We're working on exposing more flexibility - and we have some cool plans going forward, but we're focusing on the 90% use-cases first.

5. Some philosophical ones, like: is using GitHub Actions on the table? @clareliguori has done some 💯 work on the AWS-provided actions, so AWS clearly isn't ignoring them - but this project is currently using CodeBuild for CI checks. When I submit a PR I get a ✔️ / ╳, but I can't view what failed due to not having access to the CodeBuild logs.

Yea! We have some folks working on official Copilot GitHub actions right now! I spent a lot of my life in the deploy and CI/CD part of AWS so I'm super passionate about this! We're super interested in other source providers as well (we <3 GitHub, but not everyone has their source on GH). That'll be easier now with the advent of things like CodeStar Connections.

Another fun area we're looking into is Terraform support!

Anyway, I hope that answers some of your questions. I'm sorry I dropped the ball on responding to this months ago, but in some ways it's good since I can talk openly about some of the products that hadn't been released earlier this year that were shaping some of our decisions.

[ryanvade]

Out of curiosity, would the pipeline commands be at all integrated into GitHub Actions? Would be a bit more difficult but possibly worth it?

This tool is looking great and I think my team will be using it for our next project. :heart: But we only use GitHub Actions for our CI/CD so that may cause some issues.

EDIT: Also, how about other package registries such as GHCR?

[kohidave]

Hey hey @ryanvade ! You can write GitHub actions which use the copilot deploy --env {env} commands to automate your releases - you don't have to use the built in Pipelines support. Just out of curiosity, what other kinds of integrations were you thinking of for GH actions? We're eager to support it better, and would love your input! As for GHCR, I haven't looked too deeply into it yet, so let us research it and get back to you!

[ryanvade]

Hey hey @ryanvade ! You can write GitHub actions which use the copilot deploy --env {env} commands to automate your releases - you don't have to use the built in Pipelines support. Just out of curiosity, what other kinds of integrations were you thinking of for GH actions? We're eager to support it better, and would love your input! As for GHCR, I haven't looked too deeply into it yet, so let us research it and get back to you!

Thanks for the quick response! 😎

One thing that comes to mind is updating an ECS service with the "force-deployment" flag enabled but no other changes to the task definition effectively "restarting" the service (not quite the same I know, another instance and all that). We have had to "restart" one service after another is updated kind of thing. The aws-actions/amazon-ecs-render-task-definition and aws-actions/amazon-ecs-deploy-task-definition are doing that for us right now. Could probably keep doing that as a last resort.

I see that there is the copilot svc deploy command so that you don't have to update all of the services when only one has changed. Perhaps an action to help with monorepo deployments like that? (Detect services that have changed and only deploy those). Could probably just do it manually with the copilot svc deploy command.

We have used both ECR and GitHub Container Registry, but tend to prefer GHCR so that we don't have to leave GitHub. 😄

[frimik]

Terraform support could be huge. Being able to drop a module in, define its inputs, and having copilot able to use its outputs...? Curious to see what you're thinking of doing with it ...

[huanjani]

Hello, @ryanvade! Just in case you missed it, the flag to force deployments was added in Copilot's 1.10.0 release: https://github.com/aws/copilot-cli/releases/tag/v1.10.0. Thanks for the feedback!

[ryanvade]

Thanks for letting me know @huanjani

[github-actions[bot]]

This issue is stale because it has been open 60 days with no response activity. Remove the stale label, add a comment, or this will be closed in 14 days.

[github-actions[bot]]

This issue is closed due to inactivity. Feel free to reopen the issue if you have any further questions!