The term “cloud computing” covers many topics. One hot area is infrastructure as a service (IaaS), where servers and other data center resources are provided on-demand over the web and through a programming interface. The classic example is Amazon’s Elastic Compute Cloud (EC2). IaaS became popular at first as a way to deliver new applications, often from new companies. Examples included software-as-a-service companies like Animoto or Mashery, and bursty compute-intensive applications like those at Gigavox and UnivaUD. More recently enterprises have been studying IaaS as part of their IT infrastructure, and some companies have begun pilots. How do enterprises want to use IaaS? Does it differ from the ways that new companies started the use of IaaS? In this post, I’ll examine a few classic use cases for enterprises, and draw a few lessons.
In conversations with enterprises and in the trade press, three groups of applications are often cited as near-term uses of today’s IaaS. I call them Disasters, Development, and Deadlines:
In my last blog post on standards and innovation (Why Standards Matter…And When They Don’t) I mentioned that Cisco’s VNTag, had been submitted to the IEEE for standardization. Last week, the IEEE authorized a project, 802.1Qbh: Bridged Port Extension, to amend the Ethernet switch standard to include capabilities like those provided by our VNTag technology.
Official Scope of Project:
Amendment specifies protocols, procedures, and managed objects to support Port Extension. A Port Extender attaches to a MAC port of an 802.1Q bridge and provides additional MAC ports that are logically ports of the 802.1Q bridge to which it is attached (i.e. the “Controlling Bridge”). The protocols, procedures, and managed objects specified in this amendment are expected to specify new behavior in bridges that support port extension as well as the behavior of Port Extenders themselves. In addition, the protocols, procedures, and managed objects specified in this amendment support the cascading of Port Extenders. To the extent technically reasonable, all frame filtering and relay functions remain in the Controlling Bridge.
Use of a STag for Multichannel capability as being defined in Edge Virtual Bridging is envisaged to achieve this objective. A new on-the-wire indication (e.g. a new tag) is envisioned to support remote replication for purposes including frame flooding and group address support.
As always, Cisco is committed to supporting 802.1Qbh in its products once it becomes a ratified standard. More information about the proposed standard can be found at the following links:
I just wanted to give you a heads-up that we have an upcoming TechWiseTV on Unified Fabric. If you have watched TWTV before, you know this Robb and Jimmy Ray are going to take a no-holds-barred look at unified fabric with equal parts humor and enlightenment.
Eight Is Enough was an American comedy / drama that ran from 1977 – 1981. See http://en.wikipedia.org/wiki/Eight_Is_Enough if you are oddly curious. You may not share my vintage or decided to be productive during those years, but the metaphor relates to interface requirements for VMware hypervisor implementations.
The foundation for private or public clouds is virtualization. This blog entry focuses on the network interfaces used to build a topology for VMware. Specifically, VMware has the concept of port groups and vswitches ( http://www.vmware.com/technical-resources/virtual-networking/ [url reference if you want more detail]). There are many reasons and combinations to choose from relative to this implementation. I will comment on some of them next.
The year was 1992, Disney’s Aladdin was the top grossing movie, Garth Brooks had the top-selling album in the US, and I was a freshly minted SE. Being a studious and diligent SE, I read up on all the gear sold by the integrator I worked for, and I decided that the Wellfleet BCN was the product of choice for our customers based on its hardware architecture and the impressive list of standards to which it laid claim.
And, then a funny thing happened…I learned that, while customers value standards compliance, what they value even more are networks that work and do what they need them to do. And herein lies the inherent contradiction of networking standards and the constant tension between innovation and standards.
Ultimately customers look to us to address their problems: “I need my network to _________ (fill in the blank) so I can support the needs of my business–oh, and I’d like that ASAP, please” . Luckily, our customer base is not shy, so when we see a trend, we move to address it and put solutions out there for our customers. This is where innovation is critical–having the ability to continually move the ball forward to ensure networking continues to meet the needs of markets that are themselves continually evolving.
But, ultimately, standardization is the end goal. Without standardization, innovation cannot scale. Time and again, we have seen that if a technology is balkanized, it stalls because no one wants to choose poorly (on a somewhat related note, I have a fine collection of HD-DVDs I’m willing to part with at a fair price).
Most of you are probably familiar with some version of the technology adoption lifecycle chart below, made popular by Geoffrey Moore in his seminal work “Crossing the Chasm”.