Distilling Devops
I’ve been thinking a lot lately about how we really want to talk about infrastructure. While tools like Puppet, Chef, Capistrano, Fabric, etc, are all pretty popular, they incur a learning cost and upkeep that is disproportionate to the power they supply. They should get credit for breaking ground, but they are doing very well because there hasn’t really been a simpler widely available alternative. Predecessors like cfengine were utter hell, as is hand coding bash scripts. These applications were the tools that we had, and they were good answers to the problem. People were amazed by them, compared to the alternative.
But how much of them do we really need and use? Are they distilled to their bare core? I think Seth’s post here sums up that idea well. Why are there different tools for configuration and deployment? Why do my eyes glaze over when reading the documentation for Capistrano and Fabric? Dear God. Do I really want to be writing Ruby to be the policy language where I describe my security and compliance configuration? What happened?
THIS IS NOT THE FUTURE. WE WERE PROMISED FLYING CARS.
I think we got seduced by power. It was fun. Fun is ok. I understand that sysadmins want to grow skills. Sure. But I’d much rather be writing some clever API script to connect a bunch of complex systems together than I would be wanting to spend that time automating software installs. That’s boring. If it’s fun, it’s because your tools are too hard to use and you’re enjoying the challenge of the tool, not the result. I’ve grown beyond enjoying the fun of programming for the sake of development and want to make things happen.
Reading the recent post about Tumblr’s usage on HighScalability, we see they had to go through a great many hoops to unite a configuration management system, an ad-hoc task system, and a deployment task system. 3 systems each with lots of overlap. Why not one? That’s not fun. Fun is being able to solve the most interesting problems that I have, the ones that apply directly to my business. Not telling my servers what I want to do.
I want to get in and out as quickly as possible. I certaintly don’t want to be fighting syntax errors, SSL setup, DNS/timing issues, and training the new guy on a complex system with lots of very involved best practices. Sure, there are a lot of very vocal admins that pick tools and like them. That’s great. But for every one you here about there’s a medium sized shop there still struggling for a decent answer that doesn’t require these tools to suck in so much of their time — and to fit into their slightly different views on requirements. Not everyone wants to code at their infrastructure.
That is why I started Ansible. I know things can be simpler, so I set out to make them simpler.
As of 3/10/2012, Ansible is now two weeks old. It took the lessons from these other tools and distilled them down to the core. We have idempotent modules, playbooks (a merger of Chef and Puppet takes on configuration), an ad-hoc task capability borrowed from Func, and an ideal language for expressing multinode deployment steps — which has been a long-term research interest of mine but never really well solved by anything. What’s most impressive? It currently has about 1/60 the amount of code of Puppet or Chef. Yes, you read that correctly. 1/60th. And I’m using all my powers as a software developer to keep it that way. Want to extend it? Do you know what language you can write modules in? Any language you like. What software does it require to be installed on the remote machines? Nothing.
Distillation is a great concept. For software and liquor.
DevOps is great — but coding at infrastructure turns your operator meatcloud into a coder meatcloud, coding at the wrong thing. The simpler we can make the tools, the more we can distill them to their most powerful core, the more we can buy time for more interesting projects. Business objectives. Real world domination.
For many shops where resources are limited and people wear multiple hats (think startups), I want a tool that expresses configurations extremely simply, does not force me into any language choices for extensions, is super quick to set up, and allows me to go off and then do OTHER THINGS.
If you’re thinking right now this is not for you, maybe it’s not — it’s not going to have all the blingy features. If you’re Google, you probably know better. Many businesses will have feature needs that Ansible does not supply (some of these we might add, but not all). But maybe if you’ve got a reasonable number of nodes, your configuration problems aren’t rocket science, you just want something easy to figure out and use. Yeah, it’s for you. I wrote it for that.
Check out Ansible and let me know what you think.
