 Check, check, can you hear me? Yes, we can hear you, hello. Okay, hello. Hey. So usually we give people up to five minutes past the hour to start. Oh, thanks, thank you. Yeah, I know we didn't make it last time. I lost my internet connection, so I'm sitting out in my car with the, I'm gonna try and present from my iPad. We'll see how this works. Well, that sounds interesting. As long as you're not driving while you're presenting. Yeah, yeah. That would be even more fun. Depending on which car you're driving. Was it self-driving Tesla? Maybe, but I think it's still illegal. Yeah, my car is definitely not autonomous. Yeah, we got just one question from Karthik who wants to give us a brief update. Only five minutes to get started today if this is fine for everybody, but just be really brief because they wanted to mention the chaos engineering wide pay, but it was just very highly, I would give an update that it actually exists. It will really be pretty short, but he has to drop off early. So if, okay, for everybody, I will just give him the chance to just say, this is it, what we're working on. I just, mm-hmm. That works. I just have to drop it like 1120, I think, or 1125, but I think my topic probably won't take more than five, 10 minutes. Okay, then I think we should be, and I would just let them go first and miss the front still, that's into himself. That's an introduction, nice. Oh, yeah. So Thomas, do you want to present anything on the operator working group today? No, I think there's no progress currently. Okay. The next time again. No, it's fine. I was just trying to outline the agenda, but I think we're totally fine because otherwise we, yeah. So let's give people one or two more minutes to join in here. So Thomas and Alex, I think application improvement would also be something we put on the agenda for maybe then the next meeting again. Yeah, sounds great. I think today with the meetings that we have, or with the topics which we have scheduled, I think we will run out, we would run out of time anyways, otherwise. So Conelia, do you want to give any updates on the Github's working group? You don't have to necessarily. Sure, I can do that. Yeah. I'll put you at the end of today's agenda. I know this is not like, we're a gentleman like, but the reason is we have two project presentations and we skipped one already the last time. And otherwise we could do the Github's working group in one of the next meetings as well. No worries. If it slips out of today, not a problem. Good. Having said that, let's actually get started. I know, Karthik, you have a hard stop. So everybody agreed on letting you go first, discussing the chaos, white paper that you're planning to work on. So yeah, I'll just let the group you give a brief introduction, what you're up to, where you can find the current draft and how it can participate. Yeah, sure. Thanks, Eliza, for consulting my request. Thanks for allowing me to go first. Hi, everyone. This is Karthik from the Litmus Chaos community. I'll just share my screen and talk for a couple of minutes about this new initiative that was not first started thanks to Eliza for actually suggesting the idea of writing out this white paper. We're trying to create a white paper for the state of chaos engineering in Cloud Native. And one of the reasons I think the motivations for this is chaos engineering is a gathering speed as a discipline and the adoption of Kubernetes has just increased the adoption of chaos engineering, so to say. A lot of folks are migrating to Kubernetes. They want to do a lot of fault injections and they want to do chaos engineering in CI CD. They want to do it before they go and deploy their applications into production. So that's the real motivation. We want to see how the Cloud Native paradigm has influenced the trends of end users how they're adopting chaos and what they are doing with it. We want to learn from the end user experiences and one of the ways we thought we'd do this is try and gather folks from the CNCF projects that are working on chaos engineering. Litmus Chaos, which is one of the CNCFs and both projects and also Chaos Mesh, which is another chaos engineering project which is actually the premiere of the SIG network and we sort of got together and exchanged some ideas and thoughts. We wanted to further establish what we mean by Cloud Native subcategory of chaos engineering. What are the general architectural approaches that we see in Cloud Native Chaos Engineering and also take a look at what problems user are facing and what are the reasons why they are adopting chaos engineering and how they are doing it. There are people who are still doing game day oriented freestyle manual execution of chaos and there are folks using it in continuous delivery pipelines and there are people who are integrating it with the detox pipelines. There are a lot of ways they're using it. We want to capture those practices and also take a look at what are the most common problems faced by the SREs today and to try and recommend how they can avoid that. So we basically are going to capture our thoughts in this document that is a working draft. It basically contains a set of sections here. You can see, we'll be defining the goals that I just spoke about. We'll be trying to introduce the concept of chaos engineering and then define the subcategory of Cloud Native Chaos Engineering and its current stage and how practitioners are looking at it. We'll summarize the available CNC projects in the landscape today and try and take a brief look at the approaches that they are taking to solve this problem. And also learnings around that we've got from the end user community, some recommendations about how they can adopt, start for our chaos engineering. There are some well-known practices emerging people doing chaos for observability in projects in the beginning as a low entry barrier when they take it to production. I mean, they take it to the other business apps. Some of these we will try and recommend here and there will be some predictions. This is what we agreed upon and that is a slack channel dedicated to collaborating on this chaos white paper. It has folks from the chaos mesh and different chaos communities and I really appreciate, really encourage you to take a look at this and see if you'd like to include more topics around chaos engineering here. And we can also join this slack channel and this is open for comments. And we have to incorporate your feedback and come up with the white paper. There's also an issue. So you can go ahead and put your thoughts as issue comments here as well. We've not got much in terms of content. We just got together last week. So we expect that there's going to be more content as we go in the following weeks. We just created a rough draft of how we, when and how we meet and what might be some significant milestones with regards to this white paper. So you can take a look at this and share your comments. I'm happy to take that feedback and go forward. I think in the subsequent delivery meetings, maybe we can have progress updates on how we are doing here. What is the current state for our employees, et cetera. So that was a very brief intro to what we are working on. Thanks for sharing and as Kartik mentioned, this actually came out of me asking him for the upcoming KubeCon Europe talk about what they are seeing from a chaos engineering perspective because with, is it called a litmus chaos hub or yeah, what they are seeing, which chaos experiments people are running, what they're doing. There were actually quite some interesting insights and it's why don't you team up and which I think is also great with the chaos mesh team on the networks to bring this together into a more condensed format. I know it was pretty much last minute that I told you you should bring it up to people over here. So yeah, obviously as soon as you have something to share, feel free to always book a couple of minutes on the white paper. I'd also recommend using with the operator white paper team on best practices, what worked well, what did not work well from them. So they have obviously also learned a couple of things along the way, what did work better than other things. So I think it's Jennifer, Thomas or Omar, I think they also help, they can also help me here on how to best structure it and get it aligned. They got a lot of praise by coping with the security teams so they did a great job by themselves as well, but I think it's also well received by the CNC after way they actually structured this. So I also would recommend reaching out to them, especially when you talk about timelines to get feedback on what worked and what didn't work. Obviously, KubeCon EU is out of the time horizon that would be a very fast white paper, but maybe something around in the summertime frame and just looking at this. I posted most of the links in there except for the Slack channel already in the docs. Feel also free to send it out to the mailing list so that some people can join usually this meeting because for the West Coast it's really early. So that you also have more outreach there. Yeah, thanks for sharing today and let's discuss more as we go along and we can then, for example, next time we could take the findings that we already discussed that would also be interesting discussion to get things started. And with this, I would pass over to James who's presenting from his car today. Yeah, thanks. So for those of you that didn't hear the backstory I lost my internet connection at my house. So I'm in the driveway. So let's see if I can actually broadcast from my iPad here with LTE. And you'll know if you can see something here. Yes, we can see your screen broadcast. You got it. Fantastic. It's a miracle. All right, so it's loading right now but essentially I wanted to take you all through some work we're doing around Rockwell Kinder. Let me actually exit out a full screen. I think you should still be able to see this pretty well. And so... Okay, okay. Yeah, so just to give you a quick update I just wanted to appreciate the time you all take and the time to listen and give us any guidance. So basically one of the challenges that we've experienced or we've seen with all users they're getting tired of hearing about digital transfer vendors. They're also getting tired of hearing about transfer easy, just modernize your apps, modify your processes, change your culture. And the actual practitioners doing this work are really just still asking me what does that practically mean I need to do in my day of life and in my application architectures and things like this. And so in addition to that, there's, integrator and partner and vendor has a different methodology for how to do this how to rehost, re-platform, re-factory applications and all the things that they bring oftentimes is proprietary. And so what we've found in the community as we've become part of this community is that what people, the practitioners are actually hungry to learn about is how people are doing this. How they're actually, for example, strangling a model or a car off a study car container or containerizing their applications. Those are topics that they're very interested in and they wanna learn about. And they also are interested in having tools that are open source to help with this journey. Not things that require licensing or proprietary, have proprietary IP. And so that's really what we're doing in the conveyor community. We're starting to hold meetups. Actually, Karthik just presented just the other day on one of them. So Karthik, thanks for presenting on the CAS engineering topic. But really this is about trying to drive more of an ongoing conversation from practitioners to other practitioners about how they are going through taking their applications and getting them to Kubernetes and to use the CNCF projects more regularly. So that's kind of the mission statement is bringing together community people, build these tools and share knowledge and best practices on how to re-host, re-platform and re-factor your apps to Kubernetes. Inside that conveyor community, we have really five projects right now that there's active development on. You can see them here from right to left. So we have the Forklift project, which is essentially about re-hosting your versions to Kubevert. So this allows you to actually import virtual machines in mass into the Kubevert project. We have the Crane project, which is about re-hosting our applications between Kubernetes clusters. It actually leverages the Valero project to do a lot of the backup and restore the Kubernetes objects. And then it also helps with moving persistent data between clusters. Move to Kube. This was recently open sourced, actually open sourced by IBM Research and placed into the community. It is a tool that helps you re-platform your applications from other content orchestrations to Kubernetes. So Cloud Foundry, Swarm and other technologies where you're already containerized, but you want to move to Kubernetes. The Tackle project, this is a new project that has just been kicked off and is scheduled to have their first community release in the June timeframe. And it is about helping people assess and analyze their applications for container suitability. So there's actually a manual data entry point for entering the characteristics of the application. There's a shared application inventory. And then there's a static code analysis piece that can actually determine how well your applications are to be conformed to the wall vector app kind of mindset. And then all the way over to the right is Polaris. This was actually developed by some folks in a consulting organization to help measure the Dora metrics. So the meantime to recover that your change failure rate and so on. And this is a project that actually instruments across various other projects running on top of OpenShift to measure your actual software delivery performance. So those are kind of the five projects that we're working on. It's very, I would say early days, they're all in different stages, move to Kube has releases. Tackle will have its first community release in June. As I mentioned, Crane exists and is available. Forklift is also available and Polaris is due. You know, I'm not the governance expert on this call. So normally handed over, I don't know if Josh Burke is on the call but he's been working with us to kind of put some governance in place in the community. So we do have some governance and like a contributor ladder that we put out there, it's all available to be commented on as well. But essentially this, the idea is that, you know, we would have kind of each community will really have its own guidance that it puts in place, but we'll have kind of a representative, a maintainer and a member representative in that governance. There's a link at the bottom. I'll share these slides. You can look back and provide feedback if you're interested. And then there's also a contributor ladder approach as well that's in there as well. So I did want, I just want to keep it really brief and kind of give you guys an introduction and actually open it up to more feedback or questions or comments. We're on the Kubernetes Slack channel. So pound conveyor on slack.kubernetes.io. If anybody wants to ever propose a meetup, we're very open to it. We have some pretty simple rules which are don't contain proprietary technology in your demonstration, make it demonstration-based so that you could show people things. And yeah, that's pretty much it. And then joining the quarterly planning meeting. So we're starting to have quarterly planning meetings for all the projects at the same time, just to kind of get everybody engaged so that if there are integration points or sharing that we could do between the teams that happens and it's open to anybody. So we have, you know, some financial services institutions that are going to be joining us in the June timeframe as well as I'm from Red Hat. So the Red Hat engineering team will be there as IBM research and some others. But with that, maybe I can stop my screen share and ask if there's any questions, comments. We're always looking for feedback on what we should be doing. We know we're early days, but we think it's a space that's, there's really not a very good solution for people that are looking to re-host, re-platform and re-factor their apps. Can you share your screen again and show me the five kind of sub-projects again? I can't remember all their names. Yep, I can either some days. So let me, let me show you those. It should be broadcasting. You can also find them on conveyor.io. Okay. I was just gonna ask about one, but I can, let me go over to conveyor.io and see. Oh, okay. So you said there was one that was looking at shared applications. Which one was that? Yeah, that's called tackle. So there is essentially, yeah, yeah. So that's essentially kind of a, it has an application inventory that applications can be added to, whether it's through human interaction or an automated machine-to-machine. And so that application inventory is then good. There's an assessment piece that is like, asking questions around the human factors around the application that you would answer. And then there's an tackle analyze, which is like the piece that hooks into that application inventory to do code analysis. Okay. Does that help them then decompose? Is that the point? So yeah, so the idea is to make the recommendations. We eventually wanna get to the ability to start to decompose, but that's a really difficult problem. So we're starting with like assess and analyze. And then we're actually the IBM research team is actually open to open sourcing several other tools. They're actually working on that right now to open source a couple of tools. One of them is called application container advisor. It uses natural language processing to see if what you enter in from a human standpoint relates to a specific container image. So it could kind of speed up the discovery phase if there was matching container images that could potentially help you containerize. So there may be some synergy between Artilius and Tackle because Artilius is organizing the decomposed applications into domains for driving a domain driven design. So then they can be shared across teams. We'd love to have something on the front of that though. Yeah, yeah. You said it's Artilius, is that A-R-T-E-L-I-E-S. Yeah, we'll definitely look that up. That's an incubating project in the CDF. Okay, cool. Yeah, thanks for bringing this up. I remember when we were working on the charter for SIG App Delivery, there were requests from people on how they can get applications to cloud native. So we kept it in scope. We just said we're not initially going to work on it because we didn't have frankly, quite an idea of what we could provide, but this looks interesting from a tooling perspective. So is your plan then also to have Conveyor as a CNCF project, or do you want to just keep the community closely related to what the CNCF is doing? Yeah, it's a really good question. I mean, the guidance I've been giving to all the teams in the community is like, let's get a lot of people using these tools. And I think we could sort out most of the other things later, right? Like it's not necessarily something that needs to happen right away. But of course, I think I also don't know the CNCF well enough. And so Josh Burke, he works closely with a lot of the CNCF SIGs, has been giving me guidance on this, but I'm open to, is it Conveyor that would belong, or is it the each sub project that would become one, a sandbox project in the future or something if that should come to be, right? So I don't know if it's like the whole community or if it's the projects, right? Individually, but... So we had obviously project portfolios in the past from like, especially a project maturity, it kind of gets hard if you have a lot of individual projects that you have to kind of all do the diligence on to gather, especially if they're in a different phase of maturity, it's not impossible but the more they were getting, the harder it obviously is. Having, if the requirement still is to have an independent or governance model that people are already familiar with within the CNCF, I think this could be something like in a sandbox project and then maybe governed by a CNCF, maybe a working group within CGAP delivery on like onboarding applications, if at some point we wanted to. I mean, this might be a, maybe a bit more, a longer discussions. I'm just always, because it's about product portfolios because they're kind of hard to work with. I mean, maybe Conveyor, you have ideas about this. This as well. It does definitely sound interesting from what they're doing. Yeah, I mean, I'm not personally hugely concerned with portfolio projects. I think that there are quite a number of them, although this is quite wide ranging. So it's very interesting, by the way. Yeah, I think, you know what, the reason we kind of like created this Conveyor umbrella was because we recognize that migration tools aren't necessarily long lived like platform technologies. And so, everybody's going to re-host their applications to a Kubernetes or CNCF model or what have you. And then they're going to have a continuous refactoring still going on, but those tool sets might change over time. So we wanted kind of the community brand of this area that is designed for people that are practitioners that are constantly modernizing apps. But we know that the tools inside may end up, they have a maturity or a curve to them where eventually they're not used two, three years down the line and there's new tools that are available, if that makes sense. Yeah. So is it, I've heard you mentioned IBM, you're with Red Hat. Is it predominantly Red Hat and IBM who are engaging on this project so far? Yes, yep. So it's specifically it's IBM research and then the Red Hat team. That's why we put that contributor ladder in place and governance and now we're starting to go out and engage with some of our, even our customers and users to encourage them to start to, so there's going to be some press coming out around KubeCon around this community and like us trying to kind of catalyze this community and get more contribution into it. I think it's an interesting project and I should definitely keep a close eye on this one and maybe have some follow up discussions whenever we see it fit, but it does fit into the some of the initial requirements we had there. And I think in some areas you're also pretty close to existing projects like Q-Bird, for example, that you mentioned when you want to bring something on this. So some of those sub-projects might then be, maybe fit better with them. But this can be a follow up discussion. So I definitely think it's interesting and it's great that you're working on it. It is a topic that many people are concerned with. There's maybe also other groups within the CNCF that are interested in this. There is a dedicated group that's more targeted towards this business and digital transformation focused areas. So, yeah, let me think a bit about it, but it's definitely interesting. I think it's definitely worthwhile having more of a discussion about this. The Dora metrics, how do you see this relating to the four keys project? That's a good question. I don't think at this point, I think this is really the Polaris project was a Skunkworks project created by some consultants trying to measure this for specific users and customers. So I think it could definitely relate to it. And I don't know if there's anything, is there a specific project inside of the CNCF? Is that the four keys project? No, the four keys project is the Google project that actually also measures the Dora metrics. Oh, yeah, yeah, absolutely. So we're aware of their project and we're essentially measuring the same thing. So, you know, are happy to, I guess, open to collaborating and working together on that. Yeah, but we haven't had any, I don't know of any specific discussions that we've had with that team. The consulting team that actually wrote Polaris might have had conversations with them, but I'm not familiar with if they have. It might just be good reaching out to them maybe and seeing where there are some synergies there between the two projects. I know that four keys is pretty related on Google infrastructure, especially from the database back end. So there might be also some, maybe some synergies on this project there. Okay, I'm looking at the time and this time I want to give all projects a chance to present. Yeah, thanks for sharing. Thank you for the time. Yeah, I really appreciate it. I will drop a link in the, in the note stock and appreciate it and looking forward to continue to communicate on progress. All right. Then we go to the next presentation for today, which is Lagoon. All right. Hello everybody. Yes, everybody can see my screen. Perfect. All right. Yeah. I'm here today to present to you Lagoon. Well, what is the mission of Lagoon? So Lagoon tries to drastically reduce the time required to bring your application to Kubernetes and not only that, but also with all the configuration tooling sites to actually run your application at scale and securely. Now, why did we create Lagoon? And I will shortly explain later who we are, but let's look at what are the actual problems. We work with a lot of application developers and they need to learn or to understand Kubernetes YAML and any application developers that comes from like the PHP world or so, if you show them a Kubernetes YAML, I've seen them running, screaming away and saying, no, I don't want to learn that. And so that's one of the things that we're seeing. The problem is that many tools that exist right now, they're all UI-based. They're not UI-based. They're CLI-based. And if you work with governments and other pieces, that's really hard for them because they're used to UIs to click around, things like that. Then there's also no automation out of the box, meaning that if you maybe have a CLI, you need to write like a GitHub actions or a GitLab or a Jenkins integration to deploy. That's just very hard for some and for many people out there. Then also there is no real good best practice around base images, meaning which images to actually use to deploy. Yes, there is Docker Hub, but they are maybe not secure or they're not maybe built in the best practices. And another thing is money of the tools out there that currently exist to application delivery, they maybe deploy your application, but then if you need to solve a problem, you need to have logging or backups and all these things, they don't exist. So we, as a company, we work with a lot of developers and so we've built the tool Lagoon and Lagoon is fully developer focused. What do we mean? First of all, you don't need any Kubernetes YAML knowledge or not even Kubernetes access directly. You can learn it, you can look at what actually Lagoon creates, but there's no need out of the box to learn someone with YAML. We also have local development included, meaning you can run the same environment locally as also in production or in development, meaning you have the same containers, the same images, the same system which is hugely important for application developers that need to recreate problems that they face in the Kubernetes clusters on their local. It's fully built around GitOps and infrastructure as code. What does it mean? There's no CLI that you need to run or install locally. All you do, you just push your code in Git repository and from the Git repository, automatically environment for each Git branch, for each pull request will automatically be created in your Kubernetes cluster. We have a full-fledged UI that has all the same functionalities as the API and the CLI. So also people like stakeholders, project managers, they all have also access to it. They can see what is running and not only the developers that used to have a token that have the CLI. Then Lagoon also includes base images for all different type of applications that are focused on security, ease of use. They have best practices in them that you usually don't find on the regular Docker Hub images. And Lagoon is multi-Kubernetes cluster capable, meaning it can deploy in a lot of Kubernetes clusters at the same time. And it's fully end-to-end tested. That means we actually start up a Kubernetes, we deploy different applications in it. We test all the functionalities before we release new images, new Lagoon versions. And logging and backups are automatically included. So when you use Lagoon or install Lagoon on a cluster, it will automatically start collect logs and show them to the developers so they can look at what is actually happening in their application. Now, how does Lagoon fit into a whole hosting stack? Well, in the end, we are fully based on Kubernetes. So Lagoon just has the requirement to have a Kubernetes somewhere installed. And that somewhere can be pretty much anywhere. As of today, we have Lagoon running in EKS, GK, AKS, and K3S. But in the end, there is no specific requirement on the infrastructure. So we have people that are working on getting and running on DigitalOcean, Alibaba Cloud, wherever you want to do it. Lagoon right now is focused on web applications. So it assumes a little bit that you actually want to show a website. But from a technical point of view, Lagoon just deploys containers. So you could also run some machine learning or run any other application and that you can run in containers. And we have existing templates for very well-known website frameworks like Drupal, our present Laravel, and we're in the progress to creating much more. This means if you have one of these sites, you basically just copy-paste a couple of configuration files in your repository, in your push, and it deploys automatically. If you use an application that is not, that we don't have templates yet, you need to config them a bit more than normal, but it should be quite easy to get your site running with Lagoon. Now, how does the Lagoon architecture work? I don't want to do a full intro into how or every single piece, but basically we follow a core and remote or agent structure, meaning a developer pushes into any kind of Git repository that can be GitHub, GitLab, Bitbucket, or whatever else. And this then informs the Lagoon core or the control plane if we use Kubernetes terminology about this. And then Lagoon core talks to the Lagoon remote that is actually running in a Kubernetes cluster. So that's an agent that Lagoon remote that you install. It's an operator based on the operator framework that basically connects back to the Lagoon core, meaning you can also run this Kubernetes cluster in an air-gapped environment because the connection is down from the Lagoon remote to the Lagoon core. And the Lagoon core basically tells the Lagoon remote, hey, there is a new deployment. It tells it which project, which namespace it should create, et cetera, et cetera. And then that Lagoon remote creates a Lagoon build pod, and the Lagoon build pod will actually clone the Git repository. That means the Git repository never actually goes, touches the Lagoon core. So the security of the code itself. Yep, well I lost him too. It's a great freeze. We all lost him, yeah. I see everybody else moving, so I assume it's him. Yeah. But it's such a wonderful freeze though. I love it. Yeah, let's give him Michael a minute here. Most likely he's still talking and realizing that he's actually frozen. He was on such a good roll too. Hello, sorry. You're back, actually. Strange. Let me share my screen again. It was just joking. How long you keep talking until you realize that nobody's going to hear you anymore? The strangest thing, I heard you saying we lost him. And I was like, no, I can still hear you. Anyway. What I wanted to say is that it's really important that the Git repository is directly in the intercubinators cluster. And that Lagoon build part, then this is the actual piece that then creates talks to the Kubernetes cluster. So it creates all the objects that are required, stuff like that. When the deployment is done, it then informs the Lagoon core again saying, hey, I've deployed what you told me. And then Lagoon core informs the developer back. So we have different notification channels that can be Slack, RocketChat, you can see emails, things like that. They just push into Git repository. They see a message, I'm starting to deploy. A couple of minutes later, it is deployed and they can look at the logs and they have their application up and running without ever needing to run any additional command. Now, where does Lagoon come from? Like I said, Maze.io is a hosting company and we used to deploy only Drupal. We had the first customer that came to us and said, hey, we want to deploy Node.js. Node.js has different versions. So our existing infrastructure at that time had no idea about Node.js. And at that time, also OpenShift Kubernetes came up in December 2016. And so we said, hey, let's give this Kubernetes a try. See here that we were focused on OpenShift at the point. We then realized that what we've built can be open source. We have the approach in Maze.io if something can be open source, it should be open source. So we open sourced in August 2017. August 2019 did a big rewrite with full role-based access control support, meaning that we could actually define who has access to what before it was like everybody had access to everything. And yeah, so we implemented that. Then during that time, we realized that we had more and more requests for just Kubernetes and not OpenShift. So we then implemented this in beginning 2020. We added this and launched in April 2020. So you can deploy just against the regular Kubernetes. And there's no need for an OpenShift anymore. And right now, we're really close to release Lagoon 2.0 which is probably going to happen in May this year. Which means that A, it's going to be more Kubernetes native. And we're also putting much more focus on people that want to use Lagoon to run it. Because right now, it was a lot of focus on the documentation on how to use Lagoon to deploy your application. And now we're focusing more on how to use your Lagoon yourself that you can install it and you can deploy applications into your clusters. Now, how is Lagoon used today? We have many different companies all over the world that already use this. Everything that Amazio does is fully powered by Lagoon. We have from governments to big enterprises, to smaller, to startups, to media houses. We use it via us. And that means we roughly have 2,000 production environments, 5,000 development environments, around 2,500 developers that use it. And around 800 deployments a day with right now 40 Kubernetes clusters that are deployed into all over the world in different systems. And one of them, even at AWS China, which is always a very interesting experience trying to deploy through these systems. Now, how is Lagoon connected to the CNCF? Lagoon already uses a lot of tools that are either CNCF incubating sandboxes or just Kubernetes tools. Under the hood, we use Helm, we use Fluentee, Prometheus, Grafana, we use Harbor with the image scanning, we use the open policy agent, we use the logging operator from Banzai Cloud, we use KTOP for backup. So we really try to use everything that already exists in the system. So even if it's only like an AD or 70% fit, we use an already existing tool and maybe contribute and make it better than implementing it ourselves. And yeah, from a media IO, we're fully committed to donate Lagoon as a sandbox and follow the guidelines that are required. That also includes we have dedicated Lagoon product leads. His name is Tobi, he's in Australia right now and it's very exciting. And we have developer advocates, we have product designers, we have engineers that purely solely work on Lagoon and make sure that it continues. A media IO always has a marketing team, so a media IO will also support the Lagoon team for marketing. And very exciting, we have the first organizations today that are technically competitors of a media IO that are looking into adopting Lagoon to powering their pass to power. And they're looking at how Lagoon is going to be very time and money intensive, so they looked around and found Lagoon and they're actively evaluating if Lagoon could run their platform as a service as well. What's ahead, I mentioned the CNTF sandbox, we're finishing moving everything into the use Lagoon GitHub organization, it used to be still inside the media IO and then we will apply the CNTF sandbox. We're looking into creating more templates for other applications and we're looking into communities like the Type 03 or other communities to reach out to them and learn how exactly we can build these templates. There's a huge security push right now, as we're working with a lot of governments, they have really strict security requirements, so we're working on this, we're working on this, we're working on this, we're talking about enforcing network policies, have gatekeeper, use more the capabilities of Harbor like image scanning and stuff like that. We're also working a lot of on portfolio management, that's basically if you have 400 websites that you need to deploy and that you can say redeploy me all the sites and it automatically does a lot of work to upgrade, how to handle issues and things like that. And overall, we're just working on creating a community around Lagoon and that's where we're here. If you want to learn more, Lagoon.sh is the website that currently redirects to an ACIO, it will eventually have its own, we have an extensive documentation and the two GitHub works and like I said, it will be all in the use Lagoon very soon. I'm happy to answer any questions if there are any. Let's go first here. If nobody starts in Azure, I'll just kick it off. How many external contributors outside of Macy are there on Lagoon right now? Not that it's a requirement for Sandbox, but just because you mentioned 2300 developers and I think we lost him again, but we always lose him in a way that we're never sure whether he lost him or not. I think it's a unique opportunity when he freezes, he actually looks normal and usually people look like. It looks like my internet decided to die again, sorry. My question was is this currently mainly driven by Macy because you also mentioned having a lot of developers, so are these developers using it or are these developers actively contributing to Lagoon? It's mostly developers using it. In total, we have 80 contributors right now and we only have 20 employees, so there are 60 other people that have contributed, but it's really just smaller things right now in terms of fixing bugs, adding some better documentation, improving some of the features. But like I mentioned, these companies that are interested, they are fully also committed. If they will choose Lagoon, they will contribute back in one thing that we have, for example, is the GitLab integration and they want to improve the GitLab integration, therefore they would fully contribute back to the tool. Did you say was interested in that? Did you say who it was? I'm not sure I'm allowed to say. No problem, I just wasn't sure if I missed it. It's a US-based company that basically does hosting for a single site. They also come from a world where they spin up easy two instances for every single site and they want to use containers and they are now looking into a way how to modernize their infrastructure with Kubernetes. It's interesting that you called out that this is a hosting provider. Are most of your users hosting providers? Yes and no. We definitely see some interest in the business of bringing people to their hosting platform and giving your customers that you don't really know access to your Kubernetes cluster is always still a bit freaky, especially if you have like a multi-tenant Kubernetes cluster. So because of that the fact that you don't need to give customers access to the Kubernetes cluster is very interesting to them. We do though see web agencies, so customers that build a lot of websites for a lot of different customers and they need development Kubernetes cluster that they start to use this or companies that say we have a university in Germany that uses it, which said we want to give all the different departments, they all have websites that they need to host and we want to give them access to the Kubernetes cluster and again the same problem is they have no idea about Kubernetes. So it's mostly in the environment if you have many different people that maybe don't know too much about Kubernetes but you want to allow them to use it. I mean some other projects by the way could think about like working with all the beyond projects, also the GitOps working groups in the CNCF which I highly recommend you to work with. Cornelia was pretty quiet not asking you any questions. I was waiting and I definitely noticed that for example Flux wasn't on your list of technologies but you're doing a whole bunch of things that Flux does like cloning Git repositories and sending out notifications and tooling all that up, sure yeah, would love to see if you're interested in that. Yeah, I mean that's definitely something that why we want to also go into the CNCF to maybe actually rip some of the code that we currently do, we want to go out and replace it with existing other tools. We really see Lagoon as like a tool that basically a bit opinionated combines existing CNCF projects together into something that you can install and in one click deploy and so the last code we need to maintain the better. Omar also mentioned Argo, we also mentioned Argo in the past and so yeah, it's really about figuring out how could we best work together with others. Those are the base images I think it's also looking into cloud native build packs, so how are you building containers right now? As of right now it's just a docker build that runs inside the build pod that runs docker in docker so it's very well I would say archaic right now but that's another thing that we would also look like to understand a bit more because when we started the only piece that I really found that did actually building in the Kubernetes cluster was OpenShift with their source to image and now in the meantime, yes, there have been many other ideas how to do this also how to run like it with other docker demons like Potman came up or Container D that didn't exist in the beginning and some of them also allow you to like rootless and things like that, so that's definitely another piece that we're interested in to collaborate and figure out better ways to do it and just start to docker in docker all the time Yeah Good call on alloys, I was thinking about the cloud native build packs as well Yeah, because they're more like a Heroku pattern of and the pivotal pattern of a lot of those things Yeah, so another question, how complex can the applications be that you run with like you mentioned mostly websites which are not that complicated from the structure so how if I run a complex multi complex microservice architecture that consists of a multitude of services is this something you I mean you run an opinionated approach if you say this is not what we want to do because this is not what a certain target audience needs it's totally fine, just curious Yes, no, I mean so interestingly most applications that we run already exist of like 5 or 6 parts that need to work together like if you look at the Drupal you have an Enginix, a PHP you have a MariaDB, you have a Redis you maybe have a Solar so it already gets quite fast, quite complex and that's like the standard for any bigger Drupal site or WordPress site needs these but in the end there is no limit on how many let's say parts or containers you could deploy inside one Git repository actually Lagoon 1 uses Lagoon to deploy Lagoon and we wanted to do a bit inception and eat our own dog food we realized though this is very hard to tell people how to install because if you don't have a Lagoon how to install a Lagoon that's why we now actually moved into Helm so to run Lagoon Core in remote you just use Helm but Lagoon itself has around 25 microservices that worked together and that was deployed by Lagoon and it worked without a problem so you can definitely use it for more complex and we have some customers today that will run like newspaper websites and they had most of them are like quite complex like they have different frontends for different websites with one single backend and like an importer and stuff like that so yeah you end up running like 20-30 parts very fast and Lagoon easily deploys that by the way Flux2 has an interesting approach where Flux2 actually deploys Flux2 which is very nice so it's a good option itself which is kind of an exception but to be fair we have to deploy the operator via Helm which makes sense another project I would propose to look at I think we will run out of time today is how you actually model these applications because OEM is definitely a project to look into Thomas who is also here and the rest and Alex who look into like an application enablement working group here because like there are many new native approaches out there that are getting started right now which I think is great and useful I think just some interoperability at some point because there is also a community to engage with they did not present today but the last time so happy to share the links there but yeah I see it's definitely becoming more and more like different types of templating mechanisms OEM, KubeVela would be like I think the most similar project that I could think of would really be KubeVela most likely which is also at an early stage to maybe engage with not saying that you have to as a sandbox project this is always to provide some some feedback here but I think it's good to see this project emerging and again also if you need connections to those projects we can obviously also help there as well thank you we are out of questions right now I mean the criteria for sandbox are I think pretty straightforward and you're doing some of the right things like putting it into its own organization right now it has a bit of a feel that it's an amazing project and it's more like an open core which isn't a bad thing either or a bit more than open core here it's a bit on the external contribution and it's totally fine also for its sandbox to be there just I think just as part of this having an idea on how you want to grow especially your contributor base beyond yourself independent governance is obviously one first step but you mentioned contributor letters and things like this which is good we are fully aware like that was actually we talked about like almost a year ago to donate it as sandbox and at that point it was still like too much for the CIO but now with Lagoon too we actively have work where we remove everything and make sure that other people can use it plus we now have like the companies that I mentioned they're now starting to actually use it deploy the first test project so we have real world example that other people beside of us can actually use it because we obviously have like huge imposter syndrome that we feel like no it's always going to be you can never run this outside but seeing others actually do it on a daily basis is pretty cool and I think they gave us also they believe that what we have built can be also used by others or is interesting to others okay so we have depends on how you see the agenda if we go for the full hour we have 5 minutes left or we don't have 10 minutes over as a point of perspective Cornelia I still want to give you some chance to quickly talk about the Github's working group sure yeah and I have a hard stop at the top of the hour but it will only take a couple of minutes so the Github's working group just a couple of updates I think most people know that we are doing a Github's con the Github's working group is hosting that and that is a day zero event at Github con virtual of course we just discovered yesterday that we completely dorked up the times and we have it scheduled for like 5pm to 10pm Central European time and so we are nudging that we are splitting the difference so that west coast people don't have to get up at one but can get up can participate at 5 or 6 in the morning so we are making adjustments on that call for papers closed on Friday the committee is meeting today to do its final selections and we will be publishing the agenda for that a couple of things that I do know is that the CDF, Tracy Reagan is here from the CDF Tracy Moranda who is the executive director will definitely be on the agenda so she is doing an invited talk because we want to make sure that we are linking these two communities and the CD con has a day zero event which is also Github's focus so I will put in a little plug for that as well called the Github's summit I think so that's good stuff happening like I said the agenda will be posted in the next day or so and we will be letting people know about those submissions and the acceptances the second thing that the team has been working on really significantly are the principles there is a pull request and the Github's working group repository that defines the principles and so there has been both asynchronous collaboration through that PR primary thing we have been hosting a number of synchronous meetings where we can have live conversations those are all recorded and posted in the results of all of those things are folded back into the PR so anybody who can't make those is not at a disadvantage and I think those are the two main things to talk about at this point just as I should notice but I don't have any questions so this is what I'm asking did we already get this on the official cncf calendar because it was an amy okay yeah oh and the other thing maybe that I haven't mentioned is that we did tease apart when we submitted when we created the Github's working group we submitted as a sandbox project which is kind of a weird thing to put with the Github's working group and the TOC said we're not going to worry about that they'll straighten that out well the confusion was pretty big right from the get-go and so we have teased that apart we now are naming the sandbox project open get-offs the working group cares for open get-offs and that sandbox project is the place where all the long-lasting artifacts like the principles like educational materials like any code samples, things like that will be housed under that and so we have started to clean up some of the mess that we made when we came in that is a good exciting news and also I think I found that there are events everywhere I think it's good and yeah maybe we post in the meeting notes like the current state of the principles sure which reminds me one last thing is that at KUKON we did have a TOC get accepted for just the get-offs working group update which is something that Chris Sanders from Microsoft and I recorded just earlier this week we were the bad folks that got it in way late but we did get it out Monday so we recorded that and it only was about a 20 minute recording because we wanted to leave lots of time for people to ask questions so we have a session where we do review the principles as you just pointed out in their current draft form and then we will answer questions great updates going to see the principles come along and now I think everybody is happy calling them principles and no longer a manifesto yep which is fine I see manifesto getting used all over the place and I completely am very sensitive to the fact that triggers some folks it's a mixed bag there's still lots of people using it okay yeah thanks yeah and let's share the link to the current principles okay we'll do maybe something to bring to the wider audience at a given point in time here what's in there especially if you have questions and with this I think we are done for today I think we'll meet again in two weeks from now that's the week after kubicon if I'm right am I right kubicon is not next week actually you were in the middle of kubicon so maybe we cancel yeah I'd say we cancel because it's in the middle of kubicon let's cancel yes it is in the middle of kubicon I lost a week in here so I will go ahead and kill that meeting for the fifth cool because it's very unlikely that people are going to join go to kubicon it's fine it's fine you're still here a lot of what's on native there that's fine okay then thanks everyone and have a nice evening, rest of your day bye