Tech.Rocks Summit 2022

GitOps Emerging Developments and Predictions

Tech.Rocks Summit 2022 · 9 décembre 2022 · 30 min · en anglais

Résumé

Alexis Richardson, cofondateur et CEO de Weaveworks, à qui l'on doit le terme GitOps, partage sa vision de l'évolution de GitOps, en passe de devenir le modèle de référence pour les opérations cloud native. Il évoque les évolutions à venir, le passage à l'échelle, GitOps au-delà de Kubernetes, les fleets et les stacks, ainsi qu'OCI et le packaging dans un environnement sécurisé.

L’essentiel

Dans une conversation à distance menée par Philippe Ensarguet (Orange Business Services), Alexis Richardson, CEO de Weaveworks, définit GitOps, en présente les cas d’usage et donne ses conseils et prévisions.

Pour discuter de l’automatisation des déploiements et des opérations d’une plateforme Kubernetes à mesure qu’elle grandit.

Les idées clés

  1. Ce qu’est GitOps. Selon Alexis Richardson, GitOps repose sur un modèle déclaratif du système et sur des agents qui vérifient en continu que le système y correspond et le ramènent vers l’état voulu (réconciliation continue). Les agents tirent l’état de l’extérieur, sans intervention manuelle en production. Utiliser Git ne suffit pas : c’est la boucle de réconciliation qui compte. à 5:11
  2. Trois cas d’usage. Le déploiement continu, quand les commandes manuelles et les scripts de CI deviennent difficiles à contrôler au-delà de quelques opérations ou de plusieurs clusters ; l’ingénierie de plateforme, comme chez Fidelity pour déployer de façon homogène sur Amazon, Microsoft et Red Hat ; et le déploiement de la 5G de Deutsche Telekom jusqu’aux antennes mobiles avec Flux et Weave GitOps. à 8:57
  3. Démarrer prudemment, et ne pas confondre GitOps et IA. Il conseille de commencer avec Weave GitOps (son propre outil, précise-t-il), de lire la documentation et d’avancer lentement, car associer CI et GitOps fonctionne de façon inattendue. Pour lui, GitOps et IA sont complémentaires : GitOps vérifie la conformité à un modèle spécifié, l’IA apprend des motifs sans règles ; selon lui, nous ne sommes pas prêts à confier nos data centers à ChatGPT. à 11:44

Questions pour votre équipe

Il s’agit d’un échange à distance avec le CEO de Weaveworks, éditeur de Weave GitOps et à l’origine de Flux : plusieurs réponses promeuvent son offre entreprise. L’interlocuteur, Philippe Ensarguet, indique être board advisor de Weaveworks, dans laquelle le fonds d’Orange a investi. Les cas clients sont cités sans chiffres de résultats et les prévisions datent de fin 2022.

Chapitres

  1. Présentation des interlocuteurs
  2. Parcours d’Alexis Richardson
  3. Qu’est-ce que GitOps ?
  4. Cas d’usage
  5. Conseils pour démarrer
  6. Flux, la CNCF, l’écosystème cloud et l’offre entreprise
  7. Durabilité et prévisions
  8. Questions : IA et GitOps

Summary

Alexis Richardson, co-founder and CEO of Weaveworks, who coined the term GitOps, shares his views on how GitOps is becoming the de facto model for cloud native operations. He discusses what is coming next, how to scale, GitOps beyond Kubernetes, fleets and stacks, and OCI and packaging in a secure environment.

Thèmes : Cloud, infra & ops

Transcript complet

Transcription automatique, à relire : les noms propres peuvent être mal orthographiés.

Alors, notre prochain invité est à, vous l'avez compris, il est à distance. À distance, donc ça va être un zoom. On a la chance d'avoir avec nous Alexis Richardson, qui est cofondateur et CEO de Weaveworks. Tout le monde connaît Weaveworks et Alexis Richardson. Donc je vous demande d'accueillir Alexis Richardson. Ah bah... Non? Alexis? C'est pas du tout Alexis. Elsa, j'ai l'impression que t'es déçue. C'est-à-dire qu'on m'avait dit Alexis Richardson sera là, etc. Connecté. Bah écoute, je suis désolé. Philippe? Oui, moi c'est Philippe en fait. Et donc Philippe, il faut quand même que vous m'expliquiez ce que vous faites sur cette scène. J'ai vu donc votre photo, vous êtes en plus... Ah, vous êtes chez Orange alors, ça tombe bien. Non, non, non, non, non, non, non. On va rester sur le focus de la session parce que les livebox et tout ça, moi je ne fais pas. Mais après, j'ai dit que je faisais mon marché en même temps. Ok, d'accord. On verra après alors. On te promet? Ok. D'accord.

Et donc, qu'est-ce qui justifie votre présence là? En fait, moi, je connais Alexis depuis maintenant un peu plus de cinq ans. J'ai la chance de travailler et d'échanger avec lui quasiment au quotidien. Moi, j'ai rencontré Alexis il y a cinq ans lorsqu'il était chair au Technical Oversight Committee de la Cloud Native Computing Foundation. A l'époque, je m'intéressais aux systèmes complexes massivement distribués. Et donc, naturellement, on s'intéresse à l'écosystème cloud native et cube. Et c'est comme ça que j'ai fait la co-fondation. Fait la co-fondation. connaissance d'Alexis, puis après il y a eu un deuxième moment, j'ai envie de dire un peu plus fort. En fait, côté Orange, nous avons un fonds d'investissement, un corporate venture capital, qui investit dans des entreprises qui font du sens finalement pour le développement d'Orange et de ses différentes entités. Et il se trouve que j'ai eu la chance d'être associé à l'instruction du dossier dans lequel finalement Orange Venture a investi dans l'entreprise d'Alexis. Et depuis, je suis devenu board advisor pour lui. Alors j'ai la chance de le côtoyer quasiment au quotidien.

Je suis advisor pour d'autres sociétés. Ce job-là et cette activité, c'est normalement beaucoup de mentoring. Honnêtement, avec Alexis, le mentoring, il n'en a pas besoin. Il est vraiment déjà excellent. Je suis plutôt là quelqu'un pour être un sparring partner, être à son écoute quand il en a besoin, discuter des sujets qui lui tiennent à cœur. Et puis peut-être au quotidien, ce qu'on fait, c'est décrypter l'actualité et comprendre ce qui nous arrive pour aider à positionner de manière idéale Weaveworks et les équipes qu'il pilote. Et là, vous allez être à son écoute, encore une fois, et lui à la vôtre. C'est ça. Je vous laisse officier. On peut peut-être l'appeler? On va l'appeler. On appelle un ami. On appelle un ami. On appelle un ami. On appelle Alexis. On aime beaucoup ça. Est-ce qu'Alexis est avec nous? Je pense que oui. Ah, merveilleux. Hi, Alexis, where are you? Hi, I'm here in Oxford. Yeah, we love Oxford. We love Aviron. What's the word for Aviron?

Rowing? Rowing, yes. I'm not sure that it's the right word. I've just been rowing this morning, actually. Oh, fine. It's perfect. Synchronicity. Okay, so I think that we can start. You have the zapette. No, I don't need the zapette. You don't need the zapette. So it will be basically a fireside chat with you, Alexis. So all the session will be made, I would say, in English. Perhaps to start with, it may be interesting for the one who did not listen to the podcast that we recorded a few weeks ago, perhaps to introduce yourself, who you are, what is the journey, what is your background, and then we can deep dive into the session. Sure, thank you. Philippe, bonjour everybody. So yes, my name is Alexis. I am the CEO, co-founder of Weaveworks, an international company. As you can tell, I'm in England, but we have many staff all around Europe, East Africa, America, and everywhere else.

The company is best known for GitOps and Kubernetes. We have a tool called Flux, which graduated in CNTF this week, which is great news. Previously, I was the head of application platform at Pivotal and VMware. I got in there through acquisition. My company, RabbitMQ, which you may have heard of, was acquired by VMware. And before that, long ago, I worked in the city. I was a trader at Goldman Sachs, buying and selling derivative products. Very exciting. So I've been around for a while. And as Philippe mentioned, I was also the chair of the CNCF TOC for a few years. So I've interfered with open source a lot. Thank you, Philippe. Okay, so Alexis, we are going to have a fireside chat about GitOps. Apparently, the first question for you is, but what the hell is GitOps? What are the principles? Where does it come from? GitOps is a way for developers to take control of operations.

It is based on a very simple concept where you have two things, a model of the system, which is specified declaratively, and a set of agents which automatically check whether the model and the system agree. On whether they're in the right state or the wrong state. And we have a concept called continuous reconciliation. The agents are continuously checking to see if the system is in the right state, and if it is not, they will attempt to orchestrate convergence back to the correct state. They pull the state from outside of the system so that there's no way of the developer actually touching the production system by hand, which means it's more secure, it's more remote, and we can scale it to as many copies as we want. So it's a beautiful way to operate any IT, and it works particularly well for continuous deployment, platform engineering. Progressive delivery and fleet management, especially with Kubernetes, Terraform and other modern technologies for managing applications.

When I was at KubeCon in Detroit, everybody was saying GitOps is now the standard operating model for Kubernetes. The next step. GitOps to become the standard operating model for modern IT. I think it's a very good intro about what GitHub is. I think it's much more clear for the people here in the audience. You know, Alexis, here at Tech.Rocks, on the summit, the idea is about gathering, listening, sharing, collaboration. So my next question for you would be how the ecosystem in GitHub has organized itself and perhaps how are you supporting the practitioner in having more GitHub implementation and deployment? When we started GitOps, we wanted it to be a big community, an open world, a big tent. We did not want to have a proprietary product that locked people out from doing GitOps.

So number one, GitOps is about great open source tools. Tools like Flux, Kubernetes, Terraform, Flagger, Argo, Tekton, and many other tools which I could list. Number two, we have tried to do a community of not exactly open standards, but some sort of rigorous statement about when something is GitOps or is not GitOps. We do not want GitOps to be like DevOps, where it means everything to everybody, and over time it just diffuses into a practice. In fact, GitOps is a clear set of technologies and rules. And one of the most important is if you're using Git, that's great, but it doesn't mean automatically that you're doing GitHub. So really, it's about the reconciliation loop and operations just as much as it is about the developer tools. And the community agrees on this because we've got clarity on it.

Okay, thanks so much. I would say that here in Paris, in the audience, you have tech leaders from, I would say, every kind of industry. You have retailers, you have energy, you have... entertainment and it could be perhaps interesting if you can deep dive in in some use cases where githubs have been deployed and perhaps to to make the audience understanding what kind of nuts does it crack When people start using Kubernetes, they ask, how do I deploy code? And there is a cube cuttle as a way to push code into Kubernetes. This is fine for one operation. Then they start to do three or four operations and they start using a CI tool. They write little scripts and those can execute these. But as soon as you start doing more than a few operations, or changing more than one thing, or interacting with more than one cluster, it becomes very hard to control, and you need to have an automated programmatic system to do it for you.

So we see everybody doing this for CD, continuous deployment. And CD is the glue between dev and ops, or Jenkins and Kubernetes, if you prefer. That is the number one use case. Number two, platform engineering. We all know about Heroku, OpenShift, Cloud Foundry, but nowadays, big organizations want to build their own platform. The first time we worked with a customer, Another one of this at Weaveworks is with Fidelity. If you look on the web, their platform is called Fidex. Fidex is a way to deploy applications on Amazon, Microsoft, and Red Hat in a consistent way across the whole organization. We call this the application platform. This allows everybody to learn one set of skills. But deploy wherever they want to, which is fantastic. And then the third great use case that I see is Deutsche Telekom. We're rolling out 5G, which we did last year, first time in, I think, in production in Europe, Philippe.

And we rolled it out using Flux, Weave GitOps, out to mobile towers. Imagine 40,000 mobile towers. Across a country like Germany or France, you can't just use a CI tool to push changes to these things, nor can human beings do it. It must be remote, secure, automated, and under control. So we've been able to push out 5G out to mobile towers and run 5G operations through that. Which I think is a really amazing use case. We also see Flux used in airplanes. The United States Air Force uses Flux to load software before the planes fly. Okay, I think it's interesting to have all these use cases in mind. Perhaps the next question for you could be in the audience, perhaps that some are already, I would say, GitHub-based in their process, but certainly that it's not the case for everyone. If you would have perhaps some tips for the one who wanted to start and jump into the GitHub journey, what could be your first advices to the audience here in Paris?

I think two things really important and maybe a third. So easiest way to start, use Weave GitOps. This is my own tool, but I really believe that Weave GitOps gives you the graphical user interface and the developer experience on ramp to learn and get started much more quickly with any Kubernetes tool. Secondly, I think it's really important to do some reading. I mean, there's plenty of online documentation. Go to the Flux website, go to the Weave GetOps website. They'll give you lots of examples. As you read more, you build up a picture in your mind about what I can do with this tool. And you'd be surprised. It's very powerful. And the third thing is. Move slowly. Don't assume that you'll be able to do everything in one go. And don't assume that the way that you work before is identical to GitOps. We see many people using CI and attaching GitOps. This is a really great idea, but it works in unexpected ways.

So you should make sure you understand that before you just plow on. That's what I would say. Okay, thanks so much. You said in your intro that last week you had very good news with the graduation of Flux on CNCF side. What does it mean for you this graduation and how are you connected with this cloud native ecosystem? And perhaps on two sides. The first one with perhaps on the hyperscalers and I would say the cloud bearer and providers. And because you mentioned as well infrastructure as code, you talk about Terraform, but I know that Pulumi, for instance, can be as well in the scope. It could be interesting to hear you and if you can elaborate a little bit on this, it could be interesting for the audience here. Yes, Flux works with Terraform and Crossplane and Pulumi.

I was talking yesterday with somebody who wanted to make it work with Puppet, potentially Chef, Ansible. With VS Code, for example, not just Kubernetes. This means that you can actually bridge between the old world of before Kubernetes tools and the new world of Kubernetes tools very, very easily without necessarily understanding all of the technical details. So that's the first thing I would say. The second thing I would say is that, you know, the. This graduation thing, so what does that mean? The CMCF has three tiers of project graduated, incubated and sandbox. The sandbox is really there for new experimental things. Incubation. Is a difficult group to get into, but it means you're being used in production. And the tool has a real team, it has a roadmap, and it has a likelihood of success.

But graduation means that you are now accepted as one of the highest level of tools where You've proven you have strong governance, a great community, lots of users. You're very likely to be around for the perpetuity, which means it's extremely safe for large organizations to make trusted bets on the technology. So we're up there with Kubernetes, Prometheus, Envoy, and the other great tools. And now 18 graduated projects. Thanks so much. I would love to hear you as well on another point, because for me, what is unique with Flux and all the ecosystem that you are managing is that, I don't know if you know, guys, but when you are using Azure Arc, when you are using AWS EKS, when you are using Kubernetes distribution from D2IQ, from Alibaba, from IBM Cloud, the underlying infrastructure from this company are based on Flux.

It could be interesting perhaps to listen to you, Alexis, about basically what Flux and GitHub bring to those, I would say, big tech shops that are, I would say, the leaders of our tech world. Thank you. Thank you for asking that question, because I was going to talk about that and then I forgot. So if you're using Microsoft Azure, Kubernetes or Arc, you're already using Flux because it's inside the product. Microsoft made a huge bet on Flux several years ago and has invested heavily to make sure that it's Secure, multi-tenant, scalable, not just for cloud use cases, but also devices, remote tools, and the Internet of Things as well. Amazon is the same. Flux is inside EKS Anywhere. EKS Anywhere is an open source version of EKS that you can run yourself behind the firewall, if you like, on an edge, if you like. It works the same as EKS, except you operate it yourself instead of Amazon doing it for you.

And Flux is part of the EKS ecosystem. Amazon is actually an investor in Weaveworks. D2IQ, formerly known as Mesosphere, have embedded Flux in their product as well. Alibaba used Flux. If you're using VMware Tanzu, you're also using Flux. I think the only one that doesn't have Flux inside is Red Hat and Rancher, but there they work on top. So you can run Rancher very easily and then Flux on top or Red Hat OpenShift with Flux on top. So we're everywhere. Thanks, Alexis. I know how much you are committed into open source. I know that most of all the work you did since the beginning of your journey were highly connected to open source. You talk about FluxCD, but it's also about Flagger, it's about Weavnet, so much projects that are, I would say, highlights in our tech ecosystem. I would say that it's okay fine for the open source ecosystem, but you are running a company that is called Weaveworks.

And you have product, and in particular with GitOps. What can be the benefits of people in the audience here to enter in contact with you and deep dive on the Weave GitHub's core enterprise and all the different flavors of your product? And in which kind of direction will we get a boost in integrating these technologies? If you're using Flux or Kubernetes or Argo or Terraform today, or you're thinking about it, you should talk to Weaveworks about how to make it scale and how to make it secure for production use. On top of Weave GitOps, which is open source, we sell an enterprise product, which is used by telcos, banks, car companies, big American digital companies all around the world. And what this does is it gives you a way to manage multiple teams through multi-tenancy, security, supply chain, policy management, and compliance, so that you can scale to lots and lots of different use cases very easily.

Another thing that's very, very difficult with open source tools is if you have a platform and you layer different components to make a stack, managing this is very, very hard. If you make manual changes, you break the stack. If you try and use tools like Flux and Argo in the open source versions, and roll out the complicated stack, it's very easy to get it wrong. So we have enterprise solutions for this, and we find that our customers are really, really happy when they get this support because it is tricky to get it right. You want it to be automatic, robust, and comprehensive. Okay, thanks. Alexis, we are talking perhaps on nearly daily basis on a lot of different topics. But one that I think is... more and more prevalent in the last months or weeks is the topic that is a real topic here at Tech.Rocks Summit is about sustainability. And when we were talking together and basically when we are in touch with the cloud native ecosystem,

we saw that at Valencia in last European KubeCon, we have the kick of the sustainability working group, environmental sustainability working group. I know that you are more and more in Paris in this. I would love to hear you and sharing the audience. What is your thought on what can GitOps bring into the sustainable and green topic? Intel and Red Hat through the community to understand and with customers as well to understand how to manage not just one machine or one process, but a whole data center using GitOps, which would allow us to say. I want to reduce my carbon consumption to this level. I want to reduce my cash expenditure, how much money I spend, to this level. I want to work within these parameters for power management.

And if you look at the KubeCon talks, you'll see one from Niki, who works with us, Niki Malodakis, who talks about how to integrate eBPF with Flux and a tool called Kepler to provide you with exactly this capability in GitOps today. So we have working proofs of concept. And what we see happening is as people scale up GitOps, they will want to use it to turn machines off and on automatically in order to manage their power and bring it down to net zero. This is really, really, really exciting because people have been talking about this, but not achieved it. And Geodops is going to enable it. I think it's very interesting to quote the work done by Niki. And for the audience, I will share in the internal Slack the GitHub repo where all the work that have been done by Niki and the team. is of course fully public and honestly the integration of Kepler with the reconciliation loop bring by Biflux is extremely interesting to understand the power management of the different cube nodes.

Alexis, we are getting closer to the end of our chat. Perhaps a last question for you before giving the mic to the audience for question. What are your predictions around GitHub? What can we expect in the future? I would be delighted to hear you about your thoughts on this. Great. I think we can see three things happening in the future. One is because of green ops and fin ops and the sustainability opportunity, we will see a big demand for data center scale operations that are automated. And this will drive adoption of PEDOPS throughout every business. But two, ordinary developers, people with hands on keyboard. These people want to use Kubernetes, but for many of them, it's complicated, it's new, it's hard. Second prediction, we're going to make it so easy that everybody will be able to use Kubernetes.

You just won't see it. It will be hidden away beneath other layers of code. GitOps is enabling this today. And the third thing is, if you're a big company and you want your application developers to become productive using these new cloud native technologies, come to us. GitOps is the way. These enterprise products, and we're not the only one, are going to solve your problems. I think it's really exciting and perhaps if I may add a last one on which we are talking really often is the fact that it's a real booster for operational model as well. Basically today we have a question about the competitivity of what we are doing and the way we are operating the system is mainly, I would say, anchored in the past. And what is really interesting and what is not so well understood by most of the people is the resiliency and self and auto-healing properties of what the orchestrator brings. Yeah. So let's finish with a clear example. In the old days, people would spend thousands and thousands of man hours, person hours planning their IT.

And now we move into a world of agility. And DevOps, what's changing? We used to have thousands of applications. Each application would have its own team, its own operations team, and its own stack. This would be incredibly expensive because we'd have a huge, huge, huge operation. team all doing different things, no way to control resilience and reliability. Now we have a thousand applications, 100, 200 teams, each with five or 10 applications. They share a few platforms and those platforms are operated consistently and automatically. By very small operations teams. This efficiency gain is huge and it's worth 5x, 10x, 20x in your budget. Imagine freeing up all of that money that you spend, keeping the lights on and stopping errors from happening and putting all that money into innovation. That is exciting. Thanks so much. I think that it's a very good final point.

And perhaps, Elsa, you will join me on stage perhaps for some questions from the audience. Yes, and thank you, Alexis, for the clarity of your speech, especially for me when it deals with sustainability. That's nice to hear that. Thank you. Do we have any questions in the audience, burning questions? I'm sure maybe some of you have one. If you have, please raise your hand. known? Oh, one. One question here. Could we have a mic, please? Is there anybody in the... Yeah. Philippe, you can do everything. It's marvelous. Thank you, Philippe. I'd like to have you two cents about the breakthrough in AI recently. Do you think it could have an impact on get-ups and give-ups philosophy and the way you work? What's your opinion about that? I don't think we're ready for chat GPT-3 to run our data centers.

Even if it's right most of the time, it only has to be wrong once or twice to cause all kinds of problems. And it's very easy to find ways that AI generates errors. So I think that that's a really important point. I believe that quite a lot of, well, let me see how to put this. So I think AI and GitOps are actually two different and complementary things. That's the important point. In GitOps, we have a specified model of what we intend the system to look like. And all of the agents, which they are agents, automated agents, operating the system for you, all they do is they verify that we are correct with respect to the model. And if we're incorrect, they will initiate actions and enforce convergence through orchestration. And we can also do this with rules that set parameters, as I was saying, for carbon or cost management. With AI, we're in an open-ended world where we don't necessarily have any rules, but we learn patterns and we apply them.

And I think both of these technologies are going to be useful in the future for managing all kinds of things. Also for developers, you've seen code pilots. You've seen code pilots. on GitHub. I think that we've been experimenting this week at Weaveworks with ChatGPT3. There's certainly opportunities to have like a GitOps assistant inside WeaveGitOps. That is pretty cool. I know that Philippe has been trying to do the same thing because he's laughing. But on the other hand, what you need to remember is chat GPT-3 is trained on a data set. You may not know, but the data set ends in 2021. So, for example, chat GPT-3 knows nothing about Vladimir Putin's invasion of the Ukraine, and it knows nothing about technology in 2022. So actually, if you ask it questions about that, it doesn't know anything, can't help you. So the future of chat is potentially to allow it to learn in real time. But for some reason, the OpenAI team are scared of letting it do this, perhaps because it might become intelligent.

So I think we're, you know, we're in a strange new world here that we're just understanding very slowly. Thank you, Alexis. Perhaps a last question for Alexis before giving the mic back to Elzah. To me. Another one? No? Okay. I think we're good. Yeah, I think we are. Alexis, a big, big thank you for being with us this morning. I get that everyone is much more clear about GitHub, and I will share some entries in the Slack channel with some inputs and material from you. Thank you so much, and big applause for you. Thank you. And we love rooming. Merci beaucoup. Philippe, Alexis, Alexis, Philippe. Merci Elsa. Merci à tous.