Trying to understand the boundaries envisioned for Waypoint

Hi, I’ve only just started to learn about Waypoint, but I’m already extremely impressed.

I’ve lately been using Copilot, AWS’s new CLI for ECS+Fargate, and I see similarities in terms of the workflows and UX that both tools are aiming towards. So, curious, I checked out the Waypoint tutorial Deploy Waypoint to AWS Elastic Container Service and I liked what I saw there.

The workflow and UX described in the tutorial look great, but it did make me curious about the intended boundaries for Waypoint. Specifically: if Waypoint can, and does, create the ECS cluster, ECS service, ECS task definition, AWS security group, ALB target group, ALB listener, etc, as part of deployment — why does it require that an ECR repository already exist prior to starting the deployment? I mean, Waypoint can clearly create resources on the fly, as needed. And it can also clearly detect existing resources and use them. So why not have it create an ECR repository as the very first step, if one doesn’t already exist?

Similarly, near the end of the tutorial I noticed this:

NOTE : The destroy command will not delete container images in the registry or the ECS cluster itself. Visit the ECR console to manually delete the entire registry or individual container images.

This is also puzzling to me — why would Waypoint not delete the ECS cluster that it created?

I suspect this occurred to me specifically because I’ve been using Copilot recently, and Copilot will create everything needed to deploy, including a VPC, ECR repository, etc — and it will also delete everything that it created, when instructed to do so.

To be clear, I definitely understand that Waypoint is new and early and much of this might be planned and simply not yet implemented. If that’s the case, that’s totally cool. But it might also be due to the “boundaries” of Waypoint’s use cases being envisioned as not including the creation, configuration, and deletion of the target environment.

See, Copilot is meant to cover the entire development and operations workflow, from creating environments, deploying apps and services to those environments, and deleting those apps, services, and environments.

But I imagine that since Hashicorp already offers Terraform for creating, configuring, and deleting environments, perhaps Waypoint’s scope is meant to complement Terraform’s, rather than overlap it.

That’d make total sense to me; I’m just looking for some guidance/clarification on this, so as to refine my mental model of the team’s vision for Waypoint.

Thank you!

1 Like

Yes, great question. I’m also interested in the relationship between terraform and waypoint as it relates to creating target infrastructure for ecs/fargate. I like how waypoint can optionally create the infrastructure, but also allows it to be configured after creating it with something like terraform. We have a large number of terraform templates for different types of fargate architectures and a tool to wrangle them. It would be nice to have a lighter-weight waypoint plugin that simply creates task definitions and deploys them to ECS services. To do that, it would only need to be configured with the cluster, service, and task definition details. Maybe I’ll write a plugin for that.

Thanks again for waypoint! I’m super excited about it.