Bridging Divides with Open Source
Application delivery is changing. At the risk of using buzzwords, it is being transformed – digitally. Continuous delivery has become the norm for DevOps (71% plan on implementing), and continuous deployment must follow if business is to succeed in the era of Application Capital. While 73% of organizations plan on pursuing continuous deployment, nearly half of them have yet to begin. A staggering 42% have yet to automate a single component of the continuous deployment pipeline.
The divide between delivery and deployment is real. It can be seen in theory in surveys and in practice in the chasm that exists between cloud and data center. It’s seen within organizations in the wall that brings continuous delivery to a halt where it meets sort-of continuous deployment.
It’s also seen in technology, where a very real gap in visibility arises from the disconnected application delivery chain. It’s seen in the inability to monitor and measure application performance in multi-cloud environments. And it’s seen in an inability to consistently deploy and enforce security policies across the multi-generational application portfolio currently under management by thousands of enterprise organizations.
The Divide is Growing
Increasingly we’ve watched that divide widen with the adoption of modern, cloud-native applications and architectures. Even those applications that remain tethered to the data center are impacted. Whether that impact is new approaches – continuous everything – or new application services to answer the need of security and scale in modern, cloud-native environments, one thing is clear: application delivery has to change and bridge the divide between DevOps and NetOps if it is going to address the need for consistency and visibility in a multi-cloud world.
The world of DevOps is increasingly built on open source. As NGINX CEO Gus Robertson, wrote in his recent blog, “If software is eating the world, then open source is eating software.” Applications themselves are mainly developed today from third-party components, a majority of them open source. Application infrastructure is increasingly built from open source components. From web servers to app servers, from databases to ingress control, from messaging to container runtimes and orchestration. IT operations are driven by open source tools like Puppet, Chef, Terraform, Helm, Kubernetes, and Ansible.
These tools and technologies are adopted because they answer multiple challenges: fast, frequent delivery and deployment along with a frictionless business model. But they also offer benefits in terms of encouraging collaboration and spurring innovation when entire organizations move to standardize on open source-based operations.
None of that is possible without the passionate communities of developers who work tirelessly to improve on their open source solutions.
At F5, we appreciate the value of such communities.
How F5 Sees Community
In a comparable example, our DevCentral community is based on collaborative innovation, guided by many of the same principles that drive open source projects. Code sharing and knowledge transfers across the community help the hundreds of thousands of members innovate and create new capabilities for our BIG-IP platform. With those solutions come new extensions, plug-ins, and libraries for open source projects like Puppet and Chef and node.js.
We actively participate, encourage, and support these efforts to enhance not only our own products, but the open source software that our customers and the community rely on to keep their businesses running.
Still, we know many of you – especially in the NGINX open source community – don’t know F5 very well. We also recognize that gives you reason to be skeptical. That’s understandable. To date, our interaction with open source has largely remained behind the scenes.
That said, our own transformation makes extensive use of open source to drive our CI/CD pipeline and our products as we shift our focus from application delivery to application services. We are constantly interacting with open source, and our core engineers actively contribute to loopback.io and nats.io. Our Aspen Mesh arm consumes and contributes regularly to istio.io and has generated several related open source projects we maintain such as istio-vet, istio-client-go, and tracing-go. We develop and maintain a set of open source modules for Ansible.
We don’t shout about it much because we don’t contribute to score marketing points; we contribute because it’s the right thing to do for us, for our customers, and for each of the communities that steward open source projects.
Bridge Building
To bridge the divide that keep the enterprise from realizing continuous IT, the right thing to do now is to amplify and accelerate the mission of some of the most widely adopted open source components in the application delivery stack.
So let me reiterate what Gus and Igor have communicated: F5 intends to increase investment to amplify and accelerate the NGINX mission.
By bringing together F5 and NGINX, we can enable enterprises with an end-to-end, consistent set of application services to address one of IT’s most pressing needs: fast, frequent deployments across a varied set of application architectures residing in multiple cloud properties. We believe that doing that successfully depends on NGINX remaining open source and being driven in large part by the community that built it.
NGINX has done an incredible job in shepherding its open source software and community to date. It’s one of the things that attracted us. As we look into a future both NGINX and F5 believe will be driven and shaped by applications, we see both the need and the opportunity to amplify and accelerate development and innovation in the NGINX stack.
We look forward to learning from these communities and working together toward a future that is built on a shared passion for applications and their flawless delivery.