As someone who spends a lot of time on cloud-native platforms, I& #39;ve been tinkering with @HashiCorp& #39;s Waypoint today ( https://www.waypointproject.io/ )">https://www.waypointproject.io/">... and enjoying it.
It& #39;s a nice take on a build-deploy-release workflow that runs locally â sort of a Heroku-in-a-box.
https://abs.twimg.com/emoji/v2/... draggable="false" alt="đ§”" title="Thread" aria-label="Emoji: Thread"> Initial thoughts:
It& #39;s a nice take on a build-deploy-release workflow that runs locally â sort of a Heroku-in-a-box.
Here& #39;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& #39;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& #39;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& #39;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& #39;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& #39;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& #39;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& #39;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& #39;m available for consulting and I take payment in hoodies...
https://abs.twimg.com/emoji/v2/... draggable="false" alt="đ" title="Grinsendes Gesicht mit lĂ€chelnden Augen" aria-label="Emoji: Grinsendes Gesicht mit lĂ€chelnden Augen">).
Not yet ready for prime-time for enterprises (but @HashiCorp, if you want to talk about that, I& #39;m available for consulting and I take payment in hoodies...