Is cloud computing creating a new type of technical debt?
Guest post by Daniel Smithson
Don’t incur technical debt with the cloud – employ a cloud abstraction product
The arrival of cloud technologies has led to a gold rush of adoption. Cloud technologies appear to offer organisations the nirvana of rapid, on-demand elastic compute provision, be that through public, private or hybrid deployments. Having embraced the benefits of self-service infrastructure, organisations are now embarking on developing cloud-centric applications that harness the ability of the cloud to expand and contract infrastructure capacity based on application demand. However, to do so applications need to be coded to exploit the API of the chosen cloud platform. And this may have a sting in the tail - technical debt.
Organisations that were quick to adopt cloud technologies did so against the backdrop of a rapidly evolving marketplace with proprietary and open source solutions vying for attention. Some organisations initially sought to build a private cloud capability as concerns over information security deemed public cloud solutions too risky. Other organisations sought to avoid the traditional capital investment required to construct a new capability by employing one of a number of public cloud offerings. Having built the cloud, the application developers quickly followed and so did the birth of cloud-centric applications. In many cases, early adopter organisations may now be considering or embarking on the next step in the evolution of their cloud deployments. However, having built cloud-centric applications, changing the cloud platform by exchanging private cloud solutions, moving cloud providers, or adopting a hybrid cloud solution will probably entail expensive and disruptive application re-writes – the price of technical debt.
In step the cloud broker or cloud abstraction products
Abstraction libraries or products such as CloudSwitch, enStratius (now Dell) MulticloudManager, Gravitant cloudMatrix and Cloud Forge Publisher sit between applications and the cloud platform, translating application infrastructure calls to the API call of the chosen cloud platform. What does this mean for organisations and why should they care?
By providing a layer of abstraction between the cloud platform and the cloud-centric applications, organisations have greater freedom to change their chosen cloud solution, public, private, hybrid, proprietary, or open source, without fear of incurring unwanted application re-writes. Given the continually evolving cloud marketplace, this freedom is critical.
For organisations feeling hesitant at the prospect of employing cloud the ability to avoid expensive vendor lock-in should act as a catalyst in their adoption of cloud technologies and the benefits offered. For those organisations already employing cloud, implementing a cloud abstraction layer will either limit or reduce the already incurred technical debt. The cloud and cloud abstraction marketplace continues to present a complex and evolving landscape. Navigating this landscape is likely to require expert help.
What are your views of cloud brokers and cloud abstraction? Add a comment below or use the Twitter link to let me know what you think.