View All Videos
Microsoft’s early shots in the looming SaaS wars do all of us a favor

Microsoft’s early shots in the looming SaaS wars do all of us a favor

Damon Edwards / 

Head to a conference like USENIX or LISA and you’ll find regularly scheduled hallway arguments over which systems management philosophy is the “right” one. Personal biases abound, but often the roots of these disagreements are simply differences in the perspectives formed through the combatants day-to-day responsibilities.

One guy will care more about provisioning networks and sees a server or a storage devices as just another object on his network. Another really doesn’t care about the network and lives his day-to-day at the kernel and process level of the OS. Yet another sees the OS as an almost static thing and is consumed with managing app frameworks, databases, and code releases.

Obviously, a “use the right tool for the right job” approach would be the sensible one, but the lack of definition around what the various “jobs” are pretty much kills those efforts. What you end up with is a lot of opinionated people insisting that their favorite tool is the right way of approaching any job.

The good news for all of us is that some clarity to these debates may be coming from an unlikely source… the mega-companies jockeying for position in SaaS and Cloud Computing.

Their contribution? Dividing up the online computing stack into well defined buckets.

For example, check out this presentation from Microsoft’s Chief Software Architect, Ray Ozzie (transcript and downloadable version of the slide deck). The presentation is from this past summer, but the direction of his thinking is very clear. Ozzie sees the stack in four distinct parts:

1. Global Foundation Services – Hardware, power, cooling, and connectivity.

2. Cloud Infrastructure Services – CPU time (think EC2), storage services (think S3), and network services like routing and firewalls.

3. Live Platform Services – All of the various distributed application and data services that your business or consumer applications rely on and share but don’t or can’t live in any one application.

4. Applications and Solutions – Complete business and consumer applications delivered using the SaaS model.

Of course, you can count on Google, Amazon, Yahoo (maybe), and probably SAP and Oracle weighing in with their own definitions. But the financially-backed handwriting is on the wall, the giants are going to force clear definitions one way or another. After all, they can’t sell a product you can’t name.

The significance? Well it may seem small at first glance, but it’s my prediction that the definitive naming of the layers that occupy our world and the glaring spotlight provided by the media coverage these giants receive (and the budgets that come with it) will be the catalyst for period of advancement in the systems management field that hasn’t been seen the 80’s.

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

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


Damon Edwards / 

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.

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

Damon Edwards / 

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

Built for operations

Damon Edwards / 

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:

(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.

CodeData Split: New OMC Design Pattern

CodeData Split: New OMC Design Pattern

Alex Honor / 

One everyday source of confusion seen during the dev to ops handoff is the necessary modification of files during the installation and setup during deployment. Typically, there is one or more modifications to configuration files that enable the software to work in the context of the target environment. The process can be greatly improved if these files were split away from the executable software code itself. I describe this best practice as the CodeData Split:

Separate executable software files from environment specific deployment ones, identifying files that change during installation or operation, thereby facilitating cleaner upgrade process, and the ability to manage deployments independently and separate from each other.

The concept of splitting code from data in applications is nothing new and examples can be found ranging from OS filesystem structure and application servers. The pattern emerged in those places because the operation of the software was a clear requirement so this led to the data files (both configuration and variable data files) to have their own places. This best practice should be followed generally for any application. Doing so will avoid problems like the Service Monolith

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.

Page 21 of 26First1920212223Last