Sourcing IT: Cloud Computing Roadblocks

Roadblocks

Cloud computing, which is part of the widespread adoption of a Service Oriented Business approach, becomes pervasive, and is rapidly evolving with new propositions and services. Therefore organisations are faced with the question how these various cloud propositions from different providers will work together to meet business objectives.

The latest cloud computing study of 451 Research showed some interesting key findings:

  1. Sixty percent of respondents view cloud computing as a natural evolution of IT service delivery and do not allocate separate budgets for cloud computing projects.
  2. Despite the increased cloud computing activity, 83% of respondents are facing significant roadblocks to deploying their cloud computing initiatives, a 9% increase since the end of 2012. IT roadblocks have declined to 15% while non-IT roadblocks have increased to 68% of the sample, mostly related to people, processes, politics and other organizational issues.
  3. Consistent with many other enterprise cloud computing surveys, security is the biggest pain point and roadblock to cloud computing adoption (30%). Migration and integration of legacy and on-premise systems with cloud applications (18%) is second, lack of internal process (18%) is third, and lack of internal resources/expertise (17%) is fourth.

It looks like that many organizations believe in a fluent evolution of their current IT infrastructure towards a cloud computing environment. Where on the other hand, right now, organisations are facing significant roadblocks.

Remarkably in the top four of roadblocks that are mentioned in this study, one very important roadblock is missing.

The cloud computing service models, offers the promise of massive cost savings combined with increased IT agility based on the assumption of:

  • Delivering IT commodity services.
  • Improved IT interoperability and portability.
  • A competitive and transparent cost model on a pay-per-use basis.
  • The quiet assumption that the service provider act on behalf and in the interest of the customer.

SiloBuster2

So with cloud computing you could get rid of the traditional proprietary, costly andinflexible application silos. These traditional application silos should be replaced by an assembly of standardised cloud computing building blocks with standard interfaces that ensures interoperability.

But does the current market offer standardized cloud computing building blocks and interoperability?

Commodity

Currently the idea is that cloud computing comes in three flavors. This is based on the reference model of the NIST institute [1]:

  1. Cloud Software as a Service (SaaS); “The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email).”
  2. Cloud Platform as a Service (PaaS); “The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider.”
  3. Cloud Infrastructure as a Service (IaaS); “The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications.”

Each standard service offering (SaaS, PaaS, IaaS) has a well-defined interface. The consequence of this is that the consumer can’t manage or control the underlying components of the platform that is provided. The platform offers the service as-is. Therefore the service is an IT commodity service, customization is by definition not possible [2].

But is this a realistic picture of the current landscape? In reality the distinction between IaaS, PaaS, and SaaS is not so clear. Providers are offering all kind of services that don’t fit well in this 3 flavor scheme. Johan den Haan, CTO of Mendix, wrote a nice blog about this topic where he propose a more detailed framework to categorize the different approaches seen on the market today.

Besides a more granular description of cloud computing services, a distinction is made between compute, storage , and networking. Which aligns very well with the distinction that can be made from a software perspective; behavior (vs. compute), state (vs. storage), and messages (vs networking). The end result is a framework with 3 columns and 6 layers as showed in the image below.

Cloud Platform Framework. Courtesy to Johan den Haan

Cloud Platform Framework. Courtesy to Johan den Haan.

  • Layer 1: The software-defined datacenter.
  • Layer 2: Deploying applications.
  • Layer 3: Deploying code.
  • Layer 4: Model/process driven deployment of code.
  • Layer 5: Orchestrating pre-defined building blocks.
  • Layer 6: Using applications.

 While layer 2 is focused on application infrastructure, layer 3 shifts the focus to code. In other words: layer 2 has binaries as input, layer 3 has code as input.

The framework shows the complexity organisations are facing when they want to make the transition to cloud computing. What kind of interfaces or API’s are offered by the different cloud providers are they standardized or proprietary? What does this means for migration and integration?

Interoperability

The chair of the IEEE Cloud Computing Initiative, Steve Diamond[3], stated that “Cloud computing today is very much akin to the nascent Internet – a disruptive technology and business model that is primed for explosive growth and rapid transformation.“ However, he warns that “without a flexible, common framework for interoperability, innovation could become stifled, leaving us with a siloed ecosystem.”

Clouds cannot yet federate and interoperate. Such federation is called the Intercloud. The concept of a cloud operated by one service provider or enterprise interoperating with a cloud operated by another provider is a powerful means of increasing the value of cloud computing to industry and users. IEEE is creating technical standards (IEEE P2302) for this interoperability.

The Intercloud architecture they are working on is analogous to the Internet architecture. There are public clouds, which are analogous to ISPs and there are private clouds, which an organization builds to serve itself (analogous to an Intranet). The Intercloud will tie all of these clouds together.

The Intercloud contains three important building blocks:

  • Intercloud Gateways; analogous to Internet routers, connects a cloud to the Intercloud.
  • Intercloud Exchanges; analogous to Internet exchanges and peering points (called brokers in the US NIST Reference Architecture) where clouds can interoperate.
  • Intercloud Roots; Services such as naming authority, trust authority, messaging, semantic directory services, and other root capabilities. The Intercloud root is not a single entity, it is a globally replicated and hierarchical system.
InterCloud Architecture. Courtesy to IEEE.

InterCloud Architecture. Courtesy to IEEE.

According to IEEE: “The technical architecture for cloud interoperability used by IEEE P2302 and the Intercloud is a next-generation Network-to-Network Interface (NNI) ‘federation’ architecture that is analogous to the federation approach used to create the international direct-distance dialing telephone system and the Internet. The federated architecture will make it possible for Intercloud-enabled clouds operated by disparate service providers or enterprises to seamlessly interconnect and interoperate via peering, roaming, and exchange (broker) techniques. Existing cloud interoperability solutions that employ a simpler, first-generation User-to-Network Interface (UNI) ‘Multicloud’ approach do not have federation capabilities and as a result the underlying clouds still function as walled gardens.”

Lock-in

The current lack of standard cloud services with non proprietary interfaces and API’s and the missing of an operational cloud standard for interoperability can cause all kinds of  lock-in situations. We can distinguish four types of lock-in [2]:

  1. Horizontal lock-in; restricted ability to replace with comparable service/product.
  2. Vertical lock-in; solution restricts choice in other levels of the value chain.
  3. Inclined lock-in; less than optimal solution is chosen because of one-stop shopping policy.
  4. Generational lock-in; solution replacement with next-generation technology is prohibitively expensive and/or technical, contractual impossible.

Developing interoperability and federation capabilities between cloud services is considered a significant accelerator of market liquidity and lock-in avoidance.

The cloud computing market is still an immature market. One implication of this is that organisations need to take a more cautious and nuanced approach to IT sourcing and their journey to the clouds.

A proper IT infrastructure valuation, based on well-defined business objectives, demand behavior, functional and technical requirements and in-depth cost analysis, is necessary to prevent nasty surprises [2].

References

[1] Mell, P. & Grance, T., 2011, ‘The NIST Definition of Cloud Computing’, NSIT Special Publication 800-145, USA

[2] Dijkstra, R., Gøtze, J., Ploeg, P.v.d. (eds.), 2013, ‘Right Sourcing – Enabling Collaboration’, ISBN 9781481792806

[3] IEEE, 2011, ’IEEE launches pioneering cloud computing initiative’http://standards.ieee.org/news/2011/cloud.html