Cisco Blogs
Share

Will Cloud Displace Partners Doing System Integration & Professional Services?

- June 2, 2016 - 0 Comments

“Enterprises won’t need systems integration and professional services if they shut down their IT Operations and move to the cloud.”

– Light Reading, May 31, 2016

Without any context, that quote could be wildly misinterpreted, and create some angst for you. Because if you’re reading this, you’re probably a Partner providing System Integration or Professional Services, or you do IT Ops for an Enterprise.

Let’s first acknowledge that there is obviously movement to the cloud, some to private, some to public. The reality is that workloads are moving to both. The quote above, however, is referencing public cloud specifically. I mean, if there’s no IT Ops, there’s probably no private cloud.

So what’s underneath the statement?  It was made in this excellent article from Mitch Wagner.  His objective was not to cast some gloom & doom story over Partners.  Quite to the contrary, it profiles how Hutchinson Networks, a Cisco Partner in the UK, is shifting its business and competing more effectively, in part, by leveraging automation with Cisco Application Centric Infrastructure (ACI).

Problem

Hutchinson anticipated that as its small/medium sized customers moved parts of their business to public cloud, need for their services would decrease, which would make growth challenging. Stephen Hampton, CTO for Hutchinson Networks said, “If this continues to accelerate, the need for in–house skills reduces further, and the need for our services starts to erode.”(1)

In this case study, Hampton added, “We see companies moving towards cloud connections and simple campus networks, which limits our ability to continue growing through consulting services.”

So what did they do? Hampton said, “We decided to turn this problem into an opportunity. We could use our deep networking expertise to deliver cloud hosting with advanced network services normally not seen in the cloud.”

Solution

Their new solution is called Fabrix and its based on ACI. It provides several differentiators (outlined in the resources below) including a heavy emphasis on automation.

“Many companies have managed data center services that they call a cloud, but the way we see it, a true cloud infrastructure should be completely automated,” says Hampton. “Cisco ACI and the Cisco Nexus 9000 Series Switches are built from the ground up for automation in a way that traditional platforms aren’t. The result is automation that is relatively easy to implement for Fabrix.” (2)

Rationale

SDN, Orchestration and Why Fabrix Went Cisco ACI is a post that, as the title would imply, covers some of the criteria for selecting ACI as the platform on which to build Fabrix. It covers several areas including cost, programmability and flexibility. It says, There are of course very cost effective combinations of open source controllers and white box switches. However, in most cases a lot of in-house development work is required. The Cisco ACI starter kit is very competitively priced. Also, the APIC (Application Policy Infrastructure Controller) has the considerable force of the Cisco development team behind it rather than just our own in-house DevOps. As a result, we expect to lower the total cost of ownership with Cisco ACI.”  The post continues with “Cisco APIC and the Nexus 9000 have been built from the ground up for automation…Easier automation in turn leads to easier orchestration.”

Cisco UCS Director is being used for orchestration and “is preconfigured with orchestration workflows that are integrated with the Cisco Application Policy Infrastructure Controller (APIC) to deliver unified deployment and provisioning across the entire environment, including Cisco ACI ecosystem partners, such as F5 for application delivery and Nimble for storage.” (3)

As far as flexibility, the post mentions that “… a very significant feature for Fabrix is Cisco ACI’s ability to support bare metal connections…” Along these lines, Light Reading mentioned “Cisco differentiates from VMware in that it integrates API with hardware, while VMware operates an overlay model. ‘We’re not building a different network and overlaying something on top’ ” Hampton says.

Since we’re on the topic of flexibility within the context of cloud, its worth mentioning that “Hutchinson also offers application extraction – the ability to move applications between multiple cloud platforms – using services from CliQr, which was acquired recently by Cisco, as well as Pivotal and Apprenda. Extraction can be tricky for non-cloud-native apps, which require policies around security and app delivery, as well as moving large data sets.” (4)

At this point, I do need to inject a little biased editorializing by saying I think its pretty cool how they are leveraging Cisco for compute, network, orchestration and public cloud extraction/movement. They don’t need to, because they could, for example, use ACI’s northbound API’s to integrate with other orchestration tools like OpenStack. In any case, it would appear they place a heavy emphasis on automation.  The ability to use consistent policies to accelerate and simplify automation across all these platforms is unique to Cisco.

So, we’ve covered Hutchinson’s problem (business disruption), solution (ACI) and the rationale used for arriving at the solution. Hampton summarized all of this nicely by stating:

“Cisco ACI is built for automation, giving our services the speed and cost-efficiency that our customers expect.” (5)

But Wait – There’s More!

Hutchinson Networks is one of five different customers profiled yesterday in this Press Release discussing how Service Providers worldwide are adopting ACI. I don’t have enough space to cover each of them here, but would encourage you to check out how ACI is positively impacting business at Integra, NTT DOCOMO, Tele2 and Manx Telecom, as well.

References/Resources:

(1) Light Reading article

(2) Case study

(3) Case study

(4) Light Reading article

(5) Success story

Hutchinson Post

Press Release

 

Image source: Pixabay

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.

Share