dev2ops

CIM, APML, SML, CML, SDM, MOF, CMDBF, WTF??… Users aren’t buying vendors’ alphabet soup

2

Damon Edwards / February 26th, 2008

Every year there seems to be a rash of IT modeling standards proposed by vendors like Sun, Microsoft, IBM, Oracle, BMC, CA, et al. They primp, they preen, they puff out their feathers as they jocky for position. But the comedy (or really, the tragedy) of the situation is that they are competing in a race that none of them will ever win. Especially if they stick to their current belief that they can find one true industry-wide model to rule all of enterprise IT. How many times do they have to launch another vendor-driven standard to a resounding thud to get it?

The plain fact of the matter is that end users just don’t care. They want tools that just work and simple frameworks that they can quickly compose into a solution that fits THEIR operations. They want their IT management problems to just go away, not become a new center of the universe that requires an increasingly diverse and complex set of skills to master.

Although I’m a firm believer that the best solutions in IT management must ultimately be model-driven, I also am well aware that the industry has done a terrible job educating users as to why they should even care about modeling in the first place. “Tool interoperability” is the only answer that is consistently given. But tool interoperability is something that vendors care far more about than end users.

Your average systems management jockey is smart enough and skilled enough to cobble together tools as needed. Sure they would like a smoother answer, but not at the cost of pulling a big modeling headache down on top of themselves. This may not please the IT Architect types… but it’s not the first time that they’ve been ignored by their own overworked rank and file whose paychecks depend on getting things done as quickly as possible.

A fun illustration of the absurdity of the standards alphabet soup took place on a recent episode of the always enjoyable and informative “IT Management Guys” podcast.

Host Michael Cote (a RedMonk analyst) and guest William Vambenepe (a well respected vendor representative from Oracle by way of HP) get into a discussion of current standards efforts and how they relate to other recent standards efforts. Of course,those who follow these things will recognize that these standards have gone absolutely nowhere with users in the wild.

The acronym fun begins about around the 8 minute mark and things really go off the rails around the 15 minute mark. It’s a fun bit of unintentional comedy to hear it. All are very bright guys who really know their stuff and have my upmost respect, but it’s just classic to hear an analyst and a vendor jump from acronym to acronym and throwing around modeling and language concepts all while the other host, John Willis, who represents the cream of the crop of actual in-the-trenches IT Management consultants, sits in stunned silence.

John’s quote to snap them out of it is priceless:

“Just give me something that I can go and manage ESM [Enterprise Systems Management] or do IT management!”

Amen, Brother John.

———-
Side note: Cote also retold a fun little joke that a guy named Chip Holden from BMC likes to tell…

“People ask me what I do and I tell them Programming, and that puts most normal people to sleep. When I’m with Programmers I tell them I work in IT Management and THAT puts them to sleep.”

It’d be funnier if it wasn’t sadly true.

Why the crack(berry) stopped working… and counting down to the next outage.

Damon Edwards / February 13th, 2008

The WSJ is reporting that yesterday’s Blackberry outage came during an “expansion of their network operations center” due to service growth. That sounds a lot like RIM spinning the outage so Wall Street hears: “hey, we are growing like crazy so please ignore the fact that we’re a communications company and cut off most of our US customers for the better part of a workday”.

This was RIM’s second major outage in less than a year. Surely the media will place a big portion of the blame (as they previously have) on RIM’s highly centralized hub-and-spoke style architecture. But I hoping savvy tech readers will realize that the redundancy issue is a cop out. Blaming the lack of a safety net doesn’t change the fact that these failures are caused by poor change control and ineffective processes.

This isn’t exactly an uncommon problem. Many popular services are able to survive deployment screw-ups with various forms of a brownout, enabling them to play fast and loose with “uptime” statistics. But why is that even tolerated?

Until the discipline and science of operations is discussed openly and freely within IT communities as it is within mature industries like manufacturing or energy, I really don’t expect much to change. Money and goodwill will keep hitting the floor and CEO’s will just scratch their heads and shrug at the convoluted excuses offered up by their IT organization.

Built for operations

Damon Edwards / February 11th, 2008

A big piece of solving the development to operations problem is convincing developers and architects to design their applications with production operations in mind.

Randy Shoup (Distinguished Architect from eBay) gives an interesting presentation that shows how eBay has done just that:
http://www.infoq.com/presentations/shoup-ebay-architectural-principles

(And he puts his points in design pattern format!)

Edit: Michael Nygard’s book “Release IT!” also does a great job of covering the topic of designing operations-ready software. It’s a great addition to your bookshelf if you don’t already own a copy.

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

Damon Edwards / January 31st, 2008

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

Damon Edwards / January 30th, 2008

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

1

Damon Edwards / January 23rd, 2008

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.