Waypoint

What Waypoint Isn’t.

  • a build system (like make, npm, maven etc.)
  • 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?

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

  • Build: This involves producing the binaries that contain the new code changes. Most programming languages have their own suite of build tools. Most compute runtimes have their own supported artifact formats like Docker/OCI images, ELF binaries, ZIP archives, platforms specific artifacts (like AWS Lambda Layers) and more. Any “workflow” tooling that aims to cater to the largest possible developer community needs to accommodate building code written in different languages and producing the preferred format of artifact, preferably using existing language specific build tools.
  • 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

--

--

--

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

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to Measure Subscriptions & Churn with Woopra

PostgreSQL DBA Basics — Setup Replication (Master — Slave Setup) on PostgreSQL 12

What, Why and Where do we use SQLite?

How to Evaluate Speech Technology Providers — 4 Key Considerations

Type safe JSON in Swift with SwiftyJSONModel

Using GitHub Actions To Deploy To AWS Beanstalk & S3

Respondent Engineering Overview (Sept 2017)

String Matching Algo: KMP

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.

More from Medium

Evolution of Distributed Systems

Nanit’s high-scale Video Analysis Pipeline

LitmusChaos at KubeCon EU 2022

HarperDB’s Journey on Verizon 5G Edge: Collapsing the stack in a 5G world