It definitely won't disappear but we are probably past peak Ruby.
It has simply been out-niched, I can't easily think of a 'Ruby is best for this' use case today.
Python hitching a ride on the data science gravy train might be the first nail - remember the days when your scientist or mathematician or engineer buddy would ask whether they should learn Ruby or Python, and you actually had to think.
When the rise and fall of the Ruby empire is written, Chef will probably have a part in both stages.
Ruby is more a victim there, but some of my most frustrating encounters with Ruby have involved Chef. Sticking to Ruby earned Chef favour from developers but Puppet's custom DSL choice was the right one. Using Ruby forces hard dependencies where everything ends up being dependent on 'windows' and 'yum' and 'apt'.
A major problem with the first era of config management / DevOps was too much code that does too little.
Instead of telling Chef via an abstraction to enable the apache service, you have to write:
service 'apache2' do service_name apache_service_name case node['platform_family'] when 'rhel' if node['platform_version'].to_f < 7.0 && node['apache']['version'] != '2.4' restart_command "/sbin/service #{apache_service_name} restart && sleep 1" reload_command "/sbin/service #{apache_service_name} graceful && sleep 1" end when 'debian' provider Chef::Provider::Service::Debian when 'arch' service_name apache_service_name end supports [:start,:restart,:reload,:status] action [:enable,:start] only_if "#{node['apache']['binary']} -t", environment: { 'APACHE_LOG_DIR' => node['apache']['log_dir'] }, timeout: 10 end
And this is one of the better written actively maintained cookbooks.
Then there is the annoyingly common convention where every time there is a new release of the underlying package, you have to update a hash in the Chef code and release a new version of the Chef cookbook, which of course is delayed - looking at you Elasticsearch.
It runs 'yum install elasticsearch' which installs a signed package from the repository. But the first law of config management is 'support everything and let the lowest common denominator dictate design'. So supporting whichever crappy OS / release that does not have native packages always takes priority over writing something that just works and will continue to just work.
e.g. The Chef yum provider can't handle obsolete package versions. If you tell Chef to install somepackage-x.y.1, and that version has been obsoleted by somepackage-x.y.2, somepackage-x.y.2 gets installed while Chef thinks it installed somepackage-x.y.1.
The next time you run Chef with exactly the same config, it will fail because of the implicit downgrade.
Which brings us to the Third law of config management: Idempotence in config management is like world peace for the U.N. - promising an idealized unachievable goal confers nobility and thus failing at it all the time is ok.
Ruby isn't the culprit here but it is the enabler. Manual dependency management means no one configures versioned cookbook dependencies. So your infrastructure is code defined, but what that code is is a spur of the moment thing as Chef fetches the freshest stuff off supermarket.chef.io. Bringing us to the second law 'it mostly works' is good enough.
In the world of clustered distributed multi-node services, the much praised Kitchen test framework can't test multi node deployments. Have a two-node Elasticsearch cluster - forget writing tests, and add a bunch of timeout hacks to handle asynchronous builds. Let's have a long existential discussion over whether multi-node testing is really needed and continue to write tests for whether "package 'ap
Slashdot Mirror
When the rise and fall of the Ruby empire is written, Chef will probably have a part in both stages. Ruby is more a victim there, but some of my most frustrating encounters with Ruby have involved Chef. Sticking to Ruby earned Chef favour from developers but Puppet's custom DSL choice was the right one. Using Ruby forces hard dependencies where everything ends up being dependent on 'windows' and 'yum' and 'apt'.
A major problem with the first era of config management / DevOps was too much code that does too little. Instead of telling Chef via an abstraction to enable the apache service, you have to write:
And this is one of the better written actively maintained cookbooks.
Then there is the annoyingly common convention where every time there is a new release of the underlying package, you have to update a hash in the Chef code and release a new version of the Chef cookbook, which of course is delayed - looking at you Elasticsearch.
It runs 'yum install elasticsearch' which installs a signed package from the repository. But the first law of config management is 'support everything and let the lowest common denominator dictate design'. So supporting whichever crappy OS / release that does not have native packages always takes priority over writing something that just works and will continue to just work.
e.g. The Chef yum provider can't handle obsolete package versions. If you tell Chef to install somepackage-x.y.1, and that version has been obsoleted by somepackage-x.y.2, somepackage-x.y.2 gets installed while Chef thinks it installed somepackage-x.y.1. The next time you run Chef with exactly the same config, it will fail because of the implicit downgrade.
Which brings us to the Third law of config management: Idempotence in config management is like world peace for the U.N. - promising an idealized unachievable goal confers nobility and thus failing at it all the time is ok.
Ruby isn't the culprit here but it is the enabler. Manual dependency management means no one configures versioned cookbook dependencies. So your infrastructure is code defined, but what that code is is a spur of the moment thing as Chef fetches the freshest stuff off supermarket.chef.io. Bringing us to the second law 'it mostly works' is good enough.
In the world of clustered distributed multi-node services, the much praised Kitchen test framework can't test multi node deployments. Have a two-node Elasticsearch cluster - forget writing tests, and add a bunch of timeout hacks to handle asynchronous builds. Let's have a long existential discussion over whether multi-node testing is really needed and continue to write tests for whether "package 'ap