Cloud: An unexpected lock-in

Emiliano Del Fiume,
Client Executive, Unisys

Organisations are concerned about risks of 'vendor lock-in'. Fears are rooted in mainframe era when capex on a specific technology usually drove customers to marry one supplier for long, long times. Once mainframes have been replaced by enterprise servers, departmental systems and personal computers we hoped to get freedom but… problem, in a way or another, were and is still here. Any supplier tries to keep you with him for the life

When Java appeared, many thought it was a panacea. It's not. When 'frameworks' arrived on the market we had the same thoughts. We were wrong again. Indeed, it has to be said, just before the cloud we experienced a bit more freedom: focus was on Web-based interfaces with standard languages so it was easier to replace underlying technologies when necessary. Just to throw an example: serving Web content can be done with different Web servers so you were able to replace your Windows IIS with an Apache. Later, even serving ASP.NET content became possible without an IIS behind the curtain. Shortly: we had more options, more freedom, but also more complexity to govern.

Then, cloud arrived.

Many already speculated on the usual lock-in risks linked to cloud solutions. Risks that shouldn't stop you to go to the cloud: project management teaches that risks have to be managed, they're not a black beast (they become a beast if you ignore...). You can google to find out many articles on the topic with interesting comments and smart tips (as an example, this one). You should take into account for sure

• Application transfer risk

• Infrastructure transfer risk

• Human resource knowledge risk

• Data transfer risk

• Prices raise risk

• Interoperability risk

One subtle risk is often not well evaluated and managed: the lifecycle risk.

Cloud vendors have their own plans and their roadmaps. Sometimes they tell you about changes with long notice, in other cases not; in most of cases this doesn't really matter: their roadmap is theirs, not yours so they can change whenever and whatever they want; they can decide to remove a functionality starting from 'n or 'n+1' (if you're lucky) release; they can decide to fork versions; they could break compatibilities.

All above moves are well ruled by vendors contracts (I mean: are ruled in a way that allows them to do) and, in principle, cited changes do not necessarily impact your end users. Problem is elsewhere: you, as a client, have to implement a reactive approach for managing the lifecycle of your IT. Technologies are not anymore in your datacenter so the lifecycle is definitively not in your hands anymore (or not entirely): you are required to be smart, agile, reactive (very reactive!). This is especially true if you're a bureaucratic organization that reacts slowly to the changes: Cloud suppliers do periodic minor and major releases, you have to find out a way to react. No way to avoid!

So, what's the point here? Point is organizations should pay attention to the solutions lifecycle management. Going to the cloud, they should focus more on strategies and tactics: technical details are left to the cloud suppliers and to system integrators that provide managed services for monitoring, administering and updating the cloud (as an example, see Unisys CloudForte). Smart strategies with precise, but flexible plans are key to exploit the cloud avoiding to run after continuously, to become a 'slave' of supplier's roadmap.

At high level, you could see the context as follows:

• With IaaS you keep most of the power in your hands; obviously, side effect is you have to manage most of IT aspects. If your cloud supplier is not satisfying you anymore or is changing something drastically (including pricing...) you can move your solutions into another IaaS relatively easily.

• With PaaS you're in the middle: it's crucial to leverage frameworks and interoperability solutions in order to decouple your solutions from the underlying platforms. This guarantees to your applications to run on different cloud environments with less changes vs the third option below.

• With SaaS you get the best and the worst: Your cloud suppliers does everything on your behalf but… you cannot move quickly and easily from a SaaS to another. Here comes the need to focus on solutions lifecycle management looking proactively to the future, monitoring precisely your suppliers and paying much attention to the contractual clauses and the SLAs. To be clear: I'm talking about large organizations that do not use the standard and stand-alone functionalities of a single SaaS: I'm looking at large orgs that integrate several SaaS and implement several 'customization' to the standard solutions.

Said shortly: organizations should change their focus when moving to the cloud: IT raises itself to a governance role more than to a technical one. It's crucial to mind the SLAs, to understand precisely the suppliers' strategies and roadmaps, to leverage decoupling technologies. For companies that leverage more than one cloud: it's also crucial to find out a way to sync or at least create a consistent bridge between the different SLAs from the suppliers and to be sure all contracts with them are, in a way or another, linked in a useful way.