With the new year nearly upon us, SearchNetworking.com met with Lori MacVittie, F5 Networks’ technology evangelist and senior technical marketing manager, to talk about major networking technology trends for 2012. She said network engineers will increasingly turn to virtual desktop infrastructure (VDI) as a way to get a handle on the megatrend of IT consumerization. Increased traffic on dynamic infrastructure will also force networking pros to bring back the out-of-band management network. Finally, network managers will have to open their networks up to more integration with DevOps teams, bringing back nightmares of a bygone era of programmable routers.
How will virtual desktop infrastructure (VDI) help enterprises with IT consumerization?
Lori MacVittie: We're back in that world where we had three different versions of Windows and asking how we support all these applications. We're seeing that with all the different tablets and smartphones and laptops. We've got applications that might not necessarily work very well on tablets, and we want to make sure that users can get to those. But we don’t want to write native clients. It's just not feasible for IT to write applications for 50 different operating systems and platforms.
So if you pull virtual desktop infrastructure into the picture, it controls the application in the VDI environment. It keeps the data inside the data center for the most part, so you can still apply the right security. And you get a little bit more control without constraining the end user. They get to use the device where they want, when they need it. But you don't have to worry about the management of the actual endpoint. Of course that has an impact on the network because you're talking about new and different protocols and more devices. Some people like to multi-task. There is a lot of traffic and there are a lot of changes to infrastructure that have to be made to support something that.
What will enterprises have to do on the network side to support all of this virtual desktop infrastructure resulting from IT consumerization?
MacVittie: One of the first things is managing access. Who are we going to allow? From where? And over what network? One of the interesting things about the phones and even some tablets today is you can connect over both the mobile network as well as your Wi-Fi. I can turn on Wi-Fi on my phone, and suddenly I'll be on Wi-Fi network instead of the mobile network. That particular piece of information to the network is important. In the case of being on Wi-Fi you know that my phone is in the building on the network. If I'm coming over the mobile network I could be anywhere. There may be a need to control access from certain locations, such as saying this information can't be delivered outside the building. So if you're coming in over a corporate Wi-Fi connection, I'll let you have it, but if you're coming over a mobile carrier network, I don't know where you are and you can't have it.
That ability to dig down and see who you are, what you are using, where you are and what it is you want is going to be important to controlling who is going to get access. That's a lot of traffic going back and forth. You need to identify the user, you have to pick up the information out of the data that's being transferred and the protocols themselves, and you need to be able to make intelligent decisions about it and start sending people to the right places. So I think that access management layer is going to be very important, just trying to keep control of what you can: the resources and the applications.
F5 has mentioned that the out-of-band management network will be a technology trend in 2012. Whatever happened to it in the first place?
MacVittie: The networks got so fast and so fat that we didn’t have a problem with congestion. So we could keep it all on the same network. It was easier, and everything was static. We didn’t really need to have real-time [management] communication. If we needed to get some information from a switch, we could pull it with SNMP. It wasn't imperative that we got it in 0.5 seconds. If I got it in 3 seconds or 5 seconds that was fine, because I was really just digging for information or running a report or trying to hook it up to some bigger management system like [HP] OpenView.
Why do you think the out-of-band management network is coming back?
Find out how NYSE-Euronext built an out-of-band management network
MacVittie: As we're seeing all these things getting more dynamic, and [enterprises] want to provision [services] on demand, that requires a lot of interaction and it can be very time-sensitive. We need be sure that if that if we need more capacity that message actually gets to all the components involved at the right time; that it's not delayed; that it's not lost.
Automation is going to make us again more sensitive to the ability of all those components to receive things in a timely way, and that may require out-of-band management networks because the traffic on [production] networks is increasing. We have a lot of video and twice the number of applications and devices. What do you prioritize? Are we going to prioritize provisioning traffic over the CEO getting his email? I don't know; that's not a question I want to answer. I want make sure that both are just as fast as they need to be.
How do you build an out-of-band management network?
MacVittie: It's either a completely separate VLAN or a completely separate physical network, so that we can make sure it's got the speed and the bandwidth and that everything on it is actually management traffic.
As things continue to get integrated and we start looking at solutions where we've got this entire integration framework where network components are starting to be more dynamic in their configuration and actions, we're going to need a lot more collaboration and an entire set of systems and architecture to be able to support all that automation and orchestration in the network.
We talk about virtualization of the network, and we say, let's assume that every component in the network is going to become virtualized. What does that mean? That means a whole lot of management and a whole lot of communication between some other system that's managing when something gets provisioned, where it gets provisioned, where it's hooked up to, the topology [behind it]. There is a whole lot of communication and integration that has to go on in order to make sure that dynamic network actually works. It's really easy to push a button and provision a switch. It's not so easy to push a button, provision a switch and actually have it configured and doing what it needs to be doing. That's going to require a lot of integration [and] a lot of management. So there's going to be a lot of traffic and a lot of communication going on. And that's going to start taking up bandwidth. Yes, we've got really fat pipes right now and really good networks. We're talking 40 gigabit at the core, and most people say that we'll never hit that. We never thought we'd need 10 gigabit either, but apparently we do.
How would a network architect determine that it's time to establish an out-of-band management network?
MacVittie: I'm a fan of proactivity, but that's not always realistic. I think [most people will [establish an out-of-band management network] at a point where it starts to be very difficult to separate that management traffic from actual business and customer traffic; when the lines between that become very difficult; when it's really hard to find what you need to see on the network; when your span ports are overloaded and you're losing packets and information; when you're not getting all the data you need, and you can't figure out why something didn't launch; or when some configuration failed and you didn’t see it.
F5 has predicted that networks will have to integrate with scripting technologies like Chef and Puppet. Why?
MacVittie: Chef and Puppet are the two primary tools of the DevOps movement. It's the attempt to bring development methodologies and processes to IT operations. They allow you to create scripts that automate the configuration of a virtual machine or a BIG-IP or a switch or some other solution in the network. That's why the network API and the ability to integrate become more important. What the DevOps guys are tasked with is, ‘Here is this application. I need you to build this deployment script that is going to deploy the virtual machine to the right place; make sure the load balancer is configured, add these firewall rules and hook it to X, Y and Z.” So they take it and they build this package and they use things like Chef and Puppet to communicate with the different networking components and tie them together into an automated deployment package so they can just go click, deploy. And when someone says I need to launch another instance they can say click, deploy, and everything gets hooked up correctly.
I think probably not enough network guys are aware of this. The DevOps guys are growing out of the server admins and app admins who are coming in and trying to focus on operations. Also, the network guys don’t want people to run a script against their switch and router. And who can blame them? We had these arguments many years ago when programmable routers showed up. Are you crazy? You're not going touch our core router. So I think there is a lot of resistance from the networking team to allow these guys to come in and do these things. But ultimately it's going to be very important.
The network is a very important piece of getting an application out and delivered. If we can't include the network in that automation and that ability to orchestrate that and create repeatable, successful deployment packages that encompass the entire network, that's what's driving [the sentiment of] ‘we hate IT, let's go to the cloud and not have to worry about switches and firewalls.’ I think that kind of cultural transformation within the network team has to happen if they are going to continue to be relevant and a part of the dynamic data center as it's evolving.
So what role do networking pros have to play? Do they need to open up their infrastructure to be manipulated by these scripting technologies?
MacVittie: They have to be aware that it's there, aware that it's necessary and form their own team of guys who provide access to other teams to do this. Or, as they look at refresh cycles, they should start looking at infrastructure in networks that has more role-based access to APIs. So you can say: ‘OK, you developers are on this VLAN so I'm going to let you mess with it. And whatever happens, it's your problem, not mine. But you can't touch the finance VLAN because it's very critical to the business.’ They need to become the gatekeepers as opposed to the dungeon guards.
How do n of capabilities of individu
MacVittie: I'm a developer by trade, so I would say play with it. But that's not feasible for most network guys. Most networking guys are well-versed with scripting languages but not with the development side that these APIs require. So they would need to ask vendors, ‘Do you have an open management API? And what development languages are supported?’ Conversely, they could go to their DevOps guys and ask, ‘What are you using?’ Then use that to evaluate. Say, ‘do you support these things because these are what we are standardizing on? Even though I don’t understand what Chef or Puppet or REST PHP-based API means, it's what I need.’ So they need to get that list together and ask those questions.
It's also important to look at some of the management vendors. Your traditional questions are still relevant and may become more relevant, because CA, IBM and VMware are moving into that space and becoming more aware that it's about managing the entire infrastructure, not about grabbing some stats via SNMP. It's no longer about a MIB. I have to be able to control you through a much easier interface, and that means doing traditional Web-based and REST APIs and scripting languages. These are things that networking guys may not be comfortable with, but getting that list together and just asking the standard questions is important.
(Sources - http://searchnetworking.techtarget.com)
No comments:
Post a Comment