Monthly Archives: May 2012

RACI and PaaS – A Change in Operations

I have been having a great debate with one of my colleagues about the changing role of the IT operations (aka “I&O”) function in the context of PaaS. Nobody debates that I&O is responsible and accountable for infrastructure operations.

Application developers (with or without the blessing of Enterprise Architecture) select platform components such as application servers, middleware etc.  I&O keeps the servers running – probably up to the operating system.  The app owners then manage their apps and the platform components.  I&O has no SLAs on the platform, etc.

In the PaaS era, I think this needs to change.  IT Operations (I&O) needs to have full accountability and responsibility for the OPERATION of the PaaS layer. PaaS is no longer a part of the application, but is now really part of the core platform operated by IT.  It’s about 24×7 monitoring, support, etc. and generally this is a task that I&O is ultimately best able to handle.

Both teams need to be accountable and responsible for the definition of the PaaS layer to ensure it meets the right business and operational needs.  But when it comes to operations, I&O now takes charge.

The implication of this will be a need for PaaS operations and administration skills in the I&O business.  It also means that the developers and application ownership teams need only worry about the application itself – and not the standard plumbing that supports it.

Result?  Better reliability of the application AND better agility and productivity in development.  That’s a win, right?

Cloud API Standardization – It’s Time to Get Serious

UPDATE 6/2

Given the recent losses by Oracle vs. Google in their copyright Java farce it looks like using the AWS APIs as a standard for the industry could actually work. Anybody want to take the lead and set up a Cloud API standards body and publish an AWS-compatible API spec for everybody to use??

——

Okay – this is easy… or is it?

Lots of people continue to perpetuate the idea that the AWS APIs are a de facto standard, so we should just all move on about it.  At the same time, everybody seems to acknowledge the fact that Amazon has never ever indicated that they want to be a true standard.  Are we reallyIn fact, they have played quite the coy game and kept silent luring potential competitors into a false sense of complacency.

Amazon has licensed their APIs to Eucalyptus under what I and others broadly assume to be a a hard and fast restriction to the enterprise private cloud market. I would not be surprised to learn that the restrictions went further – perhaps prohibiting Eucalyptus from offering any other API or claiming compatibility with other clouds.

Amazon Has ZERO Interest in Making This Easy

Make no mistake – Amazon cares deeply about who uses their APIs and for what purpose.  They use silence as a way to freeze the entire market.  If they licensed it freely and put the API into an independent governance body, we’d be done.  But why would they ever do this and enable easy portability to other public cloud providers?  You’re right – they wouldn’t. If Amazon came out and told everybody to bugger off, we’d also be done – or at least unstuck from the current stupidly wishful thinking that permeates this discussion.  Amazon likes us acting like the deer-in-the-headlights losers we all seem to be. Why? Because this waiting robs us of our will and initiative.

It’s Time to Create A Cloud API Standard

Do I know what this is or should be? Nope. Could be OpenStack API. It won’t be vCloud API. It doesn’t freaking matter. Some group of smart cloud platform providers out there should just define, publish, freely licence and fully implement a new standard cloud API.

DO NOT CREATE A CLOUD API STANDARDS ORG OR COMMITTEE. Just go do it, publish it under Creative Commons, commit to it and go. License it under Apache. And AFTER it gets adopted and there’s some need for governance going forward, then create a governance model (or just throw it under Apache). Then every tool or system that needs to access APIs has to only do it twice. Once for Amazon and once for the true standard.

Even give it a branding value like Intel Inside and make it an evaluation criteria in bids and RFPs. I don’t care – just stop treating AWS API as anything other than a tightly controlled proprietary API by the dominant cloud provider that you should NOT USE EVER (once there is a standard).

Take it one step forward – publish a library to translate the Standard API to AWS under an Apache license and get people to not even code AWS API into their tools.  We need to isolate AWS API behind a standard API wall.  Forever.

Then, and only then, perhaps we can get customers together and get them to force Amazon to change to the standard (which they will do if they are losing enough business but only then).

%d bloggers like this: