Latest News from James Houghton

A Recipe for Cloud Design

Mon, 03 Jan 2011 06:30:00 EST

The deployment of infrastructure systems to support applications has been a challenge since we first developed a choice beyond the venerable mainframe. To some it’s a simple formula; take a server, toss in a little network and storage, bake for a few weeks and you’re done. If you’re having a few friends over (need a little more) then simply add a few more servers and you’re done.

CMDBs in the Cloud

Tue, 30 Nov 2010 08:00:00 EST

As enterprises move inexorably towards the Cloud, a faint murmur in the distance is growing louder and louder. What is it – the security forces objecting…the CFO wondering where their money is going now…business teams clamoring for faster response time? Good guesses, but this group never makes quite that much noise – it’s the operational teams scratching their heads wondering how, particularly given their existing set of challenges, they are going to keep their heads above water trying to manage something as amorphous as a Cloud. They are right to be concerned. After all, when the glamour and excitement of deploying a new Cloud application/environment has passed and the industry fervor shifts to the next Big Thing, they will be the ones left with the responsibility to ensure that business expectations are met for years to come. But just how are they to do that? While impressive advancements have been made with respect to performance monitoring, capacity management, and provisioning, they have mostly been made in independent silos. Although these improvements have provided tangible benefits, it has required human intelligence to integrate and manage. Unfortunately we all know humans make mistakes, and are not very scalable.

Ever Wonder WHY Your VMware Deployment Stalled?

Thu, 09 Sep 2010 08:15:00 EDT

The past week hosted the increasingly popular VMworld 2010 event at the Moscone Center in San Francisco. The title of the conference was “Virtual Roads, Actual Clouds”, but the undercurrent of the show was all about ‘VM stall’ and of course whatever vendor XYZ can do to help you get your VM deployment moving again. While we certainly want to un-stick any optimization effort, it’s often prudent to understand WHY something happened before attempting to fix it. It’s difficult to generalize the reasons for every situation, but we’re willing to venture a guess: failing to understand the workload. The workload is not simply an application name, the programming language it’s written in, and the hardware configuration it runs on today. Those things are a good start, but hardly provide enough information to determine the correct optimization approach. And yes, the implication in the preceding sentence is that there are multiple optimization approaches; that (gasp) the ideal target start may not be within a VM.

Accounting for the Cloud

Thu, 19 Aug 2010 11:00:00 EDT

The past few weeks we have been discussing some of the mistakes made in early cloud deployments. This week we are discussing a key mistake that occurs fairly often; one that only manifests long after the solution is operational…blindly assuming that Cloud equals costs savings. Blasphemy, you say – how could it possibly not cost less? Let’s take a look at the considerations and components of IT cost, and revisit this question at the end. The unfortunate truth is that most enterprises have well-established IT cost allocation mechanisms, but few of these have any basis in actual consumption. Put simply, can you (or your users) confidently say that your IT bill reflects how much – or little – you use something? Traditional approaches to IT chargeback involve aggregating the net IT cost, and allocating it proportionally to business units based on head count, server count, or some other surrogate for allocating actual cost. This approach (sometimes affectionately referred to as ‘peanut butter’ – you spread it around) has merit in its simplicity, but cannot be allowed to persist as we move toward Cloud operating models.

Who Really Needs a Blueprint?

Thu, 12 Aug 2010 07:30:00 EDT

A few days ago we facilitated a passionate discussion on the subject of Blueprints (ah, the joys of an emerging market). The gist of the conversation was focused on deciding where limited marketing resources should be applied, and during that exercise a surprising insight came to us. It seemed so counter-intuitive at first, then as we kept exploring it became so blindingly obvious that we questioned our intelligence for not thinking of it before.

Back to the Future: Monitoring the Cloud

Sun, 25 Jul 2010 14:00:00 EDT

This week, we’re exploring the problems associated with leveraging traditional monitoring solutions in a Cloud delivery paradigm. There is a common assumption that leveraging a Cloud operating model will save money. We won’t debate the accuracy of this statement (tune into our next installment for that discussion!). For the purposes of this discussion, we’ll assume it’s true. But if that’s the only benefit who, besides your CFO, really cares? Everyone wants to save money, but if you told a critical business customer that you were going to adopt a new computing model that would save money but introduce risk, do you think they would be supportive? Probably not: they wouldn’t find the risk/reward ratio acceptable. In order to shift that ratio, you need to improve the quality of the service(s) offered; otherwise you’ve simply lowered the cost of an increasingly commoditized service.

Can You Depend on the Cloud?

Wed, 14 Jul 2010 08:30:00 EDT

Okay, so the title is a shameless attempt to grab your attention – glad it worked! But in truth this week’s blog is actually about what your applications depend on, and understanding what impact deployment in a Cloud environment may have. As we continue the discussion about the potential mistakes with Cloud (see here), this week we are diving into Service Dependencies. What do we mean by Service Dependencies? Anyone who’s had the pleasure of doing a sizable data center move or consolidation project knows exactly what we mean. They are the annoying little links between applications and/or services that seem to defy documentation and slip from the memory of the application development team when interviewed. They are the reason most data center move projects end up significantly over budget.

Virtualization Does Not a Cloud Make

Wed, 07 Jul 2010 07:00:00 EDT

In a previous post we discussed the positive shift in the Cloud Computing discourse towards actionable steps rather than philosophical diatribes on definitions. And to support that discussion we offered the following list of things not to do. Cloud Computing is not about any particular technology, but rather is a new operational model for the delivery of IT services. Make no mistake: technology and implementation decisions have the potential to radically change your IT financial models by increasing IT efficiency. But this does not mean that specific technologies are requisite components of a Cloud.

Business Value and Cloud Computing

Wed, 16 Jun 2010 10:45:00 EDT

In our last post we discussed the positive shift in the Cloud Computing discourse towards actionable steps rather than philosophical diatribes on definitions. And to support that discussion we offered a list of things not to do. In this installment we are going to focus on the first mistake – failing to understand the business impact of leveraging a Cloud delivery model for a given application or service. What are you trying to do? The first step when evaluating a Cloud delivery option is to define the service: is it new or are you considering porting an existing service? Both options have their advantages and disadvantages. If new, there is a lower financial bar to justify a Cloud model (no legacy infrastructure to write off), but there’s also the downside of having no historical perspective on consumption trends to aid in evaluating financial considerations or performance. We’ll discuss both financial and performance considerations in a future blog, so for now let’s continue and assume we are talking about a new service.

Cloud Computing: What NOT to Do

Mon, 07 Jun 2010 10:27:00 EDT

A shift is finally occurring in the Cloud Computing discourse. Topics like "what is it" have been supplanted by more useful questions such as "should I do it?", "how should I do it?", and "when should I do it?" In appreciation of this new phase of Cloud Computing adoption, we'd like to offer some thoughts on some of the common pitfalls of both public and private Clouds so that you might avoid them as you evaluate and implement cloud solutions.

Cloud Computing: What NOT to Do

Mon, 07 Jun 2010 09:23:00 EDT

A shift is finally occurring in the Cloud Computing discourse. Topics like “what is it” have been supplanted by more useful questions such as “should I do it?”, “how should I do it?”, and “when should I do it?” In appreciation of this new phase of Cloud Computing adoption, we’d like to offer some thoughts on some of the common pitfalls of both public and private Clouds so that you might avoid them as you evaluate and implement cloud solutions. 1. Not understanding the business value It's important to weigh a Cloud solution versus the traditional approach through the lens of business value. If this is an existing service, can the Cloud truly provide a better solution than what you’re currently doing? If new, what are the important business requirements that may drive you to select a Cloud deployment model? In the event of a service outage or a security breech, what’s going to happen: is your plane going to drop out of the sky or just experience some minor turbulence?