 I guess Tom got my first slide done. I work for Moodle HQ, look after all of the core infrastructure, and I also am part of the Moodle Cloud team. So I've been working with Kubernetes and Docker and virtualization for a while now. So quick brief history of computers. We had really big ones, and they did one thing. Then we had a whole lot of little ones that did individual things. Then we decided to bring them all together into larger computers and cut them all up in little tiny pieces with virtualization. And more recently, we've been using something called containers to do something similar to virtualization, but a different way. So why would we want to virtualize? Computers became too powerful to run a single application. And so we allowed more efficiency by running more applications on a single system. Graphic there shows the three different apps as an option, each one notably having a guest OS running, which takes up resources. They keep the application secured and isolated, mostly for security and resource allocation. Containers are a different way of doing it that have come in recently. Containers give you a lot of advantages, but also don't have multiple copies of the operating system, so you don't run a whole lot of resources and waste them. And there's a lot less performance penalties. One other thing that's very useful in my line of work is standardized images and the quote dev ops workflow, where you can create an image and replicate it. Why not? Security in containers, you could argue that it's not as good. Their containers have a much more complex configuration. And virtualization, on the other hand, is slower. There's more overhead costs as far as performance. And individual VMs becomes complicated. There's a concept of cows versus pets in this world, too, where in the VMs and individual operating systems, you end up having pets where you manage them and deal with them individually. At Moodle HQ, we've got a bunch of servers that have fancy names and you have to figure out which service is running where and it gets complicated. In the cows with containers, you've got a herd of them. You manage them as a herd. You don't manage individuals. They don't get names and you don't get to keep them for long. So here's the slide with the overview of the differences between the two. The big difference is that replication of the guest OS and the overhead involved. So Docker is the containerization standard that is the winner right now. There's an installation URL there and there's a course that I prepared about getting started with Docker and building out a development environment for Docker. A Docker file is fairly simple. There's three lines there that'll create a web server for you. The first line says, grab a web server. Second line says, grab an index page. Put it where it belongs. And the third one says, here's what port you listen on so it actually is a web server. This is what you see when you build it. You can see all the three steps. It does each piece. It creates layers. That creates the container. And then if you want to run it, you run it with the publish flag that tells the host which one to listen on. And then you can see a PS. You can see it running. I said Docker gets complicated when you're using containers because of the numbers of these cows in the herd that you have to deal with. What we're running is Kubernetes. It's an orchestration framework that deals with keeping the cows alive, making sure that the traffic gets to them, making sure they scale, and making sure everything stays working, even if you have servers die or anything else. So these are some of the orchestration frameworks that are out there. It's complicated. That's the point of this slide. And that's really about all I've got in my presentation. I don't know if we're taking questions, but if you want to talk to me after, we can get more detail.