Cloud silos: the problem they forgot to mention
Is your cloud app a legacy?
It is always good to cover new ground. In our recent Regcast, Workload Placement in a Hybrid World, we dealt for the first time (but almost certainly not the last) with the concept of legacy cloud applications.
On the face of it, calling a cloud service legacy seems like a rush to judgement. Usually we get through the buzzwords more slowly. It takes a few years for something in IT to go from leading edge to commodotised.
Also, we know that most Reg readers are still deliberating whether to use public cloud services at all and that most cloud adoption is yet to come. In the real world, cloud can’t be past it because it hasn’t even arrived.
But among the early adopters, some have discovered they have the Wrong Type of Cloud.
The clue is in the title of the Regcast: the discussion between David Chalmers, chief technologist for HP’s enterprise group, and Dale Vile, CEO of Freeform Dynamics, was about where to put workloads for maximum benefit.
It is not a simple question to answer: given the choice of internal apps, colocation, private or public cloud, few users would pretend that every workload is in the right place for the most operational efficiency.
Optimum workload placement also has to account for internal politics, the range of skills you can deploy and the openness of the platforms on which the apps are being implemented.
The last of these is fundamental. Vile warns that early cloud deployments, whether DIY or SaaS purchases, often failed to provide even a minimum of openness.
"There are some cloud services that people should migrate from"
“People have made purchases of point solutions over the last four to five years. Those people have silos of cloud services,” he says.
“It has come through loud and clear. I would argue that there are some cloud services today that people should migrate from.”
The questions to be asked are the basic preoccupations of any IT project. What are the APIs of the application? How is the data held and can you move it to another location?
In the cloud world, Vile adds, “a lot of this stuff is seriously proprietary, you really have to be careful”.
Chalmers says he has many customers whose early adoption of cloud has been a dead end because they are stuck with one vendor or an unsuitable application.
He divides your platform choices into four broad areas: DIY, single-vendor cloud, paid services-led integration and a fully open solution.
All of the first three choices (especially vendor-driven public cloud applications delivered for a vertical solution) may result in a disjointed set of cloud silos, he warns, even when systems integrators lead an infrastructure development.
“Systems integrators should have the economies of scale and skills in all the areas, but there is going to be a degree of lock-in,” Chalmers adds.
If you are trapped in cloud silos, your workload deployment today may be optimal but it won't be able to adjust to changes in demand or emphasis. In this case, cloud will not provide the flexibility and integration expected of it.
Chalmers recommends that open architectures and adherence to standards should be a red line – like similar red lines in areas such as security or compliance – that cannot be crossed in a dash to cloud.
“That’s absolutely my opinion,” he says. “Last year you had to [implement cloud] with proprietary technology; this year we are making the crossover.
"From next year onwards, why would you buy the proprietary technology if the open stuff is better?”
Vile demurs only on one point: that it may be necessary to accommodate cloud services in the short term that include some lock-in if there are enough benefits in other areas. As an example of his Red Line Plus strategy he points to Salesforce.com: at one time “seriously proprietary” but much easier to integrate with other applications.
As with all aspects of workload placement, there are trade-offs between performance against manageability and cost. But the experience of some cloud early adopters suggests that avoiding cloud silos must also be factored in. ®