Technical Article It is All About Repeatability and Consistency. October 03, 2012 by Don MacVittie 219 article applications automation big-ip hardware iapp it management management tmos us v11 0 #f5 it is often more risky to skip upgrading than to upgrade. Know the risk/benefits of both. Not that I need to tell you, but there are several things in your network that you could have better control of. Whether it is consistent application of security policy or consistent configuration of servers, or even the setup of network devices, they’re in there, being non-standard. And they’re costing you resources in the long run. Sure, the staff today knows exactly how to tweak settings on each box to make things perform better, and knows how to improve security on this given device for this given use, but eventually, it won’t be your current staff responsible for these things, and that new staff will have one heck of a learning curve unless you’re far better at documentation of exceptions than most organizations. Sometimes, exceptions are inevitable. This device has a specific use that requires specific settings you would not want to apply across the data center. That’s one of the reasons IT exists, is to figure that stuff out so the business runs smoothly, no? But sometimes it is just technology holding you back from standardizing. Since I’m not slapping around anyone else by doing so, I’ll use my employer as an example of technology and how changes to it can help or hinder you. Version 9.X of TMOS – our base operating system – was hugely popular, and is still in use in a lot of environments, even though we’re on version 11.X and have a lot of new and improved things in the system. The reason is change limitation (note: Not change control, but limitation). Do you upgrade a network device that is doing what it is supposed to simply because there’s a newer version of firmware? it is incumbent upon vendors to give you a solid reason why you should. I’ve had reason to look into an array of cloud based accounting services of late, and frankly, there is not a compelling reason offered by the major software vendors to switch to their cloud model and become even more dependent upon the vendor (who would now be not only providing software but storing your data also). I feel that F5 has offered plenty of solid reasons to upgrade, but if you’re in a highly complex or highly regulated environment, solid reasons to upgrade do not always equate to upgrades being undertaken. Again, the risk/reward ratio has to be addressed at some point. And I think there is a reluctance in many enterprises to consider the benefits of upgrading. I was at a large enterprise that was using Windows 95 as a desktop standard in 2002. Why? Because they believed the risks inherent to moving to a new version of Windows corporate wide were greater than the risks of staying. Frankly, by the time it was 2002, there was PLENTY of evidence that Windows 98 was stable and a viable replacement for Windows 95. You see the same phenomenon today. Lots of enterprises are still limping along with Windows XP, even though by-and-large, Windows 7 is a solid OS. In the case of F5, there is a feature in the 11.X series of updates to TMOS that should, by itself, offer driving reason to upgrade. I think that it has not been seriously considered by some of our customers for the same reason as the Windows upgrades are slow – if you don’t look at what benefits it can bring, the risk of upgrading can scare you. But BIG-IP running TMOS 11.X has an astounding set of functionality called iApps that allow you to standardize how network objects – for load balancing, security, DNS services, WAN Optimization, Web App Firewalling, and a host of other network services – are deployed for a given type of application. Need to deploy, load balance, and protect Microsoft Exchange? Just run the iApp in the web UI. It asks you a few questions, and then creates everything needed, based upon your licensing options and your answers to the questions. Given that you can further implement your own iApps, you can guarantee that every instance of a given application has the exact same network objects deployed to make it secure, fast, and available. From an auditing perspective, it gives a single location (the iApp) for information about all applications of the same type. There are pre-generated iApps for a whole host of applications, and a group here on DevCentral that is dedicated to user developed iApps. There is even a repository of iApps on DevCentral. And what risk is perceived from upgrading is more than mitigated by the risk reduction in standardizing the deployment and configuration of network objects to support applications. IIS has specific needs, but all IIS can be configured the same using the IIS iApp, reducing the risk of operator error or auditing gotcha. I believe that Microsoft did a good job of putting out info about Windows 7, and that organizations were working on risk avoidance and cost containment. The same is true of F5 and TMOS 11.X. I believe that happens a lot in the enterprise, and it’s not always the best solution in the long run. You cannot know which is more risky – upgrading or not – until you know what the options are. I don’t think there are very many professional IT staff that would say staying with Windows 95 for years after Windows 98 was out was a good choice, hindsight being 20/20 and all. Look around your datacenter. Consider the upgrade options. Do some research, make sure you are aware of what not upgrading a device, server, desktop, whatever is as well as you understand the risks of performing the upgrade. And yeah, I know you’re crazy busy. I also know that many upgrades offer overall time savings, with an upfront cost. If you don’t invest in time-saving, you’ll never reap time savings. Rocking it every day, like most of you do, is only enough as long as there are enough hours in the day. And there are never enough hours in the IT day. As I mentioned at #EnergySec2012 last week, there are certainly never enough hours in the InfoSec day. last modified: October 03, 2012 0 Comment(s): You must be logged in to post comments.