Cisco Blogs
Share

Cisco Intercloud Services and Why the Network Matters

- May 27, 2015 - 0 Comments

Cisco Intercloud Services and Why the Network Matters

I’d like to open by restating a position on Cloud: Cloud is only in its very infancy in terms of adoption. Despite all the hype in market, largely created by the marketing of the over-the-top service providers, most of global IT spending is in the non-Cloud space. (somebody will have a stat on this but I heard it is below 10%).

So why do you think this is?

It’s All About the Network!

There are likely many reasons, such as Cloud services time in market and the test of maturity. But in my mind, one main factor stands out (and needs more consideration in my opinion): the combined value of the Network and Cloud.

As I pointed out in my last blog post, the focus of the Intercloud is “connecting the world of isolated applications and providing ubiquitous access to data processing and storage endpoints”. This vision brings back into play the concept of network centricity, where the core Cloud services architectures does not stem around islands of compute capacity to support workload types, but rather the network’s ability to scale and support cross Cloud application deployment scenarios.

The biggest barrier to adoption of Cloud services by IT is platform suitability for the mix of differnet application types existing in the IT environment. Looking at Cloud and the platform in a network centric view can remove this barrier.

So What’s in Market?

To address the obvious issue with compute centric Cloud platforms, many Cloud Service Providers typically leverage overlays like VPN tunnels to connect Cloud service end points. Although this might address a requirement for an encrypted path of connectivity, it does not align well with the benefits Cloud is meant to address.

In typical IT environments, we statically optimize infrastructure such as compute, storage and networks for applications requirements. We then adopt change control processes and policies to make adjustments to these rigid and static definitions. However, moving whole of IT into the Cloud presents a different set of challenges – although Cloud environments can provide an equivalency for application deployment in the domain of compute and storage, they do not provide the same set of feature richness in terms of network.

Typically, this goes against what we hear in market as the value proposition presented for Cloud in terms of elasticity, scalability and automation. The challenge we see is to revert back to internal methods of change control whenever we need to make an adjustment to the Cloud and its’ intersection with the network.

So Whats the Upside For The Cloud and Network?

The good news is that Cisco Intercloud Services will drive the combined value of Cloud functionality across infrastructure domains including compute, storage and the network. Whilst there will be a focus on ensuring network overlay solutions are available where required, there is also a focus on ensuring the underlay network is in highly cohesive with the overlay services.

Although many over-the-top service providers claim that the underlay is merely a set of commoditised plumbing, it’s actually key in assuring the application path and performance optimization. While service abstraction is typically seen as overlay networks, we gain limited control in terms of scale, elasticity and automation. Eventually overlays reach their limits and we go back to engineering orders and tasks to imperatively drive the overlay requirements. Such imperative controls are time consuming, cumbersome and can never be fully automated in operations.

Adopting the declarative approach across a wider abstracted network stack of combined overlay and underlay achieves the Cloud paradigm outcome of functionality in areas like scale, elasticity and automation. Simple calls to a set of well defined set of APIs into the Cisco Intercloud to request a network service that provisions that overlay ask and the underlay optimised requirements, with multiple Cloud service endpoints, and letting the Intercloud platform figure out how to achieve this one transaction is a far better approach. The alternative is adopting traditional IT change and tasks born around imperative approaches to “please do this, error and requisite check, and then repeat …”.

In Summary

So as I’ve mentioned, many of the in-market Cloud Service Provider portfolios are missing a key component of network services functionality, as aligned to Cloud paradigm capability. Cisco is in a unique and has a front foot position to drive the combined Cloud and network differentiated position for global application outcomes and architectures with the Intercloud and Cisco’s partners.

The Cisco Intercloud Services platform will drive Cloud plus combined network programmable consumption. So look out for my next blog topic where I’ll dive a little deeper into Developing Applications on Cisco Intercloud.

In the meantime, I’d love to continue the conversation. Feel free to connect with me on Twitter or Linkedin

Until next time, Kon.

Tags:

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.