Automation

Advanced Load Balancing For Developers. The Network Dev Tool

Don MacVittie — Fri, 03 Feb 2012 18:54:59 GMT

It has been a while since I wrote an installment of Load Balancing for Developers, and now I think it has been too long, but never fear, this is the grad-daddy of Load Balancing for Developers blogs, covering a useful bit of information about Application Delivery Controllers that you might want to take advantage of. For those who have joined us since my last installment, feel free to check out the entire list of blog entries (along with related blog entries) here, though I assure you that this installment, like most of the others, does not require you to have read those that went before.

ZapNGo! Is still a growing enterprise, now with several dozen complex applications and a high availability architecture that spans datacenters and the cloud. While the organization relies upon its web properties to generate revenue, those properties have been going along fine with your Application Delivery Controller (ADC) architecture.

Now though, you’re seeing a need to centralize administration of a whole lot of functions. What worked fine separately for one or two applications is no longer working so well now that you have several development teams and several dozen applications, and you need to find a way to bring the growing inter-relationships under control before maintenance and hidden dependencies swamp you in a cascading mess of disruption.

With maintenance taking a growing portion of your application development manhours, and a reasonably well positioned test environment configured with a virtual ADC to mimic your production environment, all you need now is a way to cut those maintenance manhours and reduce the amount of repetitive work required to create or update an application. Particularly update an application, because that is a constant problem, where creating is less frequent.

With many of the threats that your ZapNGo application will be known as ZapNGone eliminated, now it is efficiencies you are after. And believe it or not, these too are available in an ADC. Not all ADC’s are created equal, but this discussion will stay on topics that most ADCs can handle, and I’ll mention it when I stray from generic into specific – which I will do in one case because only one vendor supports one of the tools you can use, but all of the others should be supported by whatever ADC vendor you have, though as always, check with your vendor directly first, since I’m not an expert in the inner workings of every one.

There is a lot that many organizations do for themselves, and the array of possibilities is long – from implementing load balancing in source code to security checks in the application, the boundaries of what is expected of developers are shaped by an organization, its history, and its chosen future direction. At ZapNGo, the team has implemented a virtual test environment that as close as possible mirrors production, so that code can be implemented and tested in the way it will be used. They use an ADC for load balancing, so that they don’t have to rewrite the same code over and over, and they have a policy of utilizing a familiar subset of ADC functionality on all applications that face the public.

The company is successful and growing, but as always happens in companies in that situation, the pressures upon them are changing just by virtue of their growth. There are more new people who don’t yet have intimate knowledge of the code base, network topology, security policies, whatever their area of expertise is. There are more lines of code to maintain, while new projects are being brought up at a more rapid pace and with higher priorities (I’ve twice lived through the “Everything is high priority? Well this is highest priority!” syndrome while working in IT. Thankfully, most companies grow out of that fast when it’s pointed out that if everything is priority #1, nothing is). Timelines to complete projects – be they new development, bug fixes, or enhancements are stretching longer and longer as the percentage of gurus in the company is down and the complexity of the code and the architecture it runs on is up.

So what is a development manager to do to increase productivity? Teaming newer developers with people who’ve been around since the beginning is helping, but those seasoned developers are a smaller and smaller percentage of the workforce, while the volume of work has slowly removed them from some of the many products now under management. Adopting coding standards and standardized libraries helps increase experience portability between projects, but doesn’t do enough.

Enter offloading to the ADC. Some things just don’t have to be done in code, and if they don’t have to be, at this stage in the company’s growth, IT management at ZapNGo (that’s you!) decides they won’t be. There just isn’t time for non-essential development anymore.

Utilizing a policy management tool and/or an Application Firewall on the ADC can improve security without increasing the code base, for example. And that shaves hours off of maintenance projects, while standardizing on one or a few implementations that are simply selected on the ADC. Implementing Web Application Acceleration protocols on the ADC means that less in-code optimization has to occur. Performance is no longer purely the role of developers (but of course it is still a concern. No Web Application Acceleration tool can make a loop that runs for five minutes run faster), they can allow the Web Application Acceleration tool to shrink the amount of data being sent to the users’ browser for you. Utilizing a WAN Optimization ADC tool to improve the performance of bulk copies or backups to a remote datacenter or cloud storage… The list goes on and on.

The key is that the ADC enables a lot of opportunities for App Dev to be more responsive to the needs of the organization by moving repetitive tasks to the ADC and standardizing them. And a heaping bonus is that it also does that for operations with a different subset of functionality, meaning one toolset gives both App Dev and Operations a bit more time out of their day for servicing important organizational needs. Some would say this is all part of DevOps, some would say it is not. I leave those discussions to others, all I care is that it can make your apps more secure, fast, and available, while cutting down on workload.

And if your ADC supports an SSL VPN, your developers can work from home when necessary. Or more likely, if your code is your IP, a subset of your developers can. Making ZapNGo more responsive, easier to maintain, and more adaptable to the changes coming next week/month/year. That’s what ADCs do. And they’re pretty darned good at it.

That brings us to the one bit that I have to caveat with F5 only, and that is iApps. An iApp is a constructed configuration tool that asks a few questions and then deploys all the bits necessary to set up an ADC for a particular application. Why do I mention it here? Well if you have dozens of applications with similar characteristics, you can create an iApp Template and use it to rapidly bring new applications or new instances of applications online. And since it is abstracted, these iApp templates can be designed such that AppDev, or even the business owner, is able to operate them Meaning less time worrying about what network resources will be available, how they’re configured, and waiting for operations to have time to implement them (in an advanced ADC that is being utilized to its maximum in a complex application environment, this can be hundreds of networking objects to configure – all encapsulated into a form). Less time on the project timeline, more time for the next project. Or for the post deployment party. One of the two. That’s it for the F5 only bit.

And knowing that all of these items are standardized means less things to get mis-configured, more surety that it will all work right the first time. As with all of these articles, that offers you the most important benefit… A good night’s sleep.

Technorati Tags: Application Delivery Controllers,VPN,Security,Applicaiton Development,Acceleration,WAN Optimization,Encryption,F5 Networks,Load Balancing For Developers,Don MacVittie,blog

Connect with Don:	Connect with F5:

Related Articles and Blogs

What’s In Your Datacenter

Don MacVittie — Thu, 12 Jan 2012 19:00:22 GMT

There is a series of advertisements for Capital One aired in the US featuring Vikings talking about “more points” from their credit cards that asks “What’s in your wallet?” While they’re entertaining, I never understood what Vikings had to do with a credit card, other than perhaps both like to plunder unsuspecting innocents. Though in fairness, credit card issuers tend to just increase rates, while the Vikings enjoyed wholesale slaughter when they plundered, and took literally everything not nailed down.

But the question is valid in the modern day. Most people have enough credit cards, and read little of what is sent to them relating to those cards, that if you are like most people, you probably don’t know for certain what is in your wallet. What are the interest rates, current balances, and limits on all the cards you own? A surprising number of people cannot answer those questions – either because they have more cards than are readily memorized, or because they threw out all the paper that came with their billing statements that described changes to some or all of the above.

The author, with Lori and a collection of friends

This problem is very much true for modern IT departments also. I’ve talked in the past about getting the most out of the gear you have… Utilizing F5 BIG-IP LTM for load balancing, for example, is good since that’s where its roots are, but as a full-blown ADC, there is much more it can do that might save you the time and expense of buying another product. But there’s more. Some of the gear in your DC is redundant, some came in with a product, and you have never considered extending its use or eliminating it entirely. And that just might be costing your organization. It could be costing the organization a lot.

Let’s say you implemented a Virtual Desktop Infrastructure (VDI), for example, and the vendor that sold it to you sold a “preferred” ADC solution to go with it. While VDI is a heavy network use architecture, it should not use all the available resources on said ADC. So the question is “have you considered using it more broadly, and have you considered the use of other products that are deployed more broadly to solve the VDI ADC issues?” If every architectural solution you deploy comes with its own set of network components, you will soon have a network more complex than the minotaur's maze, and harder for operations staff to navigate. And seriously in the VDI case, if you’re virtualizing servers too, then getting specialized hardware just for VDI seems… Really very redundant (and why I picked VDI for an example, though other markets do the same thing).

We have steadily moved away from dedicated hardware for servers – particularly in cases where the servers were under-utilized – so purchasing different solutions for a single project or product seems like going backward. Network resources can be centralized and utilized across the organization – indeed, for a very long time they were. Only recently have some vendors started to delude themselves into believing that their product or solution is so special it needs its very own set of network resources. Consider for a moment the implications of “pay for the product, then pay us for this redundant infrastructure too” on your bottom line. Not pretty. And even if they give it to you free (I can think of a couple of vendors that have done this in the past either to increase apparent market share or to mask the cost of the infrastructure), you’re still paying for it one way or another. Nothing is free.

So if you have hardware sitting around that was sold as “special purpose”, and you’re using it just for one segment of your architecture, look around. Either you could use it more, or (more likely) you could use something else that does more than just the single task. Why pay repeatedly and introduce a bunch of different hardware/vendors into your growing network, when you can re-use or extend one set of gear to meet multiple needs. K.I.S.S. for those who recall that acronym.

So pay attention. Don’t settle for less because a software vendor is selling you hardware. Don’t purchase a solution you know could be used more globally unless you actually can use it more globally, and make sure that whatever hardware is in your datacenter is being utilized as much as you can/need to. And when evaluating new products, look at how you could fulfill needs from tools already in place or heterogeneous solutions before you go to buy special purpose. Save the budget. Waste not, want not and all.

Technorati Tags: VDI,Virtualization,IT Management,F5 BIG-IP LTM,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs

From a Network Perspective, What Is VDI, Really?

Don MacVittie — Tue, 06 Dec 2011 20:38:13 GMT

We at F5 – like most collectives of geeks - are constantly discussing the wide array of IT boondoggles that are out there, looking at which ones hold water and which are just passing fads. Often we’re debating which are passing fads. Today I received an email to a small group asking if any of us had tried out the augmented reality stuff out there. I haven’t, but that gives you an idea of the edge that is sometimes taken.

And it is that time of year where every pundit and their uncle is making predictions about what will happen in high-tech next year. It is easy to forget that high-tech has long suffered under the “this year is the year of X!” syndrome when each year we hear it in forecasts and predictions as if it was the gospel truth, even if anyone practicing the craft on a regular basis knows that the prediction is wrong. I can recall years when Disk was Dead (almost every one since the turn of the century, in fact), years when iSCSI would eliminate Fiber Channel (abused so much that when iSCSI + NAS finally does, no one will notice), years when ISDN was going to take over the world (and two decades later, It Still Does Nothing), and predictions that in 2010, hardware load balancers would disappear. Funny, I still work for a rather successful company that makes them.

Ever notice that the people who make these predictions will tell you how right they were for each one that comes true, and will never again mention the ones that didn’t? One year at Network Computing we at least went back and said “here’s where we hit, here’s where we missed last year”, most people don’t even do that.

But I digress. I saw an interesting statistic in a White Paper that Lori wrote that quoted an InformationWeek Analytics survey claiming 77% of you were implementing or about to implement Virtual Desktop Infrastructure (VDI). Really? I disbelieve. The margin of error in that statement when taken in context of the entire marketplace is at least 50%, I’m guessing. Unless a whole lot of you are implementing VDI already and forgot to tell me, which I suppose is possible, but then the sample of people I talk to all the time must be luddites in disguise I suppose – because none of them are. Yet.

For me, the intriguing thing about VDI is that it enables remote access from alternative devices. That’s pretty cool. The payroll manager can field calls about your $0,.02 check while he’s watching Sunday night football, or even on-site at the NASCAR race. Support doesn’t even have to get dressed, and has a standardized and secured method to access systems.

But VDI, no matter your vendor of choice – or whether you’re using application virtualization, desktop virtualization, or whatever, puts a heavy burden on the network. Even the most optimized VDI vendor is still not a networking company. They’re an application company, their application being VDI and their application protocols being IP protocols designed primarily to communicate large volumes of data between virtualized desktop and current host. The impact of the network is large, simply because applications are still making all of the network connections they were in a non-virtualized world – to the databases, AAA servers, etc – while the virtualized desktop is sending drawing information (in one form or another) to the host and receiving keyboard/mouse input back.

With the proper architecture, this and many other VDI concerns - like a public authentication server and massive encryption to send data back and forth over the Internet – can be overcome, it just requires some homework and forethought. Of course I think you’ll be happiest with F5 gear tot optimize and secure your VDI installation, but having seen architectural diagrams and heard back from customers, I can attest to the fact that my sentiment is based upon facts, not marketing BS. Your deployment can gain a lot with little investment from F5, but you can find other solutions to most of the problems our gear solves, so I’ll let you decide what’s best for your environment.

And VDI holds a lot of promise. Allowing access to work from several locations, presenting the same desktop whether the user is in the San Jose or Dublin office, allowing access from portable devices for those who work from a variety of locations, and the ability to control what’s on the VM without having to guarantee that every host is locked down to corporate standards. Of course, there’s the ability to archive or delete desktops too, which isn’t a huge driver, but certainly is attractive. And most of all, the ability to update 100s of desktops without having to touch a single desktop machine. Operations should be drooling, even if you’d have to sell it to users with the promise of easier access and desktop portability.

Am I making a prediction about 2012? Oh heck no, I’m not currently in a job that requires I make predictions, so I’m not. I’m just pointing out that you should consider it, since VDI is rapidly coming of age, and the use case of tablets makes it more appealing to users. This time of year isn’t a time of predictions for me, it’s a time of holiday cheer. And I certainly wish it to all of you over the next month or so.

Technorati Tags: Virtual Desktops,Infrastructure,Virtualization,Predictions,VMWare,View,Citrix,Microsoft,F5 Networks,Don MacVittie,Blog

Connect with Don:	Connect with F5:

Is It Time For IT Role Reorgs?

Don MacVittie — Thu, 01 Dec 2011 15:50:01 GMT

When I was hired in to a utility to head an Automated Meter Reading project that was just getting organized – R&D was largely done, but implementation was not started – the team was set up in a rather odd manner. We had our own datacenter, we had our own networking, we had our own well, everything. And that was a conscious choice on the part of management. As it was presented to me, they didn’t want the early phases of the project mired in “we can’t set up load balancing for our app, you have to go talk to the network team” type issues. The long-term plan would make a complete mirror of IT for this project – operations, networking, appdev. Again, as presented to me, the point was to have a group of people completely knowledgeable in the ins-and-outs of the applications and networking (including power line carrier, phone lines, cell towers, and satellite) that tied it all together. The project was huge, and by the time I left for another part of the company, had grown to be the largest I’ve ever been involved in – in terms of staff, dollars, however you want to measure. And my team knew those systems in ways that most IT projects never have to, largely because of the initial design.

Traditionally, the issues that concern network staff are not the issues that keep systems admins up at night. Generally speaking, the application people worry about whatever is bothering these other two groups plus whatever is wrong with the application. In a highly complex environment – like nearly every datacenter is these days – it can be downright painful to track all of the pain points from the moment a user logs in to the culmination of application usage.

The traditional silos – particularly around appdev, whose managers tend to jealously hoard their time as if the next rev of the application is always the most important thing in the future of the company – make it difficult to get a clear view of the application. The ecosystem in which a given application lives is massive. Really very massive. And there are a lot of places where improvements could be made… If the right group is available and that group has statistics on that bit, and, and, and.

So across the board performance reporting is needed. The type that can track how long it took ADS to respond to the login request, and how long it took to get a response from the database, and how responsive overall the application is… How much CPU is being utilized on both the virtual and physical machines, how much disk usage the entire system is overseeing, and if that’s a bottleneck…

We’re getting there. ADCs can manage load across multiple servers and report on responsiveness, VMWare VCenter, for example, can help with system resource usage monitoring from a more holistic point of view, and now F5 products support iApps reporting to get detailed reporting on a wide variety of app and server metrics. No doubt (if they can) our competitors will implement similar functionality. It returns managing an app to being a discussion about the app, rather than a bunch of disjoint discussions about generic resources.

So what’s next? As the title implies, it just might be time to rethink silos. Now some of you will strongly disagree, and I’m good with that – but consider the possibilities along the lines of that AMR project I worked on.

VCenter offers management at the physical machine level, but views into the application (actually the VM) itself. iApps offers management at the network level, but views into the overall impact of the network on a specific applications’ performance. Network hardware still exists and has to be maintained, servers still exist and need to be maintained, but much of that maintenance has been moved into an arena that allows less specialized staff to interface with it. Thus, you will still need a router jockey, but most of your resources could be realigned to focus on the application itself. Call them “Application Management Engineers”, and give them knowledge about the application. This only works well for some big and not-likely-to-go-anywhere applications like Oracle DBMS, or Microsoft Exchange, but that’s a lot of staff time that can be moved over. And conveniently, iApps has customized templates for most of the really big applications out there, from VDI to Exchange to Oracle to Sharepoint. Of course it can work for smaller applications, you’ll just need people to juggle a whole collection of applications at once.

Less hardware management staff and more application management staff. That’s what I’m thinking. Add that to my last post about making developers more involved in operations, and you start to look like a different organization. The focus having been shifted dramatically from hardware bits to overall application health.

These types of shifts always have some issues though – we all know that if you specialize a bunch of people in Sharepoint, then you lose some synergies with similar networking applications. But then you have a group that does Sharepoint-like applications. Essentially all web based information sharing across the organization. For small orgs this type of organization would not be feasible, but that’s true of today’s organization too – how many shops don’t have dedicated security or storage staff because they just don’t have the people for it. Then people simply take on multiple responsibilities.

The benefit is a stronger focus on the only thing your users (be they internal or external) care about – the application. Because in the end, it is (or should be) about the apps.

Technorati Tags: IT Management,Virtualization,VMWare View,Application-Centric,F5 iApps,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs:

DevOps. It’s in the Culture, Not Tech.

Don MacVittie — Tue, 29 Nov 2011 21:10:13 GMT

#F5 DevOps – Managers need to make use of existing technology and adopt culture change.

It is entertaining to read all that is currently being written about DevOps. Having been a developer, a development manager, an operations manager, and even a CTO, I can attest to the fact that the “throw it over the wall” syndrome is real, and causes real problems for everyone involved. That is about where my agreement with the current round of pundits ends. The thing is that they talk like there is some fundamental technological reason why DevOps isn’t happening. That’s just not true. For those a little behind in your jargon, DevOps is making operations prevalent in the decisions of your development organization.

We’ll take the discussion a little bit at a time. We have virtualization. We have astoundingly good virtualization from VMWare, Microsoft, RedHat, et al. So many of the concerns about development and ops go away immediately. “Developers test in the environment their tools run in!'” is oft-heard in the DevOps conversations. But that’s just not an issue. They can run three different OS’s to test with, and as many browsers in each OS as you want to support – all with a single set of hardware. So make testing in your operational environment mandatory. In fact, for most tools, they’re developing on whatever OS is being targeted anyway, because there are subtle differences – or no support at all – in other OS’s.

Virtualization taken hand-in-hand with the capabilities of an Application Delivery Controller (ADC) like F5’s BIG-IP can also remove some of the “throw it over the wall” symptoms easily – particularly in Agile or other high-rev environments. Take a copy of the VM running the app today, modify that copy, place it on the network, then, utilizing one of the many algorithms available for load-balancing, switch a select load to the new server. Make it 1/3rd as likely as any other server to receive a given connection, and utilize persistence so users aren’t bouncing back and forth between revisions of the app. See how it performs under real-life usage. Have the Devs there for the first half hour, then make a “deploy/don’t deploy” decision, and if not deploying, take down the copy with the new code on it so the devs can continue to work on it. If deploying, then bring up copies of the new server and bleed connections off of the old ones, then bring those virtuals down and archive or destroy them, as your organization sees fit.

Most of the issues with DevOps are gone at that point. Testing is the only other issue that comes up a lot, and let’s talk frankly about testing. There just aren’t enough really good test tools out there. A test tool needs to automate as close to 100% of the testing process as possible in order for thorough testing to be feasible. The complexity of today’s applications leave most test tools in the dust. When Microsoft had MS-Test available, one of the shops I worked at used it, and one of my friends was an expert at generating test scripts, but we were a software shop. Our product was the software, making it much more critical that there be as close to zero defects as possible. That’s not the case if your product is not software. In those cases, software is a supporting tool to help sell product, and as such the occasional bug, while regrettable and to be avoided, doesn’t reflect upon your entire product line.

So there are some tools out there to do testing. They’ll help determine things like buffer overflows and such, and Microsoft is selling Microsoft Test Center, which looks to be a more comprehensive solution, but no program knows your business – and thus the testing context – in the manner that your employees do, and most companies are not willing to shell out the money required to start a dedicated testing group. If you are one of the lucky ones, well you can replicate your entire production environment with VMs and an ADC… But you can’t get the volumes you would see in a live public-facing Internet application with actual personal interaction and all the dumb mistakes we users make. So you can test, after a fashion, and with real people involved even set up intelligent testing, but it will take some effort. The best bet for most shops is to make unit testing part of the developers’ jobs, and system testing part of the project managers’ job, with help from both dev and ops. See, Devops!

It is a testament to the quality of tools and developers out there that we don’t see a ton of issues all the time. Think if the Web had the percentage of problems on a daily basis that Windows Apps did early on… We’d never get anything done. So don’t take DevOps so seriously from a technological standpoint, instead, let’s talk about culture.

Developers need to feel like part of the larger team if you want them to worry about DevOps. Here’s the catch, most of them don’t want to feel like part of the larger team. Network issues and storage shortages annoy them as much as your business users. They want to write cool apps and shove them out the door (or the Internet connection, more precisely) without worrying about deployment issues too much.

It is up to management to take concrete steps to move dev closer to ops. To do this, first mandate that all testing occur on the OS that deployment will occur on. This shouldn’t be a big deal for most shops, but in a few it will be. Second, mandate that the dev team put resources on the deployment, and utilize the Virtualization/ADC scenario discussed above. Third, remind developers that their app isn’t great unless users think it is, and it is deployable. They’ll come around, but it will take some work on your part.

The days of developing in a vacuum are long gone (at least in the enterprise), and the disconnect between dev and ops is one of the few remaining artifacts of that time. You just have to remove the artifacts and hook up the strengths of your ops team with the leet app skills on your dev team, and the whole concept of DevOps is significantly reduced.

One last bit, troubleshooting when things do go wrong. Developers can build a lot into their apps to give them hints about status, but ops can use tools like iApps (built into TMOS v 11 on F5 BIG-IP LTM) to show that it is indeed the application not responding in a timely manner – or indeed to show exactly what IS the bottleneck in a deployment. The reporting functionality on iApps makes them a worthwhile endeavor without the “ease of infrastructure management” they offer. iApp reporting can tell you exactly which piece of the application environment is slow, dragging the entire system response time down. I think that’s huge. If you have a BIG-IP, check it out, I’m pretty certain you will too.

So call a meeting. Make it around lunch time and announce that pizza will be provided. Both teams will show up, and you can start changing culture. The benefits will be long-term, with applications better suiting users needs and requiring less operations man-hours. And devs will get a better feel for what works and doesn’t in your environment.

Technorati Tags: Devops,testing,ADCs for Developers,Operations,Development,Culture,Management,F5 BIG-IP,F5 BIG-IP LTM,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs

He Who Defends Everything Defends nothing… Right?

Don MacVittie — Tue, 22 Nov 2011 21:13:41 GMT

There has been much made in Information Technology about the military quote: “He Who Defends Everything Defends Nothing” – Originally uttered by Frederick The Great of Prussia. He has some other great quotes, check them out when you have a moment. The thing is that he was absolutely correct in a military or political context. You cannot defend every inch of ground or even the extent of a very long front with a limited supply of troops. You also cannot refuse to negotiate on all points in the political arena. The nature of modern representative government is such that the important things must be defended and the less important offered up in trade for getting other things you want or need. In both situations, demanding that everything be saved results in nothing being saved. Militarily because you will be defeated piecemeal with your troops spread out, and politically because your opponent has no reason to negotiate with you if you are not willing to give on any issue at all.

But in high tech, things are a little more complex. That phrase is most often uttered to refer to defense against hacking attempts, and on the surface seems to fit well. But with examination, it does not suit the high-tech scenario at all. While defense in depth is important in datacenter defense, just in case someone penetrates your outer defenses. But we all know that there are one or two key choke-points that allow you to stop intruders who do not have inside help – your Internet connections. If those are adequately protected, the chances of your network being infiltrated, your website taken down, or any of a million other ugly outcomes are much smaller.

The problem, in the 21st century, is the definition of “adequate”. Recent attacks have taken down firewalls previously assumed to be “adequate”, and the last several years have seen a couple of spectacular DNS vulnerabilities focusing on a primary function that had seriously seen little attention from attackers or security folks. In short, the entire face you present to the world is susceptible to attack. And at the application layer, attacks can slip through your outer defenses pretty easily.

That’s why the future network defensive point for the datacenter will be a full proxy at the Strategic Point of Control where your network connects to the Internet. Keeping attacks from dropping your network requires a high-speed connection in front of all available resources. The Wikileaks attacks took out a few more than “adequate” firewalls, while the DNS vulnerabilities attacked DNS through its own protocol. A device in the strategic point of control between the Internet and your valuable resources needs to be able handle high-volume attacks and be resilient enough to respond to new threats be they at the protocol or application layers.

It needs to be intelligent enough to compare user/device against known access allowances and quarantine the user appropriately if things appear fishy. It also needs to be adaptable enough to adapt to new attacks before they overwhelm the network. Zero day attacks by definition almost never have canned fixes available, so waiting for your provider to plug the hole is a delay that you might not be able to afford.

That requires the ability for you to work in fixes and an environment that encourages the sharing of fixes – like DevCentral or a similar site. So that you can quickly solve the problem either by identifying the problem and creating a fix, or by downloading someone else’s fix and installing it. While an “official” solution might follow, and eventually the app will get patched, you are protected in the interim.

You can defend everything by placing the correct tool at the correct location. You can manage who has access to what, from which devices, when, and how they authenticate. All while protecting against DOS attacks that cripple some infrastructures. That’s the direction IT needs to head. We spend far too many resources and far too much brainpower on defending rather than enabling. Time to get off the merry-go-round, or at least slow it down enough that you can return your focus to enabling the business and worry less about security. Don’t expect security concerns will ever go away though, because we can – and by the nature of the threats must – defend everything.

Technorati Tags: Security,Strategic Points of Control,Full Proxy,F5 BIG-IP,F5 Networks,Don MacVittie,blog

Connect with Don:	Connect with F5:

Related Articles and Blogs:

Making Chili and Managing Network Resources.

Don MacVittie — Tue, 15 Nov 2011 16:27:29 GMT

#f5 There’s a new brand of Chili in town.

I don’t usually talk a lot about F5 specific solutions, but since we’re the only ones doing this (so far), the contents of this blog are F5 specific. Though this needs to be industry standard.

So, you’re yearning for some chili. That’s understandable, this time of year is when those of us from the US midwest think of chili, because it’s good hunting season food, and it both fills you and warms you up.

So grab a handful of hamburger and stuff it in your mouth, then grab a handful of dried kidney beans and stuff those in there too, no, don’t worry, we’re about to get to the cayenne pepper…

No? Okay, okay, you want it to actually be mixed before it gets to your stomach. I suppose that’s understandable too. So toss a bunch of hamburger into a pot, throw in some dried kidney beans – don’t forget the water – some chili powder, some cayenne pepper, whatever other spices you like, some tomato sauce, that’ll about do it. Got all of that? Okay, so next you cook it. In all that other stuff, it’ll take a good long while for the hamburger to cook, but since we didn’t soak the beans, they’ll need a good long while anyway… What? That’s not it either?

Okay then, last try. Brown up some hamburger, drain off the grease (or Juice as one of my best friends complains at this step), pour in some canned (or pre-soaked) kidney beans, some tomato sauce, some spices, and cook it up. What? Still not detailed enough? But I told you what to put into it, weren’t you reading?

Oh heck, go to your nearest chili joint and just buy some. In Green Bay we go to Chili Johns. In Cincinnati it’s Skyline chili. But where ever, place the order and get well-made chili. I don’t have to tell you all of the steps, you don’t have to get worked up about grey areas in the directions, you get tasty chili, I can go get some too.

Wouldn’t it be nice if that’s how it worked, and you didn’t have to pay for it?

Now consider that you’re deploying your application behind an ADC.

First you configure the Virtual IP, then you create a pool to service the Virtual IP, then you add nodes to the pool… What?

I know. That’s been a problem with ADCs for a good long while. Lots of steps, all necessary, all with room for miscommunication or error. Not anymore.

I’ll borrow a picture from coworker Karen Jester’s blog to illustrate the point:

There’s more at the link to her blog above (click on her name), but the point is relatively simple. It used to be that you had to configure each of the networking/load balancing/security/app delivery/et cetera. elements of an application deployment separately. Notice in this screenshot that the questions are about the application and your deployment of it, not about nodes and pools. We have some excellent deployment guides, but they run to many pages, and since you’re copying information from a book or PDF, missing steps is possible.

With iApps, that is no longer the case. iApps take an application-centric view of network resources. In essence, they’re Skyline Chili, but you don’t have to pay for them. They come free in V.11. And they know your apps. So if you need to deploy Exchange behind a BIG-IP, open the Exchange version X template, and fill in the few questions. Next thing you know, you’re running an ADC configuration with your requirements considered. No more individual items to configure. And you can modify the configuration at a later date to adapt to changes in your environment.

Of course, if you’re an expert, you can still configure the individual elements, but if you want to utilize the power of an ADC, but don’t have time to go through each and every step in a deployment guide, now with knowledge of your application, you can get it running – secure, fast, and available – in short order. For those applications we don’t have a template for yet, you can build one, download one developed by a peer from F5 DevCentral, or configure the objects individually using one of our deployment guides.

If you don’t already, I’d recommend reading Karen’s blog. She’s wicked smart, and in a location that gives her insight into F5 gear.

And yes, I’d love to talk about how other vendors are turning app delivery into an application-focused tool, since in the end it is all about delivery of applications. But until they do, I’ll just keep telling you how cool iApps are.

Oh and did I mention they give you an astounding look into overall application performance across the network? Yes, they do that too. It’s like the cheese on top of a bowl of Skyline Chili.

Technorati Tags: Application Delivery Controllers,ADC,iApps,F5 DevCentral,Karen Jester,F5 Networks,Don MacVittie,Blog

Connect with Don:	Connect with F5:

Related Articles and Blogs:

Remember When Hand Carts Were State Of The Art? Me either.

Don MacVittie — Thu, 03 Nov 2011 19:19:00 GMT

Funny thing about the advancement of technology, in most of the modern world we enshrine it, spend massive amounts of money to find “the next big thing”, and act as if change is not only inevitable, but rapid. The truth is that change is inevitable, but not necessarily rapid, and sometimes, it’s about necessity. Sometimes it is about productivity. Sometimes, it just plain isn’t about either.

Handcarts are still used for serious purposes in parts of the world, by people who are happy to have them, and think a motorized vehicle would be a waste of resources. Think on that for a moment. What high-tech tool that was around 20 years ago are you still using? Let alone 200 years ago. The replacement of handcarts as a medium for transport not only wasn’t instant, it’s still going on 100 years after cars were mass produced.

Handcart in use – Mumbai Daily

We in high-tech are constantly in a state of flux from this technology to that solution to the other architecture. The question you have to ask yourself – and this is getting more important for enterprise IT in my opinion – is “does this do something good for the company?” It used to be that IT folks could try out all sorts of new doo-dads just to play with them and justify the cost based on the future potential benefit to the company. I’d love to say that this had a powerful positive effect, but frankly, it only rarely paid off. Why? Because we’re geeks. We buy this stuff on our own dime if the company won’t foot for it, and our eclectic tastes don’t necessarily jive with the needs of the organization.

These days, the change is pretty intense, and focuses on infrastructure and application deployment architectures. Where can you run this application, and what form will the application take? Virtualized? Dedicated hardware? Cloud? the list goes on. And all of these questions spur thoughts about security, storage, the other bits of infrastructure required to support an application no matter where it is deployed.

These are things that you can model in your basement, but can’t really test out, simply because the architecture of an enterprise is far more complex than the architecture of even the geekiest home network. Lori and I have a pretty complex network in our basement, but it doesn’t hold a candle to our employers’ worldwide network supporting dev and sales offices on every continent, users in many languages, and a potpourri of access methods that must be protected and available.

Sometimes, change is simply a change of perspective. F5’s new iApps, for example, put the ADC infrastructure bits together for the application, instead of managing application security within the module that handles application security (ASM), it bundles security in with all of the other bits – like load balancing, SSL offload, etc – that an application requires. This is pretty powerful, it speeds deployment and troubleshooting because everything is in one place, and it speeds adding another machine because you simply apply the same iApp Template. That means you spin up another instance of the VM in question, tweak the settings, and apply the template already being used on existing instances, and you’re up.

Sometimes, change is more radical. Deploying to the cloud is a good example of this, and cloud deployments suffer for it. Indeed, private and hybrid clouds are growing rapidly precisely because of the radical change that public cloud can introduce. Cloud storage was so radical that very few were willing to use it even as most thought it was a good idea. Along came cloud storage gateways like our ARX Cloud Extender or a variety of others, and suddenly the weakness was ameliorated… Because the radical bit of cloud storage was simply that it didn’t talk like storage traditionally has. With a gateway it does. And with most gateways (check with your provider) you get compression and encryption, making the cloud storage more efficient and secure in the process.

But like the handcart, the idea that cloud, or virtualization, or consumerization must take hold overnight and you’re behind the times if you weren’t doing it yesterday are misplaced. Figure out what’s best for your organization, not just in terms of technology, but in terms of timelines also. Sure, some things, like support for the CEOs iPad will take on a life of their own, but in general, you’ve got time to figure out what you need, when you need it, and how best to implement it.

As I’ve mentioned before, at the cutting edge of technology, when the hype cycle is way overblown, that’s where you’ll find the largest number of vendors that won’t be around to support you in five years. If you can wait until the noise about a space quiets down, you’ll be better served, because the level of competition will have eliminated the weaker companies and you’ll be dealing with the technological equivalent of the Darwinian most fit. Sure, some of those companies will fail or get merged also, but the chances that your vendor of choice won’t, or their products will live on, are much better after the hype cycle.

After all, even though engine powered conveyances have largely replaced hand carts, have you heard of White Motor Company, Autocar Company, or Diamond T Company? All three made automobiles. They lived through boom and were swallowed in bust. Though in automobiles the cycle is much longer than in high-tech (Autocar started in the late 1800s and was purchased by White in the 1950s for example, who was purchased later by Audi), the same process occurs, so count on it. And no, I haven’t developed a sudden interest in automobile history, all of these companies thrived making half-tracks in World War Two, that’s how I knew to look for them amongst the massive number of failed car companies.

Stay in touch with the new technologies out there, pay attention to how they can help you, but as I’ve said quite often, what's in the hype cycle isn’t necessarily what is best for your organization.

1908 Autocar XV (Wikipedia.org)

Of course I think things like our VE product line and our new V.11 with both iApps and app mobility are just the thing for most organizations, even with those I will say “depending upon your needs”. Because contrary to what most marketing and many analysts want to tell you, it really is about your organization and its needs.

Technorati Tags: Cloud,Cloud Storage,Application Security,iApps,Automation,IT Management,Virtualization,Apple iPad,White Motor Company,Autocar,Diamond T Company,F5 ASM,F5 ARX,F5 ARX Cloud Extender,V.11,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs:

RIP WinXP. Now, To The Future!

Don MacVittie — Tue, 01 Nov 2011 19:39:42 GMT

Last week, InformationWeek quoted a Microsoft manager as saying there was “No chance” Windows XP would get another stay of execution. This really shouldn’t be a surprise to anyone, it was only the backlash from enterprises that kept Microsoft from ending support for XP over the last several years.

So now that Windows XP support will no longer be available, it is time for even the most recalcitrant enterprises to consider their options. All of their options. The world is changing on us yet again, and the needs of tomorrow might not be the needs of the future. Or even the needs of today.

As always, I’ll preface this investigation with it’s your IT department, you know it best. Do what is best for your business. With that said, now I’ll tell you what I think you ought to consider – either now or in the near future.

There is a significant portion of your workforce that would do just as well with a tablet as with a laptop. Yes, I said that. And they know who they are. A simple question “would you give up your laptop if you had a tablet with remote storage?” should quickly clear up who those people are. Of course, you’ll have to make certain your applications will run on the tablets, but there are a variety of paths to get you from here to there.

There is another significant portion of your enterprise who would work just fine with Virtual Desktops. Yes, I said that too. Let’s face it, not everyone needs a top-of-the-line computer. I know, that’s blasphemy after the “PC revolution”, but it’s true. A huge percentage of your workforce wouldn’t even notice if they were working on a VDI infrastructure. There are a few classes of employee that would. Road Warriors with varying connection speeds might chafe at a VDI infrastructure, and some groups like application developers or a variety of engineers (the kind that do huge CAD files), but many in your organization are largely already working off of web apps that go over the network. From a performance perspective, that is not a huge difference from VDI.

And some people – digital artists, CAD/CAM specialists, developers and engineers (as I’ve mentioned) that have high memory and disk usage, are still going to need desktops.

But if you pair tablets with VDI, then your executives can check up on their current initiatives from their tablet after dinner – without having to go to a computer. If you think that’s not such a huge benefit, ask them how much more involved they would be off-hours if it was easier to do. The answer is lots. I’m not an executive, and I check my mail on my phone and tablet almost constantly in off-hours, but almost never go boot up my laptop to do the same. In fact, if I log into my laptop at night, it is because I received a message on one of those other two platforms that I need files on my hard-disk to answer (something VDI with universal clients would resolve, since your “desktop” could appear anywhere).

It is time to start thinking about how to handle your upgrade from Windows XP. And it is time to start considering the needs of your users in the next several years before upgrading. Things are changing, more tools to enable the business are available, and a broadly based upgrade is a good time to look into technologies that enable these tools for the benefit of your organization.

I’m writing this blog on XP, so here’s hoping our IT staff is reading my blog :-). Do I want VDI? I don’t know, since I’m in Green Bay (or sometimes Cincinnati) and our datacenters are on the West Coast of the US, I’m going to guess that my performance would suffer. But I am one of those users who, when not writing a bit of software to support a blog, could well work off of VDI. It hurt to admit that though. Just a little bit. I’d love to say “I develop all the time, not possible”, but I don’t. I develop on occasion, and could do it on my home machines if work went VDI. And while you can’t generally ask your employees to work on their home machines, you can ask them for an impartial assessment of their needs.

Perhaps a bit of cloud storage, along with VDI would resolve even some of the edge cases – though fair warning, if you’re planning on encrypting data in the cloud, you’ll need some form of decryption tool that will allow outside-the-network machines to decrypt. Which could be painful. Or even not possible since you’re talking multiple encrypt/decrypt locations and a single target store.

Personally, I think it is time for Windows XP to go the way of Windows 3.1 anyway. We are running Windows 7 or a Linux variant on all of our home machines, and yet for work I still have Windows XP. Time to let the ten-year-old go out and play.

And did I mention that F5 has some astoundingly cool VDI support? No? Okay, well that’s my marketing bit for the day. We do. And I’d love to try it out when our IT upgrades. Of course I have questions and concerns, but for some of us, that’s part of the fun!

Technorati Tags: Windows XP,Windows 7,Virtual Desktops,VDI,Tablet PCs,F5 BIG-IP,F5 Networks,Don MacVittie,Blog

Connect with Don:	Connect with F5:

Related Articles and Blogs

The Past Is History, The Future A Chance To Do It Right.

Don MacVittie — Thu, 27 Oct 2011 18:57:31 GMT

There are many things in the history of high technology that are downright conundrums. One of the obvious ones is: given the formats and media currently used to distribute text, music, and video, for example, how do we protect the rights of both legal users and the creators of content? Of course we want people to be able to make a living of creating content, which does imply it is not given away at the whim of anyone with a copy, but we also (at least in most modern countries) want to protect the rights of people who have purchased (oh fine, licensed if you prefer) the software/book/music/movie to use their purchase/license freely. There isn’t an easy answer to this problem, because people disagree on the nature of the problem, and existing technology doesn’t support a reasonably sound mechanism for determining on-the-fly if the usage is legal.

We suffer a similar conundrum in InfoSec. We need to prevent unauthorized access to an application while not unduly inhibiting authorized access. The problem lies in the definition of “unauthorized”, which changes with every given application, and is wildly different between two points on the Internet. For some government websites, for example, “unauthorized” is, well, nearly everyone in the world. For other government websites, “unauthorized” is either a tiny subset of the world population, or only those who are set on disrupting the website’s normal function. The rest of the problem lies with the definition of “unduly inhibiting”. For most websites, “unduly inhibiting” is anything beyond a simple login. Indeed, for most websites out there, even logging in is delayed as long as possible. You can fill a cart in most web stores and only log in when going to check out, for example. But for some websites, again going to the government for examples (though there are plenty in the commercial world also), a physical security token with a login and a verification of ID are not “unduly inhibiting”, because the nature of the information to be found on the site is that sensitive.

We have traditionally protected our networks with firewalls, utilizing rules of these stalwart protectors between your application and the world to limit who can even get to an application. But firewalls were never a perfect solution. Logging in, for example, is not a function of a firewall for a given application, the application must handle this process. For known vulnerabilities, firewalls with advanced features are able to protect your application in the manner that all others are protected. They do a stand-up job of keeping malcontents at bay, in the generic 90% sense of “stand-up job”. But even modern “Application Layer” firewalls are not “Application Aware”. When they say “Application Layer”, they mean in the network stack, which is standards like TCP and HTTP, not actual Application needs.

But every application has its oddities. Be they the login process or the networks you want to allow connectivity to, be they protecting sensitive data from traversing the Internet unencrypted, or protecting a given field on a web page from various attacks that you know it is vulnerable to. And firewalls aren’t real good at most of these issues if they are issues for only your one application. Indeed, since firewalls are centralized to make management easier, most firewall products become unruly if you do use them to protect for the application-specific things that you know are out there.

A wonderful thing about history though, is that we write it forward. The future is coming, and we have the opportunity to make up for the shortcomings of traditional firewalls. We can “fill the gaps” so-to-speak with Web Application Firewalls. These tools are designed to protect your application and your application specifically from attacks that are more specific than the firewall would normally prevent. Utilizing application profiles (or templates, or whatever your vendor of choice calls them), you can start with generic settings for applications of the category yours is – or in many purchased-product cases the specific product. MS Exchange has enough organizations utilizing OWA for example, that most web application firewalls offer a canned OWA solution that you can then customize. Giving you protection specific to the application is a far site better than the generic protections you’ve gotten in the past. Many places have put Web Application Firewalls into place, but aren’t really using them for anything other than to check the box that says “requires a web application firewall” in a standard or regulation. That’s not making efficient usage of the tools at hand.

And there’s another reason that focusing security on applications is going to be important in the future. One you really do need to think about if you aren’t already pursuing this approach. Due to the nature of cloud computing, as I’ve mentioned before, your firewall, and all of your rules created over years of experience, is not going to run in a cloud. At least not right now. Some cloud vendors offer firewall services, but if you have a product like F5’s Application Security Manager (ASM), you can use the same rules in the physical version inside your datacenter and in the virtual edition running in a cloud environment. That’s a big bonus, as it allows you to copy your existing configuration, and with minimal changes to reflect the change in infrastructure, apply them to the virtual edition in the cloud. Your application receives the same exact protection, regardless of where future needs direct you to deploy it.

At least with InfoSec, we are making progress toward solving the problems. Now if only we could do so in the piracy space. Perhaps one day, we’ll have a way, and all agree on what is reasonable. Or at least most of us. Billions of people are highly unlikely to all agree.

Connect with Don:	Connect with F5:

Related Articles and Blogs