Rational Survivability

I spend a good amount of time thinking about how multiple technology strategies from market leaders coalesce into a reasonably homogenized version of reality in the networking and security space in order to decide where to place bets; it's akin to reading a tell and analyzing a player's betting strategy at a poker table.

I look at Cisco and VMware and can't help to chuckle at the moves being made in the name of "partnership" on the virtualization front and there's an awful lot of twitching going on that doesn't require Phil Hellmuth to decode. 

Partnerships are nothing new, but usually they are couched with certain modicum of suspicion and cynicism.  However, speaking with folks at VMworld, either folks were high from the Oxygen Bar at the airport, or they were adding naiveté syrup to the drinks because I seemed alone in my concerns…

I've put together a couple of summary points on the matter — more for my own personal enjoyment and note taking than anything else — and framed them in terms of what I find to be really annoyingly obvious examples of these two strange bedfellows' behaviors:

1)  The purported cohesion of Cisco's and VMware's virtualization strategies is a simply a matter of converged parallelism and forced perspective.

You've seen diagrams that demonstrate the notion of converged parallel lines, right?  If you haven't here's an example:

You'll notice that in this diagram there exists a series of parallel lines which seem to converge at a "vanishing point" on the horizon.

This in fact is not the case.  The lines don't actually ever converge, they just look like they do.  It's all a matter of perspective.  Imagine these lines as Cisco's and VMware's virtualization strategies.

Similarly, the notion of forced perspective is a method by which the manipulation of perspective employs an optical illusion to make something appear closer, father away, larger or smaller than it actually is (see the title image above*.)

The announcements from Cisco and VMware are very much like these examples. Whilst they offer excellent opportunities for improving the management and security of virtual infrastructure, it's very much Machiavellian marketing — the end is going to justify the means.

Speaking to either Cisco or VMware you're asked to suspend disbelief and accept that these two companies share a common blueprint for a datacenter OS, but they don't.  In fact, they're quite different, and the balance of who needs whom more is also very lopsided.

Despite the close technical partnership needed to pull off the integration of the Nexus 1000v as the first third party virtual switch (which we've been talking about for almost two years,) Cisco and VMware really are on parallel trajectories in terms of their visions regarding the datacenter OS; how it's designed, provisioned, deployed, managed and governed…and by whom.

Cisco is approaching this primarily as an infrastructure transformation play as a way of clawing back what they lost when the network access layer become absorbed into the virtual hosts while VMware is busy distancing itself from the infrastructure and elevating the discussion to that of the cloud in an effort to stave off Microsoft and Citrix.

Each want to own your datacenter, and while they play nice on the surface, there's really a nasty game of tug of war going on here.  This is a marriage borne of convenience, nothing more.

You try and unify Cisco's DC 3.0 vision with VMware's Virtual Datacenter OS blueprint and tell me how they mesh.

2)  Dear Virtual SysAdmin: You're fired as the network admin.  You're cool with that, right?

It's funny how both Cisco and VMware's marketing folk in the sessions discussing the release of the Nexus 1000v vSwitch, both snarkily (and rhetorically) posited "How many of you Virtual SysAdmins have coordination and communication issues between your virtualization and network teams?"

Leading the witness further, the next question was  "Don't you just hate having to fight to get the network teams to give you a trunk port on an access switch?" 

They followed that up with "Your prayers are answered!  The 1000v will allow you to give the network provisioning back to the network  teams and let them control the networking and connectivity.  Isn't that great?" 

While most nodded away in the affirmative to the first and second questions, I didn't see one audience member who answered positively on the latter.  What makes anyone think the vSysAdmins *want* to give up the control of the virtual networking layer and be at the mercy of the networking teams again?

Interesting battle ground for sure.  Now, please don't misinterpret my commentary as a suggestion that this is a bad thing, but we're already in the middle of a "West Side Story" turf war over organizational fiefdoms.  This will, depending upon what sort of contention exists already, make a really tenuous issue even more so.

3) Software Sucks.  Hardware Rules.   I hope you like ping pong.

I hinted at this point in my post titled (The Network is the Computer…)  The reality is that much like point #1, Cisco could care less in the long term about the Nexus 1000v as a software switch running in someone else's backyard operating environment, but rather introduces it to enable the landscape clawback it gets to enjoy in the short term and make relevant once again it's big network iron in the longer timeframe.

A telling slide was the announcement of what's coming AFTER the Nexus 1000v in one of the sessions that I have not seen presented in detail elsewhere — that is Cisco's goal to extract networking out of the host completely.

The plan as discussed is to utilize what Cisco calls an "initiator" to replace the 1000v and force traffic, after specialized tagging which denotes affinity of flows to specific VM ID's, and ship them straight back out the network interfaces to a waiting Cisco 5000/7000 switch for processing.  Hence the ping-pong mention above.

Sorry for the quality of the picture as I took it sitting behind somebody, but here's a slide denoting just this very thing:

 
The notion of a third party switching capability is really just a way for Cisco to push the access layer back to where they think it rightfully belongs — in the physical switch.

Cisco claims that VMware and they have submitted this tagging specification to the IEEE for review/ratification.   I find that very interesting.

I wrote about the need for such a technology at both the virtualization layer and more importantly the application/data level in June of 2007. 

Check out my post which described how I suggested Crossbeam do the exact same thing by way of something I called ADAPT (Applied Data and Application Policy Tagging) which describes this very thing.  What's next, they're going to announce vNAC? 😉

—

All in all, the Cisco/VMware relationship is about as natural looking as the Microsoft/Citrix version — it's sort of like a midget dating a six foot supermodel…someone's getting the better end of the footrub in that relationship, too.

So, how about it?  Am I stating the obvious again — and does it need to be stated?

/Hoff

*image from "The Eye of Brad" flickrstream

If there's one motif emerging from VMworld this year, it's very much the maxim "be careful what you ask for, because you might just get it."

The precipitate convergence of virtualized compute, network and storage is really beginning to take significant form; after five hard years of hungering for the materialization of the technology, enterprise architecture, and market/business readiness, the notion of a virtualized datacenter OS with a value proposition larger than just " cost-optimized infrastructure" has now become a deliciously palpable reality.  

The overlap and collision of many leading technology providers' "next generation" datacenter (OS) blueprints is something I have written about before.  In many cases there's reasonable alignment between the overall messaging and promised end result, but the proof is in the implementation pudding. I'm not going to rehash this here because I instead want to pick on something I've been talking about for quite some time.

From a network and security perspective, things are about to (again) fundamentally and profoundly change in terms of how we operationally design, provision, orchestrate, manage, govern and secure our infrastructure, applications and information.  It's important to realize that this goes way beyond just  adding a 'v' to the name of a product. 

What's incredibly interesting is the definition and context of where and what makes up the "network" that transports all our bits and how the resources and transports interact to deliver them securely.

It should be clear that even in a homogenous platform deployment, there exists an overwhelming complex conglomerate of mechanisms that make up the machinery enabling virtualization today.  I think it's fair to say that we're having a difficult time dealing with the non-virtualized model we have today.   Virtualization?  She's a cruel mistress bent on reminding us we've yet to take out the trash as promised.

I'm going to use this post to highlight just how "complexly simple" virtual networking and security have become using as an example the last two days' worth of  announcements, initiatives and demonstrations of technology and solutions from Intel, VMware, Cisco and the dozens of security ISV's we know and love.

Each of the bumps in these virtual wires deserves its own post, which they are going to get, especially VMware's vNetwork/VMsafe, distributed network switch, and Cisco's Nexus 1000v virtual switch announcements.  I'm going to break each of these elemental functions down in much more detail later as they are simply amazing.

Now that networking is abstracted across almost every layer of this model and in many cases managed by separate organizational siloes and technologies, how on earth are we going to instantiate a security policy that is consistent across all strata?  We're used to this problem today in physical appliances, but the isolation and well-definable goesinta/goesouta perimeterized boundaries allows us to easily draw lines around where these

policy differentials intersect. 

 It's used to be the devil you knew.  Now it's eleven different devils in disguise.

As you visualize the model below and examine how it applies to your experience, I challenge you to tell me where the "network" lives in this stack and how,  at a minimum, you think you're going to secure it.   This is where all those vendor roadmaps that are colliding and intersecting start to look like a hodgepodge:

In the example model I show here, any one of these elements — potentially present in a single VMware ESX host — can directly or indirectly instantiate a set of networking or security functions and policies that are discrete from one another's purview but ultimately interrelated or even dependent in ways and using  methods we've not enjoyed before.  

In many cases, these layered components are abstracted from one another and managed by separate groups.  We're seeing the re-emergence of  network-centricity, it's just that the  network is camouflaged in all its cloudy goodness.  This isn't a story where we talk about clearly demarcated hosts  that plug into "THE" network, regardless of whether there's a hypervisor in the picture.

Here's where it gets fun…

In this model you have agents in the Guest OS interacting with security/networking virtual appliances on the ESX host either inline or via vnetworking APIs (switching or security) which in turn uses a fastpath networking kernel driver  connected to VMware's vSwitch while another VA/VM is connected to a Cisco Nexus 1000v vSwitch implemented as a second distributed virtual network switching fabric which are all running atop an Intel CPU utilizing SR-IOV via VT-d in the chipset which in turn allows VM's to direct attach (bypassing the VMM) to NIC cards with embedded switching connected to your network/storage fabrics…

Mass hysteria, cats and dogs living together…

So I'll ask you again: "Where's the network in that picture?"  Or, more precisely, "where isn't it?"  

This so hugely profound, but that may because I've been exposed to each of the bubbles in this diagram and see how each of them relate or do not.  When you step back and look at how, as an example, Cisco and VMware are both going through strategic sea changes in how they are thinking about networking and security, it's truly 

amazing but I think the notion of network intelligence is a little less cut and dry as some might have us believe.

Is this as mind-blowing to you as it is to me?  If not, wait until I rip open the whole vNetworking and Nexus 1000v stuff.  Very, very cool.

/Hoff

Update below.

It's the night before VMworld 2008 and the Technology
Exchange/Partner day begins and I'm pawing through the stuff in my bag,
separating the "keep it" from the "toss it" schwag.

There's an innocuous little flyer stuffed in the bag on Cisco
letterhead titled "Introducing Cisco's Virtual Switch for VMware ESX." 
Fantastic.  Let's call it the 'cSwitch' 😉

A year and a month ago in August of 2007, I blogged about this very thing in a post titled: "VMware to Open Development of ESX Virtual Switches to Third Parties…Any Guess Who's First?" based on a hint from virtualization.info.

Given
that VMworld 2007 came and went without this announcement, I'm very
excited that we're actually going to get a look at what Cisco will
offer; I think this is huge news and ultimately offers some profound
game-changing (for good and bad) implications on the network and
security fronts.

I have dozens of questions like: I wonder how
much of the Nexus (7000 series)/NX-OS code cross-pollinates over (if
any) to this solution and if we'll see capabilities such as
STP/PVST+/Private VLANs, HSRP, Multicast, etc. make their way into
Cisco's vSwitch and how this virtual switch with integrate/interoperate
with the vkernel.

Further, as Ed Haletky and I unofficially bet
over drinks this evening, I wonder if it will be a direct replacement
for VMware's at-boot loadable module or it will co-exist?  I bet the
former. 😉

In addition to the "cSwitch," there are a couple of
sessions I am very, very interested in attending given my exposure to
VFrame and some Cisco engineers/architects at last year's show:

Simplify VMotion with Virtual Machine–Aware Network and Storage Services
See how network and storage services can be linked to a virtual machine so they move with VMotion events.

ESX Server in a Unified Fabric Environment
See how ESX Server works in a unified fabric environment with ESX 3.5
U2, Emulex Converged Network Adaptors, and the Cisco Nexus 5000.

VFrame: Enriching ESX Deployment with End-to-End Orchestration
Cisco’s VFrame DC 1.2 provides an easy-to-use template-based
provisioning approach for rapid, repeatable, and compliant provisioning
of ESX Servers. Through a rich set of networking and storage
orchestration capabilities, it reduces the time required to bring up
ESX clusters while providing operational scalability to manage large
clusters effectively.

See the second topic above?  Remember when I mentioned in prior posts about virtualizing applications directly within the Nexus?

Should be a very interesting couple of days.

/Hoff

Update:
So there was no direct news/mention specifically of Cisco today in any
of the distributed virtual networking (DVN) sessions — there's a lot
of messaging collisions because the re-branded 'v-everything' strategy
has things being renamed.  Hopefully we'll see/hear more from Cisco
tomorrow.

Many
of the underlying functions that will enable 3rd party virtual switches
as well as any network interface to the vkernel via API were discussed today
under the capabilities described by vNetwork (this includes the vNetwork Appliance API's and what you've known as VMsafe.)  You can see more about vNetwork here in this post.

All
I can say is that I got a lot of my suspicions confirmed, questions
answered and conclusions affirmed in today's sessions.  Some good, some
bad.  It's going to be a bumpy ride, kids.

The Four Horsemen live! 😉

Over the last 5 years or so with the pronounced emergence of inexpensive multi-core COTS compute platforms and the rabid evangelism of virtualization, I have debated many times with folks who continue to suggest that "big iron" — high performance equipment in the compute, network, security and storage domains — is now "extinct" and that nobody buys bespoke equipment any more.

Many of them argued "All you need is a COTS PC, package up OS/Applications and voila!  Instant appliance!  Ready for the edge, ready for the core."

Not surprisingly, many of the networking/security/application delivery companies that these folks worked for ultimately introduced custom-engineered hardware solutions, melding their software with custom hardware and COTS elements to produce a piece of big iron of their own…

About a year ago, I wrote a blog on this topic highlighted by a post titled "All your COTS multicore CPU's with non-optimized security software are belong to us," in which I extrapolated some very interesting points regarding Moore's law and the hubris surrounding the gluttony of compute power offered by higher density chipsets without the corresponding software architecture to take advantage of it.

Update: I forgot that I wrote a really good post (this March!) on this same topic titled "I Love the Smell Of Big Iron In the Morning…"

This is a little tickler to that post.

I come from the land of servicing large enterprises, service providers, municipalities and nation states  and not the SME. 

While there are certainly exceptions to the "rule," and it's reasonable to suggest that my perspective is skewed, I've always been careful to ensure I framed my discussions this way, so debating/contrasting the architectural slants of an SME with a Fortune 10 doesn't really move the discussion along any.

So, sticking with the large enterprise theme, there are two interesting divergent themes emerging: the centralization of compute and storage with the distributed nature of connectivity and information.

Without muddying the water too much about how these scenarios are not all that mutually exclusive, let's stick with the "centralization" theme for a moment.

The mainstream adoption of virtualization as an enabler brings us full-circle back around to the centralized mainframe model* of compute, networking and storage.  Now that reasonably reliable, high speed and low latency connectivity is available, centralization of resources makes sense since people can generally get access to the assets they require and the performance to get from point A to point B is for the most part acceptable (and getting more so.)

Once again, the natural consolidation of functionality and platform architecture follows suit — we're back to using big iron to deliver the balance of cost, resilience, performance and simplified management that goes along with squeezing more from less.

To wit, let's examine some recent virtualization-inspired, big iron plays:

Compute:

HP introduced [recently] the Proliant BL495c G5,
the first blade designed to be a virtual machine-intensive host in a
data center rack, along with other virtualization products to enhance the offerings of VMware and Citrix Systems.

As system administrators achieve savings by consolidating 8-10 virtual
machines per server, HP is saying its new blade will host up to 32
virtual machines, based on each virtual machine
needing a minimum of four Gigabytes of memory. When 16 of the blades
are stacked in an HP C7000 enclosure, a total of 512 virtual machines
can be run from a single rack, said Jim Ganthier, director of HP
BladeSystem, its blade server division.

Network & Storage:

The Cisco Nexus 7000 Series is the flagship member of the Cisco Nexus
Family, the first in a new data center class of switching products. The
Nexus 7000 is a highly scalable modular platform that delivers up to 15
terabits per second of switching capacity in a single chassis,
supporting up to 512 10-gigabits-per-second (Gbps) Ethernet and future
delivery of 40- and 100-Gbps Ethernet. Its unified fabric architecture
combines Ethernet and storage capabilities into a single platform,
designed to provide all servers with access to all network and storage
resources. This enables data center consolidation and virtualization.
Key components of the unified fabric architecture include unified I/O
interfaces and Fibre Channel over Ethernet support to be delivered in
the future.


Security:

The Crossbeam X-Series is a carrier-class modular security services switch.  The X80 platform is Crossbeam's flagship high-end security services
platform for complete network, security.  The X80
provides up to 40 Gigabit Ethernet ports and 8 x 10 Gigabit Ethernet
ports or up to 64 Fast Ethernet ports and up to 40 Gbps of full duplex
firewall throughput.  Each network processor module features an integrated 16-core MIPS-64
security processor, a high speed network processor and a
custom-designed switch fabric FPGA.  The X80 supports up to 10
application processor modules which are based on Intel technology
running a hardened version of Linux supporting best-in-breed security
software from leading vendors in highly resilient, load-balanced
configurations.

These are just a few examples.

Each of these solutions delivers the benefits of hefty amounts of virtualized service, but what you'll notice is that they do so in massive scale, offering consolidated services in high-density "big iron" configurations for scale, resilience, manageability and performance.

In this period of the technology maturity cycle, we'll see this trend continue until we hit a plateau or an inflection point — whether it is triggered due to throughput, power, heat, latency, density or whatnot.  Then we'll start anew and squeeze the balloon once more, perhaps given what I hinted at above with clusters of clouds that define an amporphous hive of virtualized big iron.

But for now, until service levels, reliability, coherence and governance are sorted, I reckon we'll see more big iron flexing it's muscle in the data center.

What about you?  Are you seeing the return of big iron in your large enterprise.  Perhaps it never left?

I for one welcome my new blinking dark overlord…

/Hoff

* There's even a resurgence of the mainframe itself lately.  See IBM's z/10 and Unisys' ClearPath for example.

Hat tip to Rothman for this.

I don’t know if Stiennon is off his meds or simply needed to re-post something from 2001 to meet an editorial quota, but his Network World article titled "The Most Important Networking Trend of 2008" ties thus far with the "Evolution of Dance" as my vote for most entertaining Internet content.

Richard’s epiphany goes something like this:

• Multifunction network devices that have the ability to "route" traffic and combine security capabilities are the ‘next big thing’
• If a company offers a multifunction network device that has the ability to "route" traffic and combine security capabilities but have the misfortune of using Linux as the operating system, they will "…forever be pigeon-holed as SMB solutions, not ready for enterprise
  prime time."

• The Wall Street Journal issued "… the year’s most important article on networking" in an article titled "New Routers Catch the Eyes of IT Departments" which validates the heretofore undiscovered trend of convergence and commoditization!
   
• "Real" network security players such as Cisco, Juniper and Redback are building solutions to this incredible new trend and because of the badge on the box, will be considered ready for "…enterprise prime time."
   
• The WSJ article talks about the Cisco ASR1000 router as the penultimate representation of this new breed of converged "network security" device.
   
• Strangely, Stiennon seems to have missed the fact that the operating system (IOS-XE) that the ASR1000 is based on is, um, Linux.  You know, that operating system that dictates that this poor product will "…forever be pigeon-holed as SMB solutions, not ready for enterprise
  prime time."

Oh, crap!  Somebody better tell Cisco!

So despite the fact that Cisco ASR1000 is positioned as an edge device as are these crazy solutions called UTM devices, it seems we’re all missing something because somehow a converged edge device now counts as being able to provide a "secure network fabric?"

In closing, allow me to highlight the cherry on top of Stiennon’s security sundae:   

Have you ever noticed how industry "experts" tend to get stuck in
a rut and continue to see everything through the same lens despite
major shifts in markets and technology?

Yes, Richard, I do believe I have noticed this…

Funny stuff!

/Hoff

Does Not Compute…

I admit that I’m often fascinated by the development of big iron and I also see how to some this seems at odds with my position that technology isn’t the answer to the "security" problem.  Then again, it really depends on what "question" is being asked, what "problem" we’re trying to solve and when we expect to solve them.

It’s pretty clear that we’re still quite some time off from having secure code, solid protocols, brokered authentication and encryption and information-centric based controls that provide the assurance dictated by the policies described by the information itself. 

In between now and then, we see the evolution of some very interesting "solutions" from those focused on the network and host perspectives.  It’s within this bubble that things usually get heated between those proponents who argue that innovation in networking and security is constrained to software versus those who maintain that the way to higher performance, efficacy and coverage can only be achieved with horsepower found in hardware.

I always find it interesting that the networking front prompts argument in this vein, but nobody seems to blink when we see continued development in mainframes — even in this age of Web3.0, etc.  Take IBM’s Z10, for example.  What’s funny is that a good amount of the world still ticks due to big iron in the compute arena despite the advances of distributed systems, SOA, etc., so why do we get so wrapped up when it comes to big iron in networking or security?

I dare you to say "value." 😉

I’ve had this argument on many fronts with numerous people and realized that in most cases what we were missing was context.  There is really no argument to "win" here, but rather a need for examination of what most certainly is a manifest destiny of our own design and the "natural" phenomena associated with punctuated equilibrium.

An Example: Cisco’s New Hardware…and Software to Boot [it.]

Both camps in the above debate would do well to consider the amount of time and money a bellwether in this space — Cisco —  is investing in a balanced portfolio of both hardware and software. 

If we start to see how the pieces are being placed on Cisco’s chess board, it makes for some really interesting scenarios:

• 40 core QuantumFlow processor
• The 7000 series Nexus switch
• The ASR 1000 featuring the QuantumFlow
• IOS-XE Virtualization for the ASR 1000  powered by KVM/Linux

Many will look at these developments and simply dismiss them as platforms that will only solve the very most demanding of high-end customers and that COTS hardware trumps the price/performance index when compared with specialty high-performance iron such as this. 

This is a rather short-sighted perspective and one that cyclically has proven inaccurate.   

The notion of hardware versus software superiority is a short term argument which requires context.  It’s simply silly to argue one over the other in generalities.  If you’d like to see what I mean, I refer you once again to Bob Warfield’s "Multi-Core Crisis" meme.  Once we hit cycle limits on processors we always find that memory, bus and other I/O contention issues arise.  It ebbs and flows based upon semiconductor fabrication breakthroughs and the evolution and ability of software and operating systems to take advantage of them.

Toss a couple of other disruptive and innovative technologies into the mix and the landscape looks a little more interesting. 

It’s All About the Best Proprietary Open Platforms…

I don’t think anyone — including me at this point — will argue that a
good amount of "security" will just become a checkbox in (and I’ll use *gasp* Stiennon’s language) the "fabric."  There will always be point
solutions to new problems that will get bolted on, but most of the
security solutions out there today are becoming features before they
mature to markets due to this behavior.

What’s interesting to me is where the "fabric" is and in what form it will take. 

If we look downrange and remember that Cisco has openly discussed it’s strategy of de-coupling its operating systems from hardware in order to provide for a more modular and adaptable platform strategy, all this investment in hardware may indeed seem to support this supposition.

If we also understand Cisco’s investment in virtualization (a-la VMware and IOS-XE) as well as how top-side investment trickles down over time, one could easily see how circling the wagons around both hardware for high-end core/service provide platforms [today] and virtualized operating systems for mid-range solutions will ultimately yield greater penetration and coverage across markets.

We’re experiencing a phase shift in the periodic oscillation associated with where in the stack networking vendors see an opportunity to push their agenda, and if you look at where virtualization and re-perimeterization are pushing us, the "network is the computer" axiom is beginning to take shape again. 

I find the battle for the datacenter OS between the software-based virtualization players and the hardware-based networking and security gianst absolutely delicious, especially when you consider that the biggest in the latter (Cisco) is investing in the biggest of the former (VMware.)

They’re both right.  In the long term, we’re all going to end up with 4-5 hypervisors in our environments supporting multiple modular, virtualized and distributed "fabrics."  I’m not sure that any of that is going to get us close to solving the real problems, but if you’re in the business of selling tin or the wrappers that go on it, you can smile…

Imagine a blade server from your favorite vendor with embedded virtualization capabilities coupled with dedicated network processing hardware supporting your favorite routing/switching vendor’s networking code and running any set of applications you like — security or otherwise — with completely virtualized I/O functions forming a grid/utility compute model.*

Equal parts hardware, software, and innovation.  Cool, huh?

Now, about that Information-Centricity Problem…

*The reality is that this is what attracted me to Crossbeam:
custom-built high-speed networking hardware, generic compute stacks
based on Intel-reference designs, both coupled with a Linux-based
operating system that supports security applications from multiple
sources as an on-demand scalable security services layer virtualized
across the network.

Trouble is, others have caught on now…

One of the very profound impacts virtualization will have on security is the resultant collateral damage caused by what I call the "battle for the datacenter OS" framed by vendors who would ordinarily not be thought of as "OS vendors." 

I call the main players in this space the "Three Kings:" Cisco, VMware and EMC.
Microsoft is in there also, but that’s a topic for another post as I bifurcate operating system vendors in the classical sense from datacenter infrastructure platforms.  Google deserves a nod, too.

The "Datacenter OS" I am speaking of is the abstracted amalgam of virtualization and converged networking/storage that delivers the connected and pooled resource equivalent of the utility power grid.   Nick Carr reflects in his book "The Big Switch":

A hundred years ago, companies stopped producing their own power with steam engines and generators and plugged into the newly built electric grid.”

The "datacenter" and its underlying "operating system," in whatever abstracted form they will manifest themselves, will become this service layer delivery "grid" to which all things will connect; services will be merely combinations of resources and capabilities which are provisioned dynamically.

We see this starting to take form with the innovation driven by virtualization, the driving forces of convergence, the re-emergence of grid computing, the architectures afforded by mash-ups and the movements and investments of the Three Kings in all of these areas.

It’s pretty clear that that these three vendors are actively responsible for shaping the future of computing as we know it.  However, It’s not at all clear to me how much of the strategic overlap between them is accidental or planned, but they’re all approaching the definition of how our virtualized computing experience will unfold in very similar ways, albeit from slightly different perspectives.

One of the really interesting examples of this is how virtualization and convergence are colliding to produce the new model of the datacenter which blurs the lines between computing, networking and storage.

Specifically, the industry — as driven by customers — is trending toward the following:

• Upgrading from servers to blades
• Moving from hosts and switches to clusters and fabrics
• Evolving from hardware/software affinity to grid/utility computing
• Transitioning from infrastructure to service layers in “the cloud”

The topic of this post is really about the second bullet, moving from the notion of the classical hosts/servers plugging into separate network and storage switches to instead clusters of resources connecting to fabric(s) such that what we end up with are pools of resources to be provisioned, allocated and dispatched where, when and how needed. 

This is where I/O virtualization enters the picture.  I/O virtualization at the macro level of the datacenter describes the technology which enables the transition from the discrete and directly-connected model of storage versus networking to a converged virtualized model wherein network and storage resources are aggregated into a single connection to the "fabric."

Instead of having separate Ethernet, fiber channel and Infiniband connections, you’d have a single pipe connected to a "virtual connectivity switch" that provides on-demand, dynamic and virtualized allocation of resources to anything connected to the fabric.  The notion of physical affinity from the server/host’s perspective goes away.

Andy Dornan from Information Week just did a nice write-up titled "Cisco pitches virtual switches for next-gen data centers." 

It’s obviously focused on Cisco’s Nexus 7000 Series switch, but also gives some coverage of Brocade’s DCX Backbone, Xsigo’s Director and 3Leaf’s v-8000 products.

Check out what Andy had to say about Cisco’s strategy:

Cisco’s vision is one in which big companies off-load an increasing
number of server tasks to network switches, with servers ultimately
becoming little more than virtual machines inside a switch.*

The Nexus
doesn’t deliver that, but it makes a start, aiming to virtualize the
network interface cards, host bus adapters, and cables that connect
servers to networks and remote storage. At present, those require
dedicated local area networks and storage area networks, with each
using a separate network interface card and host bus adapter for every
virtual server. The Nexus aims to consolidate them all into one (or
two, for redundancy), with virtual servers connecting through virtual
NICs.

This stuff isn’t vaporware anymore.  These products are real…from numerous entities.  These companies — and especially Cisco — are on a mission to re-write the datacenter blueprint and security along with it.  VMware’s leading the virtualization charge and Cisco’s investing for the long run.  When you look at their investment in VMware, the I/O virtualization play and what they’re doing with vFrame, it’s impressive — and scary at the same time.

Them’s a lot of eggs in one basket, and it’s perfectly clear that there is a huge sucking sound coming from the traditional security realm as we look out over the horizon.  How do you apply a static security sensibility grounded in the approaches of 20 years ago to an amorphous, fluid, distributed and entirely dynamic pooled set of resources and information?

Cisco has thrown their hat in the ring to address the convergence of role-based admission and access control with the announcement of TrustSec which will be available in the Nexus as it is in the higher-end Catalyst switches.  Other vendors such as HP, Extreme and now Juniper as well as up-starts like Nevis and Consentry have their perspectives.  What each of these infrastructure networking vendors have in store for how their solutions will play in the world of virtualized and distributed computing is still to unfold.

How might this emerging phase of technology, architecture, provisioning, management, deployment and virtualization of resources impact security especially since we’ve barely even started to embrace the impact server virtualization has?  One word:

Completely.

More on this topic shortly…

/Hoff

*Update: A colleague of mine from Unisys, Michael Salsburg, prompted me via discussion to clarify a point.  I think that  for at least the short term, the "server tasks" that will be offloaded to I/O virtualization solutions such as Cisco’s will be fairly narrow in scope and logically defined.  However, given that NX-OS is Linux based, one might expect to see a Hypervisor-like capability within the switch itself, enabling VM’s and applications to be run directly within it.

Certainly we can expect and intermediary technology derivation which would include Cisco developing their own virtual switch that complements/replaces the vSwitch present in the VMM today; at this point given the heft/performance of the Nexus, one could potentially see it existing "outside" the vHost and using a high-speed 10Gb/s connection, redirect all virtual network functions to the external switch…

A couple of weeks ago I penned a blog entry titled "The Battle for the HyperVisor Heats Up"
in which I highlighted an announcement from Phoenix Technologies
detailing their entry into the virtualization space with their
BIOS-enabled VMM/Hypervisor offering called HyperCore.

This drew immediate parallels (no pun intended) to VMware and Xen’s plans to embed virtualization capabilities into hardware.

The marketing continues this week with interesting announcements from Microsoft, Oracle and VMware:

1. VMware offers VMware Server 2 as a free virtualization product to do battle against…
2. Oracle offering "Oracle VM" for free (with paid support if you
   like) which claims to be 3 times as efficient than VMWare — based on
   Xen.
3. Microsoft officially re-badged its server virtualization technology as Hyper-V (nee Veridian)
   detailing both a stand-alone Hyper-V Server as well technology integrated into W2K8 Server.

It seems that everyone and their mother is introducing a virtualization platform and the underpinning of commonality between basic functionality demonstrates how the underlying virtualization enabler — the VMM/Hypervisor — is becoming a commodity.

We are sure to see fatter, thinner, faster, "more secure" or more open Hypervisors, but this will be an area with less and less differentiation.  Table stakes.  Everything’s becoming virtualized, so a VMM/Hypervisor will be the underlying "OS" enabling that transformation.

To illustrate the commoditization trend as well as a rather fractured landscape of strategies, one need only look at the diversity in existing and emerging VMM/Hypervisor solutions.   Virtualization strategies are beginning to revolve around a set of distinct approaches where virtualization is:

1. Provided for and/or enhanced in hardware (Intel, AMD, Phoenix)
2. A function of the operating system (Linux, Unix, Microsoft)
3. Delivered by means of an enabling software layer (nee
   platform) that is deployed across your entire infrastructure (VMware, Oracle)
4. Integrated into the larger Data Center "Fabric" or Data Center OS (Cisco)
5. Transformed into a Grid/Utility Computing model for service delivery

The challenge for a customer is making the decision on whom to invest it now.  Given the fact that there is not a widely-adopted common format for VM standardization, the choice today of a virtualization vendor (or vendors) could profoundly affect one’s business in the future since we’re talking about a fundamental shift in how your "centers of data" manifest.

What is so very interesting is that if we accept virtualization as a feature defined as an abstracted platform isolating software from hardware then the next major shift is the extensibility, manageability and flexibility of the solution offering as well as how partnerships knit out between the "platform" providers and the purveyors of toolsets.

It’s clear that VMware’s lead in the virtualization market is right inline with how I described the need for differentiation and extensibility both internally and via partnerships. 

VMotion is a classic example; it’s clearly an internally-generated killer app. that the other players do not currently have and really speaks to being able to integrate virtualization as a "feature" into the combined fabric of the data center.  Binding networking, storage, computing together is critical.  VMware has a slew of partnerships (and potential acquisitions) that enable even greater utility from their products.

Cisco has already invested in VMware and a recent demo I got of Cisco’s VFrame solution shows they are serious about being able to design, provision, deploy, secure and manage virtualized infrastructure up and down the stack, including servers, networking, storage, business process and logic.

In the next 12 months or so, you’ll be able to buy a Dell or HP server using Intel or AMD virtualization-enabled chipsets pre-loaded with multiple VMM/Hypervisors in either flash or BIOS.  How you manage, integrate and secure it with the rest of your infrastructure — well, that’s the fun part, isn’t it?

I’ll bet we’ll see more and more "free" commoditized virtualization platforms with the wallet ding coming from the support and licenses to enable third party feature integration and toolsets.

/Hoff

Cisco Turns to Trend Micro for Router Security

Interesting title — and one that’s appropriately bold (pun intended.)

I found this story (below) regarding the apparent renewal of vows between Cisco and Trend interesting because of what is perceived by many as somewhat of a strange on-going dating relationship between the two companies. 

Some might suggest that over the last few years, with Trend’s inclusion as the A/V function of choice across many Cisco platforms and the NAC partnership, etc., that TM was looking to ultimately get bought by Cisco. It certainly appeared that way to me.  Perhaps the dowry was just too great, but it certainly looked like Cisco decided that monogamy wasn’t in the cards.

When Cisco acquired IronPort, many felt that while they were specifically focused on messaging security, that the technology would be leveraged heavily across Cisco’s product lines and the Trend partnership would eventually wane.

Trend is well known for both it’s anti-virus/spyware/spam solutions as well as its web-based security gateways while IronPort is known mostly for the former (see below, however.) 

It’s interesting to try and reconcile the commonalities between the two company’s product offerings.  On the surface, they both claim to do similar sets of things — even down to the reputation services elements of their products.

Here’s what IronPort suggests they provide:

Email Security

The IronPort email security appliances
are the most sophisticated systems available today. In production at
eight of the ten largest ISPs and more than 20 percent of the world’s
largest enterprises, these systems have a demonstrated record of
unparalleled security and reliability. The same code base that powers
IronPort’s most sophisticated customers is available in all of
IronPort’s email security appliances, to protect the email systems of
enterprises of all sizes. More.

Web Security

The
IronPort S-Series™ is the industry’s fastest Web security appliance.
The IronPort S-Series appliances combine a high-performance security
platform with IronPort’s exclusive Web Reputation technology and
IronPort’s breakthrough Dynamic Vectoring and Streaming™ (DVS) engine,
a new scanning technology that enables signature-based spyware
filtering. Robust management and reporting tools deliver ease of
administration and complete visibility into threat-related activity. More.

…and yet exclusing the desktop reach, it’s almost identical to what Trend Micro suggests they bring to the party. 

So if IronPort was supposed to be the content security play for Cisco, does this mean that their adaptabilty beyond messaging was either never in the cards or just isn’t panning out as quickly as was hoped?

Specific activity in the Channel from Trend certainly seemed to imply there was a wave of panic regarding the long strategic partnership between the two companies after the acquisition and it was unclear how Trend might proceed should the couple "become friends" instead of lovers. 

That’s not to say that Trend isn’t a healthy company, but there was, and is, a lot riding on this relationship.

So today, we see this announcement (from CRN/ChannelWeb):

Cisco Systems Thursday unveiled plans to add content security services
to its routers via an extended partnership with Trend Micro.

The San Jose, Calif.-based networking vendor plans soon to integrate Trend Micro technology into the operating system
of its Integrated Services Routers (ISRs), adding services such as
content filtering to its family of branch office routers, said Tom
Russell, senior director of Cisco’s Security Technology Group.

The new offering, which will be available "in the near future,"
will make it easier for channel partners to build layered security
solutions, as the ISR family already supports several integrated
security options, Russell said. It will also help push content security
out to remote locations, he added.

"You need to have content security at the central site, but you
also have to distribute it to all of the points in the network," he
said.

Cisco and Cupertino, Calif.-based Trend Micro have been working
together since 2004. Trend Micro content security technology is already
incorporated into Cisco’s Adaptive Security Appliance family of unified
threat management wares.

Trend Micro is also a partner in Cisco’s Network Admission Control
initiative and offers its own Damage Cleanup Services for the Cisco
MARS (Mitigation, Analysis and Response System) platform.

Interesting, eh?  The ASA’s were looking like the beginning of a UTM platform of choice for Cisco, but given the popularity of the ISR and the integration of certain WAN/Branch Office functionality (not to mention install base,) this makes sense.

So we’re back to figuring out where the intersection of IronPort and Trend lays.  It certainly seems that this announcement sees the happy couple holding hands again and leaves me more confused about IronPort in the long term now instead of Trend.  I also seem to recall that IronPort utilized Sophos’ AV engine…perhaps that will/has changed?

I continue to go to shows where the IronPort brand (and booth) is still separate from Cisco’s and the IronPort website is still brand discrete (albeit with a "…part of Cisco" graphic) which is a little odd.  I thought IronPort was going to be the leveraged integrated content security play for them?

It wouldn’t be the first time I’m confused by Cisco’s acquisition integration strategy.

/Hoff

On the tail of my posts from a week or so ago regarding to Cisco’s Data Center 3.0 announcement, Mr. Chamber’s keynote at VMWorld and the follow-on $150Million investment in VMware, here’s something that really gets my goose honking because the force is strong with this one…

Virtualization.info broke the news last week that VMware will "…allow 3rd party vendors to develop their virtual
switches for ESX Server virtual network, and Cisco is expected to be
the first company announcing such product (Virtual Catalyst?)"

This may sound like a no-brain yawner, but it’s quite profound…not just for Cisco, but for any of the switch vendors who want in on the lucrative virtualization market.

For a quick refresher, let’s review the concept of virtual switches (vSwitches).  From VMware’s definition:

A virtual switch, vSwitch,
works much like a physical Ethernet switch. It detects which virtual
machines are logically connected to each of its virtual ports and uses
that information to forward traffic to the correct virtual machines. A
vSwitch can be connected to physical switches using physical Ethernet
adapters, also referred to as uplink adapters, to join virtual networks
with physical networks. This type of connection is similar to
connecting physical switches together to create a larger network. Even
though a vSwitch works much like a physical switch, it does not have
some of the advanced functionality of a physical switch. For more
information on vSwitches, see Virtual Switches.

Given my previous posts on the matter, this offers two interesting and profound perspectives on the virtualization front:

1. If you recall, I blogged back in February about my participation in a Goldman Sachs Security conference where Jayshree Ullal presented Cisco’s vision of virtualized security.  During the Q&A period after her presentation, I asked her a somewhat loaded question that went something like this:

   
   If now we see the consolidation of multiple OS and applications on a
   single VM host in which the bulk of traffic and data interchange is
   between the VM’s themselves and utilize the virtual switching fabrics (ed: software)
   in the VM Host and never hit the actual physical network
   infrastructure, where, exactly, does this leave the self-defending
   "network" without VM-level security functionality at the "micro
   perimeters" of the VM’s?

   I think that this announcement pretty much answers this question.  Cisco will take the concept that I blogged about previously wherein they will abstract the software from the hardware and provide a virtualized version of a catalyst as the ESX vSwitch.  I wager we will see a subset of security functionality in the vSwitch natively that one might expect in the "physical" Catalyst hardware products as much of the capabilities still hinge on new components such as the ACE.

   Now, if the virtual switch is Cisco’s, you can expect a bevy of interaction between the "virtual switch(es)" and the physical ones that the VM Hosts connect to.  This would provide interfaces between all manner of network controls and monitoring capacities such as firewalls, IDS, IPS, SEIM, and solve the issue above by merely "offloading" this functionality via API’s to the physical boxes plumbed into the network.

   Combine that with NAC agents on the hosts and…whether or not it actually works is neither here nor there.  They told they story and here it is.  It’s good to be king.

2. This brings us to point numero dos…and it’s a doozy.  If you think that the current crop of L2/L3 switching and routing infrastructure is fragile enough, just imagine how much fun it’s going to be trying to detect and defend against infrastructure attacks on virtual switches that open up the guts of the VM hosts and hypervisors to third parties.

   We won’t need a Blue Pill, I’ll take one of these below, instead (it’s a cyanide capsule, btw):

   
   Ettercap and arp-twiddling, anyone?  If you don’t have the capability to virtualize the functional equivalent of IDS taps and/or utilize "IPS" plugins to the hypervisors, compromising a single guestOS on a VM could spell disaster that goes undetected.  We already have issues protecting physically isolated critical infrastructure, can you imagine how much fun this is going to be? 

   I’m not talking about application layer attacks here, I’m talking layer 2/layer 3.  The vicious circle begins anew.  You’ll be worrying about XSS and AJAX attacks on your virtualized web servers whilst the same attacks from 10 years ago will give your shiny new virtual infrastructure a wedgie.

   And since it’s likely we’ll see a repeat of architectural car crashes as we have in the past, most of the inter-VM traffic won’t be mutually authenticated or encrypted, either.  So you’ve got that going for you…

So, I think that this model is what Reflex was aiming for with their vIPS (from Virtual Iron) software for the virtual switch which I blogged about here, but Cisco’s going to one-up them because of their investment in VMware, their switching acumen and the unfair advantage of owning both the virtual/logical switching/routing plane as well as the physical.

Good times are comin’, for sure.  I’m trying not to be cynical.  I think it’s fairly obvious as to what ought to be done to secure this mess before it becomes one, but I’m not sure we’re going to be able to step out in front of this train and stop it before it reaches the station.

/Hoff