3 ms·

I always love HashiCorp products! But... This feels like Otto v2 to me, and it seems like it hasn't actually solved the underlying problem with Otto: that it

I always love HashiCorp products! But... This feels like Otto v2 to me, and it seems like it hasn't actually solved the underlying problem with Otto: that it was simpler to just use and learn the underlying tools instead of a very specific DSL that transformed into them. If I have to look up how to use Waypoint to create Dockerfiles/Kubernetes manifests anyway, why not just learn how to use Dockerfiles and Kubernetes manifests? I'm pretty excited by Boundary, but I don't really see the point of this.

mitchellh 6y ago
Hello! Compared to Otto there are some major simplifications we made: * Waypoint does not own/manage any infrastructure, Otto attempted to manage the infrastructure. With Waypoint, you have to bring this yourself. * Waypoint has pluggable components for build/deploy/release. Otto focused in on our tools (mainly because we had to manage the infra, point 1). This makes it much easier to slide into existing ecosystems. On your question of abstractions: this same argument can be made for Terraform so I think my answer there would be the same but for applications. The idea is that Waypoint can give you a consistent workflow to use different tools, and additional value add features such as deployment URLs, exec, logs, etc. that work across platforms.
- Veraticus 6y ago
  Thanks for the response Mitchell, and I love your work! You make an excellent point re: abstractions and consistent workflow. But for Terraform, you still need to know the underlying provider; to use Terraform in AWS I have to know what AWS resources I'm looking for, Azure resources in Azure, and so on. But Terraform adds value through abstraction. I don't need to learn the specific AWS/Azure calls; Terraform does it for me. Terraform provides a sane, consistent syntax. And it encourages a declarative workflow that the cloud providers themselves don't do very well/at all. I don't necessarily see Waypoint providing that same value. You need to know the underlying provider to know what you want to do with it, but the abstraction seems to make it more difficult to use that provider, not easier. But I am a devops professional, not an application developer, so I might just be the wrong market for it. Either way, congratulations on the release, and I'm excited to see where Waypoint goes from here.
throwaway894345 6y ago
> why not just learn how to use Dockerfiles and Kubernetes manifests? The problem I see with the entire Docker ecosystem is that the Docker/Dockerfile build system is fundamentally terrible, principally because the cache system assumes a linear dependency tree and build graphs are, well, graphs. To get reasonable build performance, you need a tool that understands this. This is something Nix gets right, and it even lets you build Docker images without the Docker/Dockerfile build system. I'd also like to see something that takes it a step further--build the docker image AND a set of kubernetes manifests that reference that docker image (a "kubernetes app package" if you will) such that you have a single artifact that represents your application that a "kubernetes package manager" can deploy (the current crop of k8s package managers altogether punt on the contents of docker images). I understand that this is a very different way of thinking about Kubernetes and Docker builds than what we practice today, but I'd really like to see this in practice or hear some debate about its merits (or lackthereof).
- jacques_chester 6y ago
  Broadly, I agree, and I've written a lot about it in the past[0]. OCI images are not quite as bad as they used to be. Linear caching is no longer baked directly into the image format, instead it's an assumption that has been carried forward by Dockerfiles and docker build. Docker folks are working on at least the docker build part in buildkit[1]. In the meantime though I prefer Cloud Native Buildpacks, which are able to perform layer rebasing as an update operation. Disclosure: I have previously worked on buildpacks technology for Pivotal, now VMware. [0] https://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POUaadcvK3ZNT9QEGDZhPk/edit https://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POU... [1] https://github.com/moby/buildkit https://github.com/moby/buildkit
- nur0n 6y ago
  I believe BuildKit solves the dependency graph problem. Docker has shipped with it since 18.09. It is opt-in for now so you have to use e.g. `DOCKER_BUILDKIT=1 docker build ...`. https://github.com/moby/buildkit https://github.com/moby/buildkit
  - 6y ago

mitchellh 6y ago

Hello! Compared to Otto there are some major simplifications we made: * Waypoint does not own/manage any infrastructure, Otto attempted to manage the infrastructure. With Waypoint, you have to bring this yourself. * Waypoint has pluggable components for build/deploy/release. Otto focused in on our tools (mainly because we had to manage the infra, point 1). This makes it much easier to slide into existing ecosystems. On your question of abstractions: this same argument can be made for Terraform so I think my answer there would be the same but for applications. The idea is that Waypoint can give you a consistent workflow to use different tools, and additional value add features such as deployment URLs, exec, logs, etc. that work across platforms.

Veraticus 6y ago
Thanks for the response Mitchell, and I love your work! You make an excellent point re: abstractions and consistent workflow. But for Terraform, you still need to know the underlying provider; to use Terraform in AWS I have to know what AWS resources I'm looking for, Azure resources in Azure, and so on. But Terraform adds value through abstraction. I don't need to learn the specific AWS/Azure calls; Terraform does it for me. Terraform provides a sane, consistent syntax. And it encourages a declarative workflow that the cloud providers themselves don't do very well/at all. I don't necessarily see Waypoint providing that same value. You need to know the underlying provider to know what you want to do with it, but the abstraction seems to make it more difficult to use that provider, not easier. But I am a devops professional, not an application developer, so I might just be the wrong market for it. Either way, congratulations on the release, and I'm excited to see where Waypoint goes from here.

throwaway894345 6y ago

> why not just learn how to use Dockerfiles and Kubernetes manifests? The problem I see with the entire Docker ecosystem is that the Docker/Dockerfile build system is fundamentally terrible, principally because the cache system assumes a linear dependency tree and build graphs are, well, graphs. To get reasonable build performance, you need a tool that understands this. This is something Nix gets right, and it even lets you build Docker images without the Docker/Dockerfile build system. I'd also like to see something that takes it a step further--build the docker image AND a set of kubernetes manifests that reference that docker image (a "kubernetes app package" if you will) such that you have a single artifact that represents your application that a "kubernetes package manager" can deploy (the current crop of k8s package managers altogether punt on the contents of docker images). I understand that this is a very different way of thinking about Kubernetes and Docker builds than what we practice today, but I'd really like to see this in practice or hear some debate about its merits (or lackthereof).

jacques_chester 6y ago
Broadly, I agree, and I've written a lot about it in the past[0]. OCI images are not quite as bad as they used to be. Linear caching is no longer baked directly into the image format, instead it's an assumption that has been carried forward by Dockerfiles and docker build. Docker folks are working on at least the docker build part in buildkit[1]. In the meantime though I prefer Cloud Native Buildpacks, which are able to perform layer rebasing as an update operation. Disclosure: I have previously worked on buildpacks technology for Pivotal, now VMware. [0] https://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POUaadcvK3ZNT9QEGDZhPk/edit https://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POU... [1] https://github.com/moby/buildkit https://github.com/moby/buildkit
nur0n 6y ago
I believe BuildKit solves the dependency graph problem. Docker has shipped with it since 18.09. It is opt-in for now so you have to use e.g. `DOCKER_BUILDKIT=1 docker build ...`. https://github.com/moby/buildkit https://github.com/moby/buildkit
- 6y ago