The Making of Flux: The Future

Bart (Host): This is the fourth and final episode in our Flux documentary series. Over the past three episodes, we've traced Flux's journey from its origins at Weaveworks to its evolution inside the CNCF to real world adoption by end users like Orange and Nomura. Now, in this closing chapter, we shift our focus from using Flux to building with Flux. Across the industry, platform teams are moving beyond experimentation and embedding Flux as a strategic enabler inside their products and services. What started as a GitOps toolkit has become a foundational technology shaping how enterprises design, deploy, and manage cloud-native platforms. In this episode, you'll hear from Brian Ross, field CTO at GitLab on bridging the gap between CI/CD and infrastructure. You'll hear from Jane Yan, principal program manager at Microsoft on delivering Flux as a managed service in Azure Arc. Sean O'Meara, CTO at Mirantis, shares their vision for multi-cluster platform engineering. And last, but certainly not least, William Rizzo, strategy lead in the CTO office at Mirantis, explains why they chose Flux as the backbone of their platform. Together, these perspectives reveal how GitOps is not only solving today's complexity, but also laying the groundwork for tomorrow's innovation. Let's begin with Brian Ross from GitLab, who walks us through the core challenges enterprise DevOps teams face today. Brian Ross (Field CTO, GitLab): I think first and foremost in DevOps, we're going through that bit of a transformation from DevOps to platform engineering. I'm going to throw all those together into one bucket. I think there's three challenges I see day in and day out. Number one is scale and complexity. And I think we found that with DevOps in particular, as we grow this in large organizations, it gets harder and harder for development teams, first of all, to be aware of all the good work that's happening throughout an organization, but it gets harder for operations teams and harder for security teams to keep up with the level of change that's happening. The pressure is always to keep moving forwards, but to do so safely. And that brings us to number two, which is security. How do we go about moving quickly without breaking things? I know we hear that from Silicon Valley a lot that we should be moving fast and breaking things, but in banks and highly regulated environments where I'm working with, the skill really isn't how fast can we go. And the way I like to think about security is that it's like the brakes on a car. I like to drive fast, but I don't think I'd be so brave if I didn't have a foot pedal that was going to work when I push it and the car slows down. I think security is the same way. It needs to be baked in. So, how do we go about shifting left, giving developers the tools to build security into applications on day one? And again, doing that in a way that we're still meeting all of our regulatory requirements in those regulated environments. And then number three, it's very dull, but it's governance and compliance. In large organizations, when you're doing anything at scale, being able to prove that what you're doing is working and all of the checks and balances are being met is a job in itself. So how do we go about reducing that regular burden day in, day out so we can get on with the stuff that we really enjoy which is making new features and handing them back to customers. Bart (Host): Those challenges Brian describes set the stage perfectly. But how do we actually address them? Brian continues by explaining GitLab's approach and where Flux fits into their ecosystem. Brian Ross (Field CTO, GitLab): I think the most basic thing is that GitLab does a phenomenal job at helping software developers build in best practice into their daily lives. And for me, GitOps is just a framework that allows us to take all those DevOps best practices and the tooling and all the lessons from the last decade and use them for infrastructure automation. So I think that's the big step for me is that Flux allows us to have a solution for operators so they can manage large bodies of Kubernetes environments using all the same tricks and all the same ways that we would in modern software development. And again from a GitLab perspective, the nice thing is if you've already made that investment, then you can use all those same tools in the exact same way. It was before my time when we made the commitment to Flux. I think it was 2023 that we mentioned that we're going to integrate directly with Flux. And as you mentioned, GitLab's compatible with basically any CD solution. The entire point of the platform is that you should be able to bring your own tools and integrate them in. But for Flux particularly, we integrate with that for a couple of really simple reasons. Number one, it was a mature solution. Flux has been around for a long time. It's well supported. And I think one of the biggest considerations is that Flux almost follows the Unix philosophy, which is it does one job very well. Whereas a lot of other solutions have grown and sprawled into various different parts, Flux continues to be a fairly small and very secure footprint. And of course for us that's ideal when we're working with customers that are in highly regulated environments because they've got huge interest in trying to keep that footprint as small as possible. And Flux particularly just lended itself very well to integration whereas some other solutions that are perhaps not following all Kubernetes APIs are a little bit harder from our perspective. But above all else, I think the big thing is that Flux already had huge support from those highly regulated environments where security is of huge importance. So financial services, telco already has a strong following for customers. Bart (Host): GitLab's experience with Flux in regulated environments resonates across the industry. Microsoft has taken this even further by offering Flux as a managed service. Jane Yan explains their approach. Jane Yan (Principal Program Manager, Microsoft): In hybrid and multi-cloud environments, GitOps plays a crucial role in providing a consistent and unified way to manage applications and infrastructure across different platforms. By using Git as a source of truth, organizations can ensure that the deployments are consistent, reproducible and auditable regardless of where they are running. And this is particularly important in environments that span multi-cloud and on-prem data centers. This also aligns with the Azure adaptive cloud approach which is aimed to unify distributed sites and sprawling systems across hybrid, multi-cloud and edge and IoT environments. Azure Arc is the key technology behind our adaptive cloud approach. It extends the Azure management and service to any infrastructure including on-premise and multi-cloud and edge environments. It provides a centralized unified way to manage our entire environment allowing you to manage, govern, and secure your VMs, Kubernetes and other cloud resources. Azure Arc supports GitOps practices by enabling configuration management and application deployment using Git. Cluster administrators can declare their cluster configuration and applications in Git and development teams can use the familiar tools like existing DevOps pipelines to deploy applications onto Azure Kubernetes, we call it AKS, as well as Arc-enabled Kubernetes clusters that run in customer data centers. This ensures that the changes to the applications and configurations are versioned, enforced and logged across a number of clusters providing a consistent and unified approach to manage hybrid and multi-cloud environments. There are several factors influencing this decision. First and foremost, we always start with the customer demand. We were asked to provide a solution to manage large-scale cluster environments. Flux was chosen for its flexibility and ability to handle complex deployments across multiple clusters and repositories. And now we're seeing customer demand for Argo CD. So we're releasing the private preview of it. Second, Azure Arc aims to provide a unified management experience for compute resources including Kubernetes clusters and VMs. Flux's capabilities align very well with this goal, enabling consistent management. Offering Flux as a managed service aims to simplify the GitOps tool chain, making deployment, updates, and configuration of Flux easier from Azure. Managed Flux integrates with Azure built-in controls like RBAC policies and Azure resource graph and so on, enhancing and simplifying this user experience. Bart (Host): Microsoft's managed service approach abstracts away complexity. But what does this actually mean for teams on the ground? Jane elaborates on the concrete benefits. Jane Yan (Principal Program Manager, Microsoft): By offering Flux as a managed service, we aim to simplify this GitOps tool chain making it more accessible and efficient for developers and the platform teams. This abstraction of complexity unlocks several key benefits. So I'll name a few. First, ease of deployment and management. You can think of managed Flux as streamlining the deployment, update and configuration process allowing teams to focus on the core development tasks. And then there is the enhancement in integration with Azure services. Flux integrates seamlessly with Azure built-in controls like RBAC policies, resource graph and so on. This integration helps our customers to leverage these controls to maintain governance and security without additional overhead. And then there's the scalability and flexibility. With managed Flux, teams can easily scale their applications across multiple clusters and environments. This flexibility is crucial for organizations looking to expand their operations quickly and efficiently. And last, improved user experience. The managed service provides a better user experience by leveraging Azure services like Azure Copilot for application deployment scenarios. This ensures the developers have the tools they need to deploy and manage applications effectively. So by abstracting the complexity of the GitOps chain, managed Flux empowers developers and platform teams to scale their applications quickly without compromising the control or security. This approach aligns very well with Microsoft's goal of providing a unified and efficient management experience for hybrid and multi-cloud environments. We actually talked about application deployment and management a lot. Customers are using Flux to deploy their applications on the Azure Kubernetes clusters as well as Arc-enabled clusters. This helps them to manage application rollouts following the GitOps principles ensuring the consistency and ease of management. And then we continue to make investment in the managed Flux area. For example, recently we added workload identity support and customers can now use it for repository authentication. This enhances security and simplifies the authentication process for deploying applications. And then there's the edge computing. Developers building applications we've seen the pattern where they build it in Azure but they need to deploy it in the edge environment. So using this managed Flux they can create the consistency in deployment and ease the management of application rollouts in these different environments and this is particularly useful for scenarios where the data needs to be deployed and processed at the edge. So the developers are leveraging the cloud to build that application and then deploy it to these edge environments closer to the data. And of course there's always the hybrid cloud management. It's always true for customers who want to deploy applications in multi-cloud environments. Azure Arc provides this unified management experience. It helps the customers to manage this complex environment reducing the operational overhead and ensuring the consistency of governance and compliance. So these use cases demonstrate the versatility and effectiveness of GitOps practices in Azure Arc and managed Flux in these various environments helping customers scale their operations while maintaining the control and security. Bart (Host): While Microsoft focuses on managed services, Mirantis is taking a platform engineering approach with Cordant. Sean O'Meara, their CTO, explains their vision. Sean O'Meara (CTO, Mirantis): Mirantis has been around for a long time very focused on the infrastructure space. We started in the OpenStack world and made the transition to Kubernetes. What we're seeing customers asking for today is stable large scale Kubernetes deployments with a heavy shift towards multi-cloud and multi-cluster Kubernetes, primarily focused on running large scale workloads. We have a lot of financial services customers and we're moving heavily into supporting customers in the AI and GPU as a service space. Flux has been a key part of one of our core products called Cordant. Amongst other things, we leverage Flux's capability to pull and handle Helm charts and other artifacts within Kubernetes as part of our multi-cluster offering. Flux is also a key part of how we're looking at the future of application management, application deployment for large scale multi-cluster environments and helping customers take control of the management of the complexity of Kubernetes applications and that service layer that sits between the Kubernetes and the applications running on top of Kubernetes itself. The vision for Cordant is a multi-cluster manager that handles services and observability providing a ubiquitous Kubernetes layer to abstract infrastructure across all infrastructure environments from bare metal all the way up to public cloud solutions, catering for large scale organizations providing them easy access to resources regardless of where those resources are available. Then we want to handle all the services that make Kubernetes actually useful. I often use the term that Kubernetes itself is just a glorified scheduler. That scheduler runs everywhere, is available everywhere, supports a broad range of different systems and application environments. So once we make it useful we have to layer on services. Those services are things like ingress controllers, CSIs, CNIs before we even think about deploying an application. The vision for Cordant is to make all of that easy. Make all of that declarative, put that into an environment where we can quickly see what we have and control and govern those environments. Where Flux fits into that ecosystem is because Cordant is based around the Kubernetes ecosystem. It leverages Kubernetes CRDs as the declarative model to use the cluster API and then a number of layered on components around that. Flux can be your declarative Git-based solution for delivering those CRD objects defining your environment and interacting with applications so that we can actually build infrastructure on demand for applications. Bart (Host): Sean frames Cordant beautifully but what drove the specific decision to integrate Flux? William Rizzo provides that perspective. William Rizzo (Strategy Lead-CTO Office, Mirantis): Flux came a long way from what it was, from the way it was taught being a developer only tool for deployment and governance of workloads. Now we see it as a CNCF graduated project where organizations that are using it can rely on that, on the ecosystem around Flux and the idea of governance behind a large organization made Flux this backbone for organizations seeking trustworthiness of the project and an assurance that the project has longevity for years to come. This goes back to what I said already. We didn't want to create something ad hoc. Cordant, the idea of Cordant is this platform control plane managing everything from the infrastructure to the developer portals or to the upper layer of the platform. So for this we needed something that was this engine reconciling and making sure that the configuration across the state was made unified and subject to governance themes. The decision was not to create something ad hoc as well. Organizations that we interviewed asked us not to create something ad hoc for Cordant but to leverage existing technologies and Flux checked all the boxes: graduated project, open source, a very large community around it. The idea that we can package everything and not be tied to Mirantis Cordant but just use Flux as a tool for this estate management was very appealing and that was an obvious decision. Bart (Host): The trust and governance William mentions are especially critical in regulated environments. He continues with how Flux enhances security and compliance. William Rizzo (Strategy Lead-CTO Office, Mirantis): As we said, Flux makes Git the source of truth for all changes. This is very important in an environment subject to compliance. Flux turns your Git repo into an auditable trail of configuration satisfying many change management controls by default. We also integrate policy enforcements with tools like Kyverno in our Mirantis Kubernetes environment. We leverage this to ensure security and compliance rules are enforced automatically and we build templates or what we call blueprints for guard rails that are applied through with GitOps. Regulated environments love this type of approach where they receive some blueprints from us and we can fine-tune with Flux what they need. And mind you, they might already know Flux or they might already be adopting it. So for them it's not a new item that they have to introduce but they can programmatically and explicitly define what they need on top of those blueprints. Bart (Host): Security, compliance, and governance are table stakes today, but what about tomorrow? Brian Ross shares his vision for how AI will transform GitOps workflows. Brian Ross (Field CTO, GitLab): Well, we couldn't get through anything without talking about AI. Look, I think without doubt AI is going to change things, but I think the most interesting thing that's happened this year is that we're no longer talking about if and when. It's now happening. For GitLab specifically, we've been working on GitLab Duo for quite some time and we've got customers getting real-world value. They are saving thousands of hours of developer time on the toil, the cognitive load of what's involved in developing software. And I don't think that automating infrastructure is any different. I think we've got a number of areas where there are boilerplate text that we need to reproduce. There are errors that can sneak into text files very simply. We want to manage them using the same best practices that we use for software. And that means that we want to use the same tooling as well. So I think right now you could get a lot of benefit from using something like GitLab Duo. That would be asking Duo to help create manifests. That might be helping to summarize long comment threads between developers or security people around the changes that they're making. It might be about helping to review a change that you're about to make or explaining the changes that have happened in one environment or one point in time versus another. So, I think already there's things that AI can help us with right now, right here. I'm very excited to see what's going to happen this year though because we're not just talking about LLMs anymore. We're now talking about Agentic AI and the world of MCP where all of a sudden AI becomes less of an assistant and more of a team player. And I'm really interested to see what happens when we can mix robots with humans effectively. So we're able to give AI a larger, woolier, high-level view of what we want to achieve and let it do the work. And I think there's lots of concerns that come with that. How do we do that safely and securely in a morally ethical way? The thing for me that I'm most interested in is that a lot of the work we do isn't using all of our brains. I think that when we think about developing software there is an element of it which is obviously you are writing the code. It's how you achieve the thing that you're trying to achieve. But I think the art of software is knowing what it is you want to achieve first. It's taking the requirements and transferring them into a language that the computer can understand. But I think it's doing that and architecting a way that makes a lot of sense. And so the thing that excites me the most from an AI and thinking about infrastructure management perspective is maybe we can spend a little bit less time writing YAML files and a little more time thinking about the architecture, thinking about scalability, thinking about translating requirements into what we want. So it's more about what it is we want to do and less about how we're actually going to achieve it. And I think perhaps the missing link that I see just now and I'm hoping this comes this year is around interface. AI just now has been largely around chat. We type commands in and it gives us some answers back. I think that's pretty inefficient. So I'm interested to see what happens next in terms of how we interface with AI and how we make that a little less annoying. I don't think any of us enjoy that type of exchange. I think there's probably better ways of getting AI to help than have to ask it lots of questions and do an interview style. Bart (Host): Brian's enthusiasm for AI's potential is infectious, but he also touches on an important human element. Let's hear his thoughts on what makes this work truly rewarding. Brian Ross (Field CTO, GitLab): And that's the art form. I think that's the question that we're all trying to get to. We can build fantastical technology platforms that are observably better in terms of security or performance, but how do we encourage people that are very busy with their own lives to take time to migrate to our platform? And we need to bear in mind that there is a migration, there's effort required from them. So for me, I think there's two approaches. There's a little bit of carrot and a little bit of stick. And I think it's to balance those two off. So number one is that from a stick perspective, we have rules that we have to follow from a company perspective. So being able to demonstrate that if you're not doing those things, then something bad is going to happen. Either you're not going to be able to get to production or there's going to be some kind of procedure that's followed. But the way I like to look at these things is that it should be a feature. Security is a feature of an application and it's a very important one. Two-factor authentication on my banking app might be a little bit annoying from time to time, but I wouldn't use my banking app unless it had two-factor authentication. And I think for developers, what we need to be able to do is describe that if they're able to use our centralized platform that has all these things baked in, they've got less work to do. They've got less work to do in terms of compliance, in terms of audit, in terms of the red tape that's going to slow them down at the end of the process. Generally speaking, the developers I speak to, they want to do a good job. They want to build safe, secure code, but often they don't have the tools provided to them early enough in the process. And so we wait until the very end when deadlines are pressing, marketing materials have already gone out and this app has to be launched now and there's no time to make any changes and that's when we say but there's this critical problem. If we can give them tools really early on in the process that they can do themselves in a self-service way, they're much more likely to adopt that and make it part of the process. And that can be testing for quality in terms of function, that can be testing for security vulnerabilities and just generally giving them the support they need. Bart (Host): Over the course of this series, we've seen Flux evolve from an experiment at Weaveworks into a graduated CNCF project that powers some of the world's most demanding platforms. We heard from maintainers who built the foundation, enterprises like Orange and Nomura who proved its value in production, and now from industry leaders who are embedding Flux into their products and services. One message stands out: Flux is more than just a GitOps tool. It's become the backbone of modern cloud-native delivery. Trusted, battle tested, and built to last. As this series comes to a close, the story of Flux is far from over. The convergence around GitOps principles isn't just solving today's challenges. It's enabling the next generation of innovation. Thank you for joining us on this journey through Flux CD.