Home > Cloud Computing, Cloud Security > The Cloud & eHarmony’s 29 Dimensions Of Compatability…

The Cloud & eHarmony’s 29 Dimensions Of Compatability…

November 23rd, 2009 Leave a comment Go to comments

I speak to many customers — large companies in numerous verticals and service providers —  who are for the reasons we are all very well aware of, engaging in projects large and small focused on Cloud adoption.

On the enterprise side, the dialog almost inevitably goes like this:

We’re working on taking applications and data which are not heavily regulated/compliance scoped, business critical or contain sensitive information and move them to a public cloud provider like AWS — we’re also considering virtual private clouds to use public cloud infrastructure in private ways.

We’ve had great success with low-hanging fruit and grid-like utility offerings, but we’re having a bear of a time with real “applications” — taking them as they run today internally and making them run the same way on someone elses’ kit.  It’s not always the application, either, but rather the attendant dependencies on other critical IT-centric functions that cause the issues (Ed: “metastructure”)

In parallel we’re engaging in building private clouds for critical applications that either have complex development and support/integration issues that are not ready for running on others’ infrastructure and/or have compliance and regulatory requirements that prevent us from moving them off our infrastructure.

We’re continuing to invest and optimize our internal virtualization deployments; we’re reducing footprint but really increasing compute, network and storage density.  Don’t let the smaller physical space fool you, we’re getting bigger in more efficient floor plans.  We’ve standardized on VMware. We’re figuring out how vSphere and vCloud intersect and what that means in the long term and how that impacts our choice of Cloud providers.

We understand that using the same vendor we use for virtualization to ultimately deliver our private cloud should yield easier portability and workload interoperability, but we’re worried about vendor lock-in…sort of.

We’d really like to be able to move workloads/applications/information in and out of private clouds to public/virtual public offerings and support workloads/applications/information that were born in the cloud on our private cloud, too.  These present a whole host of security and lifecycle management issues.

In the long term, what we want to do is build a self-service portal (not unlike apps.gov) that depending upon business logic and security/compliance requirements, etc. will allow a business constituent consumer to deploy packaged or bespoke workloads/application/information and not have to care about where it runs.

That would be nice.  We’d like to be able to do that with the thousands of applications we already support today.

We’re investigating cloud brokers currently, but most don’t do what they advertise they do or have severe limitations. While they often plug the gaps between the various cloud providers, we trade one vendor lock-in problem for another with custom orchestration and provisioning frameworks.  We’re trying to roll our own — cobbling together bits and pieces — but it’s an integration nightmare.

The lack of standard APIs and competing implementation semantics with immature sets of management, security, provisioning, orchestration and governance solutions really makes this all very, very difficult.

What should we do?

This story is the same over and over.

It’s literally the Cloud equivalent of eHarmony.com’s 29 dimensions of compatibility; it’s such a multidimensional problem in large enterprises that have a huge number of applications (thousands) and a ton of sunk infrastructure, mature decades-old operational practices, cultural dispositions, and economic pressures that it’s hard to figure out what to do.

For large enterprises (and the service providers who cater to them) Cloud is not a simple undertaking, at least not to those who have to deal with bridging the gap between the “old world” and the new shiny bits glimmering off in the distance.

Consider that the next time you hear a story of cloud successes and scrutinize what that really means.


  1. November 23rd, 2009 at 20:09 | #1

    This is why arranged mainframe marriages work so well. "We don't care what you want, you'll run it on this and you'll like it."

  2. November 23rd, 2009 at 20:49 | #2

    Animoto! Animoto! Animoto! Animoto! Animoto! (hands on my ears, I can't hear you!)

  3. November 23rd, 2009 at 19:55 | #3

    …One of your best posts yet…a dose of reality with a parity that is spot on.

  4. November 24th, 2009 at 02:11 | #4

    Animoto – well said, William.

    Startups are the early adopters of cloud because they have little to zero legacy holding them back.

  5. November 24th, 2009 at 04:25 | #5

    Hey, we've never even met and you nailed it! ;-} Legacy = inertia Many successes touted as cloud are just relabeled legacy (grid, ASP, virtualization etc.) or are small projects, off to the side of the real business of IT. Large enterprise acceptance of any new technology is about one thing; how does this help my business? Yes, Mr. Cirrus, my mainframe can be quite expensive but to convert to your ElastaCloud 3000, it will cost me eleventy jillion to rearchitect my workloads, expose me to untold risks, & freeze all app dev that actually contributes to gaining customers. I'm not seeing the value. How about if I get the ElastaCloud 350 and put my test environments on it? That will save me some money at least.

  6. Gilad
    November 24th, 2009 at 04:34 | #6

    Interesting post. Do you also have a view on which sub-components of clouds (e.g. AWS) these people are using? Is it compute, blob storage, NoSql or DB? And to what degree? Thanks.

  7. November 24th, 2009 at 05:02 | #7


    In many cases, esp. finance & pharma, the components they are using when they first dip their toes in are EC2 and S3 MapReduce (for reasons which are likely obvious.) These are clearly IaaS-focused. SaaS engagements run the gamut: email, security services, etc.

    PaaS is a challenge for many of these companies depending upon the spread investment in development frameworks and programming languages…

    I think it's fair to suggest that this post was primarily addressing the IaaS elements as a major stumbling block.


  1. November 23rd, 2009 at 20:01 | #1
  2. April 30th, 2010 at 08:56 | #2