The Virtual Data Center

In case you don’t have it on your RSS feeder list, check out the blogs by a few of my colleagues over at DevCentral. Lori has written two excellent posts (scroll down to find) recently on the idea of an enterprise cloud. I’ve given that some small press here but it’s definitely one of the most interesting parts of cloud computing to me. The whole idea of where the enterprise stops and where the cloud begins — be it with a more traditional VDC as outlined in the Maturity Model, or one that’s looking to keep everything internal but still offer programmatic services to internal groups — will be one of those big questions over the next 5 years or so. I actually think it’s already happening in larger enterprise data centers all around, we just don’t call it the cloud because we’re so stuck on the idea that the cloud has to be “somewhere else.” Anyway, Lori does an excellent job debunking that myth on DevCentral.

But two examples that I like to use when talking about how the cloud has already blown into the enterprise data center:

1. VM Chargeback: Chargebacks were all the rage last year as one of the key benefits to implementing virtual machines and moving towards a fully virtualized infrastructure. The idea is that one department in the enterprise, typically IT, will build virtual computing platforms for other departments and charge a per-computing fee for those services. For example, a software QA group may only need to test legacy environments once/year for major code drops. They own their own QA test lab for daily testing and for all minor releases, but it would be inefficient for them to maintain legacy or fringe operating systems like Windows Me for their annual testing. So instead, IT builds a virtual WMe farm and only spins it up when QA needs it once a year, keeping the virtual images spun down and archived on infrequently used Tier 3 storage the rest of the year. And they charge QA only when those images are in use. Once Dev finds out there is a virtual WMe farm available, they may want to test on it a few times/year as well, creating more revenue for IT. This is an application service cloud very much like Amazon’s EC2, except it’s 100% within the enterprise.
2. Single Sign-On: As intranet security finally becomes more of a recognized security threat (it’s taken 3 years, but I won’t complain and moan too much ), many enterprises are requiring that intranet sites be protected behind an SSO system tied to corporate authentication. Any department in the enterprise that puts up a new intranet site, such as Sharepoint or Wiki collaboration sites, must authenticate all users and track all access requests through the internal SSO system. IT owns SSO and no department has access to that or the auth directory on the back-end, yet each department is responsible for writing their new application to require this service. This architecture basically becomes a security cloud element.

So I do believe that the move to the enterprise cloud is going to happen and in fact is already well underway. The problem isn’t with writing remote services within the data center; like many things to do with virtualization, the problem is getting people to understand the ideas and not get all wrapped up in words and the terminology. Thanks Lori for braving the downpour and helping to weather the storm. I know, the cloud metaphors just won’t stop…

A few months ago, I wrote a paper and started pushing out this idea of a Virtual Data Center Maturity Model, a roadmap of sorts for you to map your current data center, with respect to virtualization technologies, to a progression plan based on your implemented levels of virtualization. The general idea is that there are 5 levels of virtualization maturity in the data center, ranging from a level 1, the most basic data center with “virtually” no virtualization through a level 5 data center, which is a complete implementation of Service Virtualization. I didn’t come up with these ideas on my own; they were done with the help of a few of my colleagues including Kieth, one of my co-VDC posters on this blog.

I also recorded a podcast with Network World’s Beth Schultz which was posted earlier this week as part of their New Data Center site. Rather than go into all the details here, why not take a gander at the podcast and content below and see what you think. How does your Data Center fit into the model today and what are your plans moving forward?

Network World Podcast

Other “Voices of Virtualization” and Network World content on The New Data Center

The VDC Maturity Model - Moving Up The Virtual Data Center Stack Whitepaper

The VDC Maturity Model Explained (A two-page handout for your wall )

Up next in the next day or so (taken with a grain of salt given my posting schedule lately): How do Cloud Computing and solutions like SaaS fit into the Maturity Model?

As has already been widely reported this morning, a bug in VMware’s ESX Update 2 caused more problems than it fixed, in fact it caused catastrophic problems. It appears to have mistakingly included a build time-out that impacted ESX licenses, ultimately keeping VMs from spinning up (no valid license, ESX won’t start VMs). I don’t want to trip the sprinklers quite yet, but I think I am going to tiptoe over to the closest Red Breakglass box and pull the fire alarm on this one. Oh yeah, this is bad.

We’ve talked it about here quite a bit, but ESX is basically a “Data center in a data center;” it’s a complete DC solution that offers systems, hardware, networking, management, security (in the form of VMs)…basically everything. And this simple software coding mistake was able to take down that entire DC platform for some customers. Imagine if your colo provider called you one morning and said “Um, yeah, we had a guy call in sick this morning so we just unplugged the entire data center. We have a backup person coming in soon though, so you should be able to turn on your machines in about 2-4 hours. We’re working on it. It happens.” That’s basically what VMware has done. And most importantly, there was no redundancy that could have prevented this (beyond a company not patching all of their hosts at the same time).

My first thought this morning when I saw this pop up was service providers: companies providing virtual hosting services to customers. These providers have SLAs in place for their customers and if a data center goes off-line for any amount of time, the end-customer isn’t going to be happy and is probably going to either walk from that SP or want a nice big refund on their monthly bill. When my broadband goes out for more than an hour during the business day I want a refund, and I have redundant connections for when that happens. I can only imagine how much this would cost a SP who pushed out the update on a large scale. Now granted, I’m sure that production houses using ESX didn’t push this out live, but what if the timeout bug didn’t show up for 30 days. Patch testing would have looked fine, then it would have been rolled out to production, then BAM!

Bottom line: this type of issue has the ability to cost customers (both SP and enterprise alike) a tremendous amount of money. We’re all putting so much faith on a relatively nascent technology in the grand scheme of data center things. You know that old phrase “Don’t put all your eggs in one basket?” Well maybe this is a good wakeup call for evaluating your VDC migration plan, and looking at ultimate costs, building a redundant failover plan for when this happens again once you’ve deployed ESX, maybe thinking as heterogeneously as possible, etc. It’s your data center; do you want to entrust it all to someone else without maintaining ownership and control?  And more importantly, can you afford to trust someone else, ’cause it could be an expensive gamble.

For some strange reason I choose to work even when I’m not working and have what some could call two jobs (well, one real job and another job that supports itself, anyway). My day job is what you see here: helping to change the way people think about and implement virtualization in their data center. My moonlit weekend job that doesn’t quite pay any bills (yet) is professional photographer. To date, these two worlds haven’t had any relation or overlap at all (although I did take the main picture you see in the blog header, which is a shot of freshly installed data center racks, so maybe that counts). Last night, however, my separate professional lives collided in a storm I hadn’t witnessed before, and I felt rouge waves on both sides.

As has been widely reported, Amazon’s S3 service was down for a good while on Sunday, July 20th. I don’t personally or directly use their service (although I do know of individuals who are looking into it as a safe and secure backup system), however I do use SmugMug as my back-end photo “store” and processing lab for the pro photog business and (as I learned on Monday) SmugMug uses S3 for all of my valuable and (hopefully someday) bill-paying photography. I have my own local backup systems that I manage (more on that some other time) and I don’t rely on SmugMug as my content storage house, but I do rely on them to make my photography available for purchase (always available, always fast, and always securely). But I don’t want to know what they use in their data center or how they manage and store my content; I only want to know that my content is safe and available. And all was good in the fields until Sunday evening when S3 went down, and took SmugMug (and all of the pro photographers they support) down with it (details available here).

So on Monday morning I began looking into the S3 outage for the Day Job and just happened to see that my Night Job was impacted by the outage, and that got my head all spinning. It got me spinning primarily because this is the 2nd outage that S3 has suffered in the past few months, and that’s big business for a lot of people beyond SmugMug. For most normal enterprise IT shops that kept their storage in-house, a critical outage and unavailability of dynamic data twice in such a short amount of time would cause the higher-ups to start asking questions about what, why, who, and how to make sure this never happens again. I imagine those types of questions are happening for large-scale S3 customers, like SmugMug, all around the globe.

The other reason I got so spun up was the response, or lack-there-of, from Amazon. As far as I can tell, the first reports came into their public forum from customers in droves reporting a “Service Unavailable” error message. Shouldn’t Amazon have known before the customers, and shouldn’t they have done a better job (beyond posting a green/yellow/red dot on a service page) notifying all their customers? Does SmugMug really want to find out about a storage outage when they try to retrieve my galleries for perspective customer, or would they prefer to know before hand so they don’t let their app spin indefinitely? Or here’s a novel idea: Perhaps Amazon should architect their storage service in an HA/DR manner so that a customer never sees a “Service Unavailable” message, or more importantly so that their service never goes down beyond a simple blip while service requests are redirected. Highly available data centers ain’t rocket science, and since Amazon is building VDCs like nobody’s business, perhaps they should already know this…

I don’t want to be too short or critical here, but f anything, Amazon is blazing a trail in the Clouds on how not to build a production-class cloud service. The core requirement for offering a cloud service has go to be availability above everything else. Otherwise there’s no reason for a customer to trust the service with their mission critical data. My Night Job customer persona is hoping that SmugMug is really sticking it to Amazon for taking them down (and at the same time making sure all their own eggs don’t fall off the tree when the S3 nest crashes again).

I think I’m going to write Amazon’s regular storefront customer service and ask for a credit in their MP3 download store to compensate for all the money I lost by not being able to sell my photographs while S3 was down. Think they’ll go for it?

I just read an interesting post by Craig over at Cloud Security about Second Life avatars that can jump from one “grid” to another, and then watched Michael Thumann’s discussion on hacking the SL software and platform (which to me is somewhat different that using the built-in tools to escape the bounds of confined grids, but I’m willing to be wrong on that). Now I know virtually nothing about the architecture in Second Life, and I’d like to keep it that way. I have something in my core that fundamentally disagrees with Second Life so I stay away. However, voyeuristically it is interesting to read about people who don’t agree with my opinions and do play around with SL. Everyone has a hobby.

One of the interesting items from Craig’s post is the implied association he makes between SL and the cloud, linking the security of virtual worlds to cloud security. Maybe he didn’t mean to make this association (although the post is called “Collaboration in the Cloud,” so I have to assume) but I’d have to disagree with this association for a number of reasons, primarily the use of the term cloud in relation to anything consumer driven. I know, I’m a stickler for using the right word to describe the right thing; what can I say? Someone sitting down and logging into Second Life isn’t logging into the cloud, they’re logging into a MMOG to play a game, not to invoke a cloud-based service. This would be like saying every time I log into my online banking site I’m invoking Cloud Banking. I’m not. My banking site may be calling methods and functions from the cloud, but I don’t see that. I see a web page.  Or when I pull up my cable DVR’s “On Demand” option; this isn’t called the Cable Cloud or the VoD Cloud.  Just because it sends a packet outside my house doesn’t mean it’s a cloud service.

Maybe it’s took picky, but I think this is how technology terms are co-opted in the first place and become way too overused. Cloud Computing has a very specific definition, as does Cloud Security. But there is no such thing as Cloud Gaming (nor Cloud Banking), and just because an internet-based game has security flaws doesn’t mean that those are Cloud Security issues. They’re just security flaws in software. The first time an analyst asks me my opinions on how Second Life is impacting the cloud or Cloud Security, I’m going to literally blow a gasket, right there on the floor, and coredump screaming “Does not compute!”

Enterprises and Service Providers have a Cloud; consumers have the Internet. They’re not in the same ballpark, not even in the same freakin’ game. Let’s call a spade a spade and the cloud the cloud. Or maybe I’m just grump because it’s Friday afternoon and 72 deg outside in the Pacific Northwest and I’m inside reading instead of relaxing on the beach with my dog, picking out Cloud Animals.

Wow, has it really been almost a month since my last post? Goodness…first and foremost, I should apologize. I have no excuse for the lag beyond being heads-down working and contemplating the virtual universe. No vacations. No burning the midnight oil for weeks at a time. Just working. Although I do love my job, so maybe I can just default to “Time flies when you’re having fun” and realize that I’m getting older and everything sweeps by faster now.

And during my silence, I’ve also been fighting with Vista issues across the board. Not all Vista’s fault, but still all Vista related. However, even though I may fault Vista for their heavy reliance on the GUI, my biggest problem these days is with VMware Fusion on the Mac (Why do these virtual platform vendors frustrate me so? Am I alone?). The thing that gets me is that I’m the target market for these products. The marketing and product is geared towards me, and yet they still can’t deliver a product for the professional IT administrator.

The first thing I did with the MacBook after it was up and configured was install Vista via Boot Camp, which kicked ass! The speed was amazing, and so far, everything has been running very smoothly (although I haven’t tested BitLocker yet, which is my next big endeavor and a requirement for me). The only downside is the dual-booting. My goal is to eventually go 100% MacBook, but my work environment has to stay MS focused. So dual-booting is an option, but not an optimal. Enter VMware Fusion 2.0 Beta, which can run a Vista Boot Camp partition in a VM environment. Good idea: I can keep my OS’ isolated but still access my work environment from any running state. If I’m working all day, Boot Camp; if I happen to be in Leopard but need to grab something from my work environment, no problem. But it just doesn’t work that way.

For one, Fusion doesn’t support 3D acceleration. Now this may seem trivial for the non-gaming work environment, but unfortunately Vista is so dependent on graphics for everything, having a less-than-stellar graphics driver in Fusion takes the entire VM down to a crawl, either when running in full mode or with Unity. Office 2007 applications take in the double-digits-to-minutes timeframe to launch. Using the Vista Performance Meter, all other hardware is on-par with the screaming Boot Camp install, so the video driver is responsible for slowing everything down. Makes it unusable. VMware’s marketing for Fusion 2.0 wants you to believe that you can run 3D games on multiple monitors, but not with Vista, only XP. And if I dual-boot into Boot Camp, I have to manually re-run the performance meter because it keeps the VMware driver score as the baseline, which takes my Boot Camp install down from a 5.2 system performance level to a 1.0. Re-running fixes that when the perf monitor loads the Boot Camp video driver, but it’s a manual process I have to do every time I dual-boot. Which leads me to…

And then the licensing issue, which to me is a huge one. Boot your Vista install as a VM and then boot it natively with Boot Camp and your install becomes unlicensed. Microsoft thinks you’re trying to steal money from their food fund, dogs start living with cats, the world is in chaos. You can re-enter your license key and it re-registers fine, but that takes time and requires you to keep a copy of your key handy just in case you need to hit Boot Camp for any reason (ie a presentation). This is supposed to be fixed by Beta 2 or RC1 so we’ll see.

So here I am, unable to reach my vision of running one platform for all my needs. Now I’ve talked here before about how I just want to run one physical machine and virtualize everything else, mainly my apps. I don’t want to have to choose between multiple OS’s, or Office 2007 running in a VM over Office 2008 on Leopard. I just want to boot then run. But all the local virtual environments I’ve tested so far have failed me. We’re just not there yet. VDI doesn’t help me here either b/c I can’t rely on an upstream connection. I want complete cross-platform virtualization locally. Is that so wrong?

So maybe that’s why I haven’t posted in so long…the virtual market is failing me and I don’t want to face reality. And now I’m depressed and need a minute. I’m going to mount my virtual storage NAS over my wireless VLAN and play Another Somebody Done Somebody Wrong Song in hopes that someone else’s pain will make me feel better…

Once my brain starts spinning around one particular topic, it basically stays there until I’ve reached some sort of mental closure. Now that closure may be achieved when I’ve reached a personal conclusion, or it may come when I throw my arms up and say “I’m out!” Either way, I need to keep processing something until I’ve reached one of those points. This week, it’s the overlay between VMs, VMDK/VHDs, and OVF, which I started a few days ago with this post. So here I am again, and now I’m wondering if there’s even a point to OVF.

As reported at Server Virtualization, the DMTF is saying that OVF is still a few months away from a standard. Now a few months may not seem like a long time, but there are going to be some big movements between now and then, depending on which projects release on time and which are delayed, most importantly we should see Hyper-V moving out of beta. Chris Wolf has some interesting comments on that post and to be honest…I just don’t get all the fuss. Mounting VMs so any hypervisor can run an application? Telling the hypervisor what the packaged VM OS needs in order to optimize the running environment? It just seems like too many steps to get to the endgame. Here are two examples where I think OVF is just going to get in the way:

• Converting VM Disk Images: Chris states that even with OVF (right now it’s just a packaging framework standard, not a runtime standard) an interim conversion step will most likely be required. So when I grab a pre-packaged VM appliance from VMware wrapped in OVF and decide I want to run that on Hyper-V, I’m going to have to extract it, do a full conversion (which amounts to running P2V, or V2V in this case), and then re-wrap it before I drop it on Hyper-V. Hypervisors are platforms, and every hypervisor is going to run VMs in a different manner. Running 2008 in Hyper-V probably won’t take as many hypervisor resources as running it on VMware simply because 2008 shares kernel code with Hyper-V. So my app on 2008 will require X resources for Hyper-V but Y resources for VMware. Then what’s the point in packaging that data with the app? Is OVF going to have an XML switch element that contains running information for every possible hypervisor scenario? If I’m that concerned with app performance, I’m going to build the VM and app natively and not trust two translation layers (the original hypervisor the VM was built for and the OVF management metadata to allocate resources for me). To me, this is pushing OS virtualization further away from production environments.
• Lose the OS: OVF and virtual appliances deal with full-blown VMs; the OS, the disk image, and the running hypervisor. But we’re making such strides towards true application virtualization these days, I don’t see the need to focus on a solution that’s only concerned with bloated OS and disk images, pieces of the virtualization puzzle that only exist to run applications. I’d much rather see work being done on something like APS (Application Packaging Standard). Unlike VMs and VMDKs/VHDs, applications truly are portable. I’m looking forward to the day when we don’t need a full-blown OS in the data center, where we run apps directly on a hypervisor, where a packaging solution like APS can really be valuable. But even until then, something like APS has more value today because it’s “future proofing” our solutions for tomorrow. With VMs, both the OS and hypervisor have to become hardware resource managers. With true application virtualization, you only need the app hypervisor to manage your resources.

So why OVF? Why not let the DC admins worry about the hypervisor and OS installs? These are platform decisions, just like choosing HP vs. Dell. You don’t see Microsoft offering a pre-built 2003 image installed on a Dell with a conversion utility to run it on HP hardware (more on that in a few days as I start to drift into the problems with P2V…stay tuned) because that wouldn’t make any sense. OVF is the exact same thing: it’s a system to create a full-blown OS image and move it around the heterogeneous data center. But why? Every OS install is different, and it will continue to be that way until we get rid of the OS, even with major band-aids like OVF. Focus on the application and why you’re virtualizing in the first place. Right now, OVF appears to be an extra step we don’t need.

I know I’ve picked on Cisco’s Data Center blog a few times here, but they make themselves such an easy target, how can I let it slide? Case in point, this post from a few weeks ago called “The Dreaded V Word.” This posts starts on a good note: Doug jumps right into the hype of the “V Word,” although I think it surpassed SOA sometime last year both on the CIO hype scale and with companies claiming to have a buzzword of the year solution. This is one of the reasons I love answering the “Isn’t Service Virtualization just SOA?” question. “[Buzzwords] are colliding!! George is getting very upset!!”

But ironically enough, Doug actually makes the virtualization buzzword factor exponentially worse. Here’s how he defines virtualization:

“Virtualization as a technology rooted in the data center requiring network, storage and server to work together and thus drives IT collaboration. It allows the business to extend the lifecycle of capital assets they’ve already invested in and then reduce the operational expenses for remedial tasks (e.g. administrative change control, server batch moves, etc.) which allows them to free up more resources to focus on business critical applications and strategic new market entrances and such.”

Huh? Rooted in the Data Center? Drives IT collaboration? Extend capital assets? Reduce operations expenses for remedial tasks? Wow. Virtualization does all that? If I had a sales guy from a company come into my IT department and give me that answer when I asked him why I need to start looking at virtualization in my DC, I’d toss him out on his ear. That doesn’t tell me anything about what virtualization is, the problem statement, or the business benefit. Talk about using a lot of buzzwords. The term only becomes “dreaded” when you define it like that.

Wait, I just got it: now I know what Doug is trying to say:

• I call up my network guy (IT collaboration)
• Tell him to cancel the order for more Cisco switches (Extend Capital Assets)
• I’ve decided to consolidate in the DC (Free up resources)
• And move all my L2-4 switching over to all those awesome Application Delivery Controllers I just bought (Reduce OpEx for remedial tasks, ie switching)

Seriously, I couldn’t agree more that we’re still dealing with the virtualization buzzword, but to address the issue from a company like Cisco, who obviously has vested interest and virtualization technologies in the data center, is really a bad idea. And then to throw in Green IT and “Data Center 3.0″ all in the same post…a term you know I can’t stand. Did no one at Cisco cleanse this post before it went out or pass it through the Buzzword BS Meter first?

And while we’re at it, have you seen one of Cisco’s other blogs, Virtual Worlds, or basically their Second Life Marketing Blog? If I was new to data center virtualization and I wanted to get Cisco’s take, from their blogs I would think that Cisco is one big publicity company that’s more concerned with marketing names, buzzwords, and playing virtual games than the infrastructure of my Data Center. I know that’s not the case, and I know they have some deep virtualization technologies, but that’s the face their presenting through these blogs. It’s one thing to spout poetic on a personal blog; it’s something completely different when your spouting via a domain named blogs.cisco.com. I hope someone in the Technical Marketing team over there is reading this and their own blogs.

I know, it’s been quiet around here lately. I’ve been heads down in research and haven’t had a lot of time to digest new ideas and pick up old ones (or respond to Hoff ). But the Symantec+Veritas+Xen announcement today gave me good reason to poke my head up, log in, and revisit an idea I’ve been working on for a while.

When I’m not noodling virtualization and data centers, I’m a semi-professional photographer; most of my evening/weekend free time in 2008 has been spent on building a solid digital workflow from shooting to selling. One of the technology choices I’ve implemented in the middle of my workflow is converting from my camera’s proprietary RAW format to the Adobe’s open Digital Negative file format, DNG. I made this decision because I don’t want to be stuck fighting with specific RAW format support down the road, and I can edit and process files natively in DNG using Adobe tools, which I use already. So you could say I’ve “Future Proofed” my workflow for tomorrow, even if I change cameras or processing software.

So the above started me thinking a few months ago about virtual machine filesystems and what’s going on under the hood. The whole model today seems silly to me: I have a VM guest that has filesystem, say NTFS; that filesystem is packaged in a proprietary flat-file format for the virtual hypervisor platform, VMDK in VMware’s case, and that flat file is stored on top of another filesystem (VMFS, again for VMware), which is vaguely connected to the host OS filesystem (let’s say ext3 for ESX), and then layered on top of yet another file management tool with iSCSI, only to finally be stored on a real disk on a SAN. So my ‘index.html’ file hosted on my guest IIS VM has to go through approximately 6 virtual<->physical layers before it’s physically stored on a device that can manage that block data, such as VMware’s DRS. That seems excessive and very inefficient.

So that brought up two questions:

1. Why can’t we have a solution like DNG for VM filesystems that will allow me to take that flat-file and manage it as part of my virtual infrastructure on any platform? Granted we do have the OVF, but this is mostly a transport and packaging solution; it’s not a running solution. And yes, I know that disk formats are part of each hypervisor secret sauce, but that’s exactly what I’m suggesting: Let each vendor continue to refine their secret sauce (just like Nikon and Sony will continue to refine their particular flavors of RAW), but let me store and run that secret sauce in an open utility so I can simply click to push a VMDK from VMware to Hyper-V.
2. Beyond the above, do we even need that extra secret sauce filesystem layer at all? Why can’t ESX write directly to a block device in my SAN over iSCSI without storing my guest filesystem in a flat package that’s stored on VMware’s proprietary VMFS file system, only to be pushed out over an iSCSI network? If we’re going through so much trouble to virtualize the OS anyway, why can’t we simply write a translator that takes the guest block read/write request and map that to a physical block on our remote SAN/NAS disk? Basically, let’s virtualize the guest filesystem. Think about the I/O we could save…may make those VMware storage benchmarks near moot. Which leads me to…

The Symantec announcement. If it’s true, it’s exactly what we need in the VM storage space and a no-brainer. Anything that removes middleman components while also adding manageability is a great thing. We remove moving parts, which in itself can remove complexity, and then obfuscate the management (or probably integrate it an existing management platform)…we move <this much> closer to a functional VDC. And since it’s Xen based and is purported to work with Hyper-V, this could also be a driver in customers choosing one hypervisor platform over another. If it delivers and specifically doesn’t work with VMware ESX, VMFS, Virtual Center, etc, then it could be end up being a platform driver for Xen and Hyper-V. We’ll have to wait until the end of the year to see if this solution delivers as promised.

I’ve read two posts in the past few days that spin around the idea of how the network factors into a complete security solution. The first from Hoff goes after the concept of moving security management responsibility to the network; the second from Richard over at TaoSecurity covers terminating SSL at the perimeter and moving your trust network closer to the edge. Being a guy who started on the network and moved up the stack, both of these posts gave me heartburn for different reasons.

First, Hoff: No one..er, no sane one, anyway…is suggesting that all networking management tasks be relegated to the network, anymore than anyone is suggesting that virtual security solutions (such as firewall VMs) are going to be the be-all, end-all security touchdown for both virtual and physical platforms in the data center. Hoff knows better than anyone that there is no smoking gun, and no one is suggesting that In The Year 2000 the network will own all of your security. I love Hoff’s “All My Life’s A Circle” security model, but it falls victim to the same thing that he’s railing against in the first place: There is no one security solution for everything in the data center at any given time. These solutions, regardless of where and when they fall on the cyclical time scale, should work together to provide one unified security solution, with the appropriate emphasis for any one solution being placed on the appropriate technology. We may fluctuate that emphasis, but we’ll always look at the entire solution. SSL is an application security solution, yet it is an integral part of a complete network security solution and the network can play a major and critical role in managing secure application transport and policy enforcement. Which leads me to…

Second, Tao: The interesting thing to me with this post is the assumptions that are made. You don’t have to terminate SSL only at the perimeter, nor do you have to do it passively. You can terminate SSL anywhere in your network, be it at the edge in a border device, within your DMZ or at the DMZ/private edge, or even completely within the private network. It all depends on what you’re cracking SSL to look for. If you’re looking inside an SSL VPN connection coming into your network before it hits the firewall, yes, you want to look at it as soon as possible. But you can still examine the traffic in your existing “trust zone” by moving and sandboxing that connection into a secure location, terminating SSL, examining, and if clear, re-SSL’ing and passing it back into the untrusted network. There are all kinds of great examples on how to terminate and sandbox encrypted traffic for firewall inspection, even at near-line speeds with modern SSL termination devices. If you want to crack SSL for your apps, do it completely within your DMZ or trusted private network where your apps live, far from the edge. And to Ivan’s question (which I personally thing was self motivated by the company he works for), it doesn’t have to be passive. For complete trust and control, actively terminate at the device with different keys than you use on the backend. Let the user know you’re doing this, no need to be coy about it. Actively terminate SSL to inspect it, don’t simply bridge it. You end up being your MITM.

So long story short, the network is an extremely powerful tool in your complete data center security batbelt. It’s not the only tool, but it’s also not a tool that should be taken for granted. In other words, don’t commodotize your network (or anything in the DC for that matter) or the security resources you can use on your network. Make the network work for and with your security tools. Packets and data are just electricity; you can do anything you want with them, including using your network to help secure them. Take off the silo blinders and look at what you can do at every step in your DC with networking and security. You’ll find out you can do some really cool stuff…