4 ms·
At Snowplow we are steadily rewriting 3 Ruby apps, one each into Go, JRuby (not really a rewrite) and Scala, choice driven by a few domain-specific factors. Go
by alexatkeplar 12y ago
At Snowplow we are steadily rewriting 3 Ruby apps, one each into Go, JRuby (not really a rewrite) and Scala, choice driven by a few domain-specific factors.
Go, JRuby and Scala all meet our new criteria for ops-friendliness, which are: 1) the app must be user-installable by a single wget from BinTray 2) the app must have 0 or 1 [the JVM] external dependencies 3) the app must not require any special environment to run in. From a packaging perspective, we're using `godep go build`, `warble` and `sbt assembly` respectively.
I've never worked with anything as install&run-hostile as Ruby.
- twic 12y agoRandom tangent: if you're getting the binaries with wget, how are you handling versions? Do you have a way to say "install version 0.0.72 on this machine"? Do you have a way to ask "what version is installed on this machine?". I've worked with (mostly, built!) deployment systems that used rsync, scp, wget, Maven, and apt-get, and i've come to be strongly in favour of systems which bake versioning in right at the bottom, in such a way that you can issue commands and make queries in terms of versions right there on the box, without having to refer to some external ledger. Both for convenience, and for the consistency of code and metadata.
- alexatkeplar 12y agoWe're basically following the HashiCorp way, where each binary is in a zipfile specifying its version, the binaries don't have version-numbers in them but all binaries respond to a --version usage flag. [1] We then unzip the binaries into versioned folders so we can have multiple versions on the same box. This works pretty neatly with our Ansible playbooks too. [2] [1] http://www.consul.io/downloads.html http://www.consul.io/downloads.html [2] https://github.com/snowplow/ansible-playbooks https://github.com/snowplow/ansible-playbooks