Undifferentiated Heavy Lifting
April 21st, 2008 javier
This phrase was used close to a dozen times by Werner Vogels, CTO of Amazon.com at his recent keynote at the MySQL conference. Werner used it to describe the day to day tasks of most web operations teams… tasks like racking boxes, configuring routers, and installing software. He mentioned ops teams at Amazon got to spending 70% of their time in this mode, and this was one of the main catalysts for developing infrastructure that brings us S3, SQS, EC2, and more.
Removing this “undifferentiated heavy lifting” (hereto referred as UHL) from your cycles is supposed to free operations to spend more time actually operating. As I was listening to the talk, I wondered how many folks believe there is some competitive advantage in UHL? Certainly choice of hardware, network architecture, data center setup all fall under UHL and can mean the difference between success at scale versus utter failure. Nonetheless, the argument is that you shouldn’t reinvent the wheel and should take advantage from those providers (Amazon in this case) who do the UHL for you, right? Well, a lot of people certainly think so based on how much press and use is being directed towards the cloud.
This begs raises the question: “If racking boxes, configuring OS’s and so forth is UHL today, what will be UHL tomorrow?” That question is material to companies in the systems management market because getting caught on the wrong side of UHL means your future is (as our favorite magic 8 ball would say) “Outlook Not So Good”.

Luckily, UHL today is mostly about the pain associated with hardware and network provisioning and configuration. These problems are bounded just enough to make it feasible for someone to simply delegate them to a cloud provider (as many already have). Of course, the implications to management vendors focused on managing UHL tasks are not pleasant if you buy the idea that most applications will move into this sort of an environment. If you buy this vision, then conceivably the future will require one GIANT Tivoli license for the One-Cloud-Provider-To-Rule-Them-All, right? Heh, not quite, but it’s fun to think about it that way!
The reality is that this trend is forcing both service providers as well as application developers to rethink their operation strategy. Providers want to be more like clouds, developers want to run inside them.
Why rethink their ops strategy? Because the stuff that sits above the UHL layer… the middleware, the databases, and most importantly, the code that makes up a given application present the most daunting challenges due to their complexity. This leaves a meaty management problem yet to be solved. One that has more to do with managing complex software stacks with components which might reside inside or outside of the cloud and with an ‘elasticity’ (to borrow another one of Werner’s terms) which demands equal agility in the management layer than what is found in the software stack.
This is where the next big wave of innovation will happen in the management space, and we’re excited to be a part of it. Come visit our booth at the Web 2.0 Expo this week, and you’ll see what I’m talking about.
Entry Filed under: Events, IT Industry, Javiers Blog













4 Comments Add your own
1. Bart van de Garde | April 21st, 2008 at 12:47 pm
Hi Javier,
On the services of Amazon there is a role for companies like Hyperic (and the company I work for) but what do you think is the role of Hyperic in a more high level cloud service like Google App Engine? I don’t believe they allow you to run a Hyperic client or any other monitoring client (or are you planning a python port?).
Bart
2. Bart’s Weblog &raqu&hellip | April 21st, 2008 at 1:54 pm
[...] http://www.hyperic.com/blog/hyperic/2008/04/21/undifferentiated-heavy-lifting/ [...]
3. javier | April 23rd, 2008 at 7:43 am
Hi Bart,
We’re definitely looking at Google AppEngine as it evolves. Regardless of its Python underpinnings, customers running parts of their app inside it (just like EC2) will need a way to manage and monitor all layers of the app environment.
No python ports planned as of right now, though you’ll see some very cool python bindings and other tricks in our next release.
-javier
4. Bart van de Garde | April 28th, 2008 at 9:03 am
Hi Javier,
Thanks for the reply, I look forward to the python bindings! They would probably be very usefull to us. I am curious how you think to monitor applications in the Google App Engine cloud but probably somebody is gonna come up with a plugin for it :).
What I am more curious about is how the developments on cloud computing change Hyperic’s (and monitoring software vendors in general) business. Now it’s just computing power from the cloud but I would guess it can’t take long before Amazon, Google etc provide there customers with nice system and application monitoring tools on there cloud. I think that would require at least some adjustments in your business model and/or challenges in keeping added value on those Clouds.
Maybe an One-Monitor-Cloud-Provider-To-Monitor-Them-All would be a good idea? I would love some Hyperic-from-the-cloud service!
Bart
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed