Hacker News Reader

Hacker News

Comment by kohidavez | Hacker News Reader

Full thread

kohidavez

Hi!! I’m a developer on AWS Copilot! We’d love your feedback!

Homebrew: brew install aws/tap/copilot-cli

Docs: https://aws.github.io/copilot-cli/

Feedback & Requests: https://github.com/aws/copilot-cli/issues/new

View on HN

The tool looks promising (and of course it is just a couple weeks after I finished rebuilding our ECS CloudFormation from the ground up... lost count of how many times AWS has done that).

My question is a bit less targeted at this specifically and more about how AWS approaches all of these various tools.

We have probably 95% of our infrastructure in CloudFormation one way or another (either directly or with something like SAM).

As more of these tools come out there is going to be crossover (and there already is with Amplify and SAM for example).

There will also be questions about how we pass exports around so we don't have to hard code endpoints that were created by another tool. (Say a Lambda created by SAM needs to be called by a service in ECS).

So my question is a couple things:

1. Does AWS have a requirement or a goal in mind of how to always ensure we can pass these exports around ideally in a consistent way (this and any future tools that may come out)? I worry about having too many different ways that things work from a code standpoint that we just introduce more bugs into our system.

2. Is the thought that a given repo should ideally be using a single tool (I ask since I see you mention S3 buckets, and databases as a coming soon) and not mixing things? Like not using this plus some native CloudFormation for example?

3. Finally, I would love to see a... "deployment tools" page or something from AWS. A page that is a table of every deployment tool for columns and every service for rows and can easily see at a glance what tool can do which services. Right now I am considering if I need to build a page like this for internal use so a developer can easily look and see what fits their use case the best. But a page managed by AWS would be great.

Ultimately what I struggle a bit with tools like this, are what does it get me long term over just using straight CloudFormation where my only limitation is CloudFormation lagging behind.

Not from AWS, but what it sounds like you're asking for is better cohesion and more consistency between AWS products and services?

I've been an AWS customer for over 10 years, and have been asking them for this (on behalf of my enterprise customers). I'm always told "they're working on getting better" but they never really do.

Cloud formation features are inconsistent across products. Documentation is formatted and structured differently depending on the tool. The AWS web console is an ever changing grab-bag of new and old. Some products integrate well, other products feel like you're using an abandoned hack-week prototype.

Part of the reason that AWS is so great is how much it can do, and I think that's been made possible by the apparent level of autonomy the teams have. However, it's at the expense of the customer's experience.

I totally get that, and its for sure the reason I both love and hate AWS. They release things at a near breakneck speed.

I guess its more, if I had to choose one area of AWS that I wish there was a but more consistency it would be their deployment tools. It really just comes down to, when I start something it's almost an agonizing choice of what do I use since I am worried that I could get stuck in a box.

I don't know what the answer is, that is just my view of all of these tools.

I'm actually in the middle of moving some apps to ECS/Fargate. Here are a few of our requirements, it'd be great if you could share if copilot meets or does not meet them.

1. Production and Staging in separate accounts 2. A new environment provisioned per github PR with setup/teardown - ideally within the same VPC/Subnet ranges, so they can utilise shared databases 3. Secrets stored in Secrets Manager or Parameter Store 4. Blue/Green deploys for production with a manual cutover step (manual step optional) 5. Deployment of 2 services (app, background tasks) from the same dockerfile/commit

Awesome - first best of luck on your transition!

1 Yeap! We can do that. 2 hmmm we don’t support this out of the box - but I’d love to know what you expect out of this. All your services spun up and infra? 3. Check! 4. No blue green deployments yet :( 5. Yea! We support this via a pipeline.

Number 2 would attract an enormous amount of developers. Can you consider doing an example of such a workflow with copilot and pipelines, including provisioning a LB and/or tweaking an existing one to get per-branch subdomains with https?

As far as expectations for 2 above, in my experience, teams really love having a completely separate environment per PR. Gitlab has done this on top of Kubernetes using a dynamic domain such as <truncated-branch-name>-review-app.domain.com. This gives QA and stakeholders the ability to easily review/signoff on changes prior to going live and not getting bottlenecked by a small number of QA/UAT environments. This becomes particularly helpful as the engineering team scales up.

For 2 - we would already have the time infra spun up via something like terraform. So we’d need to “adopt” the VPC/subnets from copilot. The actual connection details would be stored as env vars, but would need a “on create” hook to create the database for the environment.

Hi - I'm interested in using this to manage deployments on top of a Fargate cluster managed by Terraform. Is copilot able to import such a cluster or otherwise manage tasks in an existing cluster?

Not yet but we’re tracking resource importing here: https://github.com/aws/copilot-cli/issues/740

Thanks for your work on this!

Wondering if it’s possible to use this with our own self-managed ASG of ECS Host instances. I trolled through the GH repo quick, but couldn’t find any definitive answer.

Not yet - we’ve started out with Fargate but we have a roadmap item to support EC2 and resource imports:

https://github.com/aws/copilot-cli/issues/1094

We currently use Beanstalk, which seems to share a bit with this - in terms of offering a CLI they abstracts a lot of AWS specifics, deploying to ECS, the application/environment split, the deploy command fitting in a CD pipeline. Can you share a bit about how your team thinks about Beanstalk and this? We’re quite unhappy with Beanstalk from the perspective of trying to define it with Cloudformation for reproducibility and I’ve been unsure what we should be looking at next.

Remove the emojis please

This. I almost stopped reading the docs after the first screenshot. Really, it gives a childish feel to the tool. I don't want my tools to have rocket or bear emojis. It makes me feel like the tool was written by teenagers. Of course that's is not the case, but that is the feeling that I have when I see this.

I understand. It’s only on the help page :)

It’s written by some of the brightest people I’m AWS - so Don’t worry about that.

Counter-opinion: I think they do a good job of visually distinguishing the section headers in the help output. As long as they're used structurally like that, I think they're great.

It's a pity you used "copilot", because that name is already used for Red Hat's admin product.

Do you mean cockpit?

Oops yes. But there is also Performance Co-Pilot (pcp)

fogcreek/glitch then stand-alone https://www.copilot.com/

Do you know if EKS will ever be supported?

Reply on news.ycombinator.com