Your Most Important IT Skill: A firm Grasp on Reality.
In their excellent work “Life and How to Survive It” by psychotherapist Robin Skynner and his former patient British comic John Cleese, there is a passage devoted to our mental map of the world. They postulate that a possible measure of mental health is how well our inner map matches the reality of the world around us. It’s a concept that has stuck with me for many years since I first read the book, and recently resurfaced while reading the recent Cisco Annual Security Report. It’s a great report and and a worthwhile read. Amongst the many interesting, but unsurprising security issues- java & flash vulnerabilities, users careless behavior – (although we have a fix for that) the one that struck me most was the growing disconnect between perception and reality. It seems we have a situation where 75 percent of Chief Information Security Officers see their IT security as very or extremely effective but less than 50 percent of respondents are using tools such as patching and configuration management tools to mitigate risks. It strikes me that there is a reality gap opening up, which is hard to believe given a quick review of the security incidents of the last year. So is a measure of our IT security health how accurately the threats and our preparedness to defend against the mare conveyed in the boardroom? I think so. This is not a time for sugar coating and ‘managing up’. IT professionals and executives need to work hard to ensure that they are keeping their grip on reality and continue to be clear about the risks and the mitigations they can put in place. Vendors too, need to be clear in the capabilities of their solutions and how they can be implemented. That’s one of the reasons we include “Recommended Practices” guides on most of our Reference Architectures. We want to show you that we can stand by the claims we make about our security solutions – because we’ve tested and documented exactly how implement them. Are they always going to work? Is everything perfect? Probably not. But that’s reality. What you can be sure of is that we are going to keep on building real world defenses for real world threats.
F5 Friday. IT Brand Pulse Awards
IT Brand Pulse carries a series of reports based upon surveys conducted amongst IT professionals that attempt to ferret out the impression that those working in IT have of the various vendors in any given market space. Their free sample of such a report is the November 2010 FCoE Switch Market Leader Report and it is an interesting read, though I admit it made me want to paw through some more long-form answers from the participants to see what shaped these perceptions. The fun part is trying to read between the lines, since this is aimed at the perceived leader, you have to ask how much boost Cisco and Brocade received in the FCoE space just because they’re the FC vendors of choice. But of course, no one source of information is ever a complete picture, and this does give you some information about how your peers feel – whether that impression is real or not – about the various vendors out there. It’s not the same as taking some peers to lunch, but it does give you an idea of the overall perceptions of the industry in one handy set of charts. This February, F5 was honored by those who responded to their Load Balancer Market Leader Report with wins in three separate categories of Load Balancing – price, performance, and innovation, and took the overall title of “Market Leader” in load balancing. We, of course, prefer to call ourselves an Application Delivery Controller (ADC), but when you break out the different needs of users, doing a survey on load balancing is fair enough. After all, BIG-IP Local Traffic Manager (LTM) has its roots in load balancing, and we think it’s tops. IT Brand Pulse is an analyst firm that provides a variety of services to help vendors and IT staff make intelligent decisions. While F5 is not, to my knowledge, an IT Brand Pulse customer, I (personally) worked with the CEO, Frank Berry while he was at QLogic and I was writing for Network Computing. Frank has a long history in the high tech industry and a clue what is going on, so I do trust his company’s reports more than I trust most analyst firms. We at F5 are pleased to have this validation to place next to the large array of other awards, recognition, and customer satisfaction we have earned, and intend to keep working hard to earn more such awards. It is definitely our customers that place us so highly, and for that we are very grateful. Because in the end it is about what customers do with our gear that matters. And we’ll continue to innovate to meet customer needs, while keeping our commitment to quality.Support for NIST 800-53?
#f5friday There’s an iApp for that! NIST publication 800-53 is a standard defined to help government agencies (and increasingly enterprises) rein in sprawling security requirements while maintaining a solid grip on the lockdown lever. It defines the concept of a “security control” that ranges from physical security to AAA, and then subdivides controls into “common” – those used frequently across an organization, “custom” – those defined explicitly for use by a single application or device, and “hybrid” – those that start with a common control and then customize it for the needs of a specific application or device. The standard lists literally hundreds of controls, their purpose, and when they’re needed. When these controls are “common”, they can be reused by multiple applications or devices. For government entities and their contractors, this standard is not optional, but there is a lot of good in here for everyone else also. Of course external access to applications should be considered, allowed or not, and if allowed, locked down to only those who absolutely need it. That is the type of thing you’ll find in the common controls, and any enterprise could benefit from studying and understanding the standard. For applications, using this standard and the ones it is based off of, IT can develop a security checklist. The thing is that for hardware devices, support is very difficult from the outside. It is far better if the device – particularly networking devices that run outside of the application context – implement the information security portions internally. And F5BIG-IP does. With an iApp. No doubt you’ve heard us talk about how great we think iApps are, well now we have a solid example to point out, where we use it to configure the objects that allow access to our own device. Since iApps are excellent at manipulating data heading for an application, the fact that BIG-IP UI is a web application should make it easy to understand how we quickly built support for 800-53 through development of an iApp that configures all of the right objects/settings for you, if you but answer a few questions. 800-53 is a big standard, and iApps were written with the intent that they configure objects that BIG-IP manipulates more than the BIG-IP configuration objects themselves, so there are a couple of caveats in the free downloadable iApp – check the help section after you install and before you configure the iApp. But even if the caveats affect you, they are not show-stoppers that invalidate compliance with the standard, so the iApp is still useful for you. One of my co-workers was kind enough to give me a couple of enhanced screenshots to share with you, if you already know you need to support this standard in your organization, these will show you the type of support we’ve built. If you’re not sure whether you’ll be supporting 800-53, they’re still pretty information-packed and you’ll get why I say this stuff is useful for any organization. The thing is that this iApp is not designed as a “Yes, now you can check that box” solution, it aims to actually give you control over who has access to the BIG-IP system and how they have access, from where, while utilizing the language and format of the standard. All of these things can be done without the iApp, but this tool makes it far easier to implement and maintain compliance because under the covers it changes several necessary settings for you, and you do not have to search down each individual object and configure it by hand. The iApp is free. iApp support is built into BIG-IP. If you need to comply with the standard for regulatory reasons, or have decided as an organization to comply, download it and install. Then run the iApp and off you go to configuration land. Note that this iApp makes changes to the configuration of your BIG-IP. It should be used by knowledgeable staff that are aware of how their choices will impact the existing BIG-IP configuration.Bare Metal Blog: Test for reality.
#BareMetalBlog #F5 Test results provided by vendors and “independent testing labs” often test for things that just don’t matter in the datacenter. Know what you’re getting. When working in medicine, you don’t glance over a patient, then ask them “so how do you feel when you’re at your best?” You ask them what is wrong, then run a ton of tests – even if the patient thinks they know what is wrong – then let the evidence determine the best course of treatment. Sadly, when determining the best tools for your IT staff to use, we rarely follow the same course. We invite a salesperson in, ask them “so, what do you do?”, and let them tell us with their snippets of reality or almost-reality why their product rocks the known world. Depending upon the salesperson and the company, their personal moral code or corporate standards could limit them to not bringing up the weak points of their products to outright lying about its capabilities. “But Don!”, you say, “you’re being a bit extreme, aren’t you?” Not in my experience I am not. From being an enterprise architect to doing comparative reviews, I have seen it all. Vendor culture seems to infiltrate how employees interact with the world outside their HQ – or more likely (though I’ve never seen any research on it), vendors tend to hire to fit their culture, which ranges from straight-up truth about everything to wild claims that fall apart the first time the device is put into an actual production-level network. The most common form of disinformation that is out there is to set up tests so they simply show the device operating at peak efficiency. This is viewed as almost normal by most vendors – why would you showcase your product in less than its best light? and as a necessary evil by most of the few who don’t have that view – every other vendor in the space is using this particular test metric, we’d better too or we’ll look bad. Historically, in network gear, nearly empty communications streams have been the standard for high connection rates, very large window sizes the standard for manipulating throughput rates. While there are many other games vendors in the space play to look better than they are, it is easy to claim you handle X million connections per second if those connections aren’t actually doing anything. It is also easier to claim you handle a throughput of Y Mbps if you set the window size larger than reality would ever see it. Problem with this kind of testing is that it seeps into the blood, after a while, those test results start to be sold as actual… And then customers put the device into their network, and needless to say, they see nothing of the kind. You would be surprised the number of times when we were testing for Network Computing that a vendor downright failed to operate as expected when put into a live network, let alone met the numbers the vendor was telling customers about performance. One of the reasons I came to F5 way back when was that they did not play these games. They were willing to make the marketing match the product and put a new item on the roadmap for things that weren’t as good as they wanted. We’re still out there today helping IT staff understand testing, and what testing will show relevant numbers to the real world. By way of example, there is the Testing Configuration Guide on F5 DevCentral. As Application Delivery Controllers have matured and solidified, there has been much change in how they approach network traffic. This has created an area we are now starting to talk more about, which is the validity of throughput testing in regards to ADCs in general. The thing is, we’ve progressed to the point that simply “we can handle X Mbps!” is no longer a valid indication of the workloads an ADC will be required to handle in production scenarios. The real measure for application throughput that matters is requests per second. Vendors generally avoid this kind of testing, because response is also limited by the capacity of the server doing the actual responding, so it is easy to get artificially low numbers. At this point in the evolution of the network, we have reached the reality of that piece of utility computing. Your network should be like electricity. You should be able to expect that it will be on, and that you will have enough throughput to handle incoming load. Mbps is like measuring amperage… When you don’t have enough, you’ll know it, but you should, generally speaking, have enough. It is time to focus more on what uses you put that bandwidth to, and how to conserve it. Switching to LED bulbs is like putting in an ADC that is provably able to improve app performance. LEDs use less electricity, the ADC reduces bandwidth usage… Except that throughput or packets per second isn’t measuring actual improvements of bandwidth usage. It’s more akin to turning off your lights after installing LED bulbs, and then saying “lookie how much electricity those new bulbs saved!” Seriously, do you care if your ADC can delivery 20 million Megabits per second in throughput, or that it allows your servers to respond to requests in a timely manner? Seriously, the purpose of an Application Delivery Controller is to facilitate and accelerate the delivery of applications, which means responses to requests. If you’re implementing WAN Optimization functionality, throughput is still a very valid test. If you’re looking at the Application Delivery portion of the ADC though, it really has no basis in reality, because requests and responses are messy, not “as large a string of ones as I can cram through here”. From an application perspective – particularly from a web application perspective – there is a lot of “here’s a ton of HTML, hold on, sending images, wait, I have a video lookup…” Mbps or MBps just doesn’t measure the variety of most web applications. But users are going to feel requests per second just as much as testing will show positive or negative impacts. To cover the problem of application servers actually having a large impact on testing, do what you do with everything else in your environment, control for change. When evaluating ADCs, simply use the same application infrastructure and change only the ADC out. Then you are testing apples-to-apples, and the relative values of those test results will give you a gauge for how well a given ADC will perform in your environment. In short, of course the ADC looks better if it isn’t doing anything. But ADCs do a ton in production networks, and that needs to be reflected in testing. If you’re fortunate enough to have time and equipment, get a test scheduled with your prospective vendor, and make sure that test is based upon the usage your actual network will expose the device to. If you are not, then identify your test scenarios to stress what’s most important to you, and insist that your vendor give you test results in those scenarios. In the end, you know your network far better than they ever will, and you know they’re at least not telling you the whole story, make sure you can get it. Needless to say, this is a segue into the next segment of our #BareMetalBlog series, but first I’m going to finish educating myself about our use of FPGAs and finish that segment up.That Other Single Point of Failure
When you’re a kid at the beach, you spend a lot of time and effort building a sand castle. It’s cool, a lot of fun, and doomed to destruction. When high tide, or random kids, or hot sun come along, the castle is going to fall apart. It doesn’t matter, kids build them every year by the thousands, probably by the millions across the globe. Each is special and unique, each took time and effort, and each will fall apart. The thing is, they’re all over the globe, and seasons are different all over the globe, so it is conceivable that there is a sand castle built or being built every minute of every day. Not easily provable, but doesn’t need to be for this discussion. when it is night and middle of winter in the northern reaches of North America, it is summer and daytime in Australia. The opportunity for continuation of sand castles is amazing. Unless you’re in publishing or high-tech, it is likely that our entire organization is a single point of failure. Distributed applications make sense so that you can minimize risk and maximize uptime, right? The cloud is often billed as more resistant to downtime precisely because it is distributed. And your organization? Is it distributed? Really, spread out so that it can’t be impacted by something like Sandy? There are a good number of organizations that are nearly 100% off-line right now because there is no power in the Northeast. That was not a possibility, it was an inevitability. Power outages happen, and they sometimes happen on a grand scale (remember the cascading midwest/northeast/Canada outage a couple years back – that was not natural disaster, it was design and operator error). And yet, even companies with a presence in the cloud clustered their employees in one geographic area. There is a tendency amongst some to want face-to-face meetings, assuming those are more productive, which leads to desiring everyone be on-site. With increasing globalization, and meetings held around the world - long before I became a remote worker, I held meetings with staff in Africa, Russia, and California, all on the same (very long) day, and all from my home in Green Bay – one would think this tendency would be minimized, but it does not seem to be. The result is predictable. I once worked as a Strategic Architect for a life insurance company. They had a complete replica of the datacenter in a different geographic region, on the grounds that a disaster so horrible as to take out the datacenter would be exactly the scenario in which that backup would be needed. But guess where the staff was? Yeah, at the primary. The systems would have been running fine, but the IT knowledge, business knowledge, and claims adjustment would all have been in the middle of a disaster. Don’t make that mistake. Today, most organizations with multiple datacenters have DR plans that cover shifting all the load away from one of them should there be a problem, but those organizations with a single datacenter don’t have that leisure, and neither of them necessarily have a plan for continuation of actual work. Consider your options, consider how you will get actual business up to speed as quickly as possible. Losing their jobs because the business was not viable for weeks is not a great plan for helping people recover from disaster. Even with the cloud, there is critical corporate knowledge out there that makes your organization tick. It needs to be geographically distributed. It matter not what systems are in the cloud if all of the personnel to make them work are in the middle of a blackout zone. In short, think sand castles. If you have multiple datacenters, make certain your IT and business knowledge is split between them well enough to continue operations in a bad scenario. If you don’t have multiple locations, consider remote workers. Some people are just not cut out for telecommuting (I hate that phrase, since telecomm has little to do with the daily work, but it’s what we have), others do fine at it. Find some fine ones that have, or can be trained to have, the knowledge required to keep the organizations’ doors open. It could save the company a lot of money, and people a lot of angst. And your customers will be pleased too. The key is putting the right people and the right skills out there. Spread them across datacenters or geographies, so you’re distributed as well as your apps. And while you’re at it, broadening the pool of available talent means you can get some hires you might never have gotten if relocation was required. And all of that is a good thing. Like sand castles. Meanwhile, keep America’s northern east coast in your thoughts, that’s a lot of people in a little space without the amenities they’re accustomed to. Related Articles and Blogs: When Planning Disaster Recovery, Don't Forget the Small Stuff When The Walls Come Tumbling Down. First American Improves Performance and Mobility with F5 and ... Quick! The Data Center Just Burned Down, What Do You Do? First American: an F5 customer Fast DNS - DevCentral Wiki Let me tell you Where To Go. Migrating DevCentral to the Cloud Virtualize Absolutely Everything! Part II Deploying Viprion 2400 with ... DevCentral Top5 05/29/2012Is Change Coming Again?
It is a topic of fascination for me that the high-tech world just plain will not stand still. The changes in automotive technology over the last century, for example, do not match the changes in high tech over the last decade. In addition to the expected on-upsmanship that market leaders tend to spur each other on with, there is always The Next Big Thing™, often by a hitherto unheard of company. When you stop to think that Google was incorporated 14 years ago at the writing of this blog, and my own employer (F5 Networks) was founded just 18 years ago, but both are seen as leaders, perhaps even “old school”. Even more extreme, Facebook is not yet 10 years old as a corporation, yet many see it as “old”. So I kind of keep half an eye on the more global changes in high-tech to keep a feel for what might be going on, and what it might mean to you and me. The interesting news today comes from Forrester Research in a blog post entitled “For Consumers, ‘Being Online’ Is Becoming a Fluid Concept”. The topic of the post is the result of their annual usage survey that shows a rapidly increasing mobile usage pattern, and a tendency away from not just “old media”, but desktops and laptops. This came at the same time that a conversation sprung up on Facebook about stock prices of some companies, and the comment was posted (paraphrased and used without permission) “That’s the problem with client-based security companies in the mobile age. With limited access to underlying APIs, those companies have to head to the datacenter or face extinction.” Wow. That has the ring of profound when combined with the Forrester report. So what is upcoming change likely to look like? Well, we’re rapidly approaching a point where contextual authorization – based upon username, device type, locale, and even routing – will become standard for enterprise network access. People are increasingly talking about VDI on a tablet – an interesting concept to say the least. The commenter was right, security is massively different in the mobile world (upcoming blog on simply encrypting an SQLite database and still using the connectors to populate list boxes). That could spell trouble for some established security vendors, though the AV vendors seem to be getting something available for most mobile platforms, so maybe it’s just a question of catching up with adoption. Thing is, the other end of the computerverse is intruding on “old” tech also. As things move to the cloud, an entirely different set of rules starts to apply. How do you hit the cloud and still maintain PCI DSS compliance, for example (something I was helping a friend with not too long ago), and for that matter HIPPA compliance if you fall under it? Those are questions only just now starting to get answers. And there are a lot more – like how to resolve DNS when cloud-bursting, or even how to determine algorithmically that it is time to cloud-burst. Or how to develop for both iPad and GalaxyTab from the same source (Appcelerator does it with a variant of JavaScript that they translate to Objective-C and Java respectively, but that’s one case, what if JavaScript is not your choice, or the translation doesn’t suit your needs?). So both the client (what clients are most used to access your sites) and the servers (where they are hosted, what kind of control you have over the infrastructure) are changing at the same time. Again. This is going to be another interesting ride, methinks. The changes are still coming fast and furious. We’re still adapting pretty well. You know sometimes when you sit in a datacenter working hard every day you can feel so behind. Don’t. Yes I think you should adopt all of the new functionality F5 has incorporated to make your life easier, and my compatriots at other orgs feel the same, but you’re not nearly as far behind as it seems, the market is just moving faster than it needs to. Do what you do best – find the stuff that matters and adopt it. The hype doesn’t determine the market, you do.Security Shortage? Look Internal.
There has been an increasing amount of commentary about the growing shortage of Information Security folks. While the reasons for this shortage are manifold and easily explained, that doesn’t change the fact that it exists. Nor the fact that natural sources may well be causing it to worsen. Here’s why we’re where we are: Information Security is a thankless job. Literally thankless. If you do enough to protect the organization, everyone hates you. If you don’t do enough to protect the organization, everyone hates you. Information Security is hard. Attacks are constantly evolving, and often sprung out of the blue. While protecting against three threats that the InfoSec professionals have ferreted out, a fourth blindsides them. Information Security is complex. Different point, but similar to the one above. You can’t just get by in InfoSec. You have to know some seriously deep things, and be constantly learning. Information Security is demanding. When the attackers come on a global clock, defenders have to be ready to respond on one. That means there are limits to “time off”, counting both a good nights’ sleep and vacations as casualties. The shrinking pool has made the last point worse. With fewer people to share the load, there is more load for each person to carry – more call, more midnight response, more everything. Making do with the best security staff you can find may well be killing the rest of your InfoSec team. If “the best you can find” isn’t good enough, others must pick up the slack. And those last two points are the introduction to today’s thought. Stop looking for the best InfoSec people you can find. Start training good internal employees in InfoSec. You all know this is the correct approach. No matter how good you are at Information Security, familiarity with the network or systems, or applications of your specific organization is at least as important. Those who manage the organizations’ IT assets know where the weaknesses are and can quickly identify new threats that pose a real risk to your data. The InfoSec needs of a bank, for example, are far better served by someone familiar with both banking and this bank than by someone who knows Information Security but learned all that they know at a dog pound. The InfoSec needs of the two entities are entirely different. And there’s sense to this idea. You have a long history of finding good systems admins or network admins and training them in your organizations’ needs, but few organizations have a long history in hiring security folks and doing the same. With a solid training history and a deeper available talent pool, it just makes sense to find interested individuals within the organization and get them security training, backfilling their positions with the readily available talent out there. Will it take time to properly vet and train those interested? Of course it will. Will it take longer than it would take to inform an InfoSec specialist in the intricacies of your environment? Probably not. SharePoint is SharePoint, and how to lock it down is well documented, but that app you had custom developed by a coding house that is now gone? That’s got a way different set of parameters. Of course this option isn’t for everyone, but combined with automating what is safe to automate (which is certainly not everything, or even the proverbial lion’s share), you’ll have a stronger security posture in the long run, and these are people who already know your network – and perhaps more importantly your work environment - but have an interest in InfoSec. Give them a shot, you might be pleased with the results. As to the bullet points above? You’ll have to address those long-term too. They’re why you’re struggling to find InfoSec people in the first place. Though some of them are out of your control, you can offer training and places like DefCon to minimize them. Related Articles and Blogs: The InfoSec Prayer Authorization is the New Black for Infosec The InfoSec Conundrum. Keep Playing Until You Lose. WILS: InfoSec Needs to Focus on Access not Protection F5 News - Threat mitigation The Cost of Ignoring 'Non-Human' Visitors F5 News - web application firewallDoes Cloud Solve or Increase the 'Four Pillars' Problem?
It has long been said – often by this author – that there are four pillars to application performance: Memory CPU Network Storage As soon as you resolve one in response to application response times, another becomes the bottleneck, even if you are not hitting that bottleneck yet. For a bit more detail, they are “memory consumption” – because this impacts swapping in modern Operating Systems. “CPU utilization” – because regardless of OS, there is a magic line after which performance degrades radically. “Network throughput” – because applications have to communicate over the network, and blocking or not (almost all coding for networks today is), the information requested over the network is necessary and will eventually block code from continuing to execute. “Storage” – because IOPS matter when writing/reading to/from disk (or the OS swaps memory out/back in). These four have long been relatively easy to track. The relationship is pretty easy to spot, when you resolve one problem, one of the others becomes the “most dangerous” to application performance. But historically, you’ve always had access to the hardware. Even in highly virtualized environments, these items could be considered both at the Host and Guest level – because both individual VMs and the entire system matter. When moving to the cloud, the four pillars become much less manageable. The amount “much less” implies depends a lot upon your cloud provider, and how you define “cloud”. Put in simple terms, if you are suddenly struck blind, that does not change what’s in front of you, only your ability to perceive it. In the PaaS world, you have only the tools the provider offers to measure these things, and are urged not to think of the impact that host machines may have on your app. But they do have an impact. In an IaaS world you have somewhat more insight, but as others have pointed out, less control than in your datacenter. Picture Courtesy of Stanley Rabinowitz, Math Pro Press. In the SaaS world, assuming you include that in “cloud”, you have zero control and very little insight. If you app is not performing, you’ll have to talk to the vendors’ staff to (hopefully) get them to resolve issues. But is the problem any worse in the cloud than in the datacenter? I would have to argue no. Your ability to touch and feel the bits is reduced, but the actual problems are not. In a pureplay public cloud deployment, the performance of an application is heavily dependent upon your vendor, but the top-tier vendors (Amazon springs to mind) can spin up copies as needed to reduce workload. This is not a far cry from one common performance trick used in highly virtualized environments – bring up another VM on another server and add them to load balancing. If the app is poorly designed, the net result is not that you’re buying servers to host instances, it is instead that you’re buying instances directly. This has implications for IT. The reduced up-front cost of using an inefficient app – no matter which of the four pillars it is inefficient in – means that IT shops are more likely to tolerate inefficiency, even though in the long run the cost of paying monthly may be far more than the cost of purchasing a new server was, simply because the budget pain is reduced. There are a lot of companies out there offering information about cloud deployments that can help you to see if you feel blind. Fair disclosure, F5 is one of them, I work for F5. That’s all you’re going to hear on that topic in this blog. While knowing does not always directly correlate to taking action, and there is some information that only the cloud provider could offer you, knowing where performance bottlenecks are does at least give some level of decision-making back to IT staff. If an application is performing poorly, looking into what appears to be happening (you can tell network bandwidth, VM CPU usage, VM IOPS, etc, but not what’s happening on the physical hardware) can inform decision-making about how to contain the OpEx costs of cloud. Internal cloud is a much easier play, you still have access to all the information you had before cloud came along, and generally the investigation is similar to that used in a highly virtualized environment. From a troubleshooting performance problems perspective, it’s much the same. The key with both virtualization and internal (private) clouds is that you’re aiming for maximum utilization of resources, so you will have to watch for the bottlenecks more closely – you’re “closer to the edge” of performance problems, because you designed it that way. A comprehensive logging and monitoring environment can go a long way in all cloud and virtualization environments to keeping on top of issues that crop up – particularly in a large datacenter with many apps running. And developer education on how not to be a resource hog is helpful for internally developed apps. For externally developed apps the best you can do is ask for sizing information and then test their assumptions before buying. Sometimes, cloud simply is the right choice. If network bandwidth is the prime limiting factor, and your organization can accept the perceived security/compliance risks, for example, the cloud is an easy solution – bandwidth in the cloud is either not limited, or limited by your willingness to write a monthly check to cover usage. Either way, it’s not an Internet connection upgrade, which can be dastardly expensive not just at install, but month after month. Keep rocking it. Get the visibility you need, don’t worry about what you don’t need. Related Articles and Blogs: Don MacVittie - Load Balancing For Developers Advanced Load Balancing For Developers. The Network Dev Tool Load Balancers for Developers – ADCs Wan Optimization ... Intro to Load Balancing for Developers – How they work Intro to Load Balancing for Developers – The Gotchas Intro to Load Balancing for Developers – The Algorithms Load Balancing For Developers: Security and TCP Optimizations Advanced Load Balancers for Developers: ADCs - The Code Advanced Load Balancing For Developers: Virtual Benefits Don MacVittie - ADCs for Developers Devops Proverb: Process Practice Makes Perfect Devops is Not All About Automation 1024 Words: Why Devops is Hard Will DevOps Fork? DevOps. It's in the Culture, Not Tech. Lori MacVittie - Development and General Devops: Controlling Application Release Cycles to Avoid the ... An Aristotlean Approach to Devops and Infrastructure Integration How to Build a Silo Faster: Not Enough Ops in your DevopsIt is All About Repeatability and Consistency.
#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.Mainframes are dead, Right?
Funny thing about the hype cycle in high tech, things rarely turn out the way cheerleaders proclaim it will. Mainframes did not magically disappear in any of the waves that predicted their demise. The reason is simple – there is a lot of code running on mainframes that works, and has worked well for a long time, rewriting all of that code would be a monumental undertaking that, even today, twenty years after the first predictions of its demise, many organizations – particularly in financials - are not undertaking. Don’t get me wrong: There are a variety of reasons why mainframes in their current incarnation are doomed to a small vertical market at best in the very very long run, but the cost of recreating systems just to remove mainframes is going to continue to hold them in a lot of datacenters in the near future. But they do need to be able to communicate with newer systems if they’re going to hang around, and the last five years or so have seen a whole lot of projects to make them play more friendly with the distributed datacenter. While many of these projects have come off without a hitch, I saw an interesting case in financial services the other day involving a mainframe and a slow communications channel. Thought it was a slick solution, and thought I’d write it up in case any of you all run into similar problems. This company had, over time, become very distributed geographically, but still had some systems running on their mainframe back in corporate HQ. The systems needed to communicate back to the mainframe, but some of them were on horrible networks that would sometimes suffer latency and line quality issues, yet the requirement to run apps on the mainframe persisted. The mainframe has limited I/O capabilities without expensive upgrades that the organization would like to avoid, so they are considering alternate solutions to resolve the problem of one branch tying up resources with retransmits and long latency lags while the others back-filled the queue. It’s more complex than that, but I’m keeping it simple for this blog, in hopes that if it applies to you directly, you’ll be better able to adapt the scenario to your situation. No highly distributed architecture with mainframe interconnects is simple, and they’re rarely exactly the same as another installation that fits the same description, but this will (hopefully) give you ideas. This is the source problem – when site 1 (or site N) had connection problems, it locks up some of the mainframe’s I/O resources, slowing everything down. If multiple sites have problems with communications links, it could slow the entire “network” of sites communicating with the mainframe as things backed up and make even good connections come out slow. In the following slide, of course I’m using F5 as an example – mainly because it is the solution I know to be tested. If you use a different ADC vendor than F5, call your sales or support reps and ask them if you could do this with their product. Of course you won’t get all the excellent other features of the market-leading ADC, but you’ll solve this problem, which is the point of this blog. The financial services organization in question could simply place BIG-IP devices at the connecting points where the systems entered the Internet. This gives the ability to configure the F5 devices to terminate the connections, and buffer responses. The result is that the mainframe only holds open a connection long enough for it to transfer over the LAN, and eliminate the latency and retransmit problems posed by the poor incoming connections. Again, it is never that simple, these are highly complex systems, but it should give you some ideas if you run into similar issues. Here is what the above diagram would look like with the solution pieces in place. Note that the F5 boxes in the branches would not be strictly necessary within the confines of the problem statement – you only care about alleviating problems on the mainframe side – but offer the ability to do some bi-directional optimizations that can improve communications between the sites. It also opens the possibility of an encrypted tunnel in the future if needed, which in the case of financial services, is highly attractive. I thought it was cool that someone was thinking about it as a network problem with mainframe symptoms rather than the other way around, and it is a relatively simple fix to implement. Mainframes aren’t going away, but we’ll see more of this as they’re pushed harder and harder and put behind more and more applications. Inventive solutions to this type of problem will become more and more common. Which is pretty cool. Related Articles and Blogs: FNZ Teams with F5 to Deliver the Financial Services Industry's Most ... FishNet Security Ensures Application Performance and Availability ... Cloud Changes Cost of Attacks Network Optimization Won't Fix Application Performance in the Cloud Forget Performance IN the Cloud, What About Performance TO the ... Data Center Feng Shui: Architecting for Predictable Performance F5 Networks Expands Application Ready Network™ to Include ... F5 Networks Announces Application Ready Network™ for Oracle New F5 Application Ready Network (ARN) for Oracle Siebel
