Microsoft Solutions

Cloud Computing and Infrastructure 2.0

Lori MacVittie — Fri, 17 Oct 2008 10:58:35 GMT

Not every infrastructure vendor needs new capabilities to support cloud computing and infrastructure 2.0.

Greg Ness of Infoblox has an excellent article on "The Next Tech Boom: Infrastructure 2.0" that is showing up everywhere. That's because it raises some interesting questions and points out some real problems that will be need to be addressed as we move further into cloud computing and virtualized environments. What is really interesting, however, is the fact that some infrastructure vendors are already there and have been for quite some time.

One thing Greg mentions that's not quite accurate (at least in the case of F5) is regarding the ability of "appliances" to "look inside servers (for other servers) or dynamically keep up with fluid meshes of hypervisors".

From Greg's article:

The appliances that have been deployed across the last thirty years simply were not architected to look inside servers (for other servers) or dynamically keep up with fluid meshes of hypervisors powering servers on and off on demand and moving them around with mouse clicks.

Enterprises already incurring dis-economies of scale today will face sheer terror when trying to manage and secure the dynamic environments of tomorrow. Rising management costs will further compromise the economics of static network infrastructure.

I must disagree. Not on the sheer terror statement, that's almost certainly true, but on the capabilities of infrastructure devices to handle a virtualized environment. Some appliances and network devices have long been able to look inside servers and dynamically keep up with the rapid changes occurring in a hypervisor-driven application infrastructure. We call one of those capabilities "intelligent health monitoring", for example, and others certainly have their own special name for a similar capability.

On the dynamic front, when you combine an intelligent application delivery controller with the ability to be orchestrated from within applications or within the OS, you get the ability to dynamically modify configuration of application delivery in real-time based on current conditions within the data center. And if you're monitoring is intelligent enough, you can sense within seconds when an application - whether virtualized or not - has disappeared or conversely, when it's come back on line. F5 has been supporting this kind of dynamic, flexible application infrastructure for years. It's not really new except that its importance has suddenly skyrocketed due to exactly the scenario Greg points out using virtualization.

WHAT ABOUT THE VIRTSEC PIECE?

There has never been a better case for centralized web application security through a web application firewall and an application delivery controller. The application delivery controller - which necessarily sits between clients and those servers - provides security at layers 2 through 7. The full stack. There's nothing really that special about a virtualized environment as far as the architecture goes for delivering applications running on those virtual servers; the protocols are still the same, and the same vulnerabilities that have plagued non-virtualized applications will also plague virtualized ones. That means that existing solutions can address those vulnerabilities in either environment, or a mix.

Add in a web application firewall to centralize application security and it really doesn't matter whether applications are going up and down like the stock market over the past week. By deploying the security at the edge, rather than within each application, you can let the application delivery controller manage the availability state of the application and concentrate on cleaning up and scanning requests for malicious content.

Centralizing security for those applications - again, whether they are deployed on a "real" or "virtual" server - has a wealth of benefits including improving performance and reducing the very complexity Greg points out that makes information security folks reach for a valium.

BUT THEY'RE DYNAMIC!

Yes, yes they are. The assumption is that given the opportunity to move virtual images around that organizations will do so - and do so on a frequent basis. I think that assumption is likely a poor one for the enterprise and probably not nearly as willy nilly for cloud computing providers, either. Certainly there will some movement, some changes, but it's not likely to be every few minutes, as is often implied.

Even if it was, some infrastructure is already prepared to deal with that dynamism. Dynamism is just another term for agility and makes the case well for loose-coupling of security and delivery with the applications living in the infrastructure. If we just apply the lessons we've learned from SOA to virtualization and cloud computing and 90% of the "Big Hairy Questions" can be answered by existing technology. We just may have to change our architectures a bit to adapt to these new computing models.

Network infrastructure, specifically application delivery, has had to deal with applications coming online and going offline since their inception. It's the nature of applications to have outages, and application delivery infrastructure, at least, already deals with those situations. It's merely the frequency of those "outages" that is increasing, not the general concept.

But what if they change IP addresses? That would indeed make things more complex. This requires even more intelligence but again, we've got that covered. While the functionality necessary to handle this kind of a scenario is not "out of the box" (yet) it is certainly not that difficult to implement if the infrastructure vendor provides the right kind of integration capability. Which most do already.

Greg isn't wrong in his assertions. There are plenty of pieces of network infrastructure that need to take a look at these new environments and adjust how they deal with the dynamic nature of virtualization and cloud computing in general. But it's not all infrastructure that needs to "get up to speed". Some infrastructure has been ready for this scenario for years and it's just now that the application infrastructure and deployment models (SOA, cloud computing, virtualization) has actually caught up and made those features even more important to a successful application deployment.

Application delivery in general has stayed ahead of the curve and is already well-suited to cloud computing and virtualized environments. So I guess some devices are already "Infrastructure 2.0" ready.

I guess what we really need is a sticker to slap on the product that says so.

Technorati Tags: MacVittie,f5,virtualization,hyper-v,microsoft,vmware,virtsec,security,application security,application deilvery,infrastructure,application delivery controllers,load balancers,dynamism,cloud computing infrastructure,cloud computing

If Kernighan were a network architect he would say...

Lori MacVittie — Wed, 03 Sep 2008 16:28:52 GMT

My brother sent over a question to Don and I on a coding problem he's having. Yes, most of my family members are geeks, thank you. You can probably blame that on my COBOL-coding mother.

In any case, his signature always contains this lovely quote from Brian Kernighan:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

That got me thinking about network topology and configuration and application delivery. Yes, most things get me thinking about that, thank you. You can probably blame ... well, no one. That's just the way I am.

But this tongue-in-cheek humor from Kernighan is just as applicable to network and application delivery architecture. If he were a network architect he'd probably use "troubleshooting" instead of "debugging" and "configuring" instead of "writing the code", but the core of the concept would remain the same: something is wrong and we have to find out what it is and it's really, really hard. I'm pretty sure this is where the idea of outsmarting yourself came from.

Troubleshooting a network is a daunting task. There's routers, switches, proxies, application delivery controllers, application servers, and databases. There's file servers, virtualization, and a plethora of other devices and systems through which every single packet flows just to answer a simple "Hi, are you there?" ICMP message.

Sometimes it's amazing anything works like we expect it to.

Diagramming out a network is one thing, deploying and configuring all the requisite devices that make up the core network and the application delivery network is another. And troubleshooting a problem in that complex a system is yet another.

And they talk about the horrors of debugging spaghetti code! Most network topologies end up, over time, looking like spaghetti, only network architects don't have a "step through, into, or over" option on their network analyzers.

A single, simple configuration error, omission, or mistake can result in hours or even days of digging through logs and network captures trying to figure out what's wrong. Although the "ah-ha!" moment (that precious moment in time when you figure out what is wrong and fix it, or you hit compile and the application runs as expected) is incredibly satisfying, but still we wish we didn't have to sludge through every trench to get there. One or two would suffice.

One of the ways in which we (as in F5) are trying to cut the time necessary to troubleshoot is to provide configuration and deployment advice that's already gone through the troubleshooting process - because we've already done a lot of the troubleshooting for you. The goal of an application ready network - whether it's for Oracle, Microsoft, BEA, or SAP applications - is to help cut down on the number of "gotchas" that invariably creep out of the network on the backs of gremlins and interfere with a successful application deployment.

And we're working on making it even easier. But we'll talk about that later.

Technorati Tags: MacVittie,F5,application delivery,troubleshooting,debugging,kernighan,application ready network,oracle,microsoft,bea,sap,applications,spaghetti

Dear Data Center Guy

Lori MacVittie — Fri, 29 Aug 2008 11:05:26 GMT

You walked past me again today without stopping. I remember when you used to stop and admire my glowing red ball every day. But that was back when I was brand new and you thought I was the center of your data center.

I heard you talking to some friends about looking for a web acceleration solution yesterday. You were going to a meeting about it later that afternoon and you were so excited it was almost like old times, until you pointed me out on the way by and said, "Oh yeah, there's our load balancer."

It was then that I knew, knew in my backplane that you weren't paying attention to me. We just never talk anymore, do we? I am so much more than just a load-balancer, but you'd rather talk to vendors and go out to lunch with them instead of hanging out with me.

I can accelerate web applications like nobody's business, if you just give me the chance. Remember? I have a modular core that can add functionality like web application acceleration, advanced client authentication, IPv6, and layer 7 rate shaping with software modules. I have extra cycles, I can do it, but you wouldn't know that because you haven't touched my GUI in months.

It's my own fault, I suppose, for being so dependable that I don't need a lot of your attention.

I see you hanging around rack #3, checking out that router all the time. You know it's a chatty thing, don't you? You should hear what it says when you aren't tapped into a port. Always bossing us all around, telling us where to route things and reminding us that it's in charge. Whispering to you in foreign languages like OSPF and RIP. I can speak a lot of languages too, you know. I can speak SharePoint, and SAP, and Oracle, and Exchange. I can even speak Adobe.

And now you're thinking about bringing in another piece of hardware? After all these years? I suppose you'll put it in rack #1, right at eye level where you can see it all the time. Haven't I always been here for you, working hard all these years to keep your applications available? I just want to hang out with you again, like we used to back when it was just you and me. When there weren't all these point solutions cluttering up the data center and using up all the power and taking up all your time with patches and upgrades and maintenance.

I can do more, you know. I can solve more of your problems than you realize. Application acceleration, security, rate shaping, authentication, caching, compression, message and protocol security. I can do it for you, I really can.

Just give me a chance to tell you about them and I know you'll never look at another point product for a problem I can solve again.

Technorati Tags: MacVittie,F5,BIG-IP,application acceleration,rate shaping,security,availability,caching,compression,load-balancing,internet,protocols,application delivery,application delivery controller

People Delivery Networks

Lori MacVittie — Fri, 11 May 2007 20:20:55 GMT

Don and I were standing in the Minneapolis-St. Paul airport last night on our way home from Seattle, watching the boarding process and waiting for our turn to board, when it occured to me how similar the process of delivering people is to delivering applications.

Gate agents often board passengers by zone, or group, or row. They board by prioritization. They board by status. And people consistently ignore the direction of the gate agent and just board willy nilly whenever they like, causing congestion both on the jetway and on the plane - all because the policies designed to optimize the boarding process don't truly address the specific needs of people. When someone boards early during the "if you need extra time" phase that appears to, on the outside, not truly need that extra time people comment negatively and wonder whether the person in question is just exploiting the kindness of the gate agent or if they really need the time.

The gate agent has no idea whether someone has a heart condition, or is in pain, or if there is some other mitigating factor that is driving this person to board early. So the gate agent gives them the benefit of the doubt. The gate agent is there to enforce a set of broad policies that ensure the reliable, fast, secure delivery of all people from the gate area to the plane, not to optimize the experience for the individual. The agent is, after all, only people aware, s/he can't know the specific details of each individual person and the argument against doing so is that it would seriously inhibit the efficiency of the boarding process. Becoming people proficient takes time.

Like people, even though many applications appear the same on the outside (delivered via HTTP in many cases), they're very different on the inside and may in fact have special delivery needs. Unfortunately, like gate agents, most application delivery networks are merely application aware. They know some amount of detail about, say Microsoft SharePoint, but they aren't intimately familiar with all the little nuances of that application and how it would best be delivered. Unlike the gate agent however, the application delivery network should know more. It should spend extra time with each application and understand all the intimate details about how best to deliver it, because its engineers can spend time up front learning those nuances and peculiar quirks and develop policies before deployment that ensure maximum results without interfering with the actual delivery process.

It's no long enough for an application delivery network to simply be a gate agent, offering lip-service to the notion of application focused delivery. It's no longer optimal to simply deliver all applications based on their underlying protocol, there are too many mitigating factors hidden under the covers. Application delivery networks need to understand the inner workings of applications and then execute on that understanding by creating policies and procedures that will optimize and enhance the delivery of those specific applications.

Now if we could just come up with a way to optimize that people delivery network ...

Imbibing: Mountain Dew

Technorati tags: application delivery, F5, MacVittie