Archive

Archive for the ‘Cisco’ Category

On Amrit Williams’ (BigFix) Beyond The Perimeter Podcast

July 18th, 2010 No comments

My good friend Amrit Williams (@amrittsering) from BigFix (congrats on the IBM acquisition!) has an awesome Podcast titled “Beyond the Perimeter.”

He was nice enough to invite me to record episode 93 titled “Is Trust the Real Barrier To Cloud Computing?” (ultimately points you to an iTunes subscription.)

We spoke for almost an hour on all sorts of great discussion points related to Cloud Computing, specifically focusing on Trust (which I define in context as Security, Compliance, Control, Reliability and Privacy.)

We also spoke about the Cloud Security Alliance, CloudAudit and the HacKid conference — three things I am very passionate about.

Thanks Amrit, great conversation as usual.

/Hoff

Enhanced by Zemanta

Video: Cloud Computing in Government…

March 9th, 2010 No comments

I got the pleasure of moderating a great “Cloud Computing in Government” panel a few weeks ago at a conference in D.C.  The panelists included Mark Krzysko (Department of Defense,) Tim Schmidt (CIO, U.S. Dept. of Transportation,) and Mike Nelson (Professor, Georgetown University.)

The videographer jumped me on the way out to capture the essence of our discussion.

Direct link here.

Embedded below:

/Hoff

Reblog this post [with Zemanta]

Incomplete Thought: The Other Side Of Cloud – Where The (Wild) Infrastructure Things Are…

March 9th, 2010 3 comments

This is bound to be an unpopular viewpoint.  I’ve struggled with how to write it because I want to inspire discussion not a religious battle.  It has been hard to keep it an incomplete thought. I’m not sure I have succeeded 😉

I’d like you to understand that I come at this from the perspective of someone who talks to providers of service (Cloud and otherwise) and large enterprises every day.  Take that with a grain of whatever you enjoy ingesting.  I have also read some really interesting viewpoints contrary to mine, many of which I find really fascinating, just not subscribed to my current interpretation of reality.

Here’s the deal…

While our attention has turned to the wonders of Cloud Computing — specifically the elastic, abstracted and agile delivery of applications and the content they traffic in — an interesting thing occurs to me related to the relevancy of networking in a cloudy world:

All this talk of how Cloud Computing commoditizes “infrastructure” and challenges the need for big iron solutions, really speaks to compute, perhaps even storage, but doesn’t hold true for networking.

The evolution of these elements run on different curves.

Networking ultimately is responsible for carting bits in and out of compute/storage stacks.  This need continues to reliably intensify (beyond linear) as compute scale and densities increase.  You’re not going to be able to satisfy that need by trying to play packet ping-pong and implement networking in software only on the same devices your apps and content execute on.

As (public) Cloud providers focus on scale/elasticity as their primary disruptive capability in the compute realm, there is an underlying assumption that the networking that powers it is magically and equally as scaleable and that you can just replicate everything you do in big iron networking and security hardware and replace it one-for-one with software in the compute stacks.

The problem is that it isn’t and you can’t.

Cloud providers are already hamstrung by how they can offer rich networking and security options in their platforms given architectural decisions they made at launch – usually the pieces of architecture that provide for I/O and networking (such as the hypervisor in IaaS offerings.)  There is very real pain and strain occurring in these networks.  In Cloud IaaS solutions, the very underpinnings of the network will be the differentiation between competitors.  It already is today.

See Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where… or Incomplete Thought: The Cloud Software vs. Hardware Value Battle & Why AWS Is Really A Grid… or Big Iron Is Dead…Long Live Big Iron… and I Love the Smell Of Big Iron In the Morning.

With the enormous I/O requirements of virtualized infrastructure, the massive bandwidth requirements that rich applications, video and mobility are starting to place on connectivity, Cloud providers, ISPs, telcos, last mile operators, and enterprises are pleading for multi-terabit switching fabrics in their datacenters to deal with load *today.*

I was reminded of this today, once again, by the announcement of a 322 Terabit per second switch.  Some people shrugged. Generally these are people who outwardly do not market that they are concerned with moving enormous amounts of data and abstract away much of the connectivity that is masked by what a credit card and web browser provide.  Those that didn’t shrug are those providers who target a different kind of consumer of service.

Abstraction has become a distraction.

Raw networking horsepower, especially for those who need to move huge amounts of data between all those hyper-connected cores running hundreds of thousands of VM’s or processes, still know it as a huge need.

Before you simply think I’m being a shill because I work for networking vendor (and the one that just announced that big switch referenced above,) please check out the relevant writings on this viewpoint which I have held for years which is that we need *both* hardware and software based networking to scale efficiently and the latter simply won’t replace the former.

Virtualization and Cloud exacerbate the network-centric issues we’ve had for years.

I look forward to the pointers to the sustainable, supportable and scaleable 322 Tb/s software-based networking solutions I can download and implement today as a virtual appliance.

/Hoff

Reblog this post [with Zemanta]

Chattin’ With the Boss: “Securing the Network” (Waiting For the Jet Pack)

March 7th, 2010 8 comments

At the RSA security conference last week I spent some time with Tom Gillis on a live uStream video titled “Securing the Network.”

Tom happens to be (as he points out during a rather funny interlude) my boss’ boss — he’s the VP and GM of Cisco‘s STBU (Security Technology Business Unit.)

It’s an interesting discussion (albeit with some self-serving Cisco tidbits) surrounding how collaboration, cloud, mobility, virtualization, video, the consumerizaton of IT and, um, jet packs are changing the network and how we secure it.

Direct link here.

Embedded below:

Reblog this post [with Zemanta]

NESSessary Question: Will Virtualization Undermine Network Equipment Vendors?

August 30th, 2009 1 comment

Greg Ness touched off an interesting discussion when he asked “Will Virtualization Undermine Network Equipment Vendors?”  It’s a great read summarizing how virtualization (and Cloud) are really beginning to accelerate how classical networking equipment vendors are re-evaluating their portfolios in order to come to terms with these disruptive innovations.

I’ve written so much about this over the last three years and my response is short and sweet:

Virtualization has actually long been an enabler for network equipment vendors — not server virtualization, mind you, but network virtualization.  The same goes in the security space. The disruption caused by server virtualization is only acting as an accelerant — pushing the limits of scale, redefining organizational and operational boundaries, and acting as a forcing function causing wholesale reconsideration of archetypal network (and security) topologies.

The compressed timeframe associated with the disruption caused by virtualization and its adoption in conjunction with the arrival of Cloud Computing may seem unnatural given the relatively short window associated with its arrival, but when one takes the longer-term view, it’s quite natural.  We’ve seen it before in vignettes across the evolution of computing, but the convergence of economics, culture, technology and consumerism have amplified its relevance.

To answer Greg’s question, Virtualization will only undermine those network equipment vendors who were not prepared for it in the first place.  Those that were building highly virtualized, context-enabled routing, switching and security products will embrace this swing in the hardware/software pendulum and develop hybrid solutions that span the physical and virtual manifestations of what the “network” has become.

As I mentioned in my blog titled “Quick Bit: Virtual & Cloud Networking – Where It ISN’T Going…

Specifically, as it comes to understanding how the network plays in virtual and Cloud architectures, it’s not where the network *is* in the increasingly complex virtualized, converged and unified computing architectures, it’s where networking *isn’t.*

Where ISN'T The Network?

Where ISN'T The Network?

Take a look at your network equipment vendors.  Where do they play in that stack above?  Compare and contrast that with what is going on with vendors like Citrix/Xen with the Open vSwitch, VyattaArista with vEOS and Cisco with the Nexus 1000v*…interesting times for sure.

/Hoff

*Disclosure: I work for Cisco.

Calling All Private Cloud Haters: Amazon Just Peed On Your Fire Hydrant…

August 26th, 2009 15 comments

Werner Vogels brought a smile to my face today with his blog titled “Seamlessly Extending the Data Center – Introducing Amazon Virtual Private Cloud.”  In short:

We have developed Amazon Virtual Private Cloud (Amazon VPC) to allow our customers to seamlessly extend their IT infrastructure into the cloud while maintaining the levels of isolation required for their enterprise management tools to do their work.

In one fell swoop, AWS has:

  • Legitimized Private Cloud as a reasonable, needed, and prudent step toward Cloud adoption for enterprises,
  • Substantiated the value proposition of Private Cloud as a way of removing a barrier to Cloud entry for enterprises, and
  • Validated the ultimate vision toward hybrid Clouds and Inter-Cloud

They made this announcement from the vantage point of operating as a Public Cloud provider — in many cases THE Public Cloud provider of choice for those arguing from an exclusionary perspective that Public Cloud is the only way forward.

Now, it’s pretty clear on AWS’ position on Private Cloud; straight form the horse’s mouth Werner says “Private Cloud is not the Cloud” (see below) — but it’s also clear they’re willing to sell you some 😉

The cost for VPC isn’t exorbitant, but it’s not free, either, so the business case is clearly there (see the official VPC site)– VPN connectivity is $0.05 per VPN connection with data transfer rates of $0.10 per GB inbound and ranging from $0.17 per GB – $0.10 per GB outbound depending upon volume (with heavy data replication or intensive workloads people are going to need to watch the odometer.)

I’m going to highlight a couple of nuggets from his post:

We continuously listen to our customers to make sure our roadmap matches their needs. One important piece of feedback that mainly came from our enterprise customers was that the transition to the cloud of more complex enterprise environments was challenging. We made it a priority to address this and have worked hard in the past year to find new ways to help our customers transition applications and services to the cloud, while protecting their investments in their existing IT infrastructure. …

Private Cloud Is Not The Cloud – These CIOs know that what is sometimes dubbed “private cloud” does not meet their goal as it does not give them the benefits of the cloud: true elasticity and capex elimination. Virtualization and increased automation may give them some improvements in utilization, but they would still be holding the capital, and the operational cost would still be significantly higher.

We have been listening very closely to the real requirements that our customers have and have worked closely with many of these CIOs and their teams to understand what solution would allow them to treat the cloud as a seamless extension of their datacenter, where their standard management practices can be applied with limited or no modifications. This needs to be a solution where they get all the benefits of cloud as mentioned above [Ed: eliminates cost, elastic, removes “undifferentiated heavy lifting”] while treating it as a part of their datacenter.

We have developed Amazon Virtual Private Cloud (Amazon VPC) to allow our customers to seamlessly extend their IT infrastructure into the cloud while maintaining the levels of isolation required for their enterprise management tools to do their work.

With Amazon VPC you can:

  • Create a Virtual Private Cloud and assign an IP address block to the VPC. The address block needs to be CIDR block such that it will be easy for your internal networking to route traffic to and from the VPC instance. These are addresses you own and control, most likely as part of your current datacenter addressing practice.
  • Divide the VPC addressing up into subnets in a manner that is convenient for managing the applications and services you want run in the VPC.
  • Create a VPN connection between the VPN Gateway that is part of the VPC instance and an IPSec-based VPN router on your own premises. Configure your internal routers such that traffic for the VPC address block will flow over the VPN.
  • Start adding AWS cloud resources to your VPC. These resources are fully isolated and can only communicate to other resources in the same VPC and with those resources accessible via the VPN router. Accessibility of other resources, including those on the public internet, is subject to the standard enterprise routing and firewall policies.

Amazon VPC offers customers the best of both the cloud and the enterprise managed data center:

  • Full flexibility in creating a network layout in the cloud that complies with the manner in which IT resources are managed in your own infrastructure.
  • Isolating resources allocated in the cloud by only making them accessible through industry standard IPSec VPNs.
  • Familiar cloud paradigm to acquire and release resources on demand within your VPC, making sure that you only use those resources you really need.
  • Only pay for what you use. The resources that you place within a VPC are metered and billed using the familiar pay-as-you-go approach at the standard pricing levels published for all cloud customers. The creation of VPCs, subnets and VPN gateways is free of charge. VPN usage and VPN traffic are also priced at the familiar usage based structure

All the benefits from the cloud with respect to scalability and reliability, freeing up your engineers to work on things that really matter to your business.

Jeff Barr did a great job of giving a little more detail on his blog but also brought up a couple of points I need to noodle on from a security perspective:

Because the VPC subnets are used to isolate logically distinct functionality, we’ve chosen not to immediately support Amazon EC2 security groups. You can launch your own AMIs and most public AMIs, including Microsoft Windows AMIs. You can’t launch Amazon DevPay AMIs just yet, though.

The Amazon EC2 instances are on your network. They can access or be accessed by other systems on the network as if they were local. As far as you are concerned, the EC2 instances are additional local network resources — there is no NAT translation. EC2 instances within a VPC do not currently have Internet-facing IP addresses.

We’ve confirmed that a variety of Cisco and Juniper hardware/software VPN configurations are compatible; devices meeting our requirements as outlined in the box at right should be compatible too. We also plan to support Software VPNs in the near future.

The notion of the VPC and associated VPN connectivity coupled with the “software VPN” statement above reminds me of Cohesive F/T’s VPN-Cubed solution.  While this is an IaaS-focused discussion, it’s only fair to bring up Google’s Secure Data Connector that was announced some moons ago from a SaaS/PaaS perspective, too.

I would be remiss in my musings were I not to also suggest that Cloud brokers and Cloud service providers such as RightScale, GoGrid, Terremark, etc. were on the right path in responding to customers’ needs well before this announcement.

Further, it should be noted that now that the 800lb Gorilla has staked a flag, this will bring up all sorts of additional auditing and compliance questions, as any sort of broad connectivity into and out of security zones and asset groupings always do.  See the PCI debate (How to Be PCI Compliant In the Cloud)

At the end of the day, this is a great step forward toward — one I am happy to say that I’ve been talking about and presenting (see my Frogs presentation) for the last two years.

/Hoff

Inter-Cloud Rock, Paper, Scissors: Service Brokers, Semantic Web or APIs?

July 27th, 2009 8 comments

A very interesting philosophical and market trajectory arms race is quietly ramping while the rest of the world tries to ping together how the Kindle will kill Cloud Computing and how Twitter already has.

As @Jamesurquhart and I spend our time exploring the longer term evolution of Cloud Computing, we end up in orbit around the notion of the Inter-Cloud (or Intercloud, or InterCloud)

Inter-Cloud represents one vision that describes how Clouds of many types will interoperate, federate and provide for workload portability as well as how those that provide these services and those that consume them, will interact.  You can see an interesting summary of these issues here in a fellow colleague’s post titled: “From India to Intercloud

In the broadest sense, Cloud is being positioned in the long term to allow for true utility.  This means that at a 30,000 foot view, consumers should be able to declare their business and technology requirements for workloads or application needs and TAMO! (then a miracle occurs,) that workload or application presents itself operating somewhere that meets those needs backed up by some form of attestation by the provider. Ultimately, I’d like to see a common way of auditing and validating those attestations.  Apropos for this discussion, I bring up the notion of an API 😉

This all seems like a deceptively simple scenario.  Realistically, it represents a monstrous challenge in execution.  To wit, in Reuven Cohen’s recent write-up (“The Inter-Cloud and the Cloud of Clouds“) he quotes Vint Cerf’s definition of the problem with the issues at hand:

“…each cloud is a system unto itself. There is no way to express the idea of exchanging information between distinct computing clouds because there is no way to express the idea of “another cloud.” Nor is there any way to describe the information that is to be exchanged. Moreover, if the information contained in one computing cloud is protected from access by any but authorized users, there is no way to express how that protection is provided and how information about it should be propagated to another cloud when the data is transferred.

There’s a giant sucking sound coming from the Cloudosphere…

The market is essentially rotating around three ways of describing a solution to this problem:

  1. Consumers of service declare their requirements using some methodology for doing so (either directly to trusted and discrete service providers or) using an intermediary or “service broker.”  In the case of the service broker, it’s their job to take these declarations of service definition (service contracts) and translate them across subscribing service providers who may each have their own proprietary interface.  This is starting to heat up as we already have players emerging in this space and analyst groups are picking up interest (Yankee, Gartner)It would be much better if there were an open and standardized way of ensuring that all providers used the same common interface and way of providing attestation of service contract satisfaction/compliance, which leads to…
  2. There’s the notion of the “semantic” exchange of information between Clouds positioned by folks like Sir Tim Berners-Lee (in reference to Cerf’s quote above): “…by semantically linking data, we are able to create “the missing part of the vocabulary needed to interconnect computing clouds. The semantics of data and of the actions one can take on the data, and the vocabulary in which these actions are expressed appear to constitute the beginning of an inter-cloud computing language.” Capitalizing on Berners-Lee’s definition of the Semantic Web wherein “a vision of information that is understandable by computers, so that they can perform more of the tedious work involved in finding, sharing and combining information on the web,” we see how this approach would play well into the service broker model, also.

  3. We’ve seen a lot of noise around using one or more API’s — open or proprietary — that allow for individual Cloud operation, management, assurance and governance, however nuanced those functions may be.  Open-sourced or not, and even with unifying management interfaces available such as libcloud, each Cloud vendor today sees its capability for management and streamlined operations as its first layer of competitive differentiation and individual API’s — even when abstracted through service brokers — are a way to move offerings forward whilst working toward open standards such as these.

Honestly, my bet is that this arms race will net out such that we’ll end up with some combination of all three.

This isn’t as simple-sounding as it started, especially when we throw in the definitional differences between workload portability and interoperability  as alluded to by all three approaches.

Add packaging elements such as OVF and the problem starts expanding into a very complex multi-dimensional issue very quickly.

Workload portability using common packaging formats (such as OVF) can be leaned upon to show how providers might deal the “lock-in” argument (you can move from my competitor to me,) but true interoperability is the real challenge here.

Reuven said it very well: “...what the world needs is not yet another API to control the finer nuances of a physical or virtual infrastructure but instead a way for that infrastructure to communicate with other clouds around it regardless of what it is. The biggest hurdle to cloud interoperability appears to have very little to do with a willingness for cloud vendors to create open cloud API’s but instead the willingness to provide the ability for these clouds to effectively inter-operate with one another. More simply the capability to work along side other cloud platforms in an open way.”

Here’s how I see Inter-Cloud playing out: In the short term we’ll need the innovators to push with their own API’s, then the service brokers will abstract them on behalf of consumers in the mid-stream and ultimately we will arrive at a common, open and standardized way of solving the problem in the long term with a semantic capability that allows fluidity and agility in a consumer being able to take advantage of the model that works best for their particular needs.

Thoughts?

/Hoff

See You At Structure09 and Cisco Live!

June 18th, 2009 No comments

I managed to squeak out some additional time at the end of my first docking with the Mothership in San Jose next week such that I can attend Cisco Live!/Networkers the week after.  I’ll be at Live! up to closing on 7/1.

It will be a great opportunity to meet a bunch of Cisco folks, partners and customers…not to mention reunite with my best friend from high school whom I have not seen/heard from in twenty years 😉

If you’re going to be there, let’s either organize a tweet-up (@beaker) or a blog-down…

Contact information is in the right-hand galley, down toward the bottom.

/Hoff

Categories: Cisco Tags:

Virtual Networking Battle Heating Up: Citrix Leads $10 Million Investment In Vyatta

June 9th, 2009 No comments

Those crafty Citrix chaps are at it again.

Last month I reported from Citrix Synergy about discussions I had with Simon Crosby and Ian Pratt about the Citrix/Xen Openswitch which is Citrix’s answer to the Cisco Nexus 1000v married to VMware’s vSphere.

Virtualization.com this morning reported that Vyatta — who describe themselves as the “open source alternative to Cisco” — just raised another round of funding, but check out who’s leading it:

Vyatta today announced it has completed its $10 million Series C round of financing led by Citrix Systems. The new funding round also includes existing investors, Comcast Interactive Capital, Panorama Capital, and ArrowPath Venture Partners. As part of the investment, Gordon Payne, senior vice president and general manager of the Delivery Systems Division at Citrix, has joined the Vyatta Board of Directors where he will assist the company in its next phase of development.

Today, Vyatta also announced that it has joined the Citrix Ready product verification program to create solutions for customers deploying cloud computing infrastructures.

Vyatta will use the funds for operating capital as the company scales its sales efforts and accelerates growth across multiple markets.

Vyatta runs on standard x86 hardware and can be virtualized with modern hypervisors, including the Citrix XenServer™ virtualization platform. Vyatta delivers a full set of networking features that allow customers to connect, protect, virtualize, and optimize their networks, improving performance, reducing costs, and increasing manageability and flexibility over proprietary networking solutions. Vyatta has been deployed by hundreds of customers world-wide in both virtual and non-virtual environments.

This is very, very interesting stuff indeed and it’s clear where Citrix has its sights aimed.  This will be good for customers, regardless of platform because it’s going to drive innovation even further.

The virtual networking stacks — and what they enable — are really going to start to drive significant competitive advantage across virtualization and Cloud vendors.  It’s ought to give customers significant pause when it comes to thinking about their choice of platform and integration.

Nicely executed move, Mr. Crosby.

/Hoff

SQUIRREL! I’m joining Cisco.

June 9th, 2009 10 comments

squirrel-xsmallFrom the Cisco Data Center Networks Blog:

So, for me, one of the best parts of working here at Cisco is the opportunity to work with some incredibly smart folks.  Today, I can add one more person to that group of folks—Christofer Hoff is joining the Cisco Data Center Solutions team.  Chris has built a solid reputation in the industry for domain expertise, forward thinking and incisive commentary blended with a healthy dose of wit.  I know Chris has the tenacity of a squirrel chasing an acorn, and I am personally quite pleased to welcome Chris to the team as I see he will add both depth and breadth to our efforts.  So, if you are not familiar with Chris, definitely check out his blog, Rational Survivability and you can also follow him on Twitter as @Beaker.

Thanks for the warm welcome, Omar.  I’m beyond psyched. Besides getting to work with some awesome friends, I finally get to hug a Nexus 7000.  Getting my fingers back in the pie with cutting-edge technology, partners and customers should translate into even more interesting things to discuss when appropriate.  I can’t wait.

To answer your question before you ask it: “Yes, Same blog time. Same blog channel. Now with extra datacenter fu.”

/Hoff

Categories: Career, Cisco Tags: