Waypoint

What Waypoint Isn’t.

It probably helps to begin this post by spelling out what Waypoint isn’t.

  • a package manager (like helm, pip etc.)
  • a CI system (like Jenkins, GitHub Actions etc.)
  • an Artifact registry (like Artifactory, Docker Registry etc.)
  • a runtime format (like OCI images, Docker containers, buildpacks, native binaries, archives etc.)
  • a cluster orchestrator or platform (like Kubernetes, EC2, EKS etc.)

So What Is Waypoint?

The marketing pitch is that Waypoint is a tool that aims to vastly simplify build and deployment of services. With a series of CLI commands and a declarative means of specifying deployment configurations, users can get their applications up and running on any cloud platform or OSS platform like Kubernetes with minimal effort, without requiring the developer to write custom configuration. As the docs state:

Reimagining the “Build, Test, Deploy and Release” Workflow

I use the term “build and release workflow” and not CI/CD, because not every organization has embraced CI/CD wholesale, even if all organizations do “build and release” software at varying cadences.

  • Artifact Storage: The artifacts built need to be persisted somewhere. While theoretically any object store can be repurposed for artifact storage, custom artifact registries offer myriad features like encryption at rest, vulnerability scanning, high availability, garbage collection of older artifacts, artifact caching and more. It’s pointless for any new tool to try to reinvent the wheel here, since there already exist well-established products that address this particular problem.
  • Deploy: The new artifacts need to be deployed to the production (or test/staging) environment to begin serving new traffic. This often involves “installing” the artifacts on the hosts and starting the appropriate binaries. In my career, I’ve worked with deployment tooling that has run the gamut from simple git based deployments (Heroku) to labyrinthine shell scripts to “agentless”, ssh-based remote execution tools like Fabric/Capistrano/Ansible, to systems that run agents on hosts that “watch” for new deployments to (post-2015) features of cluster orchestrators like Nomad or Kubernetes. It’d be futile for a new tool to reinvent platform/runtime/cloud provider specific deployment mechanisms, since different platforms and cloud providers already provide their own opinionated APIs, custom tooling and workflows to enable deployment of code.
  • Release: I’ve always believed that deploys shouldn’t quite be conflated with the “release” of code. Releasing code encompasses traffic management, updating DNS or load balancers, gradual draining of existing services, canary traffic management, blue/green deploys and more. Again, most platforms have opinionated APIs, control planes and paradigms to achieve this.

Conclusion

What currently makes deploying code non-trivial isn’t the lack of APIs or systems that address individual problems particularly well. It’s just how much effort it takes to glue all these components together into something workable.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Cindy Sridharan

Cindy Sridharan

@copyconstruct on Twitter. views expressed on this blog are solely mine, not those of present or past employers.