What (other) kinds of apps will Waypoint support?

I didn’t see anything in the roadmap about this, but it seems like it’s just meant for your standard stateless, scaleable web service. I don’t know what this would look like, but are there thoughts around other kinds of apps? Workers that don’t have an LB? Jobs that terminate? Cron jobs? Lambdas?

Workloads that follow the build, deploy, release workflow fit within the design target for Waypoint. Yet not all types of apps will work with the capabilities in the 0.1.x release.

Stateless web apps were the first target, which you can see from the Kubernetes plugin currently only directly support a Deployment resource (rather than a StatefulSet) or the Docker plugin not supporting Docker Volumes. Reference this non-web workloads thread for some discussion.

For functions, there is a community plugin for Google Cloud Functions and Mitchell mentioned that he wanted a Lambda plugin on Containers from the Couch, so those app types should be relevant too.

There may be some Waypoint capabilities that do not apply to certain app types or platforms. For example, Google Cloud Functions does not support the Waypoint Entrypoint currently because of the lack of sidecar support. With the relatively new AWS Lambda Extensions API it’s likely possible to adapt the Entrypoint capabilities to work with AWS Lambda.

Templates, hooks and plugins should all provide Waypoint a rich set of capability and extensibility to fit many different types of apps.

Please let us know about the app types that don’t quite fit yet and what you would like to be able to do.

1 Like

Thanks for the context @jbayer.

Our primary non-web workload at Segment would probably be workers that consume from some queue, rather than being invoked by an external process (RPC-style). A distant third would be event-driven, like Lambdas or other FaaS.

To be clear, my concern about the roadmap is less about what specific platforms are supported in the future: if all else fails, we could potentially build our own plugins in-house.

My concern is around app types fitting into Waypoint’s mental model. For example, with workers, what does a deployment vs a release look like? For web apps, this is currently just traffic shifting (i.e. changing the LB or DNS). But for workers, it’s less clear. If the pre-release deployments consume from the same queue as the release deployment, they’re really not pre-release :slight_smile:

I can think of ways to map Waypoint’s current web app model onto workers (have separate pre-release and release queues to read from), but then I’m not really working with Waypoint, I’m working against it.

Hey Nick!

We always envisioned Waypoint would support non-web workloads so this is something on our radar. Your feedback here is very helpful though.

The idea behind deploy vs. release is that you can plug in different release management styles where it makes sense. For non-web workloads as you proposed here, maybe it makes sense to just not have a real release step (combined deploy/release) which is basically how Waypoint operates today.

I don’t think Waypoint is too far from being able to support non-web workloads. We have some biases in various places of expecting a URL, an HTTP listener, a port, etc. But they aren’t critical to Waypoint itself so we just have to work to remove those biases.

1 Like

Phenomenal, looking forward to it.