 Hi, my name is Jay Pipes. I'm a principal engineer on the Kubernetes at AWS team, and today I'd like to talk to you a little bit about the AWS controllers for Kubernetes project or ACK. But before I tell you about ACK, let's back up. I want to first talk, give you a big picture view, a bird's eye view of how ACK fits into the entire Kubernetes and deployment system ecosystem. Sorry. If you haven't been hiding under a rock over the last three years, and you may have been because of COVID and all that, but if you haven't, you've probably heard about GitOps. GitOps is sort of like the latest craze in the DevOps and deployment community. At the end of the day, what GitOps is, it's an operational methodology for doing safe, repeatable software deployments. That's it. Kind of seems a little bit marketing speak, though. So maybe you have gone online and something like, what exactly is GitOps? And you've seen these four things that are on your screen right now as GitOps best practices, declarative configuration management, humans using Git and Git-based workflows to change the configuration of an application, making sure that all changes are observable and verifiable, and also making sure that robots are doing the deployment and not humans. So these four best practices in isolation, yeah, they kind of make sense. But for me, I know that it didn't really click for me internally until I related the first two to each other by saying, if we use declarative configuration, then we empower humans to use Git-based workflows in order to change the configuration of an application. So GitOps is all about having a source repository in Git, usually, that contains manifests, configuration files that describe your deployment, that describe the services and the stateful sets and the deployment YAML files in Kubernetes, the ingresses, all those kinds of Kubernetes specific objects, right? Those go into manifests in a source repository. And when you want to make a change to any of those configurations, we do so, we do a Git commit and push those configuration changes up to usually GitHub. GitHub is the most popular source control platform at the moment, and so you make a change to the configuration file of something involved in your application, you do a Git commit and push that change up to usually GitHub and create a pull request. And that pull request, then your teammates can approve, review that change to a configuration just like they would a piece of code, a change to part of your application code. And they either approve or deny that particular change. Well, what's important here is that that is the end of the human interaction with GitOps. Humans stop there. Once the pull request or configuration request, change request is approved and merged, that's the end of the human interaction in GitOps, right? After the changes are merged and using, you know, after a configuration change is merged into a Git repository, then the robots take over and we'll get to that in a second. So why does Kubernetes fit really well into a GitOps model? Well, at the end of the day, Kubernetes has a Kubernetes resource model that is all declarative. You have a set of these YAML manifests that describe a stateful set and a deployment and a service and an ingress and persistent volume claims. All of these Kubernetes native concepts, Kubernetes native resources, they're described using a declarative format. That's why GitOps and Kubernetes sort of fit together so well. Well, just like Kubernetes and GitOps fit together really well for Kubernetes native resources like stateful sets and deployments and services, what Crosplain brings into the mix is that now with Crosplain CRDs, custom resource definitions that are themselves Kubernetes resource manifests, now you can declare everything to do with your application and your infrastructure using the same Kubernetes resource model. So Crosplain brings the everything bit into the GitOps world. So the second pair of best practices in GitOps is all about observing and verifying changes to those configuration files that are stored in the Git repo. And I like to put them together and say if all resources, all resource changes are verifiable and observable, then we enable robots to do the deployment of those configuration changes out into a target environment, whether that target environment is the Kubernetes cluster or it's AWS cloud or Google cloud or Azure, it doesn't matter. So Flux CD, that is the canonical GitOps robot, if you will, that is doing at the end of the day is doing a kubectl apply. It's automating the process of applying the manifest that are stored in a Git repository and in doing so actuating those desired state changes that are stored in those manifests out into production. So if we think about changes to Kubernetes resources being observed by Kubernetes controllers and things like Flux CD, well, now we can think about changes to all resources being observed by any sort of Kubernetes controller. Crossplane has a set of controllers that are Kubernetes custom controllers. They're listening for new changed and deleted custom resources of API kind that are related to the crossplane ecosystem. So when, say, you create a new database instance or a message queue or a role, an identity role, an IAM role, you will store that desired configuration resource in your Git repository, push up a change to that and create a pull request. And at that point, Flux CD will kick in and apply that particular change after the pull request has been approved. And the controllers, whether they are Kubernetes controllers or they're crossplane controllers, pick up that state change and attempt to consistently and constantly reconcile the desired state to be the latest observed state. So if we put all these things together, we like, well, I like to say this is an operational nirvana, right? We're able to declare the configuration of our entire system, not just the Kubernetes native resources like deployments and stable sets, but because we're integrating crossplane and Kubernetes and Flux and the Git platform like GitHub, we now can describe all of the resources, all of our infrastructure resources, all of our Kubernetes native application resources, all using the same format, all using the same Git based workflow, right? Where humans are responsible for approving the pull requests that describe those changes in configuration and robots are responsible for actually deploying things, right? Okay, so I spent all this time talking about GitOps. Well, what about ACK? Where does ACK come into play? Well, it depends. ACK is actually two different parts. There's a code generator inside ACK that consumes API model files, AWS API model files like the S3 API, the RDS API, and produces go code for translating those APIs into the Kubernetes resource model. Now, the code generator inside ACK called ACK Generate, it has an extensible and flexible producer pipeline. In the first part of that pipeline, we can take those API models from the AWS services and output the crossplane provider AWS module. In another way of running the ACK Generate code generator, we can consume those API files and output individual custom Kubernetes controllers, one for each AWS service, and we call these the ACK service controllers. So depending on whether you want to take advantage of cross planes, cross cloud provider, and sort of higher level abstraction model, or whether you want to install individual AWS service controllers in your Kubernetes cluster, we can do both in ACK. One thing before I wrap up here, I want to make sure that everyone understands that ACK, it's 100% open source, and we're 100% collaborative with the open source, cross plane, and elsewhere communities, right? There's also, there's nothing specific about EKS. So ACK, the service controllers inside of ACK and the code that is generated by the ACK code generator is not specific to EKS. They will run on any target Kubernetes cluster, regardless of whether you choose to use the managed control plane options of EKS. So for those of you who are interested in learning a little bit more about ACK, please come join us. We have the, on the screen here is our root URL to our community project on GitHub. I'm always hanging out on the provider AWS channel on the Kubernetes Slack. I'm also on the cross plane Slack. I look forward to working with the cross plane community even, even more and greater in the future. And I thank you very much.