10 steps to avoid cloud vendor lock-in

10 steps to avoid cloud vendor lock-in

Summary: The Open Group consortium releases guidelines on what enterprises should be aware of, and what actions the industry should be taking to achieve greater standardization in the cloud.

SHARE:

Along with security, one of the most difficult issues with cloud platforms is the risk of vendor lock-in. By assigning business processes and data to cloud service providers, it may get really messy and expensive to attempt to dislodge from the arrangement if it's time to make a change.

Buildings-Time Warner Columbus Circle NY 2-photo by Joe McKendrick
Photo credit: Joe McKendrick

There are ways enterprises, as well as the industry in general, can address these lock-in issues. Solutions to potential vendor lock-in were recently surfaced in a new guide from The Open Group.

The guide, compiled by a team led by Kapil Bakshi and Mark Skilton, provides key pointers for enterprises seeking to develop independently functioning clouds, as well as recommendations to the industry on standards that need to be adopted or extended.

Here are 10 key problems and recommendations identified by The Open Group team for achieving cloud formations based on standards, rather than on vendor technology:

Platform-platform interfaces:  A universally used standard for platform-platform interfaces — the Internet, HTTP and message envelope layers of web service APIs — "would provide a major part of the basis for real cloud interoperability," the guide states.  The two styles of web service interface handled by platforms — WS-I and raw HTTP — each has strengths for specific applications. "Many small-scale integrations that originally used WS-I with SOAP and XML, because JSON was not mature enough at the time, are now moving towards raw HTTP and JavaScript Object Notation because it is better suited to their needs. However, for enterprise-level integrations, SOAP is still king."

Recommendations:

  • Use WS-I as the service platform interoperability interface between cloud services.
  • Use direct HTTP with JSON as the service platform interoperability interface.
  • "The industry should identify best practice in use of direct HTTP and JSON, including means of authentication and access control (such as OAuth), and develop standard profiles for interoperability between service platforms using this approach."

Application-platform interfaces: "Currently, there are a number of programming languages that might be used for the interface; there is no agreement on what functionality is needed; there are no commonly-accepted application-platform interface standards that cover the full range of functionality; however, it might be agreed. There are, however, products, both commercial and open source, that implement parts of the functionality, such as Enterprise Service Buses (ESBs), and some vendor-independent interface standards for part of the functionality, such as the Java Message Service (JMS)."

Recommendations:

  • "Enterprises should seek to use cloud platforms with vendor-independent programming interfaces."
  • "PaaS vendors stating that they support .NET or J2EE should say which versions they support."
  • "A language-independent specification of a standard cloud application platform interface should be defined."
  • "Instantiations of this should then be developed for the most widely-used programming languages."

Service descriptions: The accepted standard for service descriptions, the Web Service Description Language (WSDL), has limitations, the guide says: "Its descriptions are machine-readable rather than human-friendly; it describes the functional characteristics of services, but does not cover non-functional characteristics such as quality of service and conditions of contract; it has no real ability to describe service data models; and it applies to services that use the WS-I approach, but not to services that use the direct HTTP approach." Bodies working to develop standards for service descriptions that address some of these limitations include the Web Application Description Language (WADL) authors, the Open Data Center Alliance (ODCA), the SLA@SOI Consortium, and the OASIS TOSCA Technical Committee.

Recommendations:

  • "Produce clear human-readable descriptions of them, covering functional and non-functional characteristics."
  • "Enterprises developing services using the WS-I approach should also produce WSDL descriptions of them."
  • "Insist on the availability of clear and stable human-readable descriptions and, for services using the WS-I approach, of WSDL descriptions."
  • "The industry should work to establish best practice for human-readable service descriptions covering all service characteristics, building on the work of bodies currently active in this area."
  • "The industry should work to establish standards for machine-readable service descriptions, including templates and component schemas."
  • "These standards should cover all service characteristics and parallel the human-readable descriptions. They should include or be linked to descriptions of service data models, and be applicable to services that use the direct HTTP approach as well as to those that use the WS-I approach. WSDL forms a good starting point for such standards."

Service management interfaces: "Standardization of these interfaces will enable the development of cloud management systems as commercial off-the-shelf products," according to the guide." Initiatives alreday underway include the "DMTF Cloud Infrastructure Management Interface (CIMI) and Virtualization Management (VMAN) standards, the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA), the Open Grid Forum Open Cloud Computing Interface (OCCI), and the SNIA Cloud Data Management Interface (CDMI). The Openstack APIs may also provide de facto standards."

Recommendations:

  • Ensure that "management interfaces follow emerging standards where possible."
  • Look for services "whose management interfaces follow emerging standards."
  • The industry should support the ongoing cloud management standardization work, including the work in the DMTF, OASIS, OGF, and SNIA, and the Openstack open source initiative."

Data models: "These do not cover the new 'NoSQL' paradigms that are increasingly being used in cloud computing," the guide states. "Also, the schema standards do not enable correspondences between different data models to be established, and this is crucial for interoperability. The semantic web standards and the Universal Data Element Framework (UDEF) can be used to define correspondence between data models, but their application is not widely understood, and they are little used."

Recommendations:

  • Describe data models clearly, "using text and applicable schema standards. The descriptions should be computer-readable and have good human-readable documentation. A well documented XML schema would achieve this, for example, but just using XML probably would not."
  • Look for clear data model descriptions.
  • "The industry should establish best practice to describe correspondences between data models, should ensure that the standards in this area are fit for purpose, and should work to improve understanding of them."

Loose coupling: "Tightly-coupled components are difficult and expensive to integrate, particularly over the lifetime of a system that undergoes change (as most do)."

Recommendations:

  • "Cloud application components should be loosely coupled with the application components that interact with them."

Service orientation: "Cloud offerings are packaged as services (IaaS, PaaS, SaaS). Cloud platform-platform interfaces, whether in the WS-I or raw HTTP style, assume client-server interaction. Service orientation encompasses and reinforces other principles – loose coupling, service descriptions, and described interfaces."

Recommendation:

  • "Cloud applications should be service-oriented."

Marketplaces: "Use of marketplaces and app stores is growing, but there are as yet no standards or established good practice for their operation," according to the guide. "This means that product vendors must cater for the different requirements and practices of all the marketplaces in which their products appear, that customers must understand the different features of all the marketplaces that they use, and that marketplace operators are spending effort on unnecessary differentiation."

Recommendation:

  • "Industry bodies should seek to identify the best practices for marketplace operation, with a view to defining standards and working with governments on any legislation that may be needed to underpin them."

Representational State Transfer (REST): "There is a need for robust and scalable services that are loosely-coupled and have stable interfaces that are easy to describe."

Recommendation:

  • "Applications should be designed using the Representational State Transfer (REST) style, though without insisting on its full rigor."

Machine image formats: "The ability to load a machine image containing an application together with its application platform onto different cloud infrastructure services is a new form of portability that is made possible by cloud computing. A standard machine image format makes portability possible across different infrastructure service providers, as well as across infrastructure services of a single provider.

Recommendations:

  • "The Open Virtualization Format (DMTF OVF) standard is designed to meet the need for a machine image format standard."
  • Evaluate the OVF standard "and support it if feasible."

 

Topics: Cloud, Data Management, Virtualization

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

7 comments
Log in or register to join the discussion
  • Death, taxes, and the brain dead ideas of open source filth.

    How often do people get up and change platforms? NEVER. And yet the filth are always there with their "vendor lock-in" nonsense.

    Open Group consortium do the world a favor and kill yourselves, you won't be missed. Really.
    jackbond
    • Are you all bitter because you are locked in...

      ..to some off the shelf proprietary product that gives you no interesting implementation projects, no job satisfaction and yet still does not solve your problems?

      There may be some good options out there for you that allow to move between vendors and have a flexible infrastructure that allows for cost reduction moves and better DR.

      There is a potentially a better chance to avoid vendor lock in with cloud products than there has been for many other infrastructure based products. There are two reasons I can think of and both revolve around understanding the level of abstraction in the architecture. And that means actually understanding it and getting people involved to set it up properly not just paying for the latest platform/model/product and expecting it to work perfectly for any given scenario.

      The two reasons:

      1) Abstraction from the cloud infrastructre vendor - both OpenStack and full blown vCloud are being implemented by multiple infrastructure vendors. They may have slightly quirks in implementation but if you read the labels carefully you should be able to move between infrastructure vendors of your chosen cloud eco-system. Or between public and private. This sounds similar to a where you could have only 2 or 3 big eco-system players which comes close to the argument that lock in is unavoidable except the infrastructure vendors would be offering different support packages underneath the ecosystem from fully managed 24x7 phone to no-support-diy. This will then create some choices and avoid complete lock in.

      2) Abstraction from the eco-system - this is where it gets more complicated but truth is that if you do the hard work at the beginning you will have flexibility later on. You need to get into the "infrastructure-as-code" mentality in a big way. Get familiar with a configuration management tool like Puppet / Chef / Ansible / Salt and write descriptions for each piece of infrastructure. The annoying bit is then having to find the right orchestrator and bootstrap tools for the ecosystems, but once done you can affectively move between eco-systems, as a migration, as a burst, or even as failover or load balancing between data centres.

      If you go down this road you could make some big wins now and give yourself an infrastructure which can move around and so save company money in the future. Plus you might get more interesting projects to do, more job satisfaction and generally be a bit happier!
      jamfuse
      • Get yourself help nutjob

        Yes, do a ton of work now because someday you might want to change. Oh, and never mind that you'll be using crap implemented by brain dead filth at a snail's pace. Yah, that'll keep your job interesting.

        Here's some actually sane advice, pick Azure or Amazon, and don't look back.
        jackbond
  • this column fodder list

    Is typical of a FOSS zealot's attempt to stymie any innovation within an IT organization.

    Sorry boss, AWS or Azure isn't for us because of this obscure pseudo intellectual restriction. Best we wait (and become increasingly uncompetitive) waiting for the next Open platform to support this.
    hubivedder
  • The Open Group is not an open source organization

    It is the holder of the UNIX trademark and the official maintainer of the standards for what constitutes UNIX.
    John L. Ries
  • step 11

    Don't go to the cloud. Keep your data and processing safe in your site. Simple, no?
    Doc.Savage
  • Why would I put anything on the cloud

    When we find out that Microsoft, and Google, and probably Dropbox and the rest give open access to your files to the NSA who supposedly can see them if they have a mere 51% suspicion that you are a foreign national, or they get a rubber stamped unconstitutional blanket warrant to look at just about everybody.

    Ooh and giving all skype chat and video sessions, outlook mailboxes to the NSA under the same strict rules makes me want to give up cloud email as well. Just stick to the phone.
    marque2