devopsy.kinsta.cloud

Tag: CNCF

  • Splunk Donates eBPF Telemetry Data Collector to CNCF

    Splunk Donates eBPF Telemetry Data Collector to CNCF

    Splunk Inc. announced during the KubeCon + CloudNativeCon North America conference that it donated a data collector to the OpenTelemetry project run by the Cloud Native Computing Foundation (CNCF).

    Splunk’s data collector runs as a sandbox-level program at the kernel of a Linux operating system and takes advantage of extended Berkeley Packet Filter (eBPF) technology to make it simpler to collect networking telemetry.

    The OpenTelemetry initiative itself spans a range of open source tools, application programming interfaces (APIs) and software development kits (SDKs) that are used to instrument applications. Previously, Splunk contributed the SignalFx Smart Agent and Smart Gateway to the OpenTelemetry project along with more than 64,000 code contributions.

    Morgan McLean, a director of product management for Splunk, said that while OpenTelemetry is officially in beta, some elements of the project are more mature than others. For example, tools for capturing metrics and traces are already being employed, while another set of tools for capturing log data will be ready sometime next year, he said.

    The data collector contributed by Splunk is among the first that operate at the kernel level to collect data, added McLean. That approach makes it possible for some types of data to be captured by default rather than requiring developers to always instrument their applications using agents to enable an observability platform. It will also contribute toward the eventual convergence of network operations and DevOps processes.

    Going forward, DevOps teams should expect to employ a mix of open source data collectors that operate at both the eBPF and application level, said McLean. The eventual goal is to instrument every application by default by making it much simpler to collect data. Today, most DevOps teams are employing a mix of proprietary and open source agent software to collect data that then must be deployed and then integrated with all the applications they build. Given the cost and level of effort required, the percentage of applications that are actually instrumented is, not surprisingly, fairly low.

    However, as agent software becomes more readily accessible, the percentage of applications that are instrumented should increase considerably in the years ahead. For DevOps teams that depend on that data to optimize application performance, that capability should prove to be a boon for improving overall observability in IT environments.

    Observability, in one form or another, has always been a core tenet of any DevOps best practice. Initially, DevOps teams focused on continuous monitoring as the most effective way to proactively manage application environments. However, it can still take days, sometimes weeks, to discover the root cause of an issue.

    Monitoring focuses on predefined metrics to identify when a specific platform or application is performing within expectations. The metrics tracked generally focus on, for example, resource utilization. Observability platforms combine metrics, logs and traces—a specialized form of logging—to instrument applications in a way that makes it simpler to troubleshoot issues without relying on a limited set of predefined metrics focused on a specific process or function.

    Those observability platforms then make it possible to correlate events so that it is easier to identify anomalous behavior indicative of an issue’s root cause. Armed with these insights, it becomes a lot simpler for IT teams to resolve issues faster.

    It’s unclear when OpenTelemetry tools will become more widely employed, but as more tools for collecting data become available, the impact on DevOps will be nothing short of profound.

  • CNCF Adopts Meshery to Advance Service Mesh Management

    CNCF Adopts Meshery to Advance Service Mesh Management

    The Cloud Native Computing Foundation (CNCF) announced this week during the ServiceMeshCon/KubeCon + CloudNativeCon conference that Meshery, a service mesh management plane created by Layer5, has become a sandbox-level project.

    In addition, Layer5 has also donated Service Mesh Performance (SMP), a set of tools for measuring the efficiency of a service mesh, to the CNCF. SMP provides an open source framework to define standardized benchmarking practices, performance test configurations and measurements as part of an effort to create a MeshMark index for rating a service mesh. A set of service mesh performance methodologies will also be published by the IEEE later this month, developed in collaboration with engineers from Layer5, Intel, Red Hat and HashiCorp.

    Layer5 CEO Lee Calcote said the goal is to make it simpler for IT teams to determine which service mesh to employ based on their specific use case requirements.

    Several service mesh platforms are starting to gain traction as a means to both manage application programming interfaces (APIs) and provide a layer of abstraction between lower-level networking and security APIs that makes those services more programmatically accessible to developers.

    Meshery itself is an implementation of SMP and the conformance tool created for the Service Mesh Interface (SMI), a separate CNCF project to promote interoperability between service meshes. Meshery is based on a set of microservices that are designed to make the platform easily extensible.

    That approach makes it possible to manage multiple instances of service meshes that might be deployed on virtual machines as well as Kubernetes clusters using a range of management tools that are part of the Meshery project.

    Meshery supports AWS App Mesh, Citrix Service Mesh, HashiCorp Consul, Istio, Kuma, Linkerd, Network Service Mesh, NGINX Service Mesh, Open Service Mesh and Traefik Mesh. Meshery also provides IT teams with more than 60+ best practices in the form of templates that can be used to deploy a service mesh.

    It’s still early days as far as adoption of service mesh in the enterprise is concerned. Most IT teams still rely on either proxy software or a gateway to manage APIs. However, as the number of APIs that need to be managed steadily increases, it won’t be long before many IT teams start to at least evaluate a service mesh.

    In the longer term, the impact those service meshes are likely to have on the management of IT could be profound. It is becoming apparent that a service mesh also provides a higher level of abstraction for invoking networking and security services. In fact, the service mesh may wind up playing a key role in driving the convergence of network and security operations with DevOps best practices.

    In the meantime, IT teams will need to decide to what degree they may want to standardize on a single service mesh versus letting individual teams implement their own preferred platform that could one day be centrally managed via Mashery. One way or another, the way APIs are managed and invoked will soon fundamentally change forever.

  • 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.

  • Splunk Unveils Unified Observability Platform

    Splunk Unveils Unified Observability Platform

    Splunk today unveiled an observability platform delivered as a cloud service that captures all metrics, traces and logs in real-time without relying on sampling.

    Spiros Xanthos, vice president of product management for observability and IT Ops at Splunk, said Splunk Observability Cloud collects all that data via a single agent based on open source OpenTelemetry software to instrument an application.

    Historically, application performance management platforms (APMs) have only analyzed samples of data to identify a potential anomaly. Splunk Observability Cloud analyzes all the streaming data captured by its agent software to enable IT teams to pinpoint the root cause of an issue faster, said Xanthos.

    As a result, Xanthos said the signal-to-noise ratio dramatically improves compared to legacy monitoring platforms. It will then be up to each IT team to decide how much of that data they want to store after it’s been analyzed, added Xanthos. Pricing for Splunk Observability Cloud is based on the number of hosts employed rather than the amount of data collected.

    The Splunk Observability Cloud unifies a Splunk analytics portfolio by including capabilities provided via Splunk Log Observer, Splunk Real User Monitoring (RUM), Splunk Synthetic Monitoring, Splunk Infrastructure Monitoring, Splunk APM and Splunk On-Call. Splunk Synthetics Monitoring is based on technology Splunk gained with the acquisition of Rigor last year.

    Splunk

    The Splunk Observability Cloud is one of the first such platforms to rely solely on OpenTelemetry agent software being developed under the auspices of the Cloud Native Computing Foundation (CNCF) to collect data. That project not only reduces the cost of instrumenting applications, it also reduces the number of agents an IT team might have to deploy to collect metrics, traces and log data.

    Many rival observability platforms can collect data from OpenTelemetry agent software, but also tend to encourage DevOps teams to deploy proprietary agent software that they claim is easier to install and collects data at a more granular level. Splunk has decided OpenTelemetry has matured to the point where those proprietary agents are no longer required, said Xanthos.

    The rise of observability platforms presents an opportunity for IT teams to rationalize a raft of monitoring tools that often surface conflicting analyses. IT teams today spend an inordinate amount of time convening so-called “war room” meetings to determine the actual source of an issue. Those meetings can go on for hours, only to eventually discover an issue that only takes a few minutes to fix.

    While observability has always been a core DevOps principle, the level of visibility most IT teams have into their application environments is limited. There is no shortage of monitoring tools, but because there is no unified approach to observing an IT environment, there simply isn’t enough context being provided. As IT environments become more complex – thanks primarily to the rise of microservices-based applications that have lots of dependencies – that lack of context is rapidly becoming a major issue. A microservices-based application is designed to degrade gracefully if one microservice suddenly become unavailable. The issue is that it can take a very long time to discover the root cause of performance degradation.

    It may be a while before most IT teams achieve true observability, but once they do, many will wonder how they previously managed IT without it.

  • Kong Integrates Service Mesh with OPA

    Kong Integrates Service Mesh with OPA

    Kong, Inc. today announced an update to Kong Mesh, built on top of open source Kuma service mesh, that adds support for Open Policy Agent (OPA) software that enables DevOps teams to manage compliance as code.

    Kuma and OPA are both being developed under the auspices of the Cloud Native Computing Foundation (CNCF). Kuma, unlike other service mesh offerings, provides connectivity across both microservices-based applications running on Kubernetes platform and monolithic applications deployed on virtual machines.

    In addition to adding support for OPA, the 1.2 release of Kong Mesh adds authentication mechanisms between the global and remote control planes operating across multiple zones. That functionality extends the Kuma Discovery Service (KDS) to support multiple authentication mechanisms.

    Finally, Kong has added support for the federal information processing standard (FIPS).

    Like the Istio service mesh, advanced by Google and IBM for Kubernetes environments, Kuma is based on open source Envoy proxy software. In contrast, however, Kuma is both lighter-weight and designed to span both cloud-native and legacy application environments.

    Marco Palladino, CTO at Kong, said OPA support will be a significant advance for both classes of workloads as organizations start to employ Kuma within the context of zero-trust computing environments. As DevSecOps processes are extended to include managing compliance as code, OPA will provide a programmable mechanism for ensuring that policies are not only properly implemented, but can also be easily audited, Palladino said.

    In general, an effort led by Kong, VMware and others to elevate the service mesh conversations to more broadly address application connectivity is underway. A service mesh, at its core, provides the means for integrating hundreds of application programming interfaces (APIs) at scale. It also provides a level of abstraction above the network layer that makes it easier to connect applications across a heterogeneous networking environment.

    Kong is making a case for a lighter-weight approach that spans multiple platforms and is highly extensible. As such, third-party vendors and IT teams can add extensions to Kuma as they see fit.

    Ultimately, Palladino said, the time has come to take cloud computing to the next level. If all organizations wind up doing is lifting and shifting monolithic applications to public clouds, an opportunity to advance the state of IT will have been lost.

    Of course, it’s still early days as far as adoption of service meshes are concerned. Most organizations today are relying on API gateways, proxy software or ingress controllers to manage APIs. It’s not clear to what degree a service mesh may remove the need for some of that existing application connectivity middleware.

    Regardless of which approach is ultimately favored, it’s apparent that, as microservices-based applications become more widely deployed, a different approach to application connectivity will be required. Monolithic applications, however, are not going away. In some cases, a monolithic application might be carved up into a smaller set of microservices, but it’s unlikely that every existing monolithic application will lend itself to that architecture any time soon.

  • CNCF Graduates Open Policy Agent Project to Manage Compliance as Code

    CNCF Graduates Open Policy Agent Project to Manage Compliance as Code

    The Cloud Native Computing Foundation (CNCF) announced this week that the Open Policy Agent (OPA) project, which many IT teams are employing to manage compliance as code, has officially graduated.

    Torin Sandall, co-founder of the OPA project and vice president of open source at Styra, whose compliance management platform is based on OPA, said formal recognition of OPA alongside other CNCF projects, such as Kubernetes, should help further adoption of the open source project that first took shape in 2016.

    Now being advanced under the auspices of the CNCF, the open source agent created by the OPA project is increasingly being incorporated into a wider range of compliance and security platforms. At the same time, more developers are starting to manage compliance as code across a wider range of applications. The ultimate goal is to make it easier to meet compliance requirements using a declarative framework so that responsibility for implementing compliance policies shifts further left toward developers.

    OPA uses a general purpose engine for enforcing policies that uses a set of rules that developers embed within applications using the Rego language. OPA has gained traction among cloud native application developers because it provides a means to enforce policies across a wide range of microservices.

    Sandall said going forward, the primary focus of the OPA project should be to develop and share as many integrations as possible. There are many instances where a use case for OPA has been created, but development teams simply don’t know that use case exists. As a result, many IT teams are attempting to employ compliance as code to address an issue that others have already solved, Sandall said.

    During its time as an incubation project managed by the CNCF, the security special interest group (SIG) within the CNCF conducted two external OPA security audits. The OPA project has also defined a security vulnerability disclosure process and a security response team.

    It’s not clear whether chief compliance officers within enterprise IT organizations have developed an appreciation for OPA. In theory, many compliance issues could be avoided if organizations mandated using OPA – or another approach to managing compliance as code – within their applications. Those compliance issues, of course, are multiplying as the number of compliance mandates expand globally. The challenge is that most compliance teams don’t have much visibility into the application development process.

    In the meantime, as DevSecOps processes continue to mature, it seems almost inevitable they would expand to include compliance mandates, most of which only exist to ensure some base level of security is present. Of course, developers may not want to be responsible for compliance mandates. However, the sooner compliance issues are addressed in the development process, the less likely they are to become DevOps’ problem when deployed in a production environment.

  • The Value of OpenTelemetry in Observability

    The Value of OpenTelemetry in Observability

    As infrastructure becomes more complex, the quest for better observability continues. With increased containerization, third-party applications and generally increased network complexity, it becomes difficult for organizations to track issues of stability and performance. But OpenTelemetry can be used to improve upon observability throughout a network by enhancing and consolidating reporting throughout all applications and services.

    So, what is OpenTelemetry and how can it help your organization’s processes? Here’s what you need to know.

    What is OpenTelemetry?

    OpenTelemetry is a Cloud-Native Computing Foundation (CNCF)-curated open source set of libraries, agents and components designed to increase the visibility of services. Through OpenTelemetry, organizations are able to better collect telemetric data for the purposes of debugging and management. A scalable, flexible solution, OpenTelemetry is able to adjust to organizations as they continue to grow.

    With OpenTelemetry, data is collected through:

    • Metrics
    • Distributed Traces
    • Resource Metadata
    • Logs

    The data is then sent to back-end platforms such as Jaeger or Prometheus for processing. All of this together enhances observability for the organization, making it easier for an organization to collect the data it needs to observe and mitigate issues appropriately.

    Greater levels of observability improve an organization’s reliability and reduce downtime. With better reliability, organizations are able to track down and resolve incidents much faster. Before the OpenTelemetry solution, developers might have used OpenCensus, OpenTracing or other similar products. While these products are excellent on their own, they don’t necessarily meet all the needs of modern networks.

    How Does it Work?

    OpenTelemetry works on three major observability systems: tracing, metrics and logging. For tracing, OpenTelemetry makes it easier to identify failures and performance issues by tracking requests within the system. For metrics, processes running within the system are closely tracked and reported on, with histograms, gauges and other easy-to-read graphical reporting. For logging, application-specific messages can be analyzed.

    Observability throughout a system has always relied upon tracing, metrics and logging. But it’s more difficult to complete tracing today because each action needs to go through so many layers of application and resources. When paired with vague log data, the process of tracking down a single incident can take hours, because the information isn’t always consistently siloed. OpenTelemetry (and other similar products) work to correct this by creating a consolidated system by which metrics, tracing and logging can be brought together.

    As an open source project, OpenTelemetry is available on GitHub for those who want to be a part of the community to influence and improve it. Of course, OpenCensus and OpenTracing are also open source solutions.

    So what’s the difference between OpenTelemetry, OpenCensus and OpenTracing? When should one be used over the other? And can they be used together?

    OpenTelemetry vs. OpenCensus

    Let’s take a look at OpenTelemetry versus OpenCensus. Both are used to boost observability, but they are generally mutually exclusive platforms because they each tackle the issue of observability from different angles. OpenCensus provides distributed tracing and time-series metrics from applications via a collection of libraries. Applications need to download a metrics exporter, and which one is used depends on the application microservices involved. OpenCensus will collect trace data, but OpenCensus will also collect time-series metrics. OpenTelemetry is used to connect OpenCensus and OpenTracing, providing the benefits of both. This creates a far more robust observability solution.

    OpenTelemetry vs. OpenTracing

    OpenTelemetry versus OpenTracing is similar to OpenTelemetry versus OpenCensus. OpenTracing also solves the same problems as OpenCensus but is usually mutually exclusive. OpenTracing is a specification for tracing APIs rather than library. Developers are able to either create their own tracer or use the OpenTracing version. OpenTracing is often faster and easier to deploy and use, but may not provide as robust analytics or metrics as OpenCensus. But again, OpenTelemetry makes it possible to use both OpenTracing and OpenCensus at the same time, through its consolidated libraries and support.

    OpenTelemetry is an ideal technology for organizations that want to increase their observability. Through OpenTracing, developers are able to achieve greater levels of visibility throughout the network; track metrics and performance; and react to issues within the organization swiftly and more accurately.

    While in the past developers may have been limited to either OpenTracing or OpenCensus, today developers are able to use OpenTelemetry for both function sets. Even better, since it remains an open source solution, developers are able to contribute to the OpenTelemetry community.

  • Google Exposes Old Wounds in Open Source Community

    Google Exposes Old Wounds in Open Source Community

    Things boiled over a bit last week with the announcement that Google launched the Open Usage Commons (OUC) consortium (see Mike Vizard’s article here). The announcement and subsequent angst it has caused has upset what had been a pretty stable environment that helped open source software become the dominant force in development and IT. While on its face OUC is about trademarks and usage guidelines, but make no mistake: This is about Google (and perhaps others) disagreeing with the management and direction of The Linux Foundation/Cloud Native Computing Foundation (CNCF).

    Hand-in-hand with the OUC, Google also announced it was making changes in the board composition of the Istio project. A new formula based on code contributed by companies, as well as community seats selected by the community of other contributors, would determine who governs the project.

    Together, this represents a clear bifurcation of managing the code of a project and the trademarks/IP of the project. This is not a new concept in open source, but in recent years has been seldom used. In probably the most famous example of this setup, Linus Torvalds controls a company that still owns the Linux mark, which the Linux Foundation manages it for him. It is separate from the Linux project itself, though.

    The concept of the code being open and free while the project owners retaining the IP and trademarks was very much the norm in open source years ago. However, it led to many companies’ reluctance to contribute code to projects for which they had no say in the governance or usage of the marks. One of the benefits of the foundations such as CNCF, Cloud Foundry, Eclipse and others was that under their model, everyone had access to the same code base and mark usage rules. What you did on top of that was up to you. Ironically, this is the same argument we are hearing now regarding the changes to the Istio governing board and the OUC.

    Perusing the Twittersphere on this subject turns up a few other issues that may be at play here:

    • The CNCF and the Linux Foundation, by implication, may be a victim of its own success. The amount of money they have generated and their “marketing” profile seems to have turned some people off.
    • The CNCF/Linux Foundation model of allowing major corporate contributors to, in essence, buy board seats and having just a minority of “at large” seats open to the community favors the big, rich vendors over the rest of the pack.
    • New leadership at Google and Google Cloud are having second thoughts about turning over the fruits of their work to foundations that they eventually lose control over. Recent former Oracle management is being rumored behind this, though that is not confirmed. In this scenario, second doubts about Kubernetes and other Google-donated projects that are now out in the market without a Google edge are causing them to rethink their approach.
    • Companies that rely on these open source projects and historically are decent corporate members, such as IBM, have been caught in the open here as evidenced by their reaction to the Istio affair.

    What I do know is that the loser in all of this will be the community. Open source works best when there are stability and predictability over its future and governance. The broader the base of management and ownership of a project, the more willing corporate contributors are to participate and contribute. I would hate to see us return to the maze of the Cathedral and the Bazaar. I sincerely hope we are not seeing the end of the golden age of open source software.

  • DevOps Deeper Dive: Google Roils Open Source Community

    DevOps Deeper Dive: Google Roils Open Source Community

    Google this week agitated the bulk of the open source community by launching the Open Usage Commons consortium to protect the trademarks of open source projects, starting with the Istio, Angular and Gerrit projects it launched.

    Launched in collaboration with SADA Systems and some independent contributors, the stated goal of the Open Usage Commons is to help open source projects assert and manage their project identity through programs specific to trademark management and conformance testing.

    Istio is a service mesh that runs on top of Kubernetes, while Angular is a web application framework. Gerrit is a code collaboration tool.

    Unlike previous open source projects that Google played a major role in developing such as Kubernetes, Google has yet to contribute these three projects to an open source consortium. That decision has members of the open source community now questioning Google’s commitment to open source software.

    In fact, IBM, which launched the Istio project in collaboration with Google, this week said the Open Usage Commons does not meet the level of open source governance IBM expects. Originally, IBM said the expectation was that Istio would be contributed to the CNCF once it achieved a level of maturity. That contribution would include Istio intellectual property and the trademark. Now IBM is encouraging Google to reconsider its Open Usage Commons approach.

    If Google continues to hold on to the intellectual property rights for open source projects such as Istio, those projects will become little more than a community project that Google exercises control over, said Priyanka Sharma, general manager of the Cloud Native Computing Foundation (CNCF), which oversees the ongoing development of Kubernetes, among other open source projects.

    “It’s not in the spirit of open source,” said Sharma. “I don’t think you can even call it open source.”

    Other open source initiatives will be hesitant to build on top of projects such as Istio if the intellectual property belongs to a single vendor, added Chip Childers, executive director of the Cloud Foundry Foundation (CFF). The trademark is never the main issue, he said.

    “The trademark is only part of the consideration,” said Childers.

    In the case of Istio, the decision to launch Open Usage Commons might also draw more attention to a Service Mesh Interface (SMI) project being advanced under the auspices of the CNCF. That interface promises to make it easier to rip and replace one service mesh for another.

    In the meantime, Google may be trying to maximize its investments in open source projects that until now have tended to benefit rivals more. In terms of consumption of cloud services based on Kubernetes, Google is a distant third at best to Amazon Web Services and Microsoft.

    In general, there are more open source projects than ever. However, some of the entities that launch those projects have complained that cloud service providers simply turn those projects into cloud services in a way that consumes most of the revenue opportunities any open source project might generate.

    Google now appears to be exacerbating those tensions further by trying to retain control over the open source project it leads, while selling services based on other open source software projects. It’s not clear to what degree this rift might drive a wedge between multiple open source factions. Google with this move may just drive more members of the open source community into the arms of AWS and Microsoft. However, for the moment at least, none of the projects covered by the Open Usage Commons trademarks are so critical that they could not be replaced by any one of several alternative projects that are truly open source.

  • CNCF Looks to Increase Open Source Sandbox Projects

    CNCF Looks to Increase Open Source Sandbox Projects

    The Cloud Native Computing Foundation (CNCF) today announced it has simplified the process it employs to enable open source software to become a sandbox project managed under its auspices.

    Priyanka Sharma, general manager for the CNCF, said the organization is looking to increase the number of open source projects that make up the cloud-native ecosystem. While the CNCF is best known for its efforts to govern the development of Kubernetes, the organization’s mission spans a wide range of cloud-native technologies. Many of those projects are now applicable to both microservices-based and monolithic applications that can be deployed in the cloud or in an on-premises IT environment.

    Key changes to the sandbox process include a simplified submission process using an application that asks the project owners how their project fits as part of the cloud-native ecosystem. Applications are listed in a spreadsheet available publicly for comment, with review by the Technical Oversight Committee (TOC) scheduled on a bi-monthly cadence. The existing Special Interest Group (SIG) recommendation and TOC sponsorship requirements for sandbox projects have been replaced by a simple vote for acceptance by the TOC.

    There are currently 31 sandbox projects being developed under the auspices of the CNCF. The new process for approving sandbox projects has already been applied to 11 of them. Each sandbox project has signed over the rights to the intellectual property for that project to the CNCF, which then attempts to attract more developers to participate in the ongoing effort to increase the adoption of that project.

    In some cases, CNCF projects will compete with one another for acceptance. The CNCF is committed to not becoming a “king maker,” said Sharma.

    Obviously, the CNCF is not the only organization trying to advance the adoption of open source software. In addition to The Linux Foundation, of which the CNCF is a part, there are older organizations such as the OpenStack Foundation and the Eclipse Foundation, which, to varying degrees, compete with one another to become the entity through which open source projects are governed.

    The number of open source projects being launched has increased exponentially in recent years as IT vendors transform their business models. Many now contribute their core software to an open source project in the expectation that increased adoption will lead to demand for commercial support services.

    That shift in many ways has led to a change in terms of how innovative software is brought to market. Not too long ago open source software was viewed primarily as a way to create the free equivalent of an existing operating system or database. Today, the bulk of emerging software in the enterprise starts out as open source projects.

    Much of that transition began when more IT organizations adopted “open source first” approaches to IT in the wake of the economic downturn that began in 2008. As the current downturn brought on by the COVID-19 pandemic deepens, it’s probable the preference for open source software is only going to increase in the months and years ahead.