Read on Twitter
As someone who spends a lot of time on cloud-native platforms, I've been tinkering with @HashiCorp's Waypoint today ( https://www.waypointproject.io/ ) and enjoying it.
It's a nice take on a build-deploy-release workflow that runs locally â sort of a Heroku-in-a-box.
Initial thoughts:
It's a nice take on a build-deploy-release workflow that runs locally â sort of a Heroku-in-a-box.
Initial thoughts:
Here's part of my Waypoint configuration for a quick app I built. At a glance, you can see here:
* the HashiCorp predilection for a plugins-centric model (`use "<plugin>"`)
* strong defaults mean I'm not doing a lot of config here
* clear build â deploy â release workflow
* the HashiCorp predilection for a plugins-centric model (`use "<plugin>"`)
* strong defaults mean I'm not doing a lot of config here
* clear build â deploy â release workflow
This lets me use buildpacks as image providers (zero effort for developers in making their own images), deploys those images to infrastructure I own (GKE in this case), and then releases them to make them available for use by users.
Deployments to cloud environments happen by contacting a local agent, the Waypoint server, which is already configured for you as a result of using an appropriate plugin, and acts on your behalf. You aren't typing `kubectl âŻ` to make something happen in GKE or AKS (or whatever).
Integration with CI tooling is handled by a set of standard parameters and environment variables. In general your CI tool will just be invoking the Waypoint server via the CLI, like you'd do as a human.
Some general thoughts:
* I think this is a great boon for individual developers or small teams.
* In enterprises or people who want to have organization-wide standards, there don't seem to be a lot of control or enforcement points, which could dissuade adoption in those places.
* I think this is a great boon for individual developers or small teams.
* In enterprises or people who want to have organization-wide standards, there don't seem to be a lot of control or enforcement points, which could dissuade adoption in those places.
* I suspect that using the Waypoint server as the unit of operational scaling is going to get complicated as more teams deploy more apps.
* Who gets to touch which server, and why? How should you partition your application portfolio to Waypoint servers?
* Who gets to touch which server, and why? How should you partition your application portfolio to Waypoint servers?
* For enterprises, there's a great opportunity to have an operational and analytical tooling layer: Can your engineering director see all the apps that are running? Can your ops director see their health? Can security see vulnerabilities implied by the existing deployed images?
All told, a great foray into this space; enthusiastic thumbs-up from me for small teams and individual developers.
Not yet ready for prime-time for enterprises (but @HashiCorp, if you want to talk about that, I'm available for consulting and I take payment in hoodies...
).
Not yet ready for prime-time for enterprises (but @HashiCorp, if you want to talk about that, I'm available for consulting and I take payment in hoodies...
).
