A couple of things of note have happened recently. Firstly, I managed to conquer the #10-level Currywurst at Curry & Chili, rated at a (literally) eye-watering 7.7 million Scovilles - not a performance I care to repeat. Secondly, I recently changed employer from Nokia to SoundCloud. This is a big change for me, and in some ways hard since it was working with Nokia that allowed me to anchor here in Berlin and has been a huge area of stability in our lives amongst a lot of change. Most significantly, it means making the final transition from a somewhat "DevOps" role which combined operational elements and development to a full-time developer role.

Although I've seen people go the other way (from 100% development to operations/systems-engineering), I feel like that is "Salmoning" to some extent. Especially with the fervour surrounding DevOps culture and the Cloud, Web 2.0/3.0 etc, taking on additional development experience and tasks seems a natural flow in this industry. Whatever everyone else is doing, this has been high on my personal agenda for some years now and I'm very glad to have actually made it work out. Whatever I end up working on, I'm going to try to continue writing up posts on the interesting technical aspects (and I know my new employer encourages such things).

In just over a week I've already had to get to grips with a bunch of new technologies (mostly just new to me) and systems and it is proving not only a worthy challenge but a lot of fun. Two technologies in particular I wanted to write a couple of paragraphs about.

Puppet vs Chef

If you've read previous posts, worked with me, met up with me at various Meetups or conferences or even seen me talk before you'd know I've been pretty involved with Puppet for quite a few years now. I never thought I'd be "the Puppet guy" at my last two places of work and after a while wished I wasn't - not because it wasn't enjoyable, but because I wanted some new challenges. I took a look at Chef a long time ago but didn't think it fit my/our requirements very well and more or less dismissed it after that, and didn't re-evaluate again.

If that sounds at all familiar to you, I urge you to take another look! The last couple of days working with it have been very eye-opening for me, especially given the amount of custom systems we built around Puppet at Nokia.

• The data bag system is a big win. I like that you get light-weight JSON storage built into Chef, and that it provides a hierarchical storage and lookup system out of the box. OK, Puppet has this now too with Hiera built-in, but I found the data bags system immediately understandable and usable. The only thing that bothers me is using the custom Mash type which pollutes any output into YAML (which now requires the original object definitions in order to de-serialise).
• I assume data bags are stored in CouchDB, which adds cool factor. It also means the Chef Server is completely stateful, which I'm on the fence about but so far while I've been using it it has been a good experience.
• The knife tool plays further into this concept of a stateful Chef Server and is a really useful tool for getting content into, and information out of the server. I can really say I missed having a tool like this for many years already with Puppet.
• Having a management interface built-in is a nice touch. Yes, there is Puppet Dashboard/Console but it has always been an optional extra component. Viewing all cookbooks, recipes, data bags, roles, nodes and everything else about the system immediately is a big convenience rather than getting selective access to some of those parts of the system.
• Being able to write recipes in native Ruby once you are very familiar with Ruby is extremely liberating. The gloves can come off, and you can really achieve whatever you want to achieve by using a tool you are already familiar with.

Of course, any one of these could be just as applicably a criticism against Chef. The Ruby DSL and access directly to native Ruby code would allow many novice users to shoot themselves immediately in the foot. The relatively closed nature of the Puppet DSL means that testing and introspection of the configuration code is much simpler as opposed to native Ruby which can do anything in any number of ways. A lot of the other parts of Chef would be equally hard to wrap your head around if you have not ever tried your hand at coding.

That being said, at this point I find it a logical and usable system; one that could have solved a lot of problems had we given it a chance. I think Puppet was the right tool at the time, but Chef has a lot of possibilities too - take a look at it if you haven't already.

NodeJS and the cool kids of event-based programming.

NodeJS seems to attract a lot of love and hatred - it is a polarising technology. Unfairly perhaps, I put it into my hatred bucket - mostly because a lot I had read about it seemed to consider it the silver bullet to web scaling problems, and I hadn't honestly tried it or learned about it.

I'm not sure if any of the systems I'll encounter over the next few months are actually running Node, but I decided to give myself a coding challenge and attempt to write a small application with it anyway. From what I've seen and read about its design so far, it seems like a good solution to a very specific set of event-driven, small payload, tightly-couple client/server problems. It is certainly not a silver bullet, and it comes with its own set of restrictions but again like Chef I have to recommend that you at least get yourself familiar with it and have a think about what problems you could solve with Node.

So that has been my experience the last few days, and I hope to get much more familiar with these two tools before very long. With any luck, you'll see some more posts on both of them!