The Making of Flux: The Future, a KubeFM Original Series

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 that we've worked 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 GitHub toolkit has become a foundational technology shaping how enterprises design, deploy, and manage cloud-baitive platforms. In this episode, you'll hear from Brian Ross, field CTO at GitLab, on bridging the gap between CACD and infrastructure. You'll hear from Jane Young, principal program manager Microsoft, on delivering Flux is a managed service in Azure Arc. Sean Nomura, CTO at Marantis, shares their vision for multi-cluster platform engineering. And last but certainly not least, William Ritsam, strategy lead in the CTO office at Marantis, explains why we chose Flux is the backbone of their platform. Together, these perspectives reveal how GitHub's 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. - So I think first and foremost in DevOps, we're going through that bit of a transformation from DevOps to platform engineering. So I'm gonna, you know, might upset some people, but I'll throw all those together into one bucket. I think there's three challenges I see day in and day out. Number one is scale in 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 changes happening. So of course, the pressure was always to keep moving forwards, but to do so safely. And that brings us to number two, which is security. So 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 that we're I'm working with, that the scale really isn't how fast we go. And the way I like to think about security is that it's like the breaks in a car, like 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 pushed that the car slows down, right? And 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, in those regulated environments. And then number three, it's very dull, but it's governance and compliance. In large organizations, again, 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? Those challenges Brian described 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. 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 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 in using all the same tricks and all the same ways that we would in a 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 2003 that we mentioned that we're good to integrate directly with flux. And as you mentioned, GitLab's compatible with basically any CD solution, the entire point of a 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 unique 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 a 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, as I say, those highly-regulated environments were securities of huge importance. So financial services, telco, already has strong following for customers. 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 Yam explains their approach. In hybrid and multi-cloud environment, the GitLab plays a crucial role in providing a consistent and unified way to manage applications and infrastructure across different platforms. By using Git as the source of truth, organizations can ensure that the deployment are consistent, reproducible, and audible. In regardless of where they are running, and this particularly important environment has been multi-cloud and on-prem status centers. This also aligns with the Azure Adaptive Cloud approach, which is aimed to unify distributed site 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, secure your VMs, Kubernetes, and other cloud resources. Azure ARC supports GitLab's practices by enabling configuration management and application deployment using Git. Cluster administrators can declare their cluster configuration and applications in Git, and development team can use the familiar tools like existing DevOps pipeline to deploy applications onto Azure Kubernetes, we call it AKS, as well as ARC enabled Kubernetes clusters that's runs in the 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 environment. Flux was chosen for its flexibility and ability to handle complex deployment across multiple clusters and repositories. And now we're seeing customer demand for RLCD, 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, flux capabilities aligns very well with this goal, enabling consistent management, offering flux as a managed service aim to simplifying the GitOps 2 Chain, making deployment to update configuration of flux easier from Azure. Managed flux integrates with Azure building controls like RBAC, policies, and Azure resource graph, and so on, enhancing and simplifying this user experience. >> Microsoft managed service approach abstracts away complexity. But what does this actually mean for teams on the ground? Jane elaborates on the concrete benefits. >> By offering flux as a managed service, we aim to simplify this GitOps 2 Chain, making it more accessible and efficient for developers and the platform teams. This abstraction of complexity unlocks several key benefit. So our name of the first ease of deployment and management. So you can think of managed flux streamlines the deployments, update, and configuration process, allowing teams to focus on the core development tasks. And then there is the enhancement in integration with Azure services. So flux integrates seamlessly with Azure built in controls like RBAC, policies, resource graph, and so on. And this integration helps our customers to leverage these controls to maintain governance and security without additional overhead. And then there is the scalability and flexibility. So with managed flux, teams can easily scale their applications across multiple clusters in environment. This flexibility is crucial to organizations looking to expand the operations quickly and efficiently. And last, improved user experience. The managed service provides a better user experience by leveraging Azure services like Azure Co-Pilot for applications 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 2 Chain, managed flux empowers developers and platform teams to scale their applications quickly without compromising the control of security. This approach aligns very well with Microsoft Goal of providing a unified and efficient management experience for hybrid and multi-cloud environments. So we actually talked about application deployment and management a lot, right? So customer using flux to deploy their applications on the Azure Kubernetes clusters as well as arch-enabled clusters. This helps them to manage applications roll out 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 the security and simplifies the authentication process for deploying the applications. And then there's the edge computing. Developers building applications. We see in the pattern where they build it in Azure, but they need to deploy it in the edge environment. So using those managed flux, they can create a consistency in deployment and ease the management applications roll out in these different environments. And this particularly is useful for scenarios where the data need to be deployed and processed at the edge. So the developers leveraging the cloud to build that application and then deploy to these edge environment closer to the data. And of course there's always the hybrid cloud management. Always true for customers want to deploy applications in multi cloud environment. And so Azure Arc provides this unified management experience. It helps the customers manage this complex environment, reducing the operational overhead and ensuring the consistency of governance and compliance. So these use cases demonstrate the versatility of an effectiveness of get off the practice in Azure Arc and manage flux in these various environments, helping customers scale their operations while maintaining the control and security. Well, Microsoft focuses on managed services. Marantus is taking a platform engineering approach with Cordit. Shauna Vera, their CTO, explains their vision. >> So Marantus has been around for a long time. Very, very focused on the infrastructure space. We started in the open stack world and made the transition to Kubernetes. What we're seeing customers ask before 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 removing heavily in terms of supporting customers in the AI and GPUs of service space. >> How do you see flux aligning with Marantus' tech roadmap? And what strategic business objectives will that unlock? >> So flux has been a key part of one of our four products called Cordit. Amongst other things, we leverage fluxes capability to pull and handle home charts and other artifacts within Kubernetes as part of our multi cluster offerings. Flux is also a key part of how we were looking at the future of application management application deployment for large scale multi cluster environments and helping customers take control of the management of complexity of Kubernetes applications. And that service layer that sits between the Kubernetes scheduler and the applications running on top of Kubernetes itself. >> Cordit is already making noise in the platform engineering ecosystem. What's the vision and how is that supported by flux? >> The vision for Cordit 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 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, the 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. Vision for Cordit, 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, it puts port into space around the Kubernetes ecosystem with leverage as Kubernetes CRBs 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. >> Sean frames Corden beautifully, but what drove the specific decision to integrate flux? William Ritzel provides that perspective. >> Yes, absolutely, flux came a long way from what it was, from what the way it was thought, being a developer only tool for deployment and governance of workloads. Now, we see there's a CNCF grad where the project, where organizations are using it can rely on that ecosystem around flux and the idea of our governance behind a large organization made flux, this backbone for organizations which you can trustworthiness of the project and assurance that the project has a longevity for years to come. This goes back to what I said already. We didn't want to create, so Corden, the idea of Corden is this platform control plane managing everything from the infrastructure to the developer portal. 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, was unified and subject to governance. The decision was not to create something ad hoc, as well, organizations that we interviewed as does not create something ad hoc for Corden, but to leverage existing technologies and flux checked all the boxes. Graduated project open source, a very large community around it. The idea that the government that we can package everything and not be tied to Miranda's Corden, but just use flux as a tool for this estate management was very appealing, and that was an obvious decision. The trust in governance, William mentions, are especially critical in regulated environments. He continues with how flux enhances security and compliance. As we said, flux becomes the. This makes get the source of truth for all changes. This is a very important in a complex environment subject to compliance. Flux turned your git report into an audible trail of configuration, satisfying many change management controls by default. We also integrate policy enforcement with tools like Kaverno, in our Miarntis Kubernetes environment, we leverage just to ensure security and compliance rules are enforced automatically, and when we build templates for what we call blueprints for Godrails that are applied through Kaverno. So, regulate 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. Security, compliance, and governance are table stakes today. But what about tomorrow? Brian Ross shares his vision for how AI will transform GitHub's workflows. Well, we couldn't get through anything without talking about AI, right? So, look, I think without AI is going to change things, but I think the most interesting that's happened this year is that we're no longer talking about if and when, it's now happening. So for GitLab specifically, we've been working on GitLab due for quite some time, and we've got customers getting real world value. They are saving thousands of hours of developer time on again 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, 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 do. That would be asking dual to help create manifests. That might be helping to summarize long common 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 agente AI and the world of MCP, where all of a sudden we can provide 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, willier 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 most interesting is that a lot of the work we do isn't using all of our brains. Like I think that when we think about developing software, there is an element of it, which is obviously you're 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 it a way that makes a lot of sense. And so the thing that excites me the most on from an AI and think 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. So 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 lots of questions and do an interview style. 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. And that's the art form. I think that's the question that we're all trying to get. So we can build fantastical technology platforms that are observably better in terms of career 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 as effort required from them. So for me, I think there's two approaches. And there's a little bit of character, 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, right? 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. I, you know, 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 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 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. Over the course of this series, we've seen flux evolve from an experiment we've worked into a graduated CNCF project that powers some of the world's most and many platforms. We've heard from maintainers who built a foundation, enterprises like Orange and Nomura who provided its value and production, and now from industry leaders who are embedding flux into their products and services. One mess stands out. Flux is more than just a get-ups 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 get-ups principles isn't just solving today's challenges. It's enabling the next generation of innovation. Thank you for joining us on this journey to flux CD.