View All Videos

Archive for January, 2008

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

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

Damon Edwards / 

You may want to read my review of Part 1 first.

Part 1 of Nick Carr’s “The Big Switch” was much more relevant to this blog so I’ll be brief in discussing Part 2…

While Part 1 was a well thought out analysis of economic history and it’s relevance to the trends we are seeing today, Part 2 just seems like a scare piece that you’d see in a major city newspaper looking to cook up some ratings.

Part 2 has lots of doom and gloom about the social ills of living our lives online and how there is a new breed of digital raiders (that’s my term) who are getting rich off all of our online backs. Nick is very quick to pile on the examples of the negative impact of our new connected world, but somehow manages to miss almost all of the examples of how this new connected world improves millions of lives socially and economically.

It’s my non-expert opinion that “The Big Switch” is really a collection of unfinished essays that were put together to make a book. Buy the book for Part 1, but stick around and read Part 2. If anything, Part 2 will give you great material to stir up some sensationalistic conversation at your next cocktail party.

Beware of the forklift

Beware of the forklift

Damon Edwards / 

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.

Service Monolith: Proposed OMC Anti-Pattern #2

Service Monolith: Proposed OMC Anti-Pattern #2

3

Alex Honor / 

Most software services developed and operated these days are increasingly more heterogeneous and distributed, and therefore, complex and hard to setup and manage. On top of all this, the rate of change seems to only go up. These trends can lead to an anti-pattern I’ve recently documented at the Open Management Consortium called “Service Monolith”:

Complex integrated software systems end up being maintained as a single opaque mass with no-one understanding entirely how it was put together, or of what elements it is comprised, and how they interact.

I describe some common rationale for using this anti-pattern and some of its consequences. There are positive design patterns to avoid or mitigate the anti-pattern, too. I find one interesting solution that seems to be becoming more ubiquitous and sort of side steps the deeper problem: virtualization. Virtualization is one strategy for dealing with producing these complicated systems. Using this strategy you get the whole conglomeration working on one host, cobbling the pieces together using the preferred recipe, then “freeze dry” it as an operating system image that you can instantiate on another host. With the image in hand an organization can “stamp it out” as needed. This technique seems to work for small scale deployments but I haven’t seen the approach work for maintaining large scale environments. Is this the sign of another emerging anti-pattern?

Edit (Damon 1/31/08):
This is a great quote by Kris Buytaert on his first booting of a vmware instance:
“And thus we joined the era of transferring an unmanagable image that everyone will copy around wile slightly modifying things and never placing them in version control . hence ending up one day with something nobody knows how we got there.”

Configuration Bird Nest: Proposed OMC Anti-Pattern

Configuration Bird Nest: Proposed OMC Anti-Pattern

1

Alex Honor / 

Sometimes it is more interesting (and entertaining) to talk about things not to do. Let’s face it, we have more experience doing things wrong and learning the hard way. For these reasons I decided to begin the OMC’s Design Pattern work with Anti-Patterns.

I had a clear “favorite” in mind when it came to writing the first anti-pattern. I call it Configuration Bird Nest:

A network of circuitous indirections used to manage configuration and seem to intertwine like a labyrinth of straw in a bird nest. People often construct a bird nest in order to provide a consistent location for an external dependency.

The bird nest metaphor seems so apropos as it conveys the idea that the nest cradles something important, typically something crucial to supporting an application. The pattern is so typical and manifests itself inside so many IT disciplines, I look forward to hearing about its many forms.

The (unscientific) results are in… ESM = Monitoring

The (unscientific) results are in… ESM = Monitoring

1

Damon Edwards / 

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

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

Damon Edwards / 

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.

Page 1 of 3123