[antoncohen]

This is great. I'm glad a good company is backing an open source project like this. I've built abstractions like this at two companies, and I hope one day I can stop writing my own. Some comments:

I see "promotion" on the roadmap, so this is probably in the works. But the current "Workspaces" each have their own build. I really want to be able to promote the same artifact from one environment (staging) to another (production). I'd also like to be able to choose the artifact build/version to deploy, not just what happens to be in my local repo.

The concept of multiple environments also brings up the need to vary things by environment. App config (env vars) are obvious. But also settings like number of replicas or auto scaling min/max (auto scaling is also required).

The biggest thing most of the tools in the space lack, like all the ones that try to copy the docker-compose.yml syntax, is standardized reusable app settings. Imagine I have two common types of app, "API services" and "background workers". They have common settings, like maybe they all default to using /healthz for health checks and auto-scaling at 70% CPU. Then within each group they vary, "API services" use internal load balancers and "background workers" don't.

I don't want every individual "API service" app to have to say "my health check endpoint is /healthz" and "I run on port 8080 and need a load balancer". Those are the defaults, and if the app uses the defaults it shouldn't need to be configured. But at the same time I want the app to be able to override the defaults. Within a well standardized environment 90% of app infra settings (not env vars) are the same, or can use the same template (like the image is docker.example.com/svc/{app_name}:{build_id}). I want to be able to reuse the settings.

[mitchellh]

Happy to say that everything you brought up has also been brought up internally prior to release and is on our roadmap.

(1) Promotion - yes, exactly as you described.

(2) Shared app config - kind of already there in the API but not exposed yet.

(3) Inherited settings - little further out, but some concept of module or parent Waypoint config to inherit from is something we'd like to do. We'd also like to be able to allow people to /force/ this by platform, i.e. "ALL K8S apps must have these annotations." And so on.

This is all very possible with Waypoint and I expect everything you mentioned will exist by this time next year.

[asim]

I think what you're looking for is micro => https://github.com/micro/micro or the hosted version https://m3o.com. Our goal is basically to abstract the entirety of this away to a common experience from the developers viewpoint.

[antoncohen]

Possibly, thanks, I'll look into it. One key is that I'm not looking for an abstraction, I'm looking to provide an abstraction. I run infrastructure teams that provide the infrastructure as a product to other engineering teams, including build and deployment systems. So I need a system that is flexible enough that I can create the abstraction I want to provide. Most of the tools in this space either abstract away everything, in an opinionated way that I don't agree with. Or they abstract away too little, so I would have to write a heavy abstraction over the abstraction. Waypoint, with its plugin system and if the HCL syntax is expanded to support reusable templates/modules, may provide a good building block for me.

[eysi]

Garden (https://docs.garden.io/basics/how-garden-works and https://garden.io/) might actually be a good fit. Some of our current users (I'm affiliated) actually use Garden for just the use case you're describing.

But to your point, abstractions are hard, and we've tried to design Garden such that it takes care of the _what_ and _when_ but allows the users to decide the _how_.

[asim]

If you are a builder of platforms then I agree. You are like me except building it for your own audience. In which case waypoint is quite useful for tying together a number of the pieces.