When I first saw your, “Puppet vs. BMC Bladelogic” doc here:
I was flattered (and a little confused) that you’d taken the time to write a deep-dive paper with all the reasons why Puppet is better than BladeLogic until I actually read it, when I discovered it was full of FUD and almost-hostile rhetoric. Here’s a quick phrase that jumped out at me:
“[BladeLogic is] a Frankenstein-like patchwork of technologies”
“Frankenstein-like”? Is that really how you’re going to describe BladeLogic? Not only is it unfair, it’s totally inaccurate (more about that in a minute).
One of the reasons these comments are disappointing is that in the BladeLogic group here at BMC, we really like Puppet. We think it’s great to see a team of smart people building a free and open configuration management system. Being able to describe infrastructure as code is ideal for some organizations, and that’s why we don’t only like Puppet - we like Chef too. If a customer wants to write a Puppet module to install an RPM or build a configuration file, or wants to write a Chef LWRP to add or remove domains from a DNS server, they should be able to do that.
But that functionality is just one aspect of IT automation - that one step in the middle where an object gets created or modified. True automation is about the entire lifecycle of IT - up to and including planning, scheduling, coordination and orchestration, auditing and compliance, and so on. All of those things combine to represent the overarching business process of IT automation. Configuration management tools like Puppet and Chef are just a small piece of that puzzle, and if our customers want to use any of those tools to handle a chunk of that, they should be able to and we should work with them.
I did want to address a couple of your points directly, though, because I felt like they were either misleading or just plain wrong:
- “Frankenstein-like patchwork of technologies” - BladeLogic Server Automation is a standalone product. We also have other products such as BladeLogic Database Automation that are independent solutions, targeted at separate use cases, with unique capabilities. For example, our Database Automation product natively knows how to apply patches on Oracle RAC clusters, and neither Puppet nor BSA knows how to do that without extensive scripting. There’s nothing “Frankenstein” about this - we have different products for different use cases. Also - haven’t you guys acquired some products? I seem to remember that Mcollective was acquired back in 2010, and Cloudsmith’s acquisition was announced in 2013. Does that make Puppet a “Frankenstein” too?
- Our community - it’s true that Puppet has more users than BSA, but Puppet is also free, which amps up the user base some, and BSA is primarily a solution for mid- to large enterprises. While we may not have Meetup groups, we have user groups around the world, a vibrant community site, and a user conference in Orlando this year.
- Content - It’s great that you’ve got 2000 modules and I do like that you can auto-download content from the Forge. But do you know how many of those modules are for Weblogic? 3. SAP? 0. Oracle RAC? 0. Exchange? 0. Sharepoint? 0. (Though there are 61 modules for nginx). We’ve got something similar called Zipkits for BladeLogic and our CLM cloud management platform - the difference is that ours are written by our engineers for a range of the enterprise applications our customers want to deploy and manage using BladeLogic.
I’m also disappointed by the FUD around our going private:
“In 2013, Bain Capital acquired BMC Software, opening up questions regarding the future of some of its product lines, including BladeLogic. Given that it’s a legacy product to begin with, will BladeLogic be around tomorrow?”
If by “legacy product”, you mean, “Product that is already written”, the answer to your question is “Yes, we will be around tomorrow”. We have a huge install base, happy customers, and ongoing development. Asking if we’re going to be around tomorrow is like asking if Puppet is going to be around tomorrow - since Cisco or VMware or anyone else could buy Puppet, that is very much an open question.
As I said earlier, though, we like Puppet, and we want you guys to succeed. Having open source, high-quality configuration management toolkits like Puppet and Chef around is better for BladeLogic and better for our customers.
This is why, in BladeLogic 8.5, we’ve added the ability to run Puppet and Chef automation code directly from our software. It’s the best of all worlds - if customers really like the Puppet language, they can write manifests, modules, recipes, and cookbooks and we’ll happily run them (Video to come shortly, once I'm back from some travels).
Here’s an example - let’s say an organization wants to stage the rollout of an application patch across their 10,000 server farm during a maintenance window. With BladeLogic 8.5, the patch itself could be built as a Puppet module, a Chef recipe, or as a BladeLogic BLpackage - whichever way the engineer managing the process feels most comfortable. Then the engineer can prepare the job, pre-stage the patch globally, handle any required approvals, and have it execute automatically as servers enter appropriate maintenance windows (not to mention making sure that any new servers automatically get the patch), all through BladeLogic.
Puppet alone can’t do any of that, which is why I find the competitive comparison so odd. If you want to say that the Puppet DSL is a better way to execute configuration changes than BladeLogic’s, there’s a discussion we can have (though I’ll confess to being personally partial to Chef’s approach).
I think Puppet is a cool product. But artificially conflating two very different solutions through FUD and falsehoods is lame.
PS - In the story, "Frankenstein" is the doctor, not the monster he creates.