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?

No comments: