Ruby is a dynamic, object-oriented language in which everything is an object and almost everything is a method call. Integers, nil, classes themselves — all objects with methods. That uniformity, combined with blocks as a first-class part of the calling convention and an open class model that lets code define and redefine behaviour at runtime, is what makes Ruby unusually good at expressing domain-specific languages that read like configuration rather than like code.
That property is why Ruby matters to infrastructure engineers well beyond web development. A Chef recipe is Ruby. A Vagrantfile is Ruby. Puppet's custom facts, functions and providers are Ruby. Fluentd plugins, Logstash's Ruby filter, Homebrew formulae, Metasploit modules, Jekyll plugins, Capistrano deployment tasks and countless internal automation tools are Ruby. Engineers hit the language sideways — a Chef custom resource that needs a loop, a Vagrantfile that must read a YAML inventory — and discover that the DSL they were using was ordinary Ruby the whole time.
The language itself is worth the time. Blocks, procs and lambdas make iteration and resource management concise; the Enumerable module gives one consistent vocabulary across arrays, hashes, ranges and custom collections; modules provide mixins instead of multiple inheritance; and method_missing, define_method and the singleton class open the metaprogramming door that the DSLs walk through. Around it sits a mature toolchain — RubyGems and Bundler for dependencies, Rake for task automation, RSpec and Minitest for testing, and ERB for the templating that generates a large share of the world's configuration files.
Why this skill matters now
Ruby is no longer the default choice for a new web application, and pretending otherwise would be dishonest. What has not changed is the amount of critical infrastructure automation written in it. Chef estates, Vagrant-based development environments, Puppet extension code, Fluentd log pipelines and years of internal Rake tooling are all still running, still being extended and still needing engineers who can read them.
That produces a specific and durable demand: not Ruby application developers, but infrastructure and platform engineers who can maintain, debug and extend Ruby automation. It is the reason a configuration management team stalls — the recipe works until it needs a conditional, the custom resource needs a helper module, the Vagrantfile needs to iterate over an inventory, and nobody on the team can write Ruby beyond copying the surrounding lines.
There is a second reason the skill pays. Reading the source of the tool you operate is the fastest way to stop guessing. When a Chef resource behaves unexpectedly or a Fluentd plugin drops records, an engineer who can open the gem and follow the code resolves it in an hour instead of escalating it. Ruby is small enough to learn properly in a week and it unlocks a large amount of infrastructure that would otherwise stay opaque.