Objects are not completely foreign to Puppet, but the concept of them and their application with regard to the node is vastly different from Chef. The framework that Chef provides you with for building new configuration management objects will cause you to use traditional Ruby programming tools more so than with Puppet, and grant you the insight they do as well. There is a clear distinction between the two frameworks in the level of access to core Ruby features, as noted through gem support in Chef. Attention to execution order is key, regardless of your choice of configuration management system. Together with design characteristics, these subtleties in both systems make for a new and refreshing navigational experience.
For anyone coming from a Puppet background, one of the first things you’ll learn about Chef is that it emphasizes programming rather than Puppet’s administrative mindset. In other words, mastering Chef takes a commitment to thinking differently. You’ll want to become intimately familiar, first and foremost, with the concept of Ohai and the Chef node object to advance as quickly as possible, and you’ll need to adjust to a series of quirks. Often, your problems will manifest themselves as programmatic rather than administrative, but troubleshooting them will always come down to a matter of using the ingenuity and accumulation of knowledge you already have. Take everything you remember from Puppet, and use it as an overview of concepts to apply to Chef, as a general rule of thumb. Most importantly, never forget, unlike in Puppet where nearly everything is processed on the server and sent to the client to apply locally, EVERYTHING in Chef is client side.
When first starting out at a company and building the infrastructure out from the ground up, you’re inevitably going to need to start the install process for the first systems in an inefficient manner. The first few systems will always end up being launched from ISOs, be it by way of CD, DVD, or USB, until you advance your technology and automation stack to the next level. When your initial bottleneck is one person with one piece of physical media (CD, DVD, USB) at one server, you’re in a situation that doesn’t scale very well. The more ideal target area for scalability is one where a single person can spawn multiple new systems and manage multiple systems simultaneously.
Historically, operating systems in the UNIX and UNIX-like family have not only been incredibly stable, but have also been trailblazers in technology. Some have been more renowned for using what’s become tried and true– as well as being slow moving targets that are easier to support. Those in the latter category have at times had a fear of change when seemingly too sudden or divergent from their current standing, but change isn’t always bad. Sometimes it’s just simply that: change, and in the case of SysV Init, the change has been a long time coming.