Tips for staying ahead in FinServ with BIG-IP updates

It’s not uncommon for financial services institutions to forgo refreshes and upgrades of their various vendor software deployments. This approach is commonly known as “sweating the assets.” Not staying current with vendor updates can leave institutions exposed to defects or vulnerabilities amidst an evolving security landscape — a critical point financial services organizations are fully aware of, especially with the serious risks associated with being out of compliance.

Sure, reacting to the latest major CVEs accordingly can be effective at mitigating risks, but to thrive in the hypercompetitive, and increasingly digital financial services industry, your first lines of defense provides the greatest protection with the latest vendor security updates.

With that said, it’s no secret that keeping your applications’ critical infrastructure current with updates, upgrades, and refreshes is a significant undertaking, especially for enterprise-sized institutions with hundreds of apps.

This article will provide helpful tips to stay up to date on the latest versions of BIG-IP, which always include new features and capabilities to improve your application performance and security.

Tips #1 - Identify problems quickly through dedicated resources

Leverage the automation chain you already use when you utilize a tool developed by F5 for migrations. JOURNEYS is an F5 utility designed to assist F5 Customers with migrating a BIG-IP configuration to a new F5 device . Find out more on github.

What does F5 Journeys do?

Beyond reducing the headaches associated with manual BIG-IP migrations it can:

• Load UCS or UCS+AS3 source configurations
• Flag source configuration feature parity gaps and fixing them with provided built-in solutions
• Load validation
• Deployment of the updated configuration to a destination device, including VELOS and rSeries VM tenants
• Post-migration diagnostics
• Generating detailed PDF reports at every stage of the journey

Full config BIG-IP migrations are supported for software paths according to the following matrix:

Check out this article to learn more, Welcome to the F5 Journeys App - BIG-IP Upgrade and Migration Utility

Additionally, consider including BIG-IP in existing test automation, and run those tests on BIG-IP upgrades.

Tip #2 - Have dedicated test environments for BIG-IP

 

As the most interesting man in the world indicates, it’s very tempting to skip a testing environment, but consider avoiding his ways! It’s not ideal to test in production. Avoid the clunkiness and increased challenges of testing in production. Note, its highly recommended to stage dedicated testing environments to mimic production as much as possible.

Consider also strengthening your required manual testing with a UAT (User Acceptance Testing) group as appropriate.

Tip #3 - Patch every 3 months and stay on top of tech debt

I don’t think many would argue that the tech debt associated with not getting on the latest versions can be a serious problem. To avoid compiling unwanted tech debt, consider assigning enough people to support tech debt while scaling BIG-IP. If you keep up on the latest, the churn isn’t so big down the road, but if you wait to do it over multiple versions it adds up and becomes a much bigger project.

Find the latest BIG-IP release information here: BIG-IP LTM Knowledge Center

Establishing a more structured approach is especially helpful when dealing with the large applications financial services institutions typically manage. Consider project management tools to track statuses and keep on schedule. This will particularly come in handy when assigning the proper amount of people optimally to reach your three-month patch goals.

Tip #4 - Do canary deployments

Like with new software development beta rollouts, it’s always a good idea to take things slow, so you don’t introduce a bug to a wider audience. The same practice should be considered when migrating to the latest BIG-IP releases. It’s simple, send to a limited number of users and then after you found and fixed the bugs, send to the rest. You will likely save a lot of headaches when following a slower rollout.

Check out this article here to see how you can use F5 technologies (BIG-IP and NGNIX Plus) to implement the Canary deployment in an OpenShift environment.