Automated systems configuration and provisioning is a hallmark of a comparatively “mature” DevOps environment today. Whether systems are physical or virtual, affordable/open source tools now exist that make configuration management a real possibility, even for smaller organizations.
Elimination of manual processes and custom scripting saves time, simplifies compliance and reduces the risk of data loss and catastrophic downtime. But it’s not always easy to make automation happen when the infrastructure stack has grown up around ad hoc processes, legacy tools and/or locked-in vendors.
That’s why Bitlancer created its Strings PaaS offering, despite the availability of open source tools like Puppet and Chef that enable DIY efforts. Bitlancer Strings is geared toward helping companies with traditional infrastructure and applications leverage cloud infrastructure effectively in whatever ways make sense.
“Designed with simplicity in mind,” Strings streamlines the jump to automation without introducing new hurdles. It supports a range of cloud infrastructure choices along with the freedom to deploy any modern or legacy language, framework or service.
Many PaaS solutions are built on Chef, due to its programmatic nature and resulting power and flexibility. We like Chef, we support it for our clients, and we appreciate the outstanding Chef community.
Bitlancer Strings, however, is built on top of the Puppet framework. Here’s why:
Puppet has historically targeted systems administrators and traditional systems management roles. Chef, on the other hand, maintains a language very close to pure Ruby and is targeted more towards developers.
There are many great reasons to use Chef or PaaS offerings based on Chef. But our consulting and support experience has repeatedly shown that the programmatic complexities of Chef are too demanding and stress-inducing for Operations staff in the great majority of organizations we’ve worked with over the years.
One reason is there are, like, 137 ways to implement Chef. This is part of why it has such a steep learning curve-even for developers. (The Berkshelf Way is one attempt to standardize Chef implementation practices.) There are many ways to use Puppet, too; but overall options are fewer, plus you don’t need to know Ruby. Thus the learning curve for Puppet is less steep.
The result of all Chef’s flexibility and open-endedness is frequently more human error, which defeats the purpose of using a more powerful tool that requires programming skills. It also leads to valuable Development resources being diverted to maintain automation, again defeating the purpose of automating configuration management in the first place.
That’s basically why we feel that Puppet is the best choice for our offering. In addition, Strings enhances the degree of insight and control over configurations, which some have pointed out as lacking in Puppet’s “model-driven” approach.
Strings isn’t for everybody, as I acknowledged recently. But for many organizations it makes it far easier to manage virtual infrastructure and automate existing standards and processes-while letting you chose the balance of control versus abstraction of your infrastructure that you want. (More on that in a future post.)
UPDATE: Bitlancer Strings is now open source. For more information, visit Strings Documentation on Github.