This February 15 and 16, we’re again hosting our annual customer event virtually, as we have since 2020. Agility 2022 is just one example of how lockdowns during the COVID‑19 pandemic have forced the wholesale shift of commercial and social activities online, turbocharging digital transformation. Digital transformation that simply replicates existing functionality is not enough, however. To capture the hearts and minds of customers, enterprises needed to generate compelling digital innovations, both internally and externally.
Take the case of OXXO, a fast‑growing convenience store chain in Mexico. Before the pandemic, the company was opening stores at a blistering pace – roughly one store per day. When customers were no longer allowed in the stores because of lockdowns, OXXO had to switch its business model and provide the same convenience via digital storefronts. The Mi OXXO online and mobile app was born, enabling OXXO to pivot to home delivery. The crisis unlocked rapid‑fire digital innovation and opportunity: OXXO gained a new sales channel, deepening its relationship with existing customers while picking up new digital‑native shoppers.
But’s what’s the key to rapid‑fire digital innovation that surpasses mere digital transformation? Developer empowerment.
You need to give developers – your secret weapon and superpower – what they need and want. OXXO empowered its developers to quickly build out a compelling and engaging digital experience by providing the infrastructure and tooling that they needed to develop, bring to market, and then operate an online shopping experience at scale.
In short, empowering developers leads to digital innovation.
Like OXXO, companies of all sizes and industries need to empower developers to create the next great digital service, mobile app, or online experience. Empowerment means trust, autonomy, and distributed decision making. Developers must be able to choose the tools of their trade and make key design and service choices for their digital masterpieces – within reason and in a rational framework.
While empowering developers is key to driving innovation, doing so without any constraints is dangerous. It can lead to tool sprawl, an incongruous infrastructure that is hard to maintain and secure, and over time to a disjointed customer experience. Two of the primary risks of unchecked developer empowerment are complexity and cost.
Developers love tools (often open source). But too many tools lead to sprawl, with three or four pieces of technology performing the same task. This makes your architecture significantly more complex, adding management overhead along with operational and security risk. Complexity increases both hard and soft costs, even with free open source tools. (Remember – open source is sometimes free like a puppy.) The more tools you have, the more time your valuable infrastructure and platform teams must spend maintaining them. Onboarding new developers is also more complicated and time‑consuming, because they must become familiar with each tool’s UI (including its quirks), even when it just does the same thing as another tool.
Complexity also leads to potential downtime: more moving parts with their own operational models and toolchains increase the chances things will break under load. Having your app go down involves both reputational risk and financial risk from lost revenue. Rather than wait for you to fix the problem, users may become dissatisfied or go to other providers.
To avoid these pitfalls, you need to enable developers to be agile without making your apps fragile – to allow them to write code quickly and drive products to market faster while surrounding them with necessary guardrails to ensure your enterprise is not at risk. We call this “running safely with scissors”. As parents we can to try to prevent our children from running with scissors by yelling at them. Or we can acknowledge that they’re going to run with scissors and reduce the risks by buying them scissors with blunted tips. Bonus points if you can also educate them on the risks and get them to follow safety tips like holding scissors with the tips facing downwards.
For developers we need a similar two‑fold approach of allowing them to run while educating them on how to move faster without breaking things or causing undue risks.
At F5, we believe there are four crucial guardrails you can put in place to empower developers while safeguarding against complexity, cost, and security risks:
Developers want to code. They want to provide new features and functionality. They don’t necessarily want to spend time and energy on security. But if you can introduce security earlier in the software development lifecycle, you can make security developer‑friendly (enough) that they’re willing to make it part of their workflows. This is referred to as shifting left.
Shifting left is about making developers more responsible for implementing security as they write code – whether it’s threat model assessments, code audits, pen testing, or applying security policies via controls like a web application firewall (WAF). Shifting left is also about making it easier and more intuitive for developers to accomplish these tasks within their existing workflows.
According to a survey by SANS Institute, an organization that specializes in information security and cybersecurity training, fewer than 40% of enterprises have shifted security practices left in a manner consistent with DevSecOps principles. For contrast, consider organizations like Audi. With F5 NGINX App Protect, Audi empowers its application teams to accomplish 80% of required security operations natively within their workflows on the company’s Kubernetes platform.
Developers have an open-source-first mentality. Providing guardrails doesn’t work if you don’t provide open source tooling that fits into their ethos and technology stack preferences. By now, most companies use open source – with Linux, Docker, Kubernetes, and thousands of other tools leading the charge. According to Red Hat’s The State of Enterprise Open Source report for 2021, 90% of IT leaders are using enterprise open source. That said, there’s a vast array of open source possibilities today with many thousands of projects for diverse tasks. So it’s important to prevent tool sprawl by standardizing on a curated set of open source tools (taking into account the wishes and guidance of your developer rockstars, of course!).
For example, French cable TV provider Canal operates three separate open source SQL databases for its Canal+ premium service. But when it came to ingesting data, they wanted a standard. Canal developers initially chose NGINX Open Source to handle the 50,000 requests per second generated by the streaming platform. As Canal+ grew, the platform team seamlessly migrated to F5 NGINX Plus for the additional scale and observability capabilities needed to operate a platform receiving more than a billion clicks per year. Canal doesn’t have to operate multiple proxies and load balancers, yet developers still got to choose a native open source tool without sacrificing operational requirements.
Shifting security left and embracing open source relies on another best practice: treating your infrastructure as code. This means deploying code as software or services that can be programmed by APIs.
According to our own State of Application Strategy in 2021 report, 52% of organizations have embraced Infrastructure as Code (IaC) practices. IaC means your infrastructure can be scaled up and down as needed – and it extends beyond just your security and open source tooling. Treating all modern app infrastructure as code pushes responsibility for configuring infrastructure closest to those that know the application best: the developers and DevOps teams. Containers have revolutionized how infrastructure can be deployed and allowed developers and DevOps teams to easily design and invoke the infrastructure best suited to their app deployments.
That’s why African Bank modernized its core banking platform using a microservices architecture and NGINX. By treating infrastructure as code, like the bank you can empower developers to push new features to production faster. Using containers as the foundation, African Bank reduced the time it takes to offer its customers a new banking capability from six months to six weeks.
At this point you might be asking “Do I really want to empower my developers that much?” Shifting security left, embracing open source, and deploying infrastructure as code, while allowing developers the leeway to do it all without guardrails – can lead to the operational risks we discussed. That’s why you need self‑service infrastructure, both to make it easier for developers to deploy the infrastructure and services they need and to reduce complexity while controlling cost.
Our State of Application Strategy in 2021 report also revealed that 65% of organizations have adopted automation and orchestration. More specifically, 68% are adopting automation for network and security. Why? So that DevOps, NetOps, SecOps, and Platform Ops teams can make infrastructure easy for developers to provision through self‑service catalogs, enabled by containers that limit approved deployments to “golden images” vetted as safe and effective for production. In fact, this combination of “self‑service” and “golden image” is part of what has made public clouds so popular. They function as self‑service portals for a catalog of developer‑friendly technologies, enabling small teams to build and scale apps that compete with giant enterprises. That said, we know that cloud providers don’t always provide the most secure default configurations. This is why it’s so critical to manage your own “golden images” and set them up to protect your own specific infrastructure.
For example, Modern Hire solved this problem by automating WAF deployments through F5 NGINX Controller. Modern Hire relies on NGINX Plus as a critical part of its cloud architecture for security and traffic processing. This freed them to close down a legacy data center, but when it came to pushing security they still didn’t have a solid automation story. Enter NGINX Controller, which provides a DevOps workflow engine for NGINX App Protect WAF. Now Modern Hire’s DevOps team can provide a self‑service interface to the security team without breaking the value of automation in a DevOps environment. Join the Shifting Left with F5 NGINX discussion forum at Agility 2022 to learn more from Jason McMinn, Infrastructure Architect & Sr. DevOps Engineer at Modern Hire.
[Editor – NGINX Controller is now F5 NGINX Management Suite.]
During the last two years, we’ve seen customers that moved quickly to empower developers reap the rewards of their trust and foresight. Like OXXO, many created new sales channels or empowered their developers to completely rearchitect applications and infrastructure for a future of distributed cloud‑ and service‑based deployment frameworks. Those customers are today in a better place and looking to the future. We are pleased we can help them on that path and we hope that our vision and recent product announcements help them even further.
Shifting left, enabling open source, scaling infrastructure as code, creating self‑service architectures, and building adaptive applications on the most modern and resilient infrastructure technologies like Kubernetes all drive digital innovation. Together with my F5 colleagues, I’ll be speaking during the keynote on Day 1 of Agility 2022 (9:00–10:30 a.m. PST, February 15) about how to simplify, secure, and innovate in the digital era.
You can register here for Agility, a two‑day virtual event that includes keynotes, panel discussions, breakout sessions, and demos. And it’s completely free! We look forward to meeting you virtually at Agility, and to partnering with you to empower your developers and push the envelope in the coming year and beyond.
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."