Good. We all get on the recording. Ready for me to go? OK, get the thumbs up. So thank you so much for coming. I'm going to take the entirety of the 40 minutes. So I'm going to stick around afterwards if you have questions, but I'm absolutely filling up all 40 minutes today. My name is Carson Anderson. I work for Weave, but not the Weave you might be thinking of. I'm going to come back to that in a second. This is a cloud native pitch meeting. I want to pitch to you and introduce you to all of the incubated and graduating projects in the CNCF. You can find me on Twitter at CarsonOrderScraops. And you can find me on GitHub at CarsonOid. That last one is important because that's where you're going to find me, my presentations. Every presentation I've ever done is always open source. So if you like this, you want to steal the art or reuse it or repurpose it, go ahead and take that from my GitHub. And that'll be again at the end of the talk. Like I said, I don't work for the Weave you might be thinking of. I'm just going to quickly tell you about my Weave. My Weave is an end user, and we're not the cloud native Weave.  And we use a lot of the products. And I bring this up because I'm not pitching Weave to you. I am really grateful for them to have me come here and sponsor me, but everything that we use is open source under the CNCF banner. And also, it's still June, so I'm switching that logo. I also want to thanks to Fitbit.io for these characters. Whenever you see them, they just represent software. That's all it is. They're just software that's running out there. I like using them a lot more than just boxes that say Service 1 and Service 2. So that's all they are. So if you don't know what the Cloud Native Computing Foundation is, it's actually under the banner of the Linux Foundation, but it's a focus on cloud native software. And what it means to be cloud native and it's also a governing organization. So you actually donate projects into the CNCF and then they have open governance, which means you can use any of the cloud native projects feel comfortable knowing that some company is not going to just change them out from under you. And I want to pitch to you the landscape. If you go to landscape.cncf.io, you'll see this impossibly large chart. And I'm not going to pitch all of this. Don't worry. If you look closely, though, you'll see these bigger boxes out there. And I want to pitch to you the graduated and incubating projects that you find if you go to the card mode view of that web page. And this is already out of date. This card has 16 graduated and 33 incubating projects. There are actually 35 incubating projects. A few weeks ago, they added two more. And today I'm going to show you what every single one of these does. Again, they're going to be very gross oversimplifications of these projects. And for any maintainers watching, I'm sorry for how simplified I'm making this. But I want you to walk away today having heard all of these names and at least have the slightest pitch about what they do, so you know if you want to contribute to them or use them. So here we go. We're going into all of them one at a time. First one I want to talk about is ContainerD. ContainerD is a container runtime platform. It manages all your container operations, creating, deleting, basically the container lifecycle.  And you can do that directly. And if you haven't done it directly, there's a good chance you've probably used it indirectly because if you use Docker to do container operations, it was contributed to the CNCF by Docker and is still behind Docker's container operations. So that's what ContainerD does in the CNCF space. Next is buildpacks.io. Buildpacks.io is about rethinking how we do our container image build process. If you know anything about how this works, in order to package software into a container image, you run layers.  Problem with traditional building is if you change the base layer, like update your OS, you have to rerun all the steps above it. Or even worse, if you use best practices or if you don't use best practices, you can sometimes have your base layers change and you subtly or maybe explicitly break that image and it's not super reliable. What buildpacks.io is trying to do is rethink the way we do our container image build process so you get repeatable, knowable builds. And one really cool feature, I wanna call it specifically, is that they can actually swap that base layer to allow you to get updates without rebuilding your whole image, which can be huge if you have a lot of images to manage. So if you wanna rethink how you do your container image build, you should check out buildpacks of artifact. But again, it's just kind of a standard and specification in the update framework. What you probably would use instead of using tough directly is notary. Notary is a reference implementation and actual tools built on top of tough. So again, you can distribute artifacts like packages or files and verify their provenance and basically know you're getting it from who you expect. And it even has first class support for things like container images. So several of the things we talk about today that help you get securely distribute your container updates, you do through tools like notary. So that's what notary does. Again, notary isn't, you're gonna see this a lot. There's a lot of projects that have like a specification and an implementation. There are two separate projects in the CNCF banner. Next is Harbor. Harbor is a private image registry.  Once you've got it, you've got all the things that you might expect like signing and verification of images or inspection and kind of listing and management of all the images in your private registry. It has one really cool feature as well where you can act as a pull through registry so that when you run Harbor on-prem, if you need to fetch an image from a remote registry, it can cache it and really save you a lot of bandwidth by using Harbor just as this cache as well as your own private registry. So that's what Harbor does in the ecosystem. Now of course, I can't talk cloud native without talking Kubernetes. Kubernetes, you don't have to be in Kubernetes to be cloud native, but it's really, really common and a lot of the tools in the CNCF and the ones I'm gonna talk about today build on top of Kubernetes as a platform. Kubernetes, that's core is a container orchestration platform, right? So you have a fleet of machines and you tell Kubernetes, hey, I wanna run a workload with some specific configuration and it puts it somewhere in your ecosystem. In Kubernetes, we call these nodes and it just finds a place to put your workload. And of course, you can do things like scale up and you can have Kubernetes run lots of different kinds of workloads and you get to stop kind of worrying about nodes. If they go away, Kubernetes knows how to bring your and state seek and bring your infrastructure back up or it can scale up and redistribute. It really allows you to run your product without thinking about the nodes anymore. In fact, most of the time, I'm not even gonna show you the nodes when we talk Kubernetes. I'm gonna show you the ship. So for the rest of the talk, whenever you see the ship or if you see Captain Cube, that's referencing Kubernetes as this larger platform that we really can use directly but also build on top of. What I mean by that too is that Kubernetes is great on its own as a container orchestrator, really powerful just out of the box, but there are a lot of touch points where you can extend and expand Kubernetes to better meet your needs or even build whole products on top of it. Talk about custom storage, custom networking, custom resources. This is really important. I'm gonna come back to that or even extending the Kubernetes API and taking a whole chunk of the API and processing it in a totally different way. Really powerful stuff. I said I wanted to talk about custom resources some more because these are incredibly important in the Kubernetes space. We know that we can create nodes and we know we have pods in the Kubernetes ecosystem and there's a bunch of other things but you can also create things called CRDs. CRDs stand for custom resource definition and what that is is essentially saying, okay, Kubernetes API, I know you can handle nodes and pods and all these other objects out of the box but I want you to understand what maybe a weave service is. I want you to understand what a SQL instance is and you can use the entire power of the Kubernetes API to operate on basically any document that you wanna define and manage. A lot of tools use this. You're gonna see the CRD come up a lot and just understand when you see this icon it's the entire power of the Kubernetes API managing anything that you want to describe. So again, that's Kubernetes. I'm gonna bring it up a whole lot more because a lot of CNCF projects build on it and we'll just keep going. One of the projects that does a great job of basically using every single one of those Kubernetes touch points that I've talked about is Knative. Knative says, okay, Kubernetes is a fantastic low level infrastructure. You've heard it referred to in the past as the assembly language for the cloud and Knative says, what if we run on top of and alongside using those touch points and you just hook up get repos to Knative using Kubernetes and then it can do all the Kubernetes stuff to make your workloads off that get repo as a change that can cycle through. It can even do higher level things like hook up event streams into your services or hook up user access into your services. Again, you don't have to even worry about the Kubernetes parts. You just sort of hook Knative up to your get repos and it does the rest. So again, a whole platform built on top of Kubernetes and Knative. Next is Volcano. Volcano is another Kubernetes kind of extension where you're trying to take normal Kubernetes and add new features onto it that the Volcano team supports. So you run it alongside your Kubernetes cluster and it adds these higher level abstractions that aren't in bare bones Kubernetes, things like batch scheduling, machine learning and deep learning or even big data. Again, all these concepts that can happen in Kubernetes but Volcano abstracts and manage that for you so you can build those kinds of things into your Kubernetes cluster. Next is Keta. Keta stands for Kubernetes event driven auto scaling and it's sort of what you might expect. Now in standard Kubernetes out of the box we can make this thing called a horizontal pod auto scaler. Just a Kubernetes resource and the thing you send to the API and it watches your workloads and as they increase in usage of things like CPU and memory it can scale those workloads up and down as necessary. Works really well for things like that. But what if you have to scale based on Q depth? What if you want to maybe even scale to zero when a Q is empty to save capacity? Normal horizontal pod auto scalers kind of fall down on this, they just don't work very well for that. What does work well is the Keta project. Again, just an extension can even run with normal HPAs but it allows you to make a custom resource in Kubernetes that hooks up to your Pub sub metrics and lets you do auto scaling for your workloads based on Pub sub data including like said scale to zero when your Qs are empty and there's no work for the processes to do. So if you're doing event driven architecture in Kubernetes, you should check out Keta. Next is Backstage. Backstage is really interesting in the CNCF space because it's the only graduated or incubating project that's really front end focused, the front end project. So you've got your services and modern architecture has a lot of services and each service has things like API specifications, alert configuration, docs. Some of these may have some and not the other. Sometimes for a modern service you have to go to four or five different websites just to find all the information about one service. Backstage says, well, okay, we're not gonna do all of that but we're gonna provide you a robust platform where you put plugins into Backstage and essentially build a front page for your infrastructure, for your developers to manage their service where we aggregate all that information into one place and really give you this kind of service registry and the service view for your developers. So if you're curious about that and how that works you can check out Backstage. Next is Helm. Helm is a Kubernetes package manager. What I mean by that is we know that we can run our workloads in Kubernetes. I always show them in these boxes but they're really this thing called pods which are just collection of containers that you run in Kubernetes. But you can make, like I said, a bunch of things and this is just scratching the surface of the kind of things you might make in a Kubernetes cluster. And it's a combination of all of this configuration put together that really makes a thing installed into the Kubernetes API. What Helm lets you do is kind of take that configuration, package it up into a Helm chart and you can send that chart to Helm and it will manage it in Kubernetes for you. And this is pretty great for running your own software but it's really fantastic to take that Helm chart that you've built for your software or your product and send it to other users to put into their help installations. In fact, most of the time when you install almost any of the other stuff that I've talked about up till now and going on that goes into Kubernetes odds are really good, you're gonna use a Helm chart to install that in your clusters, the de facto package manager for Kubernetes. Not the only way, but a really great way. Next is the Argo project. Argo, I wanna specifically say it's the Argo workflows project. There are several projects under the Argo banner and it's the workflows project that's in the CNCF and it's all about workflows. And workflows are just a series of steps we're gonna execute from A to B. They might have some fancy features like retries or conditionals or even kind of fan in and fan out to distribute work. And in the past workflows have kind of been limited because they're single process, single language, sometimes single threaded. And Argo said, well, what if we could do all this workflow stuff, but what if every single step was a Kubernetes resource? Then you can orchestrate your workflows as pods, as cron jobs, even as custom resources that can do anything that you need to do and really use the whole power of the cloud to do your workflows, not just a single language or a single machine. So if you're interested in powerful workflow engine using Kubernetes, you can check out Argo. Next is Flux. Flux is a Kubernetes deployment platform and sort of like a helm except for what we're doing get ops here. So you define a get repo, you put all of your Kubernetes configuration of what you want in your cluster in the repo and you can then use Flux to apply that get state into your cluster and Flux watches the repos and as you do get operations against them it syncs that state into Kubernetes and really enables you to manage your cluster as code which is a really fantastic way to manage anything in Kubernetes. So if you're curious about doing that you should check out Flux. Next is the operator framework. This is a series of tools about building and managing the entire life cycle of a Kubernetes operator. If you don't know what that is, Kubernetes operator can be thought of as an engine. It runs inside a Kubernetes cluster alongside of it and talks to Kubernetes API and its job is to watch for things in the cluster like a CRD being created, for example. Say oh, I'm supposed to do some stuff when that gets created to seek state for you and if you make a different CRD with some slightly different configuration it'll again operate on that and it'll maintain the updates and deletes and it kind of manages the whole cycle of managing things like CRDs and of course it can do anything in the Kubernetes API but that's what an operator is and a lot of things we've talked about so far have been operators behind the scenes. And again it's all about leveraging the power of these CRDs. You have to have something watching the cluster waiting for the CRDs to get created and then operating against them and that's what operators do and the operator SDK and the operator framework are a fantastic way to build and manage these operators. Next is crossplane. Crossplane is really great, it's sort of again taking the Kubernetes API power and extending it to everything. So you're on crossplane in your cluster and crossplane has a big suite of providers that allow you to create Kubernetes customer resources to define basically anything in your infrastructure. So you've got on cloud, you've got on prem and you can create a crossplane CRD that lets you make a VM in the cloud. You can create a crossplane CRD that makes you make a SQL instance in the cloud or even make hardware resources. I'm only showing you three examples but basically anything that has an API can then be integrated into crossplane or there's probably even already a provider in crossplane that allows you to manage your entire infrastructure using the Kubernetes API via crossplane. Next is the twofer. I'm gonna briefly talk about why I'm doing two at a time here. You'll see this a few times. CNCF is not about picking winners. Both of these projects fit into the same space in the ecosystem. CNCF is about governance and openness as long as two projects that fill the same gap are open and well-governed and contributed to the CNCF they can absolutely be there. We're not picking winners. So both emissary ingress and contour are Kubernetes ingress controllers. What I mean by that is we know we can run our workloads in Kubernetes but if you want to route user traffic to them you need to make these resources called ingress routes and they're basically just configuration saying hey if you come into the cluster for at this specific host and path and a whole lot of other config here's where I want you to go based on these conditions but something has to run in the cluster and make that true. Something has to listen for user traffic read configuration and route to the right workload based on all the config that you have. This is where both contour and emissary ingress live. So this is what's called a Kubernetes ingress controller and you can actually even run both of them in a cluster at the same time. You don't have to even choose one. They both just kind of fill this space. So if you're interested in that one really cool thing about both these projects is that in the past ingress controllers were legacy web servers that we kind of backwards hacked into loading config regularly and being filling this space. Both these tools were built from the ground up to be Kubernetes ingress controllers. So they're a fantastic choice for that. Next is Kube Edge. Kube Edge is all about dealing with edge compute and Kubernetes like you might guess. So you run Kube Edge in your main cluster and it allows you to manage edge nodes or edge devices or edge workloads and kind of takes care of some problems that the core Kubernetes isn't trying to deal with. So if you have unreliable connections or you need to limit your bandwidth with your edge compute nodes, Kube Edge has a lot of tools to help you deal with that. So it really extends Kubernetes all the way out and that's Kube Edge. Next is Kube Vert, also a very single purpose project in Kubernetes land. Now we've already talked a lot about Kubernetes workloads and pods and I said you run containers and pods, one or more containers is a pod. But what if you need to run a VM as a Kubernetes workload? Not all workloads are greatest containers. Sometimes you need the isolation of a hypervisor, sometimes workloads just wanna be in a container.  And so you get all of the power of Kubernetes running your workloads including all of the normal networking procedures but it's actually a VM behind the scenes for your workload to execute on. This is incredibly powerful for people that need that. So if you're interested in that you can check out Kube Vert. Next is another twofer, remember we don't pick winners. So both Rook and Longhorn are Kubernetes volume providers. There's a lot of them but these are the two that are in CNCF of the state I'm gonna talk about. And what I mean by volume providers is in Kubernetes we have another blank space where we have this thing called a persistent volume that says here's some data I need to persist and then I need you to attach it to workloads and as those workloads move around my infrastructure make sure the volume follows them around and get those with them.  This is where Rook lives. Rook uses the Ceph project which has been around for a long time to deal with disks and making persistent volumes work with the Ceph project to mount to your Kubernetes workloads. Longhorn also fills this space and does the same thing makes persistent volumes work but it does it using Kubernetes pods in this really interesting way where the pods are framerable themselves but as long as you have enough replicas you get a persist data. So again two totally different ways to run those and absolutely you can run them side by side in one cluster if you need it to. So again both of those tools are Kubernetes volume managers. Next is Cryo or the container runtime interface for OCI compliant containers long name. What I mean by this is on every single Kubernetes node in your infrastructure you run this thing called the kubelet and the kubelet's responsible for watching Kubernetes API and making resources true making containers exist and doing the whole container operations. And there's this squishy blue space that I've drawn between the kubelet and actual container operations. In the early days of Kubernetes this was pure Docker. It was instrumented directly against the Docker API and it was the only thing that could do container ops for the kubelet. But we said we need to make that pluggable so we're gonna find the container runtime interface and as long as you implement that you can fill this space for the kubelet. One tool we've already talked about that does this is container D. Container D is CRI compliant and in a lot of Kubernetes distributions you might use container D is filling this gap. But Cryo is another CNCF project written explicitly and only to be in this gap.  Cryo says what if we were just this container runtime implementation? So if you're again you can run either of these you kind of have to pick one for a Kubernetes cluster but they both fill this gap in the ecosystem. So if you're interested in from the ground up solution check out Cryo. Next is CNI. CNI is the container networking interface and it's all about standardizing the way we become a networking provider in Kubernetes. So we have our workloads they need to talk to each other sometimes over the same machine sometimes over multiple machines and something has to define well if you want to do that if you want to be a network provider in Kubernetes or the cloud what does the interface need to satisfy and that's what CNI is. It's a set of specifications and some low level tools for saying here's how we become a network provider in Kubernetes kind of niche but really important for the ecosystem that this standard exists. So next is GRPC or the Google RPC protocol. Now if we have service to service communication really commonly in the past we've used HTTP to talk to service to service. The problem with HTTP is it is stateless. So there's a lot of overhead every time you establish a connection you have to re-establish trust you have to re-establish the entire connection and re-establish state. What GRPC says, well okay we're gonna have a stateful connection that's built on HTTP and allow you to be much faster and more powerful and even leverage that stateful connection for things like single or bi-directional streaming of communication between services. So you're gonna really take your service to service communication to the next level. And that's what GRPC does. Next is core DNS. Like you might guess core DNS is a DNS provider in the CNCF but it's a modern one and what I mean by that is if we think about DNS it's really at its core is our oldest service discovery mechanism, right? You say okay I need to go to somewhere by name where do I need to go, where do those instances live? Core DNS is kind of built for the cloud to solve this problem and I'll tell you why we need that in a second. But core DNS, its power is that it's incredibly pluggable. This diagram is explicitly very empty because it's just built on its plugin system. So you've got plugins for all sorts of different ways to serve DNS resolution. You've got all sorts of plugins for ways to get to DNS configuration and to modify that all of them combine and kind of control that process. The reason I say we need this is because old DNS systems were really not good at changing DNS records multiple times a minute or second. Like they just weren't built for that. Where core DNS really is built for these very active, constantly changing configuration like Kubernetes or public clouds. So if you are running Kubernetes, there's a really good chance, in fact, it's pretty much the de facto standard default DNS server for Kubernetes now. Although you can absolutely take core DNS and run it yourself as a more modern DNS implementation. Before I go to the rest, I need to talk service mesh. Just very two minute service mesh talks so we know what the rest of the projects and how they fit in. So we've got our services talking to each other over the network and we want network level features. Things like end to end encryption, transparency, tracing, short circuiting. You have to write that in every language every time and hope that you do it in every language every time correctly in order to get those features. What a service mesh says is, well, what if we write this proxy process? I always draw it as a box because I think of it as kind of enveloping the process, though really it is just a sidecar process that there's some network magic to intercept the traffic so that sidecar can do all of the complex network work regardless of the language of the service that it's being put in front of. Once you've got a sidecar, you need a control plane. Control plane sits and configures the sidecar and tells it what to do. By combining all these proxies doing exactly what the control plane says, you get a service mesh. And once you've got that, you get things like metrics, you get things like load balancing or the intended encryption and transparency I talked about or even automatic distributed tracing. Again, that's what you get out of service mesh and a lot more. Linkerd is a CNCF project built to be a service mesh and it's incredibly easy to get up and going and maintain. It's a fantastic full-featured service mesh project. So you get both the Linkerd to proxy process in the Linkerd project and you get the Linkerd to control plane. And again, this is very easy to get up and going and using all of these features I've talked about through Linkerd. So if you're interested in a full-featured service mesh, you should look at Linkerd. Next is the Envoy process. Envoy is sort of like Linkerd but it's more narrowly focused. So Envoy is just the proxy process. It says, okay, this project's not trying to pick. If you're wondering where the control plane is, there is no control plane. It's up to you to choose what the control plane is. This might seem like a downside but the fact that the Envoy team just basically says we're gonna be the best, most configurable, most general purpose, usable proxy that we can be. We'll leave it up to you to implement the control plane part. What's fun about this is we've already talked about two kind of micro control planes that use Envoy. They don't use it to do the service mesh whole thing but they are using its network capabilities. So if you use Emissary or Contour, both of those are just really like single purpose, specialized control planes. They use Envoy to do all the network work because it's complicated and they wanna let Envoy do the complicated part. So again, if you're interested in that kind of like low level network operations, you don't have to write yourself Envoy. I'm putting this in with the service meshes because it kind of is, although it doesn't work in the same way, Dapper kind of solves some service meshing problems but in a different way. Rather than try to do network magic, you run a Dapper sidecar next to every instance of your services but they implement directly against the sidecar API. So it's not transparent, it's explicit. You talk to Dapper and say Dapper, I want you to get me some PubSub events. I want you to get me secrets. I want you to get me state and all of that is handled by the sidecar so that your services can be really simple and even move them between clouds or different kinds of providers at the top level here and Dapper will do that work. The services just implement against the very stable standardized Dapper API. So again, you get service meshy things out of this project but it's not as much magic. Next is another twofer. Both of these projects, ChaosMesh and Litmus are chaos engineering tools for Kubernetes like you might guess. So if you've got a Kubernetes cluster and you wanna see what happens, maybe if a node fails or if a network link gets bad, you can do that. Both ChaosMesh and Dapper allow you to create CRDs in Kubernetes that say simulate this failure, make this failure happen. I'm gonna record what happens and we can see how we respond to that failure. Make a node go away. Let's see what happens and see how a system responds to that failure and they track that and report back so that you can make sure your systems are resilient and handle these kinds of failures. So if you're interested in chaos engineering for Kubernetes, these are both great options. Next is OpenTelemetry. OpenTelemetry is all about dealing with standard way to instrument tracing and logs and metrics into your applications. I'm really gonna cover tracing but it does also logs and metrics. So if we've got a user that user talks to a service and that service talks to another service, we wanna trace that and especially if it goes four or five levels deep in our infrastructure, we wanna see where that request goes to get satisfied. Even better, we need to instrument our code to track the trace as it bounces around between our methods so we can see how long it took at each part of the code and follow the entire path of the request to debug problems or performance issues. You need to instrument your code to do this. In the past, we've always instrumented our code with vendor-specific tooling which makes it very hard to go to a different vendor with our logs and metrics and traces. But if you use OpenTelemetry and if vendors follow the OpenTelemetry standards, then you can instrument your code once and ship it anywhere which is really, really fantastic way to kinda turn the way we do instrumentation of metric data into OpenTelemetry. One place you might ship your traces from OpenTelemetry or another tool is to Yeager. Yeager is a trace aggregation management platform in the CNCF. So again, we've got all our services tracking our, maybe even our service mesh kind of tracking our traces and they need to send that data somewhere so you can view it in one place even though it came from lots of sources. That's what Yeager does. Yeager receives all of your trace data and aggregates it and allows you to then take it and view things like heat charts to show you how long it spent at each part of and what places it went through your code base and your infrastructure. And then you can of course get all the stats and searches and other stuff on that data or even use Yeager's API to use that trace data in really interesting ways. We actually use a lot of our trace data to kind of map out some dependencies because here's the history of what we actually have done based on the stuff coming out of the Yeager API. So that's, these are your real life dependencies you've used recently. So again, that's what Yeager does and so much more. Next is Prometheus. Prometheus is kind of cloud native metrics. What I mean by that is we've got all our services running in our infrastructure and they generate metric data. They generate a ton of metric data, right? How many requests have come through? How many are good? How many are bad? Memory, CPU used. In the past, like with traces, we used to instrument our code specifically to send that to one provider. If you wanna switch provider, you gotta have all your code send that data to a new place. Prometheus turned it on its head. Said actually, all you have to do is instrument and expose a flat, easy to parse text file format and then I'm gonna come to you and pull it off of you. Meaning that the services don't even have to know where the metrics are going. They just serve up the data as the data is. And the way Prometheus knows where that data lives is it integrates with your cloud providers and even Kubernetes, of course, to figure out where all your workloads live and to go find all those targets and scrape that data. Once it's scraped that data, it stores it in its own internal time series database and you get all sorts of features in Prometheus based on that data. You get things like charts. You get things like alerts. You get things like, of course, other statistics about your metrics. And again, an API where you can take that data once it's aggregated and kind of extend upon it. A lot of cloud native projects have APIs because they really are built to be kind of, as part of a toolkit, a chain of things. They're not trying to fully lock you in ever. So again, that's Prometheus cloud native metrics. This is another really kind of niche project open metrics. It takes that text file format that I talked about from Prometheus. So if we have our services, they have some metrics. They serve an HTTP page full of this text format. Prometheus has been very good about not breaking this compatibility. They said, here's what we do. We're not gonna make any changes that make old versions incompatible. Open Metric says, okay, we're still not gonna break compatibility. We're just gonna go a little bit farther to be a bit more specific to if your open metrics standardized, you've solved a couple edge problems while still not being backwards incompatible with Prometheus. And then it also is trying to make a protobuf description of metrics data so you can send metrics data over protobuf. Again, kind of niche here, but if you're digging into metrics and you wanna follow some absolute best practices, you couldn't go wrong with fallen open metric standards. Next is the Thanos project. It's all about scaled Prometheus. So it's very, very easy to get up and going with a single Prometheus instance. Cloud-native Prometheus is incredibly easy to get going. But what happens when you have multiples? Or even worse, I wanna send a query to one place, get the metrics from all the instances and view it in one place. That's what Thanos does. It's a set of tools that allows you to basically wrap other Prometheus instances and you can send one query and go to the Thanos dashboard or whatever you need and it will aggregate that amongst all the Prometheus instances it knows about and bring that back into one view. So even if those clusters are geographically separated or if you need sharding or replication, Thanos allows you to handle all of that. And it also has a cool feature in that it can take the data once it's gathered it and actually ship it to things like cloud storage so you can get longer term metric retention because Prometheus doesn't really want you to have long term retention but Thanos can enable that and so much more. So if you're looking for a high scale Prometheus, check out Thanos. Next is the Cortex project. Also dealing with multiple Prometheus instances but a totally different way. You set up Prometheus instances to send their data into Cortex as a system and it stores it on its internal data system. And then you can still go to Cortex for that single view but the Prometheus instances really just act as very, very fancy data sources into the Cortex system but it's really what it's built for. So if you're looking again for high scale data or distributed Prometheus management, you could go with either Thanos or Cortex. These are both great projects for that. Next is Fluent D. Fluent D is all about streaming text processing and there's a very specific application we use it for a lot but at its core it's allowed to basically set up to a bunch of text data sources including constantly added, removed and changed text sources and it reads them as they come through and it processes them however you need it to and can ship them out to one or more new locations which seems kind of basic but it's really powerful. It really handles a high scale of text processing. One fantastic use case that you may not use directly but you probably use indirectly is in Kubernetes. All of our workloads are containers generating log data. Log data at the end of the day on the server is basically just text files we constantly append to and sometimes cycle out. And so if you're running Kubernetes and you need to get all of the logs from all of your nodes and containers into one central system, you can do that with Fluent D and odds are pretty good. If you use a Kubernetes managed platform and you're getting centralized logs somewhere and you're looking at that single page, that single page probably got logs from Fluent D. Like I said, you can absolutely use it directly if you just need massive text processing that's really highly configurable and pluggable. Next is Vitess. Vitess is an relational database management system that's for the cloud but really, really great for Kubernetes. So it's pretty easy in Kubernetes or the cloud to run a SQL instance but you need to scale those vertically, right? As you get bigger and bigger data, you just keep going up and this becomes hard to manage and really vulnerable to failure. It would be great if we could scale horizontally. Being cloud native is scaling horizontally. What you can do though is use Vitess to basically handle replicated and sharded databases but not know it.  You run these Vitess layers on top and they provide powerful features like replication and sharding out of the box. And you're worried about, well, how do I manage those replicas? Vitess also has a proxy process where you can just configure endpoints to go to that proxy endpoint through both SQL and even GRPC and it does all the work to figure out where all your shards and replicas are. So again, you can send one statement into the proxy and it does all the work to kind of abstract away the database into something that it manages for you. This makes it a really great solution, like I said, for running relational databases in Kubernetes but you can definitely just run it anywhere. Again, that's Vitess, a modern cloud native way to handle relational databases. Next is TyKV or titanium key value. This is a key value store. Has all the things you might expect? Adds, updates, deletes. The great thing about TyKV though is it's scale. TyKV, according to their docs, scales up to petabytes of key value data in a single installation. That is massive amounts of key value data. It even supports acid compliant transactions. So you can say, hey, I want you to add this, update this, delete these 10 things. Do this all as a transaction all at once and if it fails, roll it back like it never happened. That's really powerful, especially that scale to ensure you can do these transactions and not get stuck in a halfway state when you're using your key value store. So that's TyKV. Next is SED. SED is also a key value store in the CNCF, but rather than focus on massive scale, SED is really focused down on simplicity. I'm talking very, very easy to get up and going with SED. Often just a couple commands or a config file away from having a fully functional ready SED installation, including just a single instance or even a cluster of SED installations where once you've got it clustered up, you get things like fault tolerance and replication and even leader election. All of this combination of features and simplicity to run has made SED the de facto back end of the Kubernetes API for ages. There used to be the only back end for the Kubernetes API. There's now a few other solutions out there, but if you're using Kubernetes and you send a document to the API, odds are still very good. You're sending it to an SED instance on the back end, but you can absolutely run SED as a key value store on your own. Next is Dragonfly. It's all about peer-to-peer file transmission. So you can send files or even it has high level support for images peer-to-peer. One-to-one's not super interesting though. What is interesting is if you run the Dragonfly agent on all your infrastructure and one of the nodes needs an image the other ones have, it can actually download pieces of that image from all the nodes in the infrastructure so that you can save bandwidth and get that image faster by basically doing peer-to-peer transmission. So again, arbitrary files or images if you want peer-to-peer file transmission Dragonfly. Next is cloud events. It's all about standardizing the event language we use in the cloud. So if we have a bunch of services and a bunch of languages and we want to use events and we don't all agree on what the structure of those events are, we can't interop with each other. What we can do instead is use the cloud events standard to say, okay, we're all going to talk events and here's exactly what they're going to look like. Here's the rough structure they're going to follow so we can interop with each other efficiently. So that's what cloud events is for. Next is NATs. NATs is a message bus for the cloud. So again, you get all the things you might expect. You can produce messages onto NATs. You can consume messages from NATs with producers and consumers. And you get all the features you would want. You get Pub sub. You get request reply. But what's really great about NATs is how easy it is to cluster it and how resilient it is for both scaling and redundancy. If you bring a NATs cluster up, it's actually quite hard to have it go down and you really don't have to do a lot of work to maintain an active, reliable NATs cluster. So it's a great way to run a message bus in Kubernetes. Again, that's NATs. Next is Spiffy, a secure production identity framework for everyone. And it's all about ID in the cloud. And I'm not talking just user identity. I'm talking about identity for servers. I'm talking identity for processes or individual components of processes. They're trying to set a standard for how we do modern kind of nuanced and detailed identity in the cloud. Again, this is a specification and standards project. You probably wouldn't use it directly. What you would use directly is the Spire project. Spire project takes the Spiffy concepts, pulls them in and gives you additional tools on top, like the Spire server and the Spire agent. Again, so you can do massive identity in the cloud or elsewhere, but not have to write the tooling yourself. So that's what Spire does. Again, Spiffy is identity standard. Spires an implementation of tools you can actually use to do that kind of identity work. Next is Intodo. Intodo is all about dealing with our full CISD pipeline securing. So you've got a pipeline, you've got a series of steps you need to execute. Intodo allows you to, as you go through those steps, track inputs, track outputs, track the results to basically take the distributed package you've created and the Intodo results and ensure that not only did it come from someone you trust, but every step along the way did exactly what it was supposed to do and nothing more. It really lets you secure your whole pipeline. And that's Intodo. Next is the Open Policy Agent. This is all about feeding policy documents. So you take Open Policy Agent, you run it. You feed it policy documentation and then as you feed it objects, it decides to allow them or reject them. I'm being very vague here on purpose because OPA is not for any one thing, it's for anything where you need to apply policy. Specifically though, the Kubernetes API is a great example. The Kubernetes API, we're sending it lots of documents and we want to basically ensure that maybe you want these exact labels on that resource. You want to make sure this configuration doesn't exist in these places. You can use Open Policy Agent to do that in the Kubernetes API and so much more. Next is Falco. Falco is all about constant, always on runtime security for Kubernetes or even the cloud. So we know we can secure how we distribute our containers. We know we can secure the pipeline that we built them. We can make sure that what we got was what we actually expected but you still might want something that's always running your infrastructure, watching your workloads all of the time to make sure they do exactly what they expect, what you expect them to do and nothing more. That's what Falco does. Falco runs in your infrastructure. It roaches all of your processes actively and it's got rules that say, hey, you're supposed to do this and not that. If you do something that you're not supposed to do like access a database I didn't expect you to access, I'm going to send an alert and we're going to respond to it. This is basically again, always on security for your workloads. And that's what Falco does. Next is Cilium. Cilium is really two things in the CNCF. It's a CNI network provider. Remember CNI is that standard specification for how we basically become a network provider in Kubernetes? So it does that, so it allows you to network containers together in Kubernetes but it also allows you to handle traffic between services. Traditional networking layers when they have policy are basically like port level. Say you can talk to that on port 80 but you can't really get much deeper with most traditional security systems. What Cilium lets you do is use the power of EBPF to not only make the networking layer but inspect it deeply. So you can say, yeah, you can talk to port that on port 80. You can do gets all day but if you try to do a delete, you try to do a post to the wrong endpoints, I can block that at the network layer. Again, really deep network security. So if you're curious in either a robust using, again, I can't stress how powerful EBPF is, a networking provider or network security for your Kubernetes clusters or elsewhere should check out Cilium. In fact, I think it's the de facto way of network policy in G Cloud at this point. So I did it. That's a lot. A speed run, we covered all 16 of the graduating and 33, like I said, there's two more I didn't cover of the incubating projects. Again, one more thanks to fibia.io. Hopefully they're more interesting to look at than if I tried to draw stuff myself. I use Inkscape to create the presentations. They're just SVG documents. Use Sozi to then animate them. And I make quite liberal use of openclipart.org to get artwork to kind of fill the blanks of what I can't make myself. Last time, big thanks to Weave. Check us out if you're curious about what we're doing at getweave.com. My name is Carson Anderson. Carson, known to score ops and absolutely go to my GitHub. I actually have more followers on GitHub than Twitter. So if you wanna do that, that'd be fantastic. And that's where you find this talk, the source code for it and every other talk I've ever made. So thank you. And I think we're right exactly at time. So again, if anybody has questions, I'll hang out here or you can hit me up online. You can tweet at me if you have questions and I'd be happy to talk about any of these projects. All right, yeah. So that's great.


Zack Snyder and Netflix teamed up to ruin your holiday with Rebel Moon, a nice chunk of coal put in the stocking and thrown into the fireplace with part one, a child of fire or something. Who cares?  This movie is terrible. The actors are lame. The CG slow motion nonsense is all over the place. Snyder can hit once in a while, but it's been a long while now and I'm over his shenanigans. Hit Rebel Moon and just put on diehard again for crying out loud.