CNCF user community recommend Flux and Helm
Weave Flux, a project developed by us and later donated to the CNCF is one of two tools placed in the Adopt category in the CNCF’s newly rolled out Technology Radar. Read about the process and results of the Technology Radar and our CTO, Cornelia Davis’ reflections on what this all means.
CNCF technology radar adds Flux and Helm projects to the adopt category
Weaveworks is thrilled to announce that Weave Flux, a project we spearheaded, developed and later donated to the CNCF is one of two tools placed in the “Adopt” category in the new CNCF Technology Radar.
“We have heard from so many people about how Flux and GitOps have massively improved the consistency, repeatability and security of their operations and continuous delivery. So it was amazing to see this positive sentiment reflected in the CNCF’s first Tech Radar. It reaffirms our decision to make Flux, the piece of software that enables GitOps and CD, into a key component in the underlying architecture for our commercial products, Weave Kubernetes Platform and Weave Cloud.” - Alexis Richardson, Co-founder and CEO of Weaveworks.
A new initiative from the CNCF End User Community, under the guidance of Cheryl Hung (@oicheryl) Director of Ecosystem for the CNCF, the Technology Radar is an opinionated guide to the tools and technologies that are in active use by these community members. It ultimately makes recommendations on those that are deemed mature and valuable enough to be used in production.
How does the CNCF technology radar work?
The CNCF End User Community consists of individuals from more than 140 companies ranging from small startups to large enterprises. This group meets several times per month to support each other through the exchange of information and experiences. The Technology Radar is a way to consolidate some of those recommendations for broader consumption.
Inspired by the TechRadar created and popularized by Thoughtworks, and adopted by dozens of companies including Zalando, AOE, Porsche, Spotify and Intuit, the process and outcome of the CNCF initiative is slightly different.
Every quarter, the End User Community chooses a theme from the cloud native landscape and surveys its members, asking them to share their assessment of the tools relevant to that theme. The tools needn’t be part of the CNCF, nor must they be open source - all technologies that are relatively well known are included - write-ins are also allowed. For each of the tools, users are asked to assign one of Adopt, Trial, Assess or Hold. Per the blog announcing the results of the inaugural Technology Radar, these levels are defined as follows:
• Adopt: We can clearly recommend this technology. We have used it for long periods of time in many teams, and it has proven to be stable and useful.
• Trial: We have used it with success and recommend you take a closer look at the technology.
• Assess: We have tried it out, and we find it promising. We recommend having a look at these items when you face a specific need for the technology in your project.
• Hold: This category is a bit special. Unlike the other categories, we recommend you hold on using something. That does not mean that these technologies are bad, and it often might be OK to use them in existing projects. But technologies are moved to this category if we think we shouldn’t use them because we see better options or alternatives now.
While the final report only categorizes each technology into one of Adopt, Trial and Assess, including Hold as one of the choices in the survey aids in synthesizing the results.
What are the results?
In this first CNCF Technology Radar on continuous delivery, the results of the survey placed FluxCD, as well as Helm, in Adopt, indicating a significant level of adoption and success with these technologies.
CicleCI, Kustomize and GitLab were placed in the Trial ring.
JenkinsX, TravisCI, jsonnet, Spinnaker, GitHub Actions, ArgoCD, Jenkins, Tekton CD, and TeamCity were placed into the Assess ring.
Reading between the lines
On the one hand, it would be easy at this point to take a victory lap, pat ourselves on the back here at Weaveworks for having created and nurtured one of the two technologies to make it into the “Adopt” category. But I feel strongly that we are still in the early stages of modernizing operations for the cloud, so I want to understand more deeply why users chose Flux as one of their favorites. These signals can help direct our efforts as we expand and enhance what we’ve only just begun with Flux.
While I haven’t spoken with any of the users who participated in the survey directly, I have spoken with many users over the last half year. Over that same time I’ve also spent a great deal of time analyzing the domain covered by GitOps. That experience, taken together with the other technologies that are on the tech radar in the “Trial” and “Assess” categories, I have two hypotheses.
#1 CI and CD - one word or two?
First, I believe that part of what this report reflects is that until relatively recently, CICD was often used as a single word. Tools and practices of continuous integration (CI) are quite mature - according to Wikipedia, Grady Booch first used the term “CI” nearly 30 years ago. But recall that CI was born in an era when the state of the art software engineering practices were centered around the waterfall methodology where we deployed code into production on the order of months, if not years.
As the industry began moving toward more frequent deployments, often executed by the developers who had been using the CI process for years, it was easy to simply make continuous delivery (CD) the last step in the CI process - just extend existing tools to do a bit more. Hence, we arrived at CICD - using it as a single word exposes the history and a bias toward one way of solving the problem.
Looking at the tech radar we see several tools that seem to have followed exactly this trajectory - CircleCI, Travis CI and Jenkins were all created in 2011, all with a focus on CI. Only later did they extend those tools to also handle delivery. My first hypothesis is that Flux stands as a leader because it does not come from that legacy - my colleagues created the tool thinking about delivery as something quite independent from, albeit related to CI.
#2 Cloud-native tools for cloud-native development patterns
The second thing I believe this report suggests is that there is a growing preference for technologies that are cloud-native - that is, they were born when the industry had reached a certain level of maturity and understanding around cloud native patterns and practices. Distributed systems have gone from being something rather niche several decades ago to being the norm. We have come to understand that through redundancy - multiple app instances, request retries, replicated data, etc. - we can create systems that are more resilient than the infrastructure they run on. We now see eventual consistency and reconciliation as key patterns for the cloud, something that Kubernetes didn’t invent but certainly played a major role in making it nearly ubiquitous.
Both of the technologies that are in the “Adopt” category, Flux and Helm, embrace these cloud-native paradigms. They operate off of declarative configurations. The engines that implement their capabilities are delivered as reconciling agents. Those implementations are designed so that they can be deployed in highly available configurations.
I fully expect that Kustomize, another cloud-native tool that is in the “Trial” category now, will quickly make it into the center of the target. My second hypothesis is that Flux stands as a leader because it is cloud-native. Continuous delivery sits at the start of the cloud-native operational model that is GitOps, and hence it must itself be cloud-native.
Final thoughts
We’re very pleased to have been included with Helm as one of the two projects in the “Adopt” category for the first CNCF Technology Radar. Flux, a key element of GitOps, is and always has been a cloud native-first tool built for teams developing distributed applications on Kubernetes.
If you need help getting started with cloud native and GitOps but you’re not sure how to navigate your organization to success, the Weaveworks team is here to help. Whether you’re using Kubernetes in the cloud or behind the firewall, your team requires battle-tested architectures, workflows and skills to operate and manage Kubernetes reliably. The underlying architecture of Weave Kubernetes Platform is based entirely on GitOps best practices, reducing complexity of configuration management for complete Kubernetes platforms.
