I built one of these too -- and using ansible and salt has sorta taught me how it actually wasn't that bad of an idea. I got exactly what I wanted and knew exactly what it was doing.
Like, if you're coming from it as a developer, it's not hard to write this sorta thing, and you understand it -- where as with ansible and salt you have to wade through the docs to figure out how things are done and then some things just don't really work that great all the time.
That being said, I wouldn't write another one, but IMO, if it's fun, why not?
Hi all, I'm one of the designers of the sup project.
Interestingly, we only looked at Ansible, or later heard of salt, after we already wrote the first version of sup. Later our friends told us it reminded them of Ansible. We believe sup is much simpler, because its more DIY from the perspective of the user.
It's written in Go and currently the master cloc's in at 890 lines of code. Sup is just a small utility and personally I view it as complete, other than any refinements that come through its life. Thanks to Go, it's also pretty nice that the sup binary doesn't require the install of any external runtime.
When designing it, our high-level goals were to have a very fast and simple deployment tool that anyone on our development team (including frontend devs), could deploy their applications to our network. It's been working really well for us for over a year now.
To be honest, I've still never tried Ansible or salt, and I'm sure there is a lot of capabilities they have, but, whatever they are, we've been fine without them. For example, sup doesn't have 1000s of community playbooks, but you can reference local programs/scripts that are piped and executed remotely on a network - we use this often for deploying docker containers.
Finally here's something I love, and maybe possible with Ansible (I don't see why not):
Or Salt? All that and simple YAML flavor by default. I mean, nice work, but I don't see any holes in the ops space that this fills, and there's already a proliferation of tools solving the same problem. I like that the MIT license has fewer words than Apache 2.0, but otherwise I see nothing to buy into here.
Scanning this site I feel déjà vu like I am looking at an incipient, less mature version of Salt with fewer features.
Sup is simpler, much faster and doesn't have any dependencies (since it's written in Golang). It doesn't come with any Playbooks and doesn't have large community. Writing Supfile is much more DYI thing where you exactly know what happens, when and why.
From Devops perspective, it's a step back. From developer's perspective, it's a very handy tool without any learning curve.
Like, if you're coming from it as a developer, it's not hard to write this sorta thing, and you understand it -- where as with ansible and salt you have to wade through the docs to figure out how things are done and then some things just don't really work that great all the time.
That being said, I wouldn't write another one, but IMO, if it's fun, why not?