IMO, this topic of cloud lock-in is way over blown and more of a “blog” topic then anything else. Most commercial clouds are “Linux” servers. If enterprise companies are concerned about lock in with the cloud then why are not concerned with lock-in’s with AIX vs. Sun Vs. Linux vs. MS? In the cloud the only real lock-in for most cloud vendors is the API. Have you ever worked with NIM server? In fact you mention Eucalyptus as an alternative they actually map Amazon’s WSDL (API) so that is not really a great example. In the end running applications in the cloud is not really going to be to terribly different from running applications on VMWare (not including the security issues). The enterprise in the future will most likely use the cloud as spare parts for elastic workloads.

Gigaspaces is a great example for non-lock in. If a company uses Gigiaspaces the can run their application internally or in the cloud(s).

my 2 cents
johnmwillis.com

Cloud computing / On Demand / Grid Computing / XSP’s - aren’t they all basically the same ideas of giving enterprises access to compute / memory / bandwidth as they require (”buying” versus “building”?). Marketing term or actual technology domain?

Botchagalupe,

I disagree with your assertion that cloud lock-in is a made-up topic by bloggers. It is a very real issue for many [large] companies assessing how to take advantage of this cloud wave with the least exposure/risk.

Your Gigaspaces “lock-in” rationale misses the point. It’s not about being locked-in to onsite or on-demand deployment models, it’s about being locked into a specific vendor’s piece of technology (ex. API, data storage mechanism, etc.).

I believe Matt’s point re:lock-in has to do with the availability of a valid choice (or two or three) that do not require rewrite or “porting” of a cloud-based solution. Having the flexibility to deploy internally (onsite) or in the cloud (on-demand) helps ensure that certain companies are able to begin their adoption process.

Eucalyptus, for example, relieves the Amazon lock-in since it provides compatibility (by implementing a defacto standard). It further relieves lock-in if other solutions leverage it (embed it, extend it) for its Amazon compatibility. Thus making compatibility “table stakes” and leveling the playing field.

Finally, your question re: AIX vs. Sun vs. Linux vs. M$ misses the point. Cloud-based systems, in my mind, are abstractions above the Operating Systems, thus making that layer swappable (i.e. inherently not locked in).

[...] Aslett raises a good question for the future…who will be the first to establish an open source [...]

First - a clarification. Whether on the cloud or not, GigaSpaces doesn’t lock you in because it uses standard programming models and frameworks (e.g., Spring/POJOs, JMS, Hibernate, .Net). What it also does is allow you to take an existing application and cloud-enable it with minimum or no code changes, providing it with a sscale-out architecture, self-healing the ability to scale and shrink on-demand, the ability to ignore the physical location of services, etc.

The question is do we really need special standards for the cloud, or should we find a way, as GigaSpaces has done, to shield the developer from the unique aspects of the cloud?

I am not familiar with Eucalyptus yet (will look into it), but if it requires a new way of doing things it’s not a good solution, even if it’s open source.

Geva Perry
http://www.gigaspaces.com

Assuming that simply open sourcing something will provide interoperability is naive. Several cloud providers already use Xen and Linux, but as you note there’s no portability because the vendors have layered on proprietary interfaces, storage, etc. Eucalyptus, by the way, doesn’t solve the problem of lock-in for AWS either. They simply implemented the API, but it’s over Rocks and not Xen. Plus they don’t have an S3 or SQS implementation. And even then, they’d need to know how AWS set up their zones to make it truly compatible. Therefore, no portability.

As the only vendor to demonstrate unlimited application portability between data centers, 3tera is ready to open the kimono and share what we’ve learned in order to achieve portability between vendors. In fact, in our latest release we’ve exposed the definition language that is the secret sauce so users can see it and edit it. It’s only the first step, but a necessary one.

Second sourcing is one of the single most important strategic considerations for the use of any ubiquitous, well defined and commodity like activity. This is not only for the reasons of security consideration and vendor lock-in, but also for the reasons of competitive pricing.
The manufacturing industry is well used to such concepts, IT is only just entering the stage where activities are ubiquitous and well defined enough to be provided as common services.
It was clear from the London Cloud Camp that potential consumers of such services are concerned about these factors, and without portability and interoperability between providers there will remain barriers to adoption.
However portability and interoperability is only possible if the service provided is based upon the same standard (i.e. no more and no less), which is why I have long argued for the need for open source standards (i.e. open sourced operational reference models of the service).
Since my talk at OSCON back in 2007 (based upon my earlier talks on this subject, video is here), we have started to see potential open sourced standards such as the open SDK of GAE and Eucalyptus appear.
Such standards (at various levels of the aaS - as a Service - stack) will almost certainly grow through the normal cut and thrust of market forces rather than be created by committees.
We will see de facto standards in the cloud and not de jure.
Open source obviously provides the fastest way of operationally implementing a standard between vendors but it is also in keeping with the shift from a product to a service based economy. Not all products will move in this direction, some activities are simply not ubiquitous enough. Furthermore commoditisation does not mean that innovation will stop (see creative destruction) as both innovation and commoditisation are nothing more than consequences of the continuing process of change.
The shift towards services and open source in the cloud, will result in further componentisation of the software stack and the business activities built upon this and should result in ever faster business innovation.
Not everyone is happy with this, especially those for which fortunes are made in a product based world. But then town criers lamented the growth of newspapers and newspapers lamented the growth of blogging - that’s progress for you.
As for competitive advantage with cloud vendors, the purpose of an open source standard is to provide the reference model and to solve the issue of portability and interoperability between providers of the same service. This does nothing to prevent operational advantages being created with how the code is implemented. This is also why GPLv3 rather than AGPL is the ideal license for creating competition in a cloud computing world based upon open sourced standards.
It is also why trademark and compliance authorities will become key to such marketplaces. Compliance to the same primitives (the open sourced standard) can be assured through such mechanisms whilst vendors can compete on operational advantages without strategic loss of control of their business to a technology vendor.

[...] seeds of my presentation can be found in this post I wrote a year ago today discussing the idea that open source had the potential to level the [...]