Live data from Hacker News

Show HN: Dotmesh – A git-like CLI for application states

dotmesh.com

1–10 of 39 posts

Re: Show HN: Dotmesh – A git-like CLI for application states

#3

Congrats Luke and team. I'm curious, what did you learn at ClusterHQ with Flocker that made you want to start dotmesh?

ClusterHQ was a fantastic learning experience. I'm proud of what we achieved and the many strong relationships that were built in the team.

Ultimately the reason that ClusterHQ failed, I think, was that we believed we had product-market fit before we really did, and we started scaling too soon.

When we started, it wasn't possible to connect storage to containers at all, and so we had to put a lot of work into making that possible. And by the time we'd got Flocker working reliably across AWS, GCE, OpenStack & a dozen or so storage vendors, we'd been commoditized by Kubernetes.

Our premature scaling then made it harder to adapt as fast as we needed to. Many lessons learned!

We're focusing on a rigorous approach to finding product-market fit, my colleague Alice has written more about this here: https://dotmesh.com/blog/dotmesh-hypotheses/

Re: Show HN: Dotmesh – A git-like CLI for application states

#5
It seems like a good idea in theory but i'm not so sure it'd work in many environments in practice. If i understand it correctly, you're storing all the state such as files but there is state that is tied to that specific machine (ie. machine fqdn, machine-specifc filepaths) and you wouldn't want to apply that state on another machine. I guess you could do some data wrangling and .stateignore that stuff but it would require quite the effort on a large application that spans many components and many teams.

On a very small app, i can see the utility of dotmesh.

Re: Show HN: Dotmesh – A git-like CLI for application states

#6

It seems like a good idea in theory but i'm not so sure it'd work in many environments in practice. If i understand it correctly, you're storing all the state such as files but there is state that is tied to that specific machine (ie. machine fqdn, machine-specifc filepaths) and you wouldn't want to apply that state on another machine. I guess you could do some data wrangling and .stateignore that stuff but it would…

Hey! Yes, it's hard to capture the state of VMs.

This is where the Docker and Kubernetes integration comes into play -- if your app is captured entirely in Kubernetes manifests, the only thing left to capture (apart from the declarative Kube manifests, which should already be in version control) is the state that exists in Kubernetes Persistent Volumes. Dotmesh provides a Kubernetes Persistent Volume driver which provides Dotmesh StorageClass PVs and a Dynamic Provisioner, meaning that you really can capture the entire state of your app with Dotmesh... as long as you're deploying it with Kubernetes.

Code and infrastructure are already under control thanks to version control and terraform, ansible etc -- this completes the picture.

Give it a go: https://dotmesh.com/try-dotmesh/ and please leave more feedback here or in our Slack! (linked to in the footer at the bottom of dotmesh.com)

Re: Show HN: Dotmesh – A git-like CLI for application states

#7
post #4

It might be better to just call it version control for application states, rather than saying a "git-like CLI" for application states. When I hear "git-like CLI" I interpret that as "hard to use" and "confusing"

Interesting feedback, thanks. I agree that the git CLI is confusing, unfortunately it's the best thing we've got that a huge number of developers are familiar with for exploring a state tree with branches and commits.

If you're interested, we've described some important ways that dotmesh is _different_ to git here: https://docs.dotmesh.com/faq/#how-does-dotmesh-differ-from-g...

Post reply on HN