Cisco Blogs

Services in a Cloud Computing Environment

- December 3, 2008 - 2 Comments

Quite a few years ago, when we we positioning the concept of the intelligent network, we had a slide that showed how features moved from servers or dedicated hardware to the the network over time. The trigger was usually when a service, say name resolution, became broadly used. At that point, it was seldom workable to have that service delivered by a place in the network–it needed to be ubiquitous…and highly available…and scaleable…and manageable…and usually ended up as a network service.Reading a recent post by the ever fearless Christofer Hoff and the related Twitter exchange got me thinking about this again. Once we cut through the cloud-hype and start looking at the practicalities of implementing things like workload portability, I think the lessons of the past will re-assert themselves, this time with things like security and L4-7 services. There was a time when security=firewall, in essence, security was associated with a specific place in your network. Now, to be effective, security needs to be pervasively deployed and deliver security services that ubiquitous and consistent–no matter where a workload runs (my desktop, my data center, someone else’s data center) the security policy must be consistently implemented. In short, models that depend on services such as security or load-balancing being associated with a specific place in the the network or a specific piece of infrastructure will not survive the transition. We need to be able to implement services wherever they are needed–the ability to provide security services to a given workload cannot be constrained by whether that workload happens to be running on a server that happens to be plugged into a firewall–it would be like saying you can only call certain area codes from certain certain extensions in your house–“Oh, you want to call New York? You’ll have to use the phone in the guest bedroom…”For us, this is in our DNA–you plug into the network, you get access to all its goodness. As an example, our SAN solutions are built upon the concept of and intelligent fabric, where critical services are a function of the network,not a specific box. This means that I don’t have to worry about a server dying and taking my VSAN routing with it. It also means my capacity and performance automatically scale-up and scale-down with the number of switches in the network.Unified fabric is an extension of this concept: plug into a unified fabric and you automatically have access to all your storage resources–no HBAs, no fiber runs, no fabric switches–access to storage is no longer a function of having specific infrastructure deployed. VN-Link and the Nexus 1000V are also a logical extension of this concept: no matter where a workload (VM) ends up running, its security policy will stay with it, so application of security policy is no longer a function of having a workload running in a specific location.As you may guess we are continuing to expand on this concept, so expect to see some interesting things in the future around services for the virtualized data center.

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.


  1. Dear omar hi i want some information about cloud architecture and the layer of that not in the field of cloud computing only . could you plz help me and guide me to find a good path.thank you very much.

  2. Amen.Notwithstanding the definition of the etwork,"" (I like fabric better, anyway because it represents the convergence of compute, network and storage,) the fact that old-guard perimeter model networking companies are still clutching to their placement at the ingress/egress while simultaneously speaking of how they adapt to virtualized and cloud models is humorous at best.Consolidating functionality across the fabric means that the fabric itself will become intelligent.This doesn't necessarily mean that all services are delivered by switches and routers, but rather that the ""blending"" or extension of networking services will become more prominent, even if distinct service layers for functionality are formed around operational, organizational or technical siloes.Ignoring the fact that CPU and I/O in COTS systems are really starting to scream combined and pooh-poohing the notion that networking capabilities emerging via extensible virtualization platforms that integrate the notion of distributed switching, load balancing with requisite resiliency and scale won't fly is a silly position to take for vendors who are hardware bound...such is the debate I'm having now with that blog entry you cited.I've come to respect (gasp!) Cisco's approach a lot more since -- despite the fact that Cisco is still a hardware company -- investing in solutions such as VN-Link/1000v, etc. means you're not leaving your head in the sand as to the impact that the democratization of resources thanks to virtualization brings along with the redefinition of the network.Love that telephone analog... ;)/Hoff"