Rob Whiteley, VP and GM of NGINX at F5, explores how to empower developers while safeguarding against complexity, cost, and security risks.
Digital transformation that simply replicates existing functionality is not enough. To truly capture the hearts and minds of customers, enterprises need to generate compelling digital innovations, both internally and externally.
Empowering developers to speed up innovation
Companies of all sizes, and indeed entire industries, need to empower developers to create the next great digital service, mobile app, or online experience. This 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 within a rational framework.
Driving innovation comes with costs
While empowering developers is key to driving innovation, doing so without any constraints can be dangerous. 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 architectures significantly more complex, adding management overheads along with operational and security risk. Complexity increases both hard and soft costs, even with free open-source tools.
Fundamentally, the more tools you have, the more time 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.
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 apps 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.
A happy medium: build guardrails, not gates
We believe there are four crucial guardrails that can empower developers while safeguarding against complexity, cost, and security risks:
Shift security left
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.
Embrace modern open source
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!.
Deploy infrastructure as code
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 F5’s 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. The emergence of 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.
Automate through self-service
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 operational risks. 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.
F5’s 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.
Innovations drive progress and productivity
During the last two years, we’ve seen customers that moved quickly to empower developers reap the rewards of their trust and foresight. 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.
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.
Developers are people!
If the cloud era has taught us anything, it’s that if security and infrastructure is easy enough to provision developers will do it.
The guardrails specified above are vital in providing a modern, cloud-native experience—but in a secure and cloud-agnostic manner.
It is important not to forget that developers are people. Make it easy and make it personal. Let them see the benefits of guardrails instead of gates and you’ll achieve secure innovation at scale and with speed.