4 ms·
I work on Ubicloud. REPL, testing, a few key high quality libraries. In turn: The REPL: lets you have unified development and operation. Makes it easy to rec
by fdr 3y ago
I work on Ubicloud.
REPL, testing, a few key high quality libraries.
In turn:
The REPL: lets you have unified development and operation. Makes it easy to record and review methodology when taking administrative action.
Testing: both made more necessary by the dynamic typing of Ruby, but more importantly, without disturbing the program under test much you can inject any input, any fault, nearly anywhere. In this way you can accrete invariants guarding against a large class of bugs encountered in production into the test suite, a form of retained learning.
The libraries: Sequel, Roda, Rodauth, part of the Jeremy Evans universe. They're very good by any standard, not even as confined to the Ruby world. The maintenance level on those is something I aspire to, but have never been able to duplicate. I did copy the 100% line (and later, branch) coverage project practice from this, though, in Citus Cloud and later projects, and it seems like a good thing, though not for the reasons people might anticipate.
An anti-requirement: control planes often have fairly lax performance needs relative to operation value. A few crucial loops, like monitoring, may indicate something with more efficient machine code. But mostly it's a fancy SSH client with quite a few tests, and some carefully designed concurrency patterns. Of the above factors, I'd say the REPL is the most dispositive for why I tolerate the performance and parallelism ramifications of Ruby, though, they all add something to my decision to use it for this.
This design theory is the fourth in a progression for me, though there are other clades by now. Heroku Postgres was the first, Citus Cloud was the second, Crunchy Bridge is the third, this is the fourth.
- throwawaymaths 3y agoI'd have picked elixir... Much better concurrency and distribution support. SSH is built into the (erlang) standard lib, really fantastic support for templating via EEx (if you're using libvirt, e.g.). Easy to deploy as an on-metal or containerized platform using releases. Ruby deployment dependency management can be tricky unless you have a way to isolate from the host (containers e.g.) but that's not the best for being a hypervisor.
- fdr 3y agoI've considered at various points (but not with deep seriousness I admit), typescript, julia, scala, swift. You might notice all of these have a REPL in common. Elixir might be a reasonable alternative, but not one I exercised here. In areas I wanted to take risk, I had some other stuff going on.
- throwawaymaths 3y agouh just fyi: Elixir's repl is the most powerful of all of them, as it gives you incredible introspection. With care you can attach a repl to a remote running program (in prod, if you take appropriate precautions) and be able to diagnose the running state of your program quite effectively -- like you can examine the tail call state of any given process.
- vidarh 3y ago> With care you can attach a repl to a remote running program That's good, but it's also table stakes. Drb (in the standard library) lets you remote access any Ruby object, so if you want a remote REPL, it's is simply a case of injecting a Drb server. Hence e.g. pry-remote which remotes the Pry REPL, but you can also then remote any already existing object in any running application.
- throwawaymaths 3y agoI mean the equivalent is also possible out of the box Erlang VM. Without having to install sidecar servers or monkey patching objects with potentially spooky action at a distance. Erlang, from day 1, was designed to be logged in to remotely. No other system is remotely close to the sophistication that Erlang (and as a result elixir) has in this regard
- vidarh 3y agoThere are no "sidecar servers" or monkey patching or "potentially spooky action at a distance" involved in what I described.
- vidarh 3y agoThey're not a hypervisor, though. They provide a control plane that uses one via ssh. Choosing to deploy outside containers at this point in time should in my opinion be a last resort almost irrespective of what you're deploying; if the surface you interact with the host is so complex you can't grant access with granularity to a container without it becoming problematic (or at the very least via a tool providing similar levels of isolation using namespaces), chances are you have a bigger problem. There are some exceptions, but they're few.