Skip navigation

Server Automation

2 Posts authored by: Matthew Zito
Share:|

To Luke Kanies and the Puppet gang,

 

When I first saw your, “Puppet vs. BMC Bladelogic” doc here:

 

https://puppetlabs.com/sites/default/files/Puppet_Enterprise_vs_BladeLogic.pdf

 

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.

 

Thanks,

Matthew Zito

Architect

@matthewzito

 

PS - In the story, "Frankenstein" is the doctor, not the monster he creates.

Share:|

It's just before the start of the second day at ChefConf here in San Francisco, where BMC is a Gold sponsor, and it's been a busy 24+ hours.   We've got a booth, we're giving a talk on "Orchestration in Meatspace" later today, and we've got a team of people soaking up the interesting talks and having some great conversations with folks from the Chef community.

 

I figured this is as good an opportunity as any to talk about why we're sponsoring ChefConf and what we hope to gain from it.

 

Chef: A quick primer

 

For those of you who might not be familiar, Chef is at the core an open source programming language for your infrastructure.  As a quick example, if you wanted to create a user called "bmc" with a specific home, shell, and password, in Chef's Ruby dialect it would look like this:

 

user "bmc" do

  home "/home/bmc"

  shell "/bin/bash"

  password "$1$pOPJQnIg$uCaPdbQle4sjWf8ZSAd361"

end

 

The clever part is that it's not just going to run "useradd" behind the scenes and create the user - it'll look to see if the user already exists and if the attributes like home, shell, and password match what's defined in the resource, it'll skip over and do nothing.  If the user doesn't exist, or if the user exists but has been changed in some way, Chef will put it back the way it is defined in the resource.

 

Chef users define all of the different resources for their servers - packages, services, users, config files, etc. and periodically run the Chef client utility to bring all of the resources back into sync the way they should be configured for their server.

 

But wait - isn't that what BSA does?

 

Yes, both Chef and BSA have the ability to install packages, to check if permissions have changed, to test the validity of a server's configuration.  There is a huge difference, though, in approach, technique, and process.

 

A deep dive on the differences is a topic for another time, but  at a high level, I think it's fair to say that BladeLogic is very process- and event-driven -  you want to check the configuration of a server once a day and generate a report or run a command once across 10,000 machines.  You get the automation, but it's very controlled and deliberate process.

 

Chef, meanwhile, ascribes an extremely agile approach.  Model all of your configurations inside of Chef and push that to all your servers.  When you need to make a change to a server, you edit the code, commit it, and that change goes live on your machines.  It’s designed to be continuous delivery for servers.

 

So why are we sponsoring ChefConf?

 

We're sponsoring ChefConf for a couple of reasons.  First, we want to support the Chef community.  BMC isn’t a name you think of when you think of open source, but we do want to be part of the exciting things that are happening in the open source world.  Emerging patterns and technology like Docker show up first on the bleeding edge next to tools like Chef, and then eventually mature into solutions that our customers will want to use - and we want to be ready when they do.

 

Second, we believe that Chef and BladeLogic are not just compatible from a co-existence perspective, but that we can actually work better together.  BladeLogic could stand to be more agile, and offer users easier ways of building and creating automation content.  Chef is a great platform, but heavily pushes a hyper-agile cloud-focused operational pattern that doesn’t work well in many traditional enterprises.  Together, maybe we can get the best of both worlds.

 

So we’ve built some first-generation integration between Chef and BladeLogic 8.5, which we're demoing in our booth for the first time here at ChefConf.  You can use BladeLogic to call Chef cookbooks and recipes on a push/scheduled basis, and you can reference BladeLogic compliance policies from inside your Chef cookbooks.  It’s all very early and not production-ready, but we want to put this integration front and center with the people here at ChefConf and start a conversation about how they want to blend these two approaches to a stable, managed IT infrastructure.

 

The early response from the first day of the show has been incredibly receptive and interested - particularly from enterprises who are grappling with these challenges.  We’ve got one day left, so hopefully we’ll get some more feedback and can start to build tighter integrations between the solutions.

 

If you’re not at ChefConf, but are interested in talking about how we can integrate with tools like Chef or where we can add value by working together, drop me a note at mzito@bmc.com and we can show you what we’ve done .


If you are at ChefConf, come and say hi at booth #102 and check out Niek's talk "Orchestration in Meatspace" today at 3:15pm (and we'll be posting the slides online afterwards for sure). 

Filter Blog

By date:
By tag: