Archive for the ‘Virtualization’ Category

Reflections on MPLS 2009

Monday, December 14th, 2009

It has been well over a month since I attended the MPLS 2009 conference and participated in the panel on Emerging Technologies and Business Architectural Impact, and it is about time (over-due) that I posted my thoughts.

Foremost, I should say Thank You to Monique Morrow for organizing such a great panel and inviting me to participate.  I’ve known Monique as a colleague and friend for a while now, and whenever we have chance to meet she never fails to impress me.  In the context of this panel, I was dumbfounded at the quality and breadth of the other participants that she secured.  Monique moderated the discussion such that the panel’s large size was a benefit rather than liability.  As a panel we managed to cover multiple topics with decent depth, and were each allowed to illustrate our different perspectives.  I’ve been told by several audience members that it was an excellent panel, and from my (admittedly biased) perspective I must agree.

As for the discussion itself, I very much enjoyed participating.  Considering the quality of the other panelists, I am honored to have been included; each of the other panelists are recognizable for their contributions and role in the industry.  Given my respect for the other panelists, I tried to enter the conversation prepared and did not hold back any of my significant thoughts during the discussion… for better or worse.

Some of my comments may have included points that were controversial.  For instance, one theme that ran through the entire discussion was the complex balance of cost vs. capacity vs. features in network devices.  I challenged comments from Vijay Gill (of Google) and Donn Lee (of Facebook) which argued in favor of very-large dumb switches. ("dumb" is my word choice, but I suspect they would agree)  From their perspectives, as engineers for large web properties, they need to scale out single-tenant environments to support Internet-scale traffic loads and a simple L2 or L3 switch would enable their topology.  But, I argued, they were "weird" in their requirements, which are unique to large web properties.  Service providers and enterprise environments need more features in order to deal with the complexity and changing "customer" requirements they face daily.

After the panel I had the opportunity to chat with Vijay and Donn, and they had an interesting view of the cost / capacity / features debate.  Their comments deserve some focus, so look for a future post on this topic.

Another topic was the relevance of standards, which wasn’t particularly controversial but which caused some interesting comments.  My point was that standards are critical to the industry, but in the same way that fundamental research is critical to science and technology (broadly speaking).  We need to put effort into standards because it brings people together and promotes the state of the art.  But we also need to recognize that functioning interoperable implementations are what matter, regardless of the standards conformance, etc.  In other words, standards bodies should work diligently but not take themselves too seriously in the process.

Regardless, I hope to be included in future panels such as this one (at the MPLS conference and/or elsewhere) and I’m glad to have had the opportunity at MPLS 2009.  I would absolutely recommend that you attend future panels by Monique, at MPLS 2010 or otherwise, whether I’m taking part or not. Though, obviously, it would be better with my opinion included. ;)

Blade Networking Architecture: Cisco vs. Juniper

Monday, November 30th, 2009

My interest was piqued by news from Juniper Networks that they had licensed JunOS to BLADE Network Technologies.  Not that I’m surprised; I’ve suggested this approach (and some approaches more extreme…) to both Juniper and Cisco in the past.  But it did get me thinking about the differences in network architecture, between the approach of Cisco’s UCS versus the potential JunOS/BLADE approach.

For instance, a UCS system leverages a "fabric extension" module, transparently connecting multiple blades to a Top-of-Rack switch (TOR) such as the Nexus 6120.  When combined with the Nexus 1000V software (and VMware-integrated port profiles) an entire cluster of UCS chassis can be managed as a single resource pool.  Making a few design assumptions, the environment may look something like this:

This design provides a single logical interface to the external network (i.e. data center backbone, WAN, whatever).  However it is a flat network within the environment.  This is great for VM mobility throughout the resource pool, but not so great for scaling the network to many VLANs.

The alternative presented by Juniper provides an interesting comparison because it moves a switching function into the blade-server chassis.  Admittedly this doesn’t have to replace the TOR switch.  But just for argument’s sake, again making a few additional assumptions, the design could look something like this:

Note that I show a chassis with and without hypervisor-local switching.  This is just to illustrate the possibility, which admittedly could also exist in the Cisco UCS environment; this is not because I have some interesting point to make about it. ;)

Regardless, the Juniper/BLADE design may allow for better network scaling depending on the features that are bundled into the chassis switch.  However, in contrast to the UCS design there are more management touch-points.  And to really take advantage of the network scale possibilities, the network architecture itself has to be different — more oriented around layer 3, less of a wide-flat-layer 2.  This could be a problem for VM mobility depending on the overall application needs (mostly due to IP addressing and the need for shared broadcast domains).

The key next-step in either approach, in my opinion, is to deploy new features in the TOR and/or chassis switch.  Specifically, data center networking doesn’t have to be an all or nothing L2 vs L3 debate.  Please look for additional thoughts on this topic in a future post.

Participating in MPLS 2009

Saturday, October 24th, 2009

I’ve meant to post something about this before now, but I suppose it’s better late than never…

I’m traveling this weekend to Washington, DC in order to attend the MPLS 2009 conference. Specifically I will be participating in a panel hosted by Monique Morrow entitled Emerging Technologies and Business Architectural Impact. The topic of the panel is described as “Cloud Computing, P2P applications, Social Networking and Infrastructure Required to Scale” and also includes a handful of panelists from other interesting companies, both vendors and service providers.

The program for the technical sessions can be found at http://www.isocore.com/mpls2009/program/technical_sessions.htm.

If you’re in the DC area and want to meet up, please let me know. If you’re going to be attending MPLS 2009 then definitely stop by and say hello after the panel.

Cloud: Private vs Public, Internal vs External, Oh My!

Tuesday, September 15th, 2009

James Urquhart (Cisco marketer and author of The Wisdom of Clouds) has posted a video to the Cisco Data Center Networks blog entitled Clarifying Internal Cloud versus Private Cloud. In the video James stands by an unreadable whiteboard (new markers, please, James! ;) ) and discusses the difference between public vs. private clouds and internal vs. external clouds, briefly summarized as:

While internal and external clouds are based on the ownership of where the computing resources reside, two other cloud types – public and private – have more do to with the control point of the cloud applications and resources.

Sam Charrington (Appistry marketer and regular CloudCamp organizer) commented on James’ definition in a post on his blog:

While I agree that Private is not always equal to Internal, James’ [re]definition of increasingly accepted terminology just serves to muddy the waters by introducing the existence of unified control systems as a defining characteristic.

I have much respect for James and Sam as cloud thought-leaders, but I’m afraid I have to disagree with them both.

I’ve been hearing confused voices discuss the public/private cloud concepts for a couple years now, but I don’t think the industry has yet settled on a definition that captures the dimensions of a cloud environment completely. Oh, I agree that the conversation has become more subdued recently. But I suspect this is due to boredom with the topic rather than consensus.

But boredom be damned, James expands/clarifies the definition to cover a new dimension. His division of the cloud based on two attributes, ownership and point of control, leaves aside other dimensions that are critical to the cloud’s definition. I don’t have any disagreement with these attributes being central to a cloud instance. But I would add a few critical attributes to the list of dimensions that must be captured by the internal/external private/public definition.

To illustrate the point: My own boss*, Bryan Doerr (Savvis CTO), was recently summarized describing the “Private” aspect of a cloud instance similarly to how I suspect Sam would define it but with the on/off-site aspect that James is trying to accommodate in his internal/external definition:

In general, the phrase, “private cloud” has meant cloud-like resources inside the enterprise. Savvis is proposing that the “private cloud” be located off premises but include greater measures of security and quality of service than temporary workloads sent to the shared facilities, like Amazon’s EC2.

Bryan’s talk, which led to the summary quoted above, hints at the fundamental problem: that a cloud service has to accommodate all of the complexities of a traditional IT environment. There is no magic pixie-dust that makes an infrastructure cloud capable of side-stepping longstanding IT challenges and best-practices while scaling existing applications as-is in an efficient hardware environment.

Rather, cloud service providers design and package different IT elements into a solution, addressing the aforementioned challenges on the user’s behalf. It’s IT outsourcing taken one step closer to the inevitable conclusion of any technology life-cycle in a free-market economy: commoditization.

But we’re not there yet. We can say that this packaged solution is a “cloud” solution because of the high-level behaviors that it supports: on-demand provisioning, usage-based costing/billing, consolidated controls, etc. These behaviors are typically enabled by a collection of multi-tenant hardware and software platforms. But the specific platform details such as capabilities and features, implementation choices, etc, all lead to small differences in the solution.

These differences, in addition to being the gap between commoditization and our current position in the technology life-cycle, are what lead us to need terminology like internal/external and private/public. Maybe one day IT infrastructure will converge around a common set of attributes with limited and known values. (Not that I would predict such a thing anytime soon.) In the meantime we’re stuck with a terminology that is more complicated than cloud marketers and customers would like.

I’d propose that this terminology includes at a minimum the following attributes:

  • Platform Ownership – customer, provider, other
  • Financial Liability – customer, provider
  • Physical Location – customer premises, provider premises, other location
  • Point of Control – customer, provider, other
  • Point of Management – customer, provider, other
  • Network Connectivity – private, public, both
  • Security Policy Management – customer-driven, provider-driven
  • QoS Policy Management – customer-driven, provider-driven

Our job as cloud service providers is to package these attributes in the best way for our customer-base and to make transitions between different attribute states as seamless as possible. As an architect working on one such cloud platform, however, I’d sure kill for some of that aforementioned pixie-dust…

* – Note Well: This post is not endorsed or sponsored by my employer, Savvis, Inc, and has not been written, edited, reviewed, or approved by anybody except me (Benson Schliesser).

Cloud is a System of Control

Monday, June 1st, 2009

Of course I’m biased… Bryan Doerr is my boss1 and a man that I greatly respect personally. But even considering my bias, I have to say that this is a great quote from his recent article at GigaOm, Cloud Computing: A System of Control:

…cloud computing isn’t cheap computing; it is the delivery of more control to enterprises so they can deliver IT services more affordably and efficiently.

This is the “dirty” truth: infrastructure costs money, and service providers don’t have any magic dust to make that fact obsolete. What providers do have is increased “buying power” and synergy due to large-scale multi-tenant operations. As well, an enterprise-class cloud provider has a focus on IT and the tools needed to operate as best-of-breed.

These are issues that businesses have historically invested in, just to build a platform to support their critical apps. But with the majority of apps running on common and well-established platforms this is “undifferentiated heavy lifting”2. By investing in enterprise-class cloud services instead of in-house platforms many enterprise IT shops can become more nimble, more focused on the issues and apps that drive their business, and ultimately lead their company to further competitive advantage.

1 – Nota Bene: This post is my own, is not sponsored, and has not been reviewed by anybody. My opinions, postings, and all other materials are my own and do not necessarily represent those of my employer (Savvis, Inc.) or of any other entity.

2 – Attributed to Werner Vogels (http://www.allthingsdistributed.com/), also see http://portal.acm.org/citation.cfm?id=1466443.1466447 and http://blip.tv/file/471349