Posted by: Brian Gracely
Cloud Computing, Data Center, Google, Henry Ford, Licensing, Open Source, OpenStack
A funny thing happened on the way to the next wave in IT technology – Cloud Computing – people seemed to want combine the portability of a time-machine with the freedom to change of the 1960s. Not only do people want the benefit of unlocking IT service delivery from capital expense budgets, but more and more they also want the flexibility to move the source of those services to any location or any provider.
Then reality sets in and they are faced with the challenges of Data Gravity, multiple variations of APIs, multiple variations of projects, and other nuances that highlight that we’re still quite a long way from being able to switch between any cloud computing service as simply as we plug into any Ethernet port.
So given that we’re still in the early days of this next wave, what is an appropriate level of concern to have for “lock-in” vs. focusing on bringing new value to the business via technology? And are there specific areas where lock-in might be more of a concern that other areas?
In the past, we often looked to standards bodies (eg. IEEE, IETF, W3, etc.) to define interoperability. But in today’s world, there are as many best-practices being defined via open-source projects as in any standards-body, so companies now need to decide if they value pace-of-change over standardization. IT organizations have traditionally leaned towards risk-migration as the higher priority, which is often in conflict with their business-side counterparts that want results now and aren’t thinking about the management and maintenance of legacy systems years into the future.
In some cases, we’re seeing levels of standardization between defined by loosely defined committees (eg. Open Data Center Alliance; podcast) or by groups of providers looking to establish market-baselines (eg. Cloud Foundry Core; podcast). Some companies view efforts like this as a good thing as it moves them farther along towards levels of interoperability, but there are still some in the industry who are never satisfied with the level of “openness” or often seek to find alternative motives from committees or vendors.
With bleeding edge technologies, we’re often faced with the challenge of no existing standards since the technologies are so new that a focus on standardization has not been anyone’s priority. Technologies like Software-Defined Networking (SDN) fit this category today.
Ultimately the answer to the trade-off between complete standardization and keeping up with change should be driven by business needs. Waiting for a piece of technology to become completely standardized or be “completely open” means trading off business opportunity now. Demanding the freedom of portability, whether it’s at the application or provider level, typically means giving up some of the advanced functionality that made the technology unique for the business needs at the time.
Inevitably, change creates costs. Either opportunity costs, capital costs or operational costs. Whether that change is high in the stack (applications, development frameworks, middleware) or down in the technology weeds (management software, operational process, worker retraining, etc.), there is always going to be a cost. It’s critical that both the business and technology “costs” are evaluated and considered when trying to determine whether to focus on standardization or openness. Neither come for free.