 Well, since this is the last session of the day, I am going to go ahead and start right on time just to hopefully get you out here maybe a few minutes early, depending on the number of questions you have. So my name is Paul. I'm going to give you a couple of warnings real quick. I do have a tendency to wander. So if I wander too far away from the microphone, if somebody could just wave their hands and tell me to move back, I'd appreciate that. The second is that I am not a Kubernetes expert, and Kubernetes is often associated with GitOps. My interest in GitOps came out of being, my experience is as a developer. I'm not an infrastructure person. My interest in GitOps came out of being part of a team at the University of Missouri, where we were tasked with modernizing and making our workflows more efficient, which meant lots and lots of meetings with our infrastructure team. And that's where this first concept, this term came up of GitOps. And as a developer, I thought it was in my best interest to really have a good understanding of what that is so that I could be a better developer and take advantage of this. And I mentioned all that to say that this is not going to be a deep dive into how to implement GitOps. This is an introduction. So if you're looking on, if you're expecting to learn how to implement Hex, I just forgot all my terminology, or how to implement a GitOps, that's not what this is going to be. Instead, what I'm going to do is I'm going to go back through kind of the challenges in the history of our industry. So how we got to a point where GitOps is a solution that we might need. We're going to define GitOps and then talk about the principles behind GitOps. We'll talk about how GitOps is different than DevOps. We'll talk about the advantages that GitOps can bring to your organization. And since many of you, since this is DrupalCon, many of you are probably developers, I'll talk a little bit about the specific advantage that GitOps brings to the developers. And then we'll talk, and I don't like the word disadvantage. I probably should change that at some point. It's not really disadvantages of GitOps, but the things that GitOps doesn't address. So again, I have a background in higher education. A lot of my analogies, a lot of my examples are higher ed focus. If you're not, I'll try to also give some other ones. But just remember that as I'm going through. So the challenges that we've always faced ever since we started putting things on the web is that in order to thrive, we have to innovate, right? Whether that's driving enrollment in a university, or you're trying to deliver new amazing digital experiences or features for your clients, we have to innovate, right? But innovation comes with complexity. Whether that's that you lack the resources or don't have enough talent in-house, we're probably all under time constraints or budget constraints. But it doesn't just stop there, does it, right? We have, as we're trying to develop these features, as we're trying to deliver these new experiences, we're having to deploy and deliver those features faster and faster and faster to keep that innovation going. Your developers are probably often pushing the stack, right? They need the newest run times. They need the newest services. They're pushing that stack constantly. That can lead to stack diversity. So way back, most of us were probably on the lamp stack using Apache. At some point, you might have realized that Nginx was a little bit faster to respond to things. So you developed an Nginx stack, and now you've got two stacks. And maybe you've gone to different vendors. Maybe you ventured out into virtualization or containerization orchestration. You might venture out into new software architectures like microservices and decoupled. And somewhere, somebody is probably saying, hey, wait a second, has we create all this diversity? What about standards? What about compliance? What about security? That complexity is challenging to adapt to. It's hard to move fast, especially historically. If you've got all these different applications, all these different stacks across different vendors, that development to staging to production workflow can get bottled down. And your teams end up spending more time fighting that infrastructure and solving problems inside of that infrastructure. Instead of developing those new features. It's also hard to collaborate, especially historically. Oftentimes, in the past, your operations team, your infrastructure team was siloed. They were a completely separate team from your developers, which was a separate team from maybe your marketing and communications people. And they often had competing goals. So your operations, your infrastructure people, their goal was to provide a healthy, reliant, stable platform for you to develop on. And that often meant getting it to that point and then freezing it. But we already talked about how developers are always needing to push that stack, right? So we've had these competing goals, which often leads to delays and frustration. In addition, if you didn't design that stuff from the beginning to scale, you could suddenly find yourself not being able to withstand that capacity, that incoming traffic. Or maybe you've decided or you had a need to scale out horizontally. You're adding more and more and more sites and trying to keep your arms around that complexity, that diversity gets really, really hard. So sometime around 2007, 2008, this idea, this philosophy of DevOps came about. And if you're not familiar with DevOps, it is a philosophy, it's a cultural change where you break down the silos between your teams and you bring these different teams together and you give them a singular goal instead of a hyper focus on satisfying that customer. And you do so with quicker iterations on products. So it features collaboration between those teams. You're also going to automate as much as you can in that software development life cycle and do that continuous improvement. The big advantage then is you have this improved collaboration or improved communications between your teams. You have these shorter development cycles where you're releasing smaller bits but in a faster pace, which often leads to reduced deployment failures because you have less that you're introducing each time, it's more easy to go back and find those problems. So you end up with faster delivery features and hopefully more time to innovate. But notice the big piece that's missing is that infrastructure, right? Because up until that point, we really couldn't automate a lot of the infrastructure. It was a lot of manual processes. In fact, how many of you are old enough and are willing to admit old enough that your first system, your first application, your first website that you deployed was to a physical server? Oh good, thank God I'm not the only one. How many of you that physical server was under your desk? Yeah, all right, so back in the old times when you had a system, when you had a website or web application, it was on a physical box, right? An actual box that had to be paid for and those things were expensive, right? So it was very rare for organizations to have true development staging and production servers because that's three different physical boxes. As we learned best practices and discovered, hey, you probably shouldn't run your SQL server on the same box as your web server. Well now suddenly we have six servers to try to implement that workflow and that's really, really expensive and it's also a lot of manual labor. There's a system administrator that had to physically set these up. So sometime in the late 2000s, you know, 2008-ish, we saw the rise of virtual machines. Virtual machines allows us to run virtual servers on top of a physical piece of hardware and it became much more economical for us to have multiple servers. So now a lot of organizations began to adopt staging and development production servers. But at that time, it still required usually a system administrator to go in and install the OS, set up everything, set up all the software, make sure it was working and there was very much a pet mentality. In other words, we gave them names, we housed them, we fed them, they got sick, we nursed them back to health and as they aged and got older, we retired them to a data form upstate. Okay, I thought I was gonna get a couple of laughs, but okay. So sometime around the late 2000s, early 2010s, we saw the first iterations of configuration management like Puppet and Chef and this was a big step forward. Now what we could do with these virtual machines is once they were provisioned, we could go and install an agent and then that agent would run through all the rest of the configuration on the setup. That was a big step forward. One of the problems though was systems administrators are not developers and had not at that point adopted version control. So there wasn't a lot of central management of this configuration, so you ended up still with a lot of drift between systems administrators or even systems themselves. How many of you that remember deploying back to physical servers or virtual machines had problems where you'd identify a bug in production that you could not replicate in development? Yeah, because of this little bitty drift, all this little drift. So these were a good step forward, but not quite where we needed to be. 2010, 2011, we saw the second generation like Ansible and Saltstack, which took over the provisioning and the ability to install an agent and set up all the configuration and that's where we really began to see the possibilities of automation where we could begin to centralize these scripts and automate the provisioning setup. About that same time, early 2012, is where we saw the beginnings of cloud infrastructure being offered, so AWS and GCP, et cetera. And if you're not familiar, you're probably familiar with cloud infrastructure, but it's physical hardware, but through virtualization and software, these resources are available to rent out to you on demand, so CPU, networking, data storage, et cetera. And they all introduced their own versions of infrastructure as code. So on AWS, it's Amazon cloud formation on Azure, it's Azure resource manager, but they were all slightly different. So we still had this problem where if you were on AWS back in the early 2010s and you wanted to go to GCP, it was pretty hard because you had to essentially rewrite all of that infrastructure as code. So in 2017, Alexis Richardson introduced this idea of GitOps and he was the CEO, I believe he's still the CEO of Weaverx, and he had this idea. He said, why don't we take the very best of what we've learned from DevOps and apply it to the automation of infrastructure? And he had this idea of taking from the sys admins and bringing the control and the ability to deploy this infrastructure back to the developer who needs it the most. And he had a grand idea that eventually the deployed systems would be able to monitor themselves between the desired state that we want to the actual state and heal themselves. Now anything that kind of gets some legs underneath them, kind of gets a momentum behind it, it's eventually too big for one person. So eventually the cloud formation, the cloud-needed foundation, excuse me, took over GitOps as a working group and solidified some core foundations, some core principles of GitOps. And I'm gonna go through these and then we're gonna walk through each one to make sure we're clear on them. And that is that the entire system is described declaratively. The canonical desired system is stored and inversioned inside of Git. Approved changes can be automatically applied to that deployed system. And that some software agent inside the system is continuously diffing between desired state and actual state and reconciling that. So I wanna talk about each of these principles. I'm gonna move just, Mike, just a little bit so I can come out. All right, so the first one, a system managed by GitOps must have its desired state expressed declaratively. So what do we mean by a system? How many of you have tried to set up a Drupal site on AWS? Anybody? Okay, you know it looks like this, right? That is a heck of a lot more than a web server and a database server, isn't it? It is all the pieces. It's all the environments. It's all the runtimes. It's all the software inside of an environment. It's all the services. It's the networking. It's the load balancing. It's the VPNs. It's the IM groups, all the access controls. The system, when we talk about GitOps and a system, we're talking about all of the infrastructure components that make up what your application needs to run. All right, so the next one is desired state. We need to describe or we need to have a desired state. That is the aggregate, all of that system, a description of all of that system that it is required so that we can implement or deploy an instance of that system such that it is behaviorally indistinguishable one from another. The last piece is that it should be described declaratively. So in the past, back with like puppet and chef in the original versions of puppet and chef, it was very imperative scripts. It was install this thing, then do this, then do that. And instead now with GitOps, we don't describe how to get somewhere. We simply describe the end goal. This is the system that I desire. Everybody clear so far on this first principle. All right, good, fantastic. All right, so then the next one is interesting because one way they describe the second principle is it's in Git. Technically it doesn't have to be in Git. It just has to be versioned. There needs to be authentication. There needs to be versioning or some kind of log. And there ideally should be some type of metadata around why and how that decision came to be to change the system. But when you read that, what does that describe? Git, right? Especially the version control system management systems such as GitHub and GitLab and FitBucket, right? So technically if you wanted to, I mean, Google Docs has versioning, you could do GitOps and Google Docs. But it was designed, it was thought of in terms of Git and these version control systems. The next one is that software agencies, or sorry, software agents, automatically apply that desired state once it's approved into or deploy out to our systems. Now, the important bit of this is there is a clear delineation between where we store that desired state, that infrastructure that we want, and the actual implementation. So that keeps all of the credentials, all of that information is on a separate side. We don't have any of that in that repository where we're describing this. We keep it all on the other side. A clear delineation. There are two types of ways we can do this. We can either do a push or we can do a pull. So we can either approve the changes and then push them over across the wall onto the other side, or the agent on the other side can be watching for changes and then pull those in once those have been approved. That last principle then is that a software agent is continuously observing the systems and comparing it to that desired state that's been approved, looking at the current state and trying to self heal or trying to reconcile that stuff. And then if not able to, then involves a human, alerts a human for human interaction or human involvement. So here's kind of a diagram of how this might work. So it doesn't take away your operations teams. I wanna make sure that's clear. It does not take away your operations teams. It simply separates the concerns about who is involved with what. So you still have, and hopefully you can see this laser pointer, maybe not. So you still have a developer, right? And we've exposed controls of this infrastructure down to the developer. So the developer says, hey, I need a node environment. I need a node environment at version 16, all right? They can push that up to the repository, start an MR, start a PR. And now everybody that needs to be involved can be involved in approving that change. Once that's been changed and approved, it can kick off a pipeline to build an image. And then that software agent watching can pull that image in and deploy it out to our cloud resources. In addition, we might have software reliability engineers. That's what that SRE stands for. Those people are in charge of all that stuff the developer doesn't wanna worry about. Load balancing, network, firewalls, all that stuff. That's not a concern to, I mean, I don't, I don't particularly care about that stuff. As long as it works, I'm interested in PHP 53. 53, 83, let's go with 83. PHP 83, 53 is really old, sorry. So PHP 83, right? I'm not concerned about any of the rest of that stuff. But somebody has to be. So they can be working on that, send their changes out, work through the same workflow, maybe have pipelines, and that system can be watching for those changes and implement those. Everybody's still good. I know it's late in the afternoon, everybody's kinda quiet, it's all right. So then how is GitOps different from DevOps? Well, DevOps is more of a cultural change. It's breaking down those silos, giving everybody a similar goal, similar, not requirements, but a similar set of goals. In fact, hyper-focus on the customer and delivering those features and automating as much of the software cycle as possible. GitOps is entirely focused on a framework of being able to apply those best practices to infrastructure automation. So you can do DevOps and not do GitOps. You can do GitOps and not do DevOps, but they are very complimentary, they go very well together. So if you are doing DevOps, it is a good idea to begin to look into GitOps to see how it can complement your DevOps philosophies. All right, so why? What are some of the advantages that we can do? Well, a big one is you have greater deployment frequency. What I mean by that is in GitOps, one of the things we said was a principle was we have to be able to describe that infrastructure in its totality such that we can create it again and they're always going to behave the exact same way, right? So if I create an environment based on that information in a pull request and I test it, how should it function when I deploy it? This is where you answer me, just... How should it work? Exactly, it should work exactly the same way as it just did because they should always be the same. That's the whole point. So you can deploy much more frequently because you know what you're deploying has already been tested. It is going to behave the exact same way. Yes, you have much greater frequency in deployments. You also have a quicker time to recover from an incident because just like with Git, if I have code, if I have a bug that's been introduced to code, I can roll back to a previous Git commit. Those Git commits are immutable. I know that that commit has been tested. So now I can roll back all of my infrastructure and I know that when I deploy it, when I've rolled back, it's going to behave exactly the same way it did back at that previous state. It's also less error-prone because we've removed a lot of the human interaction for Drift to be introduced. We've automated a bunch of it. In addition, because we've involved Git, pull request, merge request, some auditing on it, it should be less error-prone because more eyeballs have been on it. They've all looked at it, tested it, plus we can actually run it through testing before we move it on, which all improves your security and compliance because each of these systems, especially if you're starting from a base collection, a base repository, they should all be working exactly the same way. You can bake in those security requirements and you know that every instance that comes from that repository is going to have the exact same security, the exact same compliance. In addition, all of the configuration for the infrastructure is typically in YAML or JSON or something like that. So it can be easily audited and all the changes are in Git, so they're versioned so we can go back and see exactly who did what, when, and where. All right, so how many of you are developers? Okay, good, good, okay. So what advantages do you get? Well, the big one that Alexis envisioned was that we're the ones pushing these things, right? We're the ones pushing the stacks. So why not get that control that allow us to decide what it is we need to do to do our jobs? All right, so the big push in GitOps is to expose that back to you so that if you need, again, like a Node-18, you need Python 39, whatever it is you need, you should be able to say, I need this push and deploy and get it so that you can begin to innovate. He had this grand idea that the whole experience for the developer, all they would need to do is Git add, Git commit, Git push, and now you've got your infrastructure. So you're probably all using Git, most likely, or some version control of some sorts, right? You've probably all used YAML files and JSON. So the onboarding is much easier because it's all things you're already familiar with. Plus now, if all of my infrastructure is deployed and managed through GitOps, it's all gonna work in a similar fashion so it doesn't matter what runtime it is. It doesn't matter what service it is. All that matters is changing the name and exactly what I want and describing it. Otherwise, it's the exact same. So onboarding new developers is much easier. Now I will say that my co-worker from the University of Missouri tomorrow is doing a talk on Thursday about onboarding and some of the challenges they still face, but in general, GitOps should ease that onboarding process. The big thing for me, though, was the same realization that I had when I finally learned Git and that was I could experiment and fail with confidence that none of that was going to leak back into my production systems, right? Like if you have a new idea and you want to test it out, you can take a branch on Git, right? Because branching in Git is cheap and easy. Create a branch, play with it. You don't like it, you cut it off. You do like it, you merge it in. It's very quick, easy, it's cheap to do. That same philosophy now applies to your infrastructure. If you are suddenly going, hey, we should experiment with how our module functions in PHP 8.3 because it's coming up in less than six months, well, it's just a branch and now you start working. If something comes along and, hey, there's a bug, we gotta go fix it, you can leave that branch, switch back to your production branch, make your changes, push them out without having to worry about that going away or disappearing or leaking back in, you can then take any of those changes that you had to make and incorporate them back into that branch. This is the same thing for now for infrastructure. You wanna play with Node, it's just, hey, I want Node. You wanna play with Python, building out some APIs. You should be able to just say, give me Python 3.9 and let me go, all right? All of that now is given, that control of this infrastructure is brought back down to you who are doing the innovation. And so then, because you can experiment with confidence that you can fail and then retry and learn from that failure and do it again and again and again, all that's gonna lead to faster iterations because you don't have to worry about waiting on a ticket for somebody to create that instance for you. You don't have to worry about taking down your current development server to bring up another one. This is gonna allow you to iterate much faster. So some shortcomings of GitOps. Again, I don't wanna say disadvantages, but you kinda need to be cloud native or at least be heavily into containerization and virtualization because you've gotta be able to automate these things. Gotta be able to describe it in a declarative fashion and then have something be able to read that information and deploy this. You end up with a lot of Git repositories, right? All of your infrastructure now is being described and it's gonna be stored in Git. Each project might be its own repository, so you end up with a lot of repositories, which can make auditing a bit more complex. It's all in YAML, it's all in JSON, but it's spread out across all these different repositories. You kinda gotta bring them all back in together to do that auditing. It lacks input validation. So depending on how you're doing that declarative statement, GitOps by itself is not going to ensure you've described that correctly. That's going to be on you to decide how you want to implement, whether you're gonna use something like a Terraform which will do some input validation and then also translate to the different cloud providers or you're gonna do something in-house. It doesn't address persistent application data, so your database storage, your file storage, it doesn't address that. It also doesn't solve centralized secret management. So if you've got API tokens that you need to store and inject into those environments, GitOps by itself does not address that particular piece. That's another piece that you're still gonna have to figure out. So in grand terms, GitOps is a wonderful idea, right? In fact, let me ask it this way. How many of you have worked in a DevOps shop? Because DevOps is a solid philosophy, right? How many of you worked in a shop where they've done DevOps or they've done Agile and it's definitely not Agile or DevOps-y? Yeah, right? Okay, so there's a big leap from the philosophical ideals, right? And I liken it to when you see these kind of tutorials where it's like, okay, you wanna draw an owl? Okay, draw two circles, now finish the owl, right? There's a lot of steps in between. So there are a ton of tools and resources available to you in the open source world to do your own implementation of GitOps. Flux, Helm, WeWorks has a whole collection, a tons of different resources, but it is left for you to figure out how to get there. So if you are sitting there going, GitOps sounds good. It is going to complement our current workflows. I like these ideas, but I don't have the resources. I don't have the talent in staff to maybe implement this. I definitely wanna check this out. At the university, we ended up going with a company called Platform.sh. That is the company I work for now, so I will let you know. And we did that because they are based on Git. They are a fork of Git with proprietary technology. They have been GitOps for over 10 years. That is their entire workflow as a GitOps workflow. Everything I've talked about, they've already solved. All the secrets management, persistent data, all of that, they exposed the infrastructure back to you as code, so you as a developer can stop focusing on infrastructure and start focusing back on developing those new features. And in fact, if you remember, Larry Garfield who used to be big in the Drupal community, he once said that Platform.sh is in a sense, you know, not having to build and maintain a complicated GitOps pipeline as a service. So again, we've taken over all that ops piece of GitOps, all that site reliable engineer, reliability engineer piece, all the security aspects, the compliant aspects, all those pieces, and given that back to you so that you can implement a GitOps workflow. We can't make you a GitOps shop. Can't do that. That's still kind of a cultural change, but we can certainly give you a good foundation and all the tools to adopt that GitOps mentality and have that cultural change at your organization. Now, if you instead would prefer to do that in-house, tons of resources available to you. The top two are part or owned by the Cloud Native Foundation and that working group for GitOps. Of course, GitLab, Alasin with Bitbucket, GitHub are all gonna have articles and tools on how you can adopt a GitOps workflow because obviously they're part of that GitOps workflow. It's in their best interest. And that last one is actually really cool for a couple of dollars worth of AWS resources. It's a tutorial, a tutorial that will walk you through all the steps necessary to implement your own instance of a GitOps workflow on AWS. So it's really cool to get your hands in there and kind of get dirty on how all these things work and how the system really works. All right, so that's kind of my talk. Oh, good, that's about exactly what I wanted it to be. So that is my business card if you'd like to get a hold of me, but I'd happy to take on any questions that anybody has. You're all either stunned or I didn't make any sense at all. So it could be Kubernetes, it certainly could be Kubernetes. That's why I mentioned at the beginning, Kubernetes is often associated with GitOps, but it can be any containerization orchestration system. Doesn't necessarily, oh, the question was, is it usually going to be Kubernetes to do this? And it can be any orchestration system. What are we going to do instead of... Oh, that is a good question. Help me out, Hailey. No, it's not CLX, oh, I can't remember them. LXV. Thank you, what was that? LXV. LXV. Okay. I know there's more. There's a lot of different orchestrations, but Kubernetes is often associated with it's kind of the big one. Any other questions? I think another thing really... Very quick. ...and it also... Yes, exactly, because if you need to scale, all you have to do is change the configurations. All you have to do is say, okay, instead of one CPU, we want two CPUs, or however you ended up describing that. And exactly, the disaster recovery is much faster because you can roll back just like you roll back code. And you know it's going to behave exactly the way it did at that point because that point is immutable. It's not changed. I have one more question. Sure. So there is going to be an agent, a GitOps agent that you'll install into the deployed infrastructure. And what it's doing is reading the configuration files of the current, of the desired state and comparing them to what is actually there. Then that will begin a process of trying to re-implement the desired state. Depending on which one you use will have different ways that it does that. Kubernetes has its own self-healing, and I forgot what it's called, but Kubernetes has its own. Each implementation is going to have its own version of how it does that. But it is going to simply read that configuration and compare it to what's currently in production and attempt to reconcile. Yeah. How on earth would those things ever get out of sync? I mean, if you're using a YAML file and you're using a DevOps to deploy and create your infrastructure, how in production is that ever changing? From what? Wow. I'm going to say I do not know how that would happen. I mean, humans, I think I just blocked out my screen. Sorry about that. It could be human interaction, although it shouldn't be possible, though I guess if, because of all the credentials are on the implementation side, if somebody had access to them, they could make that change, although they shouldn't. I don't know of another way it could, but I'm sure it is, since that is a principle of it. Yes? In the changing of the host, it can change. Okay. Then we are trying to replicate the local environment with the Lando and Docker combo. But this approach, I think, from first we are doing in the local with Docker combos, how they acquire our pantheon support. So it is very similar. It's very close. The difference in like a Lando or even a Ddev is going to be that it is probably going to use an actual image, the same image, that has already been compiled as an artifact versus reading configuration files and then have the software agent. So that's going to be the big difference there. I'm sure pantheon is probably doing a GitOps thing. I know they host on AWS, if I remember right. And oh, they do do both. Okay, so they do both. So they're probably doing a GitOps flow of some sort already internally, if not exposed back to you as a developer. Okay. So they have a GitOps workflow, they've just limited what is exposed back to the developer. Yeah, because they've limited what you can do. You've adopted their Git workflow, our GitOps workflow, which then you can't control, which would be an advantage if you needed to, to move to either somebody else that doesn't GitOps workflow that's more flexible, that exposes more pieces back to you or we're building that in-house so that you can have that ability to say, I want elastic search. And then Azure developer could just say, that's what I need at this version with these configurations. So yeah, I'm sure they're doing it internally and GitOps workflow just depends on, like he said, how much they're exposing back to you. Any other questions? Yeah, Jay. I was gonna say, fraud is out of sync with desired state when you change the desired state. Right. Like I'm upgrading PHP to 8.3, I've tested it, it works great, push that, now fraud has to say, oh, it's time to upgrade PHP. Right. So there's a case where fraud is out of sync with desired state. That's a good point, right. And that's why there's that push. And so that push would say, hey, I've gotten a new change, I need to implement it, or I've noticed I'm out of sync now and I'm going to implement that. So that would be one case, a desired instance of where that happens. Still, I'd have to think about an undesirable how that happens, but thank you, Jay. That's actually the next one point. Yes, John. John's gonna, John and I are good friends. So he's probably gonna heckle me. Oh, that, yeah, that's a good idea. Because in GitOps, we don't, it doesn't specifically address that network stores and network storage might disappear during that or network issues. Yep, that's a good point too. Any other questions? Yes, Jessica. Oh, sure. Is any, can I ask one? Is that okay? How many of you are already doing GitOps? Is anybody doing GitOps? Okay, a couple? Or is it my sort of? Okay. Cool. All right, did you learn something new, I hope? Maybe a little bit? Okay, maybe. Okay, just checking. Any other questions? All right, well, if there's no other questions, I'll give you back an extra 15 minutes for your day. And again, this, like I said, I would be happy to talk about this. I'll be at our booth tomorrow and then I'm also gonna be here at the Higher Education Summit on Thursday. It's super easy to find me. There's like 20 gilzos in the States and they're all related to me. So search for gilzo and you're gonna find me or a relative. Thank you. Thank you.