Sunday, March 25, 2007

Slides from my UKUUG presentation online ...


... here (click on "Agile Systems Administration"). The talk was fine. 25-30 people came, which was enough for me to feel good about attendance, and still keep vaguely cool.



It turned into a general discussion at the end with a particular focus on Puppet. One point I wanted to make now that everyone has left the room (and the conference) is that you don't need to know Ruby to use Puppet. It has a very simple declarative syntax that you use to tell Puppet what state you want your system to be in. And you can call shell scripts if you really want to ...


Monday, March 12, 2007

CruiseControl.rb: the newest Cruise Control

There are 3 CruiseControls as of today. Java, .NET, and now Ruby. The newest one looks fantastic and is very simple.

There's a 5 minute movie of the install here:

and more info on the site here:

Here's the features:


* Can be installed in 10 minutes.

* Works out of the box with a regular Ruby or Ruby on Rails project. No configuration necessary.

* Web-based dashboard, convenient, useful and pretty.

* When a build is broken or fixed, notifies users via email, instant messaging or CCTray.

* RSS feed to track the build status of your favourite projects.

* Jump to the code causing a build error in one click.

* Displays custom build artifacts. No configuration necessary.

* Can interoperate with any build tool that can be invoked through command line and returns a non-zero exit code if the build fails. Like:
o nant
o ant
o etc…

* Extendable through builder plugins, custom build schedulers and other configuration options.

* Infinitely hackable thanks to publicly available source code and Ruby open classes.

* Free as in “free beer”.

Sunday, March 04, 2007

Infrastructure Patterns

Chris and I talked about applying patterns to infrastructure some time ago - developers use patterns in their work to identify common uh, patterns in code and identify those. Once I joined TW and saw developers using this common vocabulary to describe code, I was sold on the idea. So can we do the same thing in the world of infrastructure?

The answer would seem to be "yes" because Bruce Robertson and Velentin Sribar wrote this book about identifying patterns, and how that leads the infrastructure architect to design infrastrutures that allow for adaptability. It's about time too. I've refactored infrastructure and I usually bark my knuckles in the rack.

A keyproblem identified in the book is "stovepipe" infrastructures - where you may have many applications that have seperate but similar infrastruture, sitting side by side in the same datacenter. Those who tend towards risk aversion might consider that a good thing - if your NFS server falls over, it only takes out one application, rather than 4. But if you're managing 4 NFS servers, how much does that cost you to operate? And do you manage to get any economies of scale?

Anyway, 9 infrastructure patterns pop out of the book. It's a damn fine start.

What I wonder is this: The patterns that we use in code are sometimes named after concrete (infrastructural) things: Proxy, Repository. So when we deal with concrete, actual proxy servers and repositories, can we try and adapt those patterns for this context? Should we make a concrete proxy pattern to describe the Squid proxy, web server plugins for application servers, or other infrastructure that does a proxying job?

Or perhaps a that concrete object is simply a part of a larger infrastructure pattern, like "N-tier transact" from the book? What do you think?