dev2ops

Beware of the forklift

The idea of the “forklift” upgrade/replacement is an attractive option for high volume hardware environments. The idea of adding or moving things as one pre-configured mass is compelling, but shouldn’t be applied overzealously to other domains… especially application deployment.

I remember when word first got out that Google just tossed servers in the trash on the first sign of failure. Then it was news when it leaked out that Google had pre-configured units of infrastructure – servers, switches, racks, etc. – that they just “popped” into place when new capacity was needed. Many found this new paradigm shocking, but it did shine an early light on the forklift concept.

Jump forward to today and the forklift idea has matured even further. Sun is now shipping the Modular Datacenter (formerly known by its sexier name, Project Blackbox), a cargo container with an entire pre-configured datacenter inside. Add power, connectivity, and water (for cooling) and the thing hums. Need more capacity? The truck arrives with another unit.

But the forklift paradigm isn’t limited to just hardware these days. With the rise of virtualization, these same concepts are being applied to the software domain. Check out this recent press release from VMware. They are advocating the forklift model for production deployment: tinker with an image until you like it, snapshot it, copy it a bunch of times, and then move the whole lot of server images in masse to the production environment. It sounds like a reasonable theory, but in practice this often leads to more problems than it solves.

“Snapshot and copy” (the forklift of the software world) works well for OS provisioning. But when it comes to application provisioning, it’s just not so simple. The key to any deployment process is the configuration and coordination of actions across software components (which naturally means across OS instances, physical or virtual). This has to be done even if you’ve utilized the snapshot and copy approach. This means you are still writing your own complex scripts or doing a lot of actions by hand.

I’ve seen several situations lately where the promise of virtualization and it’s snaphot and copy paradigm has been embraced by an organization but in time they’ve only found themselves with a more complex and difficult environment to manage. What worked well in the small scale eventually ends up creating the Service Monolith hairball that Alex was discussing in his previous post. The primary culprit? The idea that the snapshot and copy paradigm replaces the need for tooling that allows you to build any OS or integrated application from a specification driven, fully automated process.

Don’t get me wrong, I’m a big fan of virtualization. We use it extensively ourselves and build it into solutions for our clients. It solves a lot of problems, just not all problems. So remember, when designing you application deployment process bring the rest of your tools along with your forklift.

The (unscientific) results are in… ESM = Monitoring

So I’m sure there was a wise person who was quoted as saying something like “If you ask people what is important they will tell you one thing. But observe their behavior and you’ll often learn something very different”. I had a bit of an experience with this principle at BarCampESM in Austin this weekend.

Ask any of the attendees (and their was decently broad representation from both big vendors, little vendors, and independent consultants) what “Enterprise Systems Management” (ESM) is all about and you get some great answers about topics like business service management, resource optimization, system control, business alignment, etc.

But as I watched the presentations and joined the lively discussions, there was one constant topic from which all other topics flowed… good old monitoring. It quickly became obvious to me that, if you boil things down to its core, the term “ESM” is all about monitoring. Everything else is an add on or an upsell! It makes since on some level since, like the old adage says, “you can’t manage what you can’t see”. But it still came as a but of a surprise how much monitoring was the end point, if not the starting point, of most trains of thought.

For better or for worse, it appears that today’s common world view goes something like this: How do you do Business Service Management? Correlation of monitoring events. Control? That’s what you do in reaction to monitoring events. Resource optimization? That’s when you setup your monitoring to gauge how well you run things. Business alignment? That’s when you make sure the output of your monitoring tool is organized according to business concerns.

Monitoring. Monitoring. Monitoring. If you aren’t a monitoring tool’s “goesinta” (input) or “goesouta” (output) you really aren’t ready to fit into today’s ESM ecosystem. Hey, I’m not saying that there is anything intrinsically wrong with that. It’s simply something about which we have to be honest with ourselves

Now, if you would excuse me, I have to go integrate with some monitoring tools.

Nick Carr’s “The Big Switch” – Review of Part 1

I just finished reading Part 1 of Nick Carr’s new book, The Big Switch. Let me just say that I’m both excited and disappointed thus far.

First, the excited part…
In my opinion, Nick Carr is a great writer. His way of explaining the future by retelling the past from an enlightened point of view reminds me a lot of George Gilder’s seminal Telecosm essays. Both make for a fascinating read. Part 1 is really a retelling of how electrical power generation went from being a custom piece of local infrastructure to a commodity delivered almost exclusively through a variable-rate utility grid. Through some very accessible storytelling, Nick makes an obvious case for how the same economic factors that drove “the big switch” for the electrical power industry are about to hit the IT industry. If you know someone who can’t clearly see the SaaS/cloud/outsourcing writing on the wall… give them this book. The economic argument is highly compelling.

Now for the disappointed part…
The vast majority of this first part is about the electrical power industry. While it makes for a compelling argument for a certain economic model, it doesn’t really say what the impact is going to be or what the response should be other than the fact that 1. most hardware vendors and on premises software vendors are toast 2. everyone better quickly figure out how to plug into the new grid. I thought that Part 2 was going to cover this… but nope. I skimmed through Part 2 and it looks like it is all about what the impact of the new grid will be on our personal lives, government, etc. It feels like I’m watching a compelling PBS miniseries and I missed an episode. Perhaps this book should have been called “Warning: a big switch is coming”.

The other disappointing part is how he glosses over over the fact that while computer cycles are a commodity, computing services are not. Electricity is electricity but not all computing needs are the same. You can’t just pick AC or DC and a voltage and tell everyone to fall in line. Nick jumps a little too easily between things like Google Search, Amazon Web Services, and Salesforce.com. Those are all very different things and, aside from the need for power, computing cycles, and bandwidth, they all have very different technical requirements. While power, computing cycles, and bandwidth are commodities that can be grid delivered just like electricity, the various levels of computing services that can be delivered on top of them are not. As I’ve said before, manufacturing is a much better model to study for how those services are going to play out.

But all in all, this has been a fun read thus far. For the uninitiated masses who don’t really know what we do in the IT trenches all day long, this book should be a startling wake up call for how fast the world is going to change.

I’m fired up to read Part 2 as soon as I get a chance. I’ll be sure to post my $0.02 when I’m done.

BarCampESM… the start of something interesting?

A couple of us from ControlTier are headed to Austin for BarCampESM. It promises to be an interesting gathering of scrappy open source and big closed source (“but oh we so badly want to be viewed as ‘open'”) vendors all focused on the systems management space. The idea from this gathering came from the Open Management Consortium and is being organized by folks from BMC, Zenoss, and Zabovo (including the tasty sounding free food). This is the first BarCamp of this type so where this all leads is anyone’s guess.

For those unfamiliar with the BarCamp concept, it can best be described as a self-forming “unconference”. The idea is to encourage as much brainstorming and networking as possible. While sessions are proposed on a wiki ahead of time, much of the actual structure forms at the start of the conference and while it progresses. Oh and they are free and open to all.

A fun side observation:
Check out the these videos of past general technology BarCamps in San Francisco and Austin. I guess stereotypes about cities exist for a reason!