devopsy.kinsta.cloud

Author: Mike Vizard

  • CircleCI Bets on Webhooks to Streamline DevOps Integrations

    CircleCI Bets on Webhooks to Streamline DevOps Integrations

    CircleCI today announced CircleCI webhooks, a feature that enables software engineering teams to build integrations that react to CircleCI job and workflow status notifications in near-real-time.

    Tom Trahan, vice president of business development at CircleCI, said this latest iteration of the company’s implementation of webhooks, which send messages any time an event occurs, will become the foundation upon which CircleCI will expand the ecosystem surrounding its continuous integration/continuous delivery (CI/CD) platform.

    For example, the CircleCI platform can now employ webhooks to integrate with a CI visibility tool from Datadog that can now be used to surface CicleCI metrics. Sumo Logic is similarly employing webhooks to enable its Continuous Intelligence observability platform to track events on the CircleCI platform. Those capabilities are now available via the software-as-a-service (SaaS) edition of the CircleCI platform.

    Trahan said the primary goal is to reduce the amount of friction within DevOps workflows that span multiple platforms by increasing the level of orchestration DevOps teams can take advantage of without having to create and maintain integrations using low-level application programming interfaces (APIs).

    Webhooks make it possible to streamline developer workflows while also increasing overall engineering velocity, he added. In addition, it should also become simpler for DevOps teams to triangulate events in a way that results in incidents being resolved faster, noted Trahan.

    CircleCI is relying on webhooks to strengthen its case for a best-of-breed approach to DevOps that enables organizations to mix and match tools as they best see fit rather than getting locked into a single integrated DevOps platform. The best-of-breed approach often makes it simpler to take advantage of new tools as they become available. The downside is the level of integration that DevOps teams need to maintain after they integrate all the tools that make up a DevOps workflow.

    It’s not clear what impact relying on webhooks to share messages in real-time about events as they occur across multiple platforms will have on integrations. However, any effort to streamline DevOps environments without requiring DevOps teams to abandon one tool for another is likely to be well-received. After all, every minute spent managing a DevOps platform means much less time that can be applied to building and deploying applications.

    It will be up to each DevOps team to decide to what degree a best-of-breed approach to DevOps suits their organization. As more organizations realize how dependent they have become on software to, for example, drive digital business transformation initiatives, many IT leaders are making a case to standardize DevOps platforms across their organization. Achieving that goal, however, may be difficult given all the various departments within an enterprise that have already adopted a wide range of tools and platforms.

    In the meantime, the focus on developer and engineering productivity will only increase as organizations look for ways to further accelerate application development and deployment at a time when software updates can now have a profound impact on profits and revenue. In fact, a delay to one software project can have a cascading impact on a wide range of initiatives that can’t go forward because of their dependency on a delayed project. Given the impact all those delays might have on revenue, the tolerance organizations have for delays to software development projects is understandably lessening by the day.

  • CNCF Advances OpenTelemetry Initiative

    CNCF Advances OpenTelemetry Initiative

    The Technical Oversight Committee (TOC) of the Cloud Native Computing Foundation (CNCF) has voted to accept OpenTelemetry as an incubating project as part of an ongoing effort to simplify instrumentation of software using open source agent software.

    OpenTelemetry is a collection of tools, application programming interfaces (APIs) and software development kits (SDKs) that can be employed to collect metrics, logs and traces that make it simpler to determine the root cause of an application issue.

    At its core, OpenTelemetry is based on an OpenTelemetry Protocol (OTLP) specification that describes the encoding, transport and delivery mechanism of telemetry data gathered from sources, intermediate nodes and backend platforms. An OpenTelemetry Collector provides a vendor-agnostic implementation for receiving, processing and exporting telemetry data. APIs and SDKs that make it possible to instrument applications are available for 11 different programming languages.

    Previously a sandbox-level project within the CNCF, the next step would be for OpenTelemetry to become a graduated level project alongside other open source offerings such as Kubernetes and Prometheus, a platform used to monitor IT environments.

    The OpenTelemetry project was created via the merger of the OpenCensus and OpenTracing projects in May 2019. Since then more than 500 developers from 220 companies, including Amazon, Dynatrace, Google, Honeycomb, Lightstep, Microsoft, Splunk and Uber have contributed to the project.

    Most providers of observability platforms have at least signaled their intent to support OpenTelemetry as an alternative to proprietary agent software they had previously created to collect metrics, logs and traces.

    Ben Sigelman, one of the co-creators of both OpenTracing and OpenTelemetry and CEO of Lightstep, said different elements of the OpenTelemetry project are at varying stages of maturity. As such, support for the elements of the project are being added to platforms depending on the degree to which a vendor has confidence in, for example, the ability of OpenTelemetry agent software to collect logs.

    Liz Fong-Jones, principal developer advocate for Honeycomb.io, a provider of an observability platform, said that, in time, most observability platforms will support all the elements of the OpenTelemetry initiative to reduce their own engineering and support costs. In time, those savings will be passed on to organizations that will be able to instrument applications more affordably, she noted.

    It may take a while longer for OpenTelemetry to be widely employed, but the faster organizations transition to microservices-based applications the more pressing the need for open source telemetry software becomes. The dependencies that exist between all the microservices that make up multiple applications will be unmanageable without some form of telemetry. The challenge organizations face is finding an affordable way to instrument all those microservices.

    Of course, organizations have been instrumenting applications for decades. However, the time, effort and cost associated with instrumentation have tended to limit its use to only an organization’s most mission-critical applications. The issue now is that not only do microservices-based applications require instrumentation to manage them but in the age of digital transformation the percentage of applications deemed mission-critical is also steadily rising.

  • GitHub Updates CLI to Make Creating Extensions Easier

    GitHub Updates CLI to Make Creating Extensions Easier

    GitHub this week made available an update to its command-line interface (CLI) that enables DevOps teams to add extensions to workflows.

    Billy Griffin, director of engineering for GitHub, said the company’s initial focus was providing DevOps teams with a set of workflows that could be invoked easily via a CLI. Now GitHub is encouraging developers to extend those workflows using version 2.0 of its CLI that hopefully will be shared with the larger community, he added.

    For example, extensions have already been created that order branches by how recently they were created and then display all associated pull requests.

    At the other end of the spectrum, developers are creating simple screensaver extensions for their own amusement.

    The level of interest in extensions varies widely across DevOps teams. Many of them simply want to employ an opinionated workflow that has been created on their behalf. Other DevOps teams want to be able to make modest modifications. Others prefer to customize workflows as much as possible to fit their specific purposes. Version 2.0 of the CLI provided by GitHub enables each DevOps team to decide how much to modify their workflows. However, as a DevOps team gains more experience, increasingly they tend to want to customize workflows.

    The number of workflows being created around the GitHub repository continues to increase steadily as more organizations embrace best GitOps practices. GitHub is the most widely employed repository for managing software artifacts, and the level of sophistication of workflows built using either scripts or GitHub actions is increasing steadily. Much of that effort is focused on streamlining processes that otherwise would get in the way of enabling developers to spend more time writing code.

    Of course, the pressure on developers to write more code faster has never been greater. As organizations embrace digital business transformation, they are discovering how dependent they are on software to create customer experiences that drive revenue. The challenge comes at a time when many developers are working from home to help combat the spread of the COVID-19 pandemic and many existing workflows need to be re-engineered. At the same time, development teams are becoming more distributed as organizations become more comfortable with hiring developers anywhere in the world.

    It’s not clear to what degree the changing application development landscape might drive organizations to re-evaluate what platforms they are employing to drive DevOps processes. Many on-premises development platforms have been replaced by cloud-based alternatives in the past year. However, because necessity is the mother of invention, the workflows relied on prior to the pandemic are not only now forever changed, but they will also likely be altered again as development teams work more intermittently in-office and from home once the pandemic subsides.

    Regardless of how those workflows evolve, the single-valued DevOps attribute is going to be flexibility. The challenge now is determining which platform does the most to enable that flexibility at a time when uncertainty continues to prevail.

  • GitLab Updates Improve Developer Productivity

    GitLab Updates Improve Developer Productivity

    GitLab this week released an update to its namesake continuous integration/continuous delivery (CI/CD) platform that primarily addresses the need to improve developer productivity.

    Parker Ennis, senior product marketing manager for GitLab, said the GitLab 14.2 release adds, for example, a real-time Markdown preview capability that makes it possible to have a live preview of Markdown files used to create rich web content that can be accessed either via the web integrated development environment (IDE) or a single file editor. The goal is to eliminate the need to switch from raw code to a separate preview mode tab, said Ennis.

    At the same time, GitLab has made it possible to now launch GitPod, a tool for automatically launching development environments in the cloud, directly within a merge request page, while adding the ability to more easily track which groups within organizations have enabled dependency scanning and fuzz testing. Previously, DevOps teams could only track adoption of these GitLab features via an application programming interface (API).

    GitLab

    Finally, GitLab is adding a beta release of Build Cloud for macOS that makes it easier for developers to build applications on the software-as-a-service (SaaS) edition of GitLab.

    Ennis said in the wake of the COVID-19 pandemic, adoption of the SaaS edition of GitLab has naturally increased because so many developers are still working from home. Most DevOps teams are now focused on trying to improve the productivity of developers; they are not expected to return to the office any time soon as new variants of the COVID-19 virus continue to emerge, he noted.

    The challenge organizations face is that, in the wake of the pandemic, there’s more pressure than ever to build applications faster as organizations race to digitally transform business processes. As a result, the productivity of developers working in physical isolation from one another has become a major concern, added Ennis.

    The developer experience is also critical because it’s never been easier for developers to jump ship. Not only are developers being heavily recruited, Ennis noted that most DevOps leaders have little visibility into how they are spending their time. It’s relatively easy for developers to scan job sites for new opportunities while they are supposed to be writing code, he added.

    It’s not clear how much of an impact the CI/CD platform is likely to have on overall developer satisfaction. However, Ennis noted that the more disjointed DevOps processes become, the less favorably developers will regard their employers. Most developers want to be able to spend more time writing code rather than managing pipelines and workflows. GitLab is making a case for a more integrated set of DevOps workflows based on a CI/CD platform that tightly integrates all the modules that a DevOps team might decide to use. That approach is designed to appeal to enterprise IT organizations that typically don’t have a lot of time and energy to devote to integrating the modules that make up a DevOps workflow, noted Ennis.

    Of course, it’s still early days as far as the pervasive enterprise adoption of DevOps platforms is concerned. However, as the pressure to deliver software faster continues to rise, the need to revisit application development processes becomes that much more pressing.

  • CloudBolt Survey Shows DevOps Frustration in the Enterprise

    CloudBolt Survey Shows DevOps Frustration in the Enterprise

    A survey of more than 200 senior IT leaders at organizations with more than 1,000 employees published today finds only 4% consider their organizations to be experts when it comes to continuous integration/continuous delivery (CI/CD).

    Conducted by CloudBolt Software, a provider of a platform for many IT environments, the survey also found only 11% consider their CI/CD infrastructure to be reliable. Another 69% said their CI/CD infrastructure was somewhat reliable, while 21% said their platforms were somewhat unreliable or not reliable at all. A full 85% also report they regularly test the infrastructure they rely on to drive DevOps processes.

    Overall, the CloudBolt survey finds only 5% of respondents report their organization is deploying code multiple times a day. Most respondents (85%) said their organization only deploys code on a weekly or monthly basis.

    A full 70% said that, on average, it also takes multiple days or even weeks to set up a pipeline. Nearly two-thirds (63%) said there are too many manual processes involved when setting up pipeline infrastructure. More than half (56%) also noted they have no automated processes for post-deployment tasks.

    More than half (53%) said it is also challenging to proactively detect infrastructure issues, while 55% said it is difficult to create a consistent CI/CD pipeline environment across multiple development teams. Improving those pipeline environments requires speeding up the process of provisioning infrastructure through automated processes (70%); continuously detecting infrastructure issues to reduce testing challenges and failures (62%) and simplifying remediation of infrastructure issues proactively (56%), according to survey respondents.

    The CloudBolt Software survey specifically identifies issues organizations encounter when employing Terraform to manage infrastructure-as-code (IaC). Only 5% of respondents said they were “very satisfied” with using Terraform and another 75% reported they are somewhat satisfied. Top challenges include difficulty using it in on-premises infrastructure deployments (62%), lack of Day 2 management for deployed resources (53%) and governance (42%). Only 2% of respondents said they were employing Terraform to deploy 75% or more of their infrastructure. A full 90% noted that Terraform requires more custom-coded integrations with other critical tools and systems to work properly.

    Finally, 29% said their organization lacks specific Terraform expertise. The most sought-after Terraform capabilities are enabling non-Terraform experts to easily deploy infrastructure using Terraform; ensuring that only Terraform plans with IT “guardrails” are executed and the ability to visualize and cost-optimize infrastructure deployed by Terraform. More than a third (35%) want to simplify deployment of on-premises infrastructure when using Terraform.

    Jeff Kulkowski, CloudBolt CEO, said the survey makes it clear there simply isn’t enough expertise available to implement DevOps  best practices at scale without enabling IT administrators—that often lack programming expertise—to manage infrastructure and DevOps platforms. That requirement creates the need for an IT management platform based on a set of visual tools that enables DevOps professionals and traditional IT managers to work more collaboratively, he added. DevOps teams can manage IaC whenever they desire, but it’s also crucial to enable IT operations staff to manage IT infrastructure alongside those teams.

    Obviously, DevOps as an IT discipline still has a long way to go before it is pervasively adopted across enterprise IT organizations. The challenge now is to remove many of the low-level barriers that conspire to block IT modernization initiatives.

  • Cosmonic Contributes WebAssembly Runtime to CNCF

    Cosmonic Contributes WebAssembly Runtime to CNCF

    Cosmonic today revealed it has donated its universal application runtime for building cloud-native applications using the WebAssembly (Wasm) development framework to the Cloud Native Computing Foundation (CNCF).

    The Cosmonic wasmCloud runtime makes it possible to run applications built using WebAssembly on any platform. In comparison, applications built using containers are not as portable because IT teams can’t take a container application developed for Linux and run it on Windows. The container technologies for each operating system are implemented differently.

    The CNCF will make wasmCloud available as a sandbox project and will invite other organizations to start making contributions as part of an effort to eventually put wasmCloud on par with other projects such as Kubernetes. There are already nearly 80 contributors to a wasmCloud runtime that was launched last November.

    Cosmonic

    The CNCF is trying to advance other WebAssembly technologies including Krustlet, a tool for Kubernetes environments that listens for event streams from new pods so that the scheduler can then assign workloads.

    However, the CNCF is now not the only organization looking to promote adoption of WebAssembly technologies. The Bytecode Alliance has launched WebAssembly (Wasm) and WebAssembly System Interface (WASI) initiatives as part of an effort to promote standards that would make it easier to run Wasm applications anywhere. Originally founded by Fastly, Intel, Mozilla and Microsoft, the Bytecode Alliance now also includes Arm, DFINITY Foundation, Embark Studios, Google, Shopify and University of California at San Diego.

    At its core, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. That approach might one day replace the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct security boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application.

    Liam Randall, CEO of Cosmonic, said even though Wasm, in effect, provides another type of virtualization for applications, IT teams should not view it as a set of technologies that will one day obviate the need for containers. Applications developed using Wasm will be layered on top of various container platforms, he said.

    There is, for example, already a Wasm project that creates a server-side Wasm runtime that enables applications to be deployed on a secure container architecture that is more efficient than Docker containers.

    The World Wide Web Consortium (W3C) drove the development of Wasm as part of an effort to create a common format for browsers executing JavaScript code. Wasm is now being extended beyond browsers and JavaScript to enable developers to ultimately create a set of universal binaries that could work on any platform without modification.

    It may be a while before the fruits of those labors are realized. However, it’s apparent the walls that have separated one IT platform from another are starting to crumble. Once applications become much more portable, the reasons why one organization may choose one platform over another will have a lot less to do with what developers prefer.

  • F5 Networks Planning Open Source Projects Beyond NGINX

    F5 Networks Planning Open Source Projects Beyond NGINX

    F5 Networks today revealed plans to launch multiple projects in the months ahead that will extend its commitment to open source beyond the NGINX proxy software the company acquired in 2019.

    The announcement was made during an online NGINX Sprint event; two of the projects are extensions of NGINX that will address networking requirements between microservices-based applications in addition to the management of fleets of NGINX instances. The third project is a platform-agnostic open source developer tool for building modern applications that does not necessarily require NGINX proxy software.

    At the same time, F5 Networks also unveiled an open source NGINX Modern Apps Reference Architecture that gives IT teams access to a complete, fully operational microservices-based application that can be deployed in minutes on a Kubernetes cluster. Based on a modular approach made up of open source components that come pre-wired and pre-integrated, F5 Networks is committing to extending this framework in collaboration with multiple third-party vendors and organizations.

    F5

    Rob Whiteley, general manager for the NGINX product group at F5 Networks, said the company is also committing to modernizing its NGINX proxy software to leapfrog rival open source Envoy proxy software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). NGINX is still more widely employed than Envoy largely because it is lighter-weight and easier to deploy, but Whiteley conceded that Envoy has more advanced capabilities.

    Envoy, of course, is at the core of the Istio service mesh. F5 Networks supports both Istio as well as a service mesh it has developed on top of NGINX. Depending on the number of application programming interfaces (APIs) that an organization needs to support, an IT team might make use of proxy software, ingress controller or an API gateway for a service mesh to manage them.

    Finally, F5 Networks said it will participate in the Kubernetes ingress project and that it is joining the gateway API community as its implements its own NGINX-based gateway controller to ensure its proxy software and Kubernetes remain tightly aligned in the future.

    In general, Whiteley said F5 Networks also is making a commitment to be clearer about where the line between the open source and commercial editions of its offerings is drawn. As a rule, the open source editions are designed for developers and small teams while the commercial version is designed to scale within enterprise IT environments. The overall goal is to promote innovation without enabling cloud service providers to reap all the revenue benefits of F5’s research and development by creating a service based on that open source software, said Whiteley.

    As part of that effort, F5 Networks is expanding the number of open source projects it supports to make it easier for developers to contribute code beyond the core NGNIX proxy software, said Whiteley.

    It’s not clear to what degree F5 Networks will be able to rally the open source community to advance additional projects beyond NGINX. The company is promising to provide additional details at an unspecified future date. However, Whiteley said there is still plenty of room for innovations not only in emerging technologies such as service meshes but also proxy software that is already widely employed within many enterprise IT organizations. Especially since most of them are embracing microservices-based applications that will ultimately change every aspect of IT.

  • Kentik Open Sources Five Projects to Advance Network Observability

    Kentik Open Sources Five Projects to Advance Network Observability

    Kentik today unfurled a developer hub, dubbed Kentik Labs, through which it is making five open source projects available as part of an effort to advance observability across network operations (NetOps).

    The five projects are:

    kTranslate: A system for pulling and pushing network data that is the basis of the Kentik Firehose integration the company created for the New Relic observability platform

    NetDiag: Scalable, asynchronous implementations of low-level network diagnostics

    Convis: Example code showing how to attribute process and container information to network traffic via the Linux kernel using eBPF

    kProbe: A high-performance host and sensor network probe (PCAP)

    Grafana App: A real-time tool for ingesting and querying network data

    Nick Stinemates, vice president of business development at Kentik and co-chair of Kentik Labs, said the goal is to enable DevOps teams to incorporate NetOps within the workflows already being employed to programmatically manage the rest of IT.

    Stinemates noted that, as IT environments become more distributed, managing NetOps has become more challenging. If there is a failure, it can be difficult for DevOps teams to determine if the issue is due to application code, the underlying infrastructure or some other root cause. Kentik Labs is committed to providing tools that will help DevOps teams reduce their mean time to recovery (MTTR), he added.

    Most NetOps teams increasingly rely on software to manage distributed networks either in the form of graphical tools provided by router and switch vendors or by using the Python programming language and the open source Ansible automation framework that enables IT teams to declaratively manage IT infrastructure.

    As the teams that manage network operations gain more proficiency with those tools, it becomes simpler to incorporate them within the construct of a larger DevOps team. While DevOps teams have been programmatically managing IT infrastructure-as-code (IaC) for years, network management has largely remained in a separate silo. However, as more applications are deployed in the cloud, it’s clear NetOps needs to become more integrated with the rest of the workflows employed to deploy and manage a highly distributed IT environment, said Stinemates.

    Less clear is to what degree the networks that make up a hybrid cloud computing environment will continue to be managed by network administrators versus site reliability engineers (SREs) that are starting to assume responsibility for managing compute and storage.

    Regardless of who manages the network, the next generation of microservices-based applications that are dependent on application programming interfaces (APIs) to call various services are much more latency-sensitive than previous generations of applications. Many of those applications will regularly experience performance issues due to networking issues that are often not readily apparent to DevOps teams. The goal should be to, at the very least, arm those DevOps teams with the tools required to confirm the source of those issues before a “war room” is convened to determine how to address the issue.

  • Micronaut Taps Moderne to Automate Java Framework Updates

    Micronaut Taps Moderne to Automate Java Framework Updates

    Micronaut, a provider of a framework for building applications based on microservices and serverless computing platforms, today revealed it is allying with Moderne, a provider of a tool for refactoring code, to create a “recipe” that will automatically update the Micronaut framework.

    Moderne CEO Jonathan Schneider said the open source OpenRewrite refactoring tool for code, originally developed at Netflix, makes it possible to automate updates to codebases, remediate vulnerabilities and provide a foundation for high-level building blocks that will make authoring custom transformations simpler. That approach will eventually be embraced by other providers of application development frameworks.

    Fresh from raising $4.7 million in initial funding, Moderne makes OpenRewrite available via a software-as-a-service (SaaS) platform to enable IT teams to search and transform millions of lines of code in minutes. OpenRewrite currently supports Java, but the company is working toward adding support for additional languages, including infrastructure-as-code (IaC) tools such as Kubernetes, YAML and XML.

    Moderne has also developed “recipes” for common search and refactoring operations that can be assembled into more complex recipes for framework migrations involving, for example, an upgrade from Java 8 to Java 11. Micronaut is the first provider of a development framework to create a recipe for its own framework using OpenRewrite.

    At a time when applications are more distributed than ever, updating codebases is a major challenge. In fact, the manual effort involved in making those migrations is one of the primary reasons many organizations continue to employ older versions of frameworks such as Java 8. OpenRewrite is designed to automate that process at scale in a way that leaves it up to the individual developer to determine how involved they want or be or if they simply prefer to have a DevOps team manage the upgrade process on their behalf, said Schneider.

    In the longer term, Schneider said he expects recipes will be created to address everything from mass migrations to remediating specific types of vulnerabilities across an entire codebase.

    Too much reliance on legacy development frameworks generally stymies innovation. The latest versions of Java, for example, are designed to make it simpler for developers to build microservices-based applications.

    It remains to be seen to what degree DevOps teams will embrace automation to upgrade code. Many developers are hesitant to rely on automated tools of any kind. However, given the need for most developers to spend more time writing new code, it’s only a matter of time before most of them come to terms with automated approaches to updating existing code.

    In the meantime, the cost of supporting legacy frameworks should decline as organizations begin to migrate their codebases faster. One of the reasons there is so much technical debt in the enterprise is because different development teams tend to adopt different framework versions at different times. DevOps teams can find themselves being asked to simultaneously support multiple versions of the same framework. There may always be multiple versions of those frameworks, but, over time, DevOps teams should eventually see the bulk of deployed applications all using the same framework as the upgrade cycle becomes more automated.

  • Foundation Proposes Advancing eBPF Adoption Across Multiple OSes

    Foundation Proposes Advancing eBPF Adoption Across Multiple OSes

    The eBPF Foundation, which proposes to advance adoption of an approach that enables sandbox programs to run faster at the kernel level, is being launched today as an arm of the Linux Foundation.

    The technology known as eBPF was originally developed for Linux. The eBPF Foundation is now committed to expanding use of eBPF across all operating systems. Members of the eBPF Foundation include Facebook, Google, Isovalent, Microsoft and Netflix.

    Thomas Graf, CTO and co-founder of Isovalent, a provider of networking and security tools that leverage eBPF, said IT organizations should expect to see the technology become part of Windows, along with other operating systems, as the core technology is tested and validated across a much wider range of platforms.

    In effect, eBPF changes the way operating systems are designed. It bridges the boundary between kernel and user space by enabling developers to combine and apply logic across multiple subsystems that, historically, were completely independent of one another. That approach enables, for example, a security tool to scale to the point where it can identify threats at much higher levels of throughput to improve overall scale at a time when the volume of cybersecurity attacks being simultaneously launched continues to increase.

    Currently, eBPF is widely employed by web-scale companies such as cloud service providers. Facebook is using it as the primary software-defined load balancer in its data centers while Google is using open source Cilium networking software within its managed Kubernetes offerings.

    However, adoption within on-premises IT environments that have deployed Linux has been more limited simply because the number of vendors that have optimized networking, security and storage offerings to take advantage of eBPF is still fairly limited.

    Sysdig, for example, recently launched made available an instance of the open source Falco container security platform available that employs eBPF. Tigera has also made available an instance of its container networking platform that leverages eBPF at the kernel level of Linux.

    Ultimately, Graf notes the biggest benefit of eBPF is efficiency. The total cost of processing for security, networking and storage platforms should decline as more vendors take advantage of a capability that will one day be widely employed across multiple operating systems.

    In the meantime, IT organizations would be well-advised to ask their vendors when they plan to support eBPF. Cloud service providers generally require it to deliver their own managed services more efficiently, so any vendor that hopes to sell a platform to those providers will need to support eBPF to drive performance at scale. The issue then becomes determining which platforms that have embraced the technology are also available in on-premises IT environments looking for similar benefits.

    Regardless of approach, it’s clear there will soon be a reason to upgrade not just networking, storage and security platforms but also instances of operating systems that don’t yet support eBPF. DevOps teams would be well-advised to plan accordingly because the number of platforms that will ultimately benefit from eBPF spans the entire enterprise.