Why Flux Isn’t Dying after Weaveworks

Image may be NSFW.
Clik here to view.

PARIS — Flux is not dying. The future of Flux as a leading open source GitOps platform for Kubernetes may have been in question among some following Weaveworks ending operations. But for those familiar with the project, there has been little concern about Flux’s future life.

While Flux did lose Weaveworks-employed Flux contributors, most of them continued their work on the project. It continues to have a significant and active contributor and user base, including support and its use by Aenix, Aviator, Microsoft Azure, GitLab, Teracloud and others that the CNCF listed in a blog post during KubeCon.

It can be said that following the massive amounts of investments the community has made in Flux, and how Microsoft, AWS, and others rely on Flux to some extent for their infrastructure, it would be highly unlikely that these organizations would have pulled the plug on their support and use of Flux. It now stands that there has not been a shortage of contributions and maintainers following Weaveworks’ decision to discontinue its support and the enterprise version.

In an email response after KubeCon, Andrew Block, distinguished architect, Global Services Office of Technology at Red Hat, who attended a talk on the subject, said: “I was not only surprised but encouraged as a member of the Open Source and GitOps community to see so many people in attendance in support of the project. The room was packed,” Block said. “If this one session was an indication of the support that the community has for the Flux project, it’s clear that it’s ‘not going to go quietly into the night.’”

However, there does need to be some incentive from organizations making use of Flux “for their mission-critical applications to enable their developers the ability to contribute,” Block said. “With the unfortunate demise of Weaveworks, one of the key stakeholders of Flux no longer has the pool of developers to be able to take advantage of being paid to help move the project forward.”

That said, Block remains confident about Flux’s future, which he also described in a blog post.

“The Flux project will continue — the community and the support from an enterprise perspective are there,” Block said. “It is now just putting together the structures that will enable the project to continue.”

Also, ControlPlane continues to offer support for ControlPlane Enterprise with an enterprise version for organizations seeking to use Flux through a third-party platform provider for integration and continues to offer contributions for the graduated project.

“The Flux project will continue — the community and the support from an enterprise perspective are there,” Block told The New Stack in an email message. “It is now just putting together the structures that will enable the project to continue.”

At KubeCon, Stefan Prodan, a Flux maintainer, and Alexis Richardson, co-founder of Weaveworks who first coined the term “GitOps,” provided details about Flux’s status during their talk “Flux and the Wider Ecosystem Planning BoF.”  They discussed its current status, its future and how people can get involved with this popular project for GitOps processed on Kubernetes. Prodan and Richardson also covered how FluxCD and other projects like Flux-IaC with Terraform, are seeing an uptick in maintainers.

The Flux project has grown to “become a major piece of the CNCF platform and “benefits from important integrations,” like OCI and Terraform, Richardson told The New Stack following his talk. “Members of the community have been working together at an impressive rate to transition from the old Weaveworks-led model to a community-led model with multiple vendors playing a role,” Richardson said. “This is proof that the CNCF model is robust in the face of such changes and can only be good news for end users.”

There are currently 600 Flux contributors. Out of those 11 are active maintainers. As Prodan explained, Flux comprises multiple controllers and Go packages, “making it a complex system.” A maintainer is tasked with contributing to a specific component of Flux and voluntarily takes responsibility for overseeing that component. A core maintainer, on the other hand, possesses a comprehensive understanding of Flux as a whole. Their primary role is to assist with contributions, recruit contributors to become maintainers of sub-projects and “ultimately guide them to become core maintainers, thereby maintaining oversight of the entire project,” Prodan said.

The ProjectImage may be NSFW.
Clik here to view.

Flux shares its leading status as a GitOps platform with Argo CD. Both seen as GitOps enablers, they are now considered critical components of cloud native infrastructure, as they join the graduated ranks of Kubernetes itself, Prometheus and Envoy.

Meanwhile, GitOps has emerged as the de facto process for deploying applications to cloud native environments.

According to GitLab, GitOps is “an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation.” It is built on the open source git version control software.

A more precise and consensus-led description of GitOps has been released by OpenGitOps — a GitOps working group under the CNCF App Delivery SIG. It consists of a set of open source standards, best practices and community-focused education to help organizations adopt a structured, standardized approach to implementing GitOps. It describes GitOps Principles as:

1. Declarative: A system managed by GitOps must have its desired state expressed declaratively.
2. Versioned and Immutable: Desired state is stored in a way that enforces immutability, and versioning and retains a complete version history.
3. Pulled Automatically: Software agents automatically pull the desired state declarations from the source.
4. Continuously Reconciled: Software agents continuously observe actual system state and attempt to apply the desired state.

Flux can be used at the main layer that instrumentalizes the functionalities of GitOps as described by its principles. As Prodan explained, Flux works as an “invisible infrastructure in your clusters”  and can be used to build a platform for continuous delivery and internal platforms, Prodan said. “Flux is not designed to be all-encompassing: rather, it serves as a foundational layer upon which you can construct your delivery infrastructure. Flux is highly opinionated, offering various deployment options akin to assembling Lego pieces,” Prodan said. “You can mix and match components to tailor your platform accordingly. ”

You Can Do It

Open source users, in my opinion, should also seek to give back to the community. Contributing to a project out of intellectual interest or because it supports your organization’s work and you can get paid to contribute are worthwhile reasons to get involved. For those who use and work with Flux or are enticed by its potential, there are worse projects to get involved in.

“There’s significant opportunity within the ecosystem to develop complementary tools and services atop Flux. By contributing to the project and providing commercial offerings such as SaaS versions, organizations and individuals can sustain Flux’s development,” Prodan said. “While there are numerous solutions available, it’s essential to recognize that Flux isn’t a finished product on its own.”

Other ways to contribute to the project include purchasing support from ControlPlane, Richardson said. Alternatively, as a vendor offering something different from what ControlPlane offers, it is possible to utilize their products and services and then resell them or integrate them into larger solutions.

Additionally, you may have identified another aspect of the project to focus on; for example, security, policy enforcement, observability, dashboards or fleet management, he said. “There are numerous areas where contributions are valuable, and we’ll showcase various pieces of code that you can work on within these domains.”

In the near future, the Flux project maintainers hope to increase the number of maintainers without “overwhelming them with all the responsibilities at once,” Prodan said. “Currently, we have a large pool of people making contributions but a very small number of maintainers,” he said. “By gradually granting individuals more responsibility, we hope they’ll become more knowledgeable about Flux over time and take on greater roles within the project.”

The post Why Flux Isn’t Dying after Weaveworks appeared first on The New Stack.

While Flux lost Weaveworks-employed Flux contributors, most of them continue their work on the project and it continues to have a significant and active contributor and user base.