 Great. So the title of today's keynote is, we're in six years in, is GitOps Boring? And the reason for this is because I was talking with Scott and some of the other organizers a few weeks ago about what is new in GitOps. And what we learned is, you know, people are starting to think of it as standard. It's the standard operating model for Kubernetes now. It's being adopted by people who use Terraform. It's boring. We don't need to worry about how a lot of this stuff works anymore. And that's fantastic news. But also I'll be talking about, you know, is it really boring? What are the other really boring things that have happened in the last year and what might be fun around the corner? But before I do that, I just want to remember that while we're all enjoying this happy fun world of technology, there are people around the world in wars who are experiencing terrorism, famine and other disasters. So I'm just going to stop talking for a short while just to remember those people. Thank you. So here we are in 2023, six years in. And as I said, at the beginning, GitOps is boring. Well, is it boring really? As you can see, people are falling asleep even as I speak. So the question then is, why is it boring? Well, one reason it's boring is because we've now reached 100% adoption, at least in surveys. This is the recent CNCF survey or micro survey on GitOps. And they asked people, if you're not using GitOps already, if you're not already using GitOps tools like Flux and Argo and others, when do you plan to begin? And two thirds said in the next year and the rest said in the next two years. So that's pretty amazing. Nobody has plans not to use GitOps. I think this is really fantastic news and a sign that this is spreading throughout the industry. And we're going to see some really great examples during this online conference of real well GitOps use that I'm very excited to see and hear about. So that's one reason why it's boring. Everybody's doing it. So what is new and exciting? Well, that's a great question. This is a picture of Corey Quinn last week at AWS where they announced Q, which is the AI solution. And of course, AI is what everybody is excited about in tech this year. If you talk to all of the important people in technology, venture capitalists, tech bros, CIOs, journalists, they will all tell you the same thing, which is that AI is where it's at. Everything else is boring. Well, maybe we're going to talk a bit about AI today because I do think AI is really important. But I think AI and GitOps will actually end up going quite well together. What I'm actually going to talk about is these things in this order. First of all, I'll just talk about what I call the developer experience gap. This is when people unable to do things they want to because they're too hard for developers to use. We'll see how automation is the answer or at least part of the answer. But then we'll also ask, how do we scale GitOps? This is a question we've been asking for the last two or three years as an industry. And I'll have a little refresher on that. And then I'll talk about platforms. If 2323 has been anything in in cloud native, it's been the year of platform engineering really coming to prominence after, I don't know, 15 years, maybe of being a walk on part. And then I will ask, can AI lead to better platforms and solve the developer experience gap? So here's a picture you might have seen me show before I've talked about this a lot. This is when we have 100 million developers, what on earth are they going to do? Are they all going to be Java programmers? What are they going to be doing? And what happens if this keeps growing and we have a billion developers? What are they going to do? What even is a developer and what tools will they use? We can be quite sure that if the number of developers keeps doubling every few years, then they will not use old tools that were developed in 2008 or 2013. They would use new tools. The problem is that the ability of tools to do what people want. If you look at Kubernetes is clearly not keeping pace with what developers need. Every survey that I see tells me people want more Kubernetes skills. They want Kubernetes to be easier. They want cloud native to be simpler. They get that you get more flexibility. They understand that you get reliability. They understand you get security. But how about making it easier for people? And that's the developer experience gap that I think we need to fill. And if you talk to the CIO, they will tell you, oh, my goodness, these are all my problems. People don't understand technology. Things are moving too quickly. Managers don't know what's going on. And yet we need more software all the time. And we have no money to pay for it. How do we do this? I talked to somebody who runs a large telco in Europe. They said, my biggest IT problem is I have tens of thousands of tech stuff and I'm not sure what they do all day. That's the CIO view from the top of the pyramid. But really it is true that productivity could be better for technology today. And so people look to automation to help us. That's one reason why we're excited about AI. Maybe we can automate things that are manual or difficult. Well, GitOps provides automation. GitOps means automatically synchronizing the running system with the desired state in both directions in order to make it work correctly. And then doing that again and again and again forever at scale so we can automate any system that can be described. And this means in practice, as we've seen, developers can more safely and more easily deploy and operate more apps. And that is productivity up the wazoo right there for you. But okay, I mean a team of developers can do this, but what if you have lots and lots of teams? What changes? How do you scale to many teams? And this is something I talked about back in March at another conference that I've linked to here. You're welcome to go have a look at it. It's online. You know, this developer experience gap is because not everybody understands Terraform or Kubernetes or wants to fiddle around with YAML. YAML may be great for providing a metal language for describing properties, but not so great as a programming tool. It's not compositional, for example. And most tech people just don't want to learn this stuff. I was talking to a customer a few weeks ago. They said every time we want to load something onto the platform, they make us reconfigure Terraform and Vault. It's like, why? Why do we have to do that? The second problem is not only do developers want frictionless delivery and their managers want them to be doing stuff all day long, nine to six or whatever it is, but they also want security and compliance sort of baked in automatically, visibly integrated frictionlessly too. And then finally, as we know, when you have config-based management solutions like GitOps, you want to increase the number of systems that you're controlling, operating like staging systems or fleets, but you don't necessarily want to have lots and lots and lots more config. You might want to have one repo controlling thousands of systems, for example, in GitOps V. Well, you might have other things that seem like burdens or a manual to the team and you want this to go away. But if you go back to the CIO, they'll say, I just want all of the good stuff to be codified and turned into safe guardrails, environments, golden paths, so that my developers, any team can be productive and I can scale this across my whole organization. I don't just want the experts to be successful, I want everybody to be successful. And that's where we get to platforms or platform engineering. Platform engineering is just the latest phrase for something that's been around for about 15 years, which is this concept of organizing systems and then making it really boring. This is actually a photograph of an actual boring platform. This company is actually, I found it on the internet, is describing itself as the most boring company in the Gulf and there you go. But actually, the goals of platform engineering are not boring at all. We really are trying to speed up how development works. More deployments a day, more correct changes a day, fewer errors and we're also trying to massively reduce the number of operations costs we would like to have instead of I was talking to another customer last week, they didn't want to have 20 operations staff, they wanted to have one or two and then move everybody into development, which sounds like a cool thing to me. They saw operations of the platform as becoming like the DBA role, a small number of true experts who are setting very fine grained controls, but everyone else isn't as a user of applications on the database or in this case, the platform. And that would be really good. That would actually turn a lot of organizations around in terms of productivity. So what exactly is a platform? Well, it is fundamentally where the automation happens. It is a contract for automation and an expression of the relationship between a platform operations team and what they want to decide is going to be used by the development teams, the app teams, and the app teams themselves inside an organization. And when I talk about an organization, think about a bank or a telco or if you're thinking about more of a small business platform it might be an online cloud platform like Kiroku or Versailles where you have lots and lots of independent teams all doing their own thing and yet there's a small group of people who operate and manage what's in the so-called platform that everyone is using. And that group provides instant environments. It could be a machine learning environment, a mobile environment, a data science environment, a web app environment, a banking app environment. There could be many different flavors of these things and they all work in slightly different ways, but we don't want the app teams to worry about those details like secrets or storage. We want the platform teams to take care of that and make it safe and fast to run apps all day long. And so this contract has to enforce simpler integration between all the moving parts, much more rapid configuration of user additions like templates. It has to make the platform trusted. If you go into an organization and ask them, have you built a platform? The next question you should ask if they say yes is who trusts it? How many people trust your platform or are they still going and doing their own thing? Do you have a service desk for it? Or is that automated? And then finally, as you scale up to dozens, hundreds, thousands of teams in large organization, how do we make sure that they're all compliant? Meaning they don't trip over each other. They don't accidentally open the wrong door and find themselves in the wrong meeting room. The other thing about a platform is it usually contains multiple pieces of very standardized or well-known functionality. Here's the Weaveworks take on this. Yours may be different. We see these pieces as fundamental to a Github-based platform engineering solution. We see this all the time in our customers, again and again and again. A couple of examples. These are ones from people at the conference. Here's one from Acuity that Christian is at. This is their new open source project called Cargo, which I think is trying to do what Spinnaker did, but for Argo and Kubernetes. As you can see, there's staging and things like this. It's pretty cool looking. Here's the new thing from Codefresh. Both Codefresh and Acuity are launching promotions and in multiple environment-based management tools. And if Dan is listening, I really liked the blog post you wrote about this. And here's a screenshot of the SaaS app, whereas Cargo, I think, is open source. Here's another example of platforms at work. This is Microsoft working with us. One of the great works is Pinky talking about going to beyond 10,000 clusters using a combination of both Argo and Flux, which apparently was quite popular at KubeCon a few weeks ago. Go look at the video if you want to here. Here's something we've done recently. You might have been paying attention to the integration we've done with Huggingface and other large language model controllers. It's the same principle as the Flux Terraform integration. And what it allows you to do is load models as containers, potentially signed containers, and run them as a standard component of your platform. And this just shows you the power of the platform. It's that you can have one set of infrastructure for managing things, and another for application users, in this case AI users, loading things, running them, sharing them, deploying them, updating them. And with Flux, one of the things that we've worked hard on is having lots and lots of these integrations, that you can see here in this picture and in this blog post. So I think that's all really boring. I hope if you're watching now, you're feeling very, very bored indeed and ready for something a lot more exciting. And if you're paying attention, you'll notice that these kittens are in fact AI generated. Yes, we can tell because most of them are in fact looking very similar indeed. And there we go. AI, as I said, not boring, very exciting, especially if you're a VC pro or a journalist or somebody like that. So GitOps and AI, do they go together? Well, I think maybe they do. One of the things that we could imagine is having a sort of chat bot or assistant that ask you questions like, oh, do you need help with writing your Yavels? Or can I just run this app for you? And that would be quite cool if all operations worked that way and weren't really annoying. And I think that is genuinely the potential future of some of this technology if we can get it right. Oops. So if we put AI together with GitOps, we've got two things. We've got GitOps-based automation, which is all about using reconciliation to drive convergence and enforce correctness programmatically. And we've got something completely different, which is this generative, inductive, creative tool for doing all the stuff that isn't captured very well by the programmatic GitOps approach. And if we put these two things together, we could have a really powerful automation platform. And here's Anne Stanley on Twitter. Some of us are still on Twitter, by the way, talking about his predictions about a week before the Amazon reinvent event, what he thought LLMs would do for infrastructure as code. And could it be that you could generate cloud formation and then here he is talking about something where someone else has managed to do that. You can see the video of this demo on Twitter as well. But you can actually generate IAC the same way that some chat GPT can generate code. And you can actually manually fix the errors so you can iterate quickly. And it's much faster in aggregate than doing the whole thing yourself, which I think is the key point. And this is also really cool is that you can feed the system back in on itself and you can combine it with the enforcement properties of GitOps and IAC in order to check itself. So that allows you to use YAML files as a sort of type system for correct behavior of a distributed generative system. So this is actually really exciting in its potential. It's something to certainly think about. It also means that programming language stops being Python or Java, but actually becomes a normal spoken language like English because you actually interact with express intent with the automation system in a natural language, which means that we can talk about a different kind of GitOps which is generative in the technology. What would that mean? Well, as example, the developer expresses intent and that goes down through the platform through several stages to actually create code and YAML for me. On the other way up, I might have things going wrong. This is the equivalent of drift detection in standard GitOps. An anomaly occurs and I need to alert and explain it. So that means that we can look at generative in sequence along with the history of declarative management, which GitOps absolutely represents, and generative is a complementary extension to how we do GitOps today, creating a much more powerful automation system where higher level intent can be expressed by the user and this diagram is drawn by my friend Adam Frank at Armory, which I really like. So putting it together, we've got a different kind of life cycle. It's the same at the bottom two layers, but we've added this layer at the top intent. And we can see how information can flow in all directions, going from state to state, from left to right or back again from right to left through the central component which is the platform whose job remains the same, which is to express and capture all of the desired state correctly so that it can be applied programmatically to automate operations and can represent developer intent correctly, therefore meaning that developer intent and operations can be expressed, can have relationships expressed cononically. As a parting thought, what could go wrong? Well feedback was the example that Ant had in his tweets. Could this improve performance and we remove the famous hallucinations that large language models have or do we just have to wait for them to become more powerful? I don't know. That is a challenge for you to figure out and I hope that you do. And until then we will continue to hallucinate about a future where we are lovingly looked after by Kubernetes bots and paper clips. I don't know if you've seen this famous poem from the 60s but in it we were all watched over by machines of loving grace. And so as we reach the end of 23 we look ahead to 2024 and I will ask is it boring but I think it will be very boring in much the same way as the last six years have been extremely dull and I hope you're part of it. Thank you very much. Thank you. I'm going to stop sharing now and I believe there may be some time for questions. Thank you, Alexis. What a great way to kick off what a great way to kick off this conference. There are some questions starting to come but I just want to remind everyone that in the chat in the platform just to the right at the top where you see the chat hopefully you've all found that. To the right of that is a Q&A tab. It usually takes folks a little bit to find it but we have one question that's come in from Saad Sheik. I'll go ahead and read it off. He is asking why the GitOps is shown separate to automation does it mean we need a delta outside GitOps to make it automated? GitOps is automated and GitOps enables automation. What I'm saying is that programmatic automation where we know the intended state the desired state and we drive the system correctly to that state works when we can describe the state and we have agents that understand the description can apply to the running state like Flux or Argo or whatever else but what if we can't describe the state and what if we don't know what a configuration should look like then we might use other tools that generate that configuration and that's where AI can make automation even more powerful and cover more use cases. So I think GitOps genuinely is automation and AI is a different kind of automation that can really go together. Any other questions? I'm happy to give opinions really on any topic you learned at least for a while. I definitely could ask a billion questions but I just want to give folks an opportunity. I'll go ahead and ask you one just for fun. So you've been presenting about AI Alexis and in the context of GitOps there's this there is this idea of writing back to the desired state having agents that can potentially write back to the state which is used as the source of truth for your system and I know for example Flux and Argo now too has image ordination that's an example of that right back where it's not really the machine going running wild on its own but the user specifying rules that we want these agents to follow and then in order to do things like pinning versions in that case and perhaps other cases they could do write backs to the desired state so I guess my question for you is in the context of in the context of AI and you know where do you see that go? So I think the way to think about this in AI is using the diagram that I had with the developer the platform and the system underneath and really in the old days we would move from one operating state to another just by interacting directly with the system and then we would introduce this platform which is powered by configuration where we would interact with the configuration and the image repo and other things the secrets store etc all the pieces that make up the source of truth and it would be external and the platform would make them simple and we would interact with the platform and then the operation stuff would happen for us that means that the application owner doesn't have to think about application operations in quite the same way as they used to but it leaves open the question what about if we need to change the config and the developer isn't aware of that like oh my gosh your config is wrong and it's causing a repeated looping error or what about things like auto scaling you know I'm going to do an auto scale which means I'm going to change the config according to an algorithm as opposed to a human moving the config up through series of notches to 11 and in your example Scott of the right back I think that's just another example of the config needing to change due to an observation of the system the summing has happened in the system and the system is now in a state that needs to be kept so we need to write that back into the system we don't necessarily want the human being to have to be part of that loop we'd like to say to the human being we did this already now it's in the state you expected and now oh whoops the deployment has completed please update the config to record that and so all of that human stuff now allows us to move through states not at the level of the operations but also the level of developer intent so we can go from intended state to intended state to intended state so auto scaling and right back and other things are all then examples of managing that automatically and that's where tools that quote-unquote do generative generative config could be useful I'm speculating and I stress the word speculating that because I haven't seen any of this work in practice and I hope it does in the future and if I see another talking chatbot paperclip I will have to screen good any other questions I love that thanks Alexis yeah we do have questions streaming in now I think it's needed to get to get rolling so okay so one the next question by Mars Rashana Bond and by the way I think there are about questions now so I'm not sure how many will get through but we do have a little bit of time so their question is how can get ops be used to help developers who don't have much knowledge of the platform that's a fantastic question but remember the first job of the platform is to help developers to have who have no knowledge of the platform and so the question is what would that look like and what the number one job of the platform is to so you don't have to think about that oh do I have to hook up logging myself do I have to choose a logger you know this is the kind of thing that a platform should do it doesn't have to be done the same way for everybody that's the model platform engineering is it might be done differently according to different use cases but the end user probably shouldn't have to think about it most of the time and if so then the platform should be configured so that the integration is correct and get ops should enforce that make it automatic and make it on-demand and ready for the user so they don't have to do it as well and that's my answer to question okay any other questions yes there were a few I was just consolidating a few of them because there's a there's a running theme here so I'll just mention a few of these together because I think they rolled together the first one is yes the first one is what are your thoughts about LLMs potentially excuse me potentially being injected with malicious data to generate unsafe code especially for IAC and there are basically there are just several other questions specifically about about security asking about security considerations and specific concerns give specific concerns around platform engineering with AI I'm not a security expert and I follow Simon Willison on Twitter who constantly talks about hacking prompt engineering and whether or not the Amazon Q AI service they launched last week could be hacked so that you'd ask it to do something and it would then tell you Andy Jassy and I don't know if it's a gallery or something like this and the answer is I don't think enough people are thinking about this right now it is something that we need to understand better but I don't believe that this cannot be solved I mean I think there are potentially sort of sandboxing things that we can do and part of this is about having different layers of control so that the end user who's asking for things to be done doesn't necessarily get access to behind the curtain all stuff the platform team might see and there might be different ways that different teams are supported by different LLMs usefully to solve different sub-problems and that could be the way to do it to have lots of different tenanted safe boxes so if something does escape then it doesn't escape into the rest of the system so that would be my answer to that which is a long way of saying I don't know carry on more questions do we have use cases to explain the scope of generative AI with GitOps and telco no because there are some telco use cases coming up in this conference I believe both orange and Dr. Telecom will talk and I highly recommend you pay close attention I know but all the telcos are super excited about generative AI for the same reasons I gave which is it could be really labor saving and if you've ever wanted to see Bury in IT go work with telcos they do a lot it's really hard work so that could be really powerful but I can't tell you the answer to the question does GitOps work better with specific branching strategies trunk I can't remember exactly what the answer to this is but it's been covered by more technical people than me basically our recommendation is not to use I think it's called GitFlow but you really want to be merging back into trunk as much as possible Scott is that the right way around I get confused about this yes exactly think about folks at home can think about directories as opposed to using branches for promotion and part of the reason for that is that GitOps is you really want to define all of your branches and there's very few cases where you're going to want to move your platform configurations from development and then somehow promote those development configurations to staging and then promote your staging platform configurations to production it's mainly you want those to all be there and they're going to be different if you want to save money yeah somebody's asking what are the security considerations when it comes to GitOps I would say the most important thing is to not have a single security perimeter around both CICD and operations so really you want to keep operations and dev as separate as you can and we've talked a lot in the past about this concept of the immutability firewall I would go research that and also look at things like signing OCI images which is a really good way of providing all kinds of security support automatically in your pipelines signing OCI images which is something that Flux supports somebody is asking for examples of GitOps being done with Argo there are plenty of those on the internet you could also look at the video that I linked to where Argo and Flux are used together to do 10,000 plus clusters that was in the presentation which will be online soon let's see will we be running our own LLMs asks Torben as GitOps repos usually have sensitive data in it well I think people will run their own LLMs but I'm not an expert on how this will work I read about it in the trade press same as you are online and social what we've done with Weave AI is make it easier for people to run standard LLMs privately on your own Kubernetes platforms and adapt them to your own needs based on your data which is private and what your teams want to do and your own weights so go look at that please how do you make reducing the developer gap attractive to developers content with the current state of things asks Sorin that is a great question if you are content with the current state of things that's fantastic then you have no developer gap there's nothing to be done I'm not sure why it should be more attractive though so I think perhaps the way to think about it is like this if you are somebody who understands everything already you're probably building or providing a platform to your colleagues go ask them what would make their life easier and then you'll see the developer gap is my recommendation okay a few more questions I'm being told to stop I'm talking too much I think the organizers want to move on to the next talk any last questions Scott or should we wrap it up there no I think we should wrap it up mainly for technical reasons there's a technical transition gap so okay but no that's perfect there's more questions here that we can follow up on you can ping me on Twitter I'm Monaddick on Twitter you can send me emails it's not hard to figure out my email address and you can also follow up through the CNCF there's also Slack channels where you also have the same user name as on Twitter it's pretty easy to find me and ask me questions which I'm always very happy to answer just remember that whatever you do Ginox is boring thanks a lot take care bye bye thank you