Let’s go back in time to the beginning of Web Services, when the industry was on track to re-create all the CORBA services in XML, leading to a smorgasbord of in-progress WS-* standards. So where are today? The majority of us use REST – a far simpler and far more successful system.

So yes, public cloud providers can and will build out the kinds of management and compliance infrastructures that enterprises need to be able to confidently make use of them. But to be clear, private clouds are no delusion…we have dozens of enterprise customers building them today. We’re seeing several RFI’s for internal cloud projects each month!

Personally, I think that there is a lot to be learned from the Twitter ecosystem. Here you have at the core, a message, and that message can have a payload like a URL, but with bit.ly you start to have simple wrapper mechanism for the payload itself.

This is an elegantly simple and powerful concept, inasmuch as because of the openness and transportability of this messaging model, and thanks to an open API structure, you have third party service builders that are creating all sorts of interesting handling logic mechanisms for aggregating, filtering, transforming and presenting this data in new and interesting ways.

Some, like TweetDeck, build client-side extensions. Others, like StockTwits, build server-side extensions. Yet the same message at the core remains unaffected.

Granted, a 140 character message is a heck of a lot simpler than a complex data store, but it seems that when you solve the right problem at the core, all sorts of unexpected upside surprises drop into your lap.

Hence, to me the fundamental “IT” becomes figuring out what it means to be native and cloud-ified; how you deal with asynchronous and real-time states within this domain; and what layer of the stack is elemental, and as such, needs to be open and transportable, and what layer can be proprietary and closed.

On some level, it hearkens back to the seven layer OSI networking model, which facilitated both interoperability and proprietary-ness at the same time.

Cheers,

Mark
–
READ: Right Here Now Services: Weaving a Real Time Web Around Status
http://bit.ly/i40h

I blogged about this and its relationship to Google Chrome OS and SOA a few days ago. See: http://sanjiva.weerawarana.org/2009/07/googles-new-os-project-soa-and.html

While as Tim notes, LAMP is an aggregation of components from lots of different sources, none of those components is exclusively licensed or locks you in any other way to a specific vendor. That means we can have a competitive commercial ecosystem of LAMP hosting providers, which drives all sorts of beneficial behaviors, competing on price and quality of service and SLA.

In contrast, if I build to Google App Engine, I have no other hosting choice if I decide that their hosting of my app is insufficient. If there is an independent implementation of the App Engine runtime that can be hosted by other cloud providers, then clearly that’s less of a concern. Amazon EC2 has less inherent lock-in since the deployment image is mostly the same as what you’d run in any other virtualization system; but the more you use company-specific APIs like S3, or AE, or Salesforce.com’s language, the more lock-in you inherently have.

I believe that the usual market pressures will push the cloud providers towards common interfaces and possibly eventually a common platform, the way that they drove the Unix vendors to Linux. Cloud app builders can help us avoid another twenty-year mistake like that, by encouraging cloud providers to move to common platforms (or by implementing alternative runtimes – OpenS3, or OpenAppEngine, anyone?)

Brian

p.s. – my gut tells me there *should* be an “OpenAppEngine” runtime project somewhere already, but I couldn’t find it, please prove me wrong! Especially now that we have a decent BigTable equivalent with Hadoop, etc.

Tools for compliance, security, SLAs and policies are being built out as we speak (http://s3.amazonaws.com/aws_blog/AWS_Security_Whitepaper_2008_09.pdf). And employees of Amazon or Google are disinterested parties (unlike internal IT staff) and so less likely to breach the policies and procedures. The overall benefit of public clouds will be very obvious in a few years. …

BTW: Enterprises use cloud based HR for the last 50 years (http://www.investquest.com/iq/a/adp/main/archives/anniversary.htm): it is called ADP.

I don’t agree with your assertion that private clouds are “a delusion”. Despite the tremendous hype that we’re seeing around Google and Amazon, a large proportion of our Enterprise (and public sector) customers are looking at building what they term private clouds. (The definition of which, BTW, is all over the map…many of whom are really just using cloud as a euphemism for moving to a modern, heavily virtualized data center environment).

We are seeing many enterprises *today* with funded projects for internal clouds. The elasticity mentioned is one of the benefits, but ranks behind others such as reduced OpEx, increased agility, and increased responsiveness to the business.

In addition, many organizations have some serious misgivings about potentially moving work and data out to an external cloud — how do they ensure that these remote systems are in compliance with their regulations or operational policies? How do they measure and manage the SLAs that their business users expect? What about data security? How are these systems audited?

I’m not saying that public cloud usage isn’t going to happen, but I believe that the preponderance of enterprise spending on “cloud” over the next couple years will be around private cloud creation and management – at least for production systems. Now, for development or non-production systems, I can easily see an uptake in the use of public clouds — there are far fewer concerns about the questions mentioned above, plus the workloads tend to be much more variable in scope and scale than for production systems.

I think open source is all about standardization. it’s been wildly successfull in the operating system space (chrome os and google are based on linux, no?), why not be a little open minded and aim to replicate this success on top of the stack? where it counts.

standardize data the open source way.

to mashup servers. not browsers. to enable computers to work for us. instead of the other way around.