 So we'll just get right to it. While he was talking actually, it made me go back and do a little bit of like timeline searching and it was very interesting to see that I'm coming up to my 10 years with Drupal on Drupal.org. I'm nine years, nine months. So I kind of cheated in this slide and rounded up, but that was, that's quite interesting. Yeah, and then five years with Kubernetes, which was also super interesting. So, yeah, but for those who don't know me, my name's Nick Xu. I've been in the Drupal community for a really long time. I've worked at previous decks for nine years and I've also contributed to Drupal Core and these days kind of in the second half of my career, I'm way more focused on operations and platform building and CICD and that whole kind of DevOps movement. And I'm here to talk to you about Skipper or introduce you to Skipper and the core development workflows around it. So first, what is Skipper? This is kind of everything boiled down into one sentence, a scalable cloud hosting platform, specifically designed to maximize the productivity of development teams. That's a lot to chew on. So I'll skip to the next slide and kind of talk about the problem and not read this statement either. But if you want to read this, this is actually on our website. So, but the problem case is that this is kind of our story in a nutshell. We five, six, seven years ago, a lot of our hosting was disparate across lots of different cloud hosting providers. We also had, which meant that certain sites were on single instance hosting or sites were on Acquia hosting or sites were on like these really expensive HA AWS stacks. The problem that we had was trying to have a consistent set of tools as well as provide the same kinds of guarantees. And our solution was to take all those boxes and put them on a one box to bring them onto a cluster approach. And this was really driven by the container movement and the Kubernetes, so Docker, Kubernetes and the like and cloud native more specifically. So for others, Skipper will then take all your sites and run it on one consistent platform versus running it across multiple different disparate platforms with different guarantees. And it's also built on, like I mentioned, solid foundations in terms of Kubernetes, cloud native. And then we also sit on top of AWS managed services for everything that we do. And yeah, cool, okay. So, and sorry, and this isn't kind of, I just wanted to touch on, this isn't kind of a new thing. This isn't just an us problem. Like this is a pretty broad problem and a journey that a lot of folks are only just starting to go on now. I think it's really worth touching on that. We're seeing a lot of people going on this journey now and given we have about five years of experience in this field and getting to where we are now, we know where all the potholes are. So if you want to know more about that, next month we'll be doing a webinar and you can just subscribe to our socials and follow us there, but we'll also post potentially in the Slack as well. Cool, so our approach, this is it at the high level in terms of workflow. So for taking us as the example, we have a development team and it's very typical for development teams now to have more than one project gone are the days of just having one Drupal site that somebody maintains. So the development team has consistent tooling that goes through their CICD pipelines using the Skipper CLI. This piece is very crucial because Skipper is CLI based, it's command line based, which means it can integrate with anything that can run a command line. That's your GitLab, GitHub, Actions, Bitbuckets, Jenkins from your local, if you really want to. It's all very consistent and can integrate anywhere and meet your needs. And then the Skipper API itself, I like to think of it as a bit of an iceberg because everything like you're only seeing the tip of it and we're orchestrating all these services, not just Kubernetes, but a myriad of managed services under the hood to deploy what is essentially in the context of this Drupal Meetup, a Drupal, a cloud native version of Drupal. Just zooming in a little bit, this is what the stack looks like. Front and back are all managed services from AWS. Whether it's their WAF or their solution or their CDN solution, which is proven itself, I think CloudFront was maybe the third or fourth service that AWS shipped. It was very early in the AWS journey and it's proven itself time and time again. But then services like databases for MySQL, which have also proven themselves and are getting to the point where you can click and install a serverless database that will just scale CPU and memory to your needs. It's pretty amazing. And that's not just AWS, that's cloud, but in this case, AWS for us and in general. You just can't deny how far ahead AWS are with some of these technologies as well. And then your sites are deployed onto our cluster, which is orchestrating all these managed services and then scaling your application out across three availability zones. Cool, so to sum it all up, we're kind of the place to take all your sites, that's Elastic, we're Australian based, we're also not just sort of ops support, I guess is something to point out. We also have, we're very skilled in Drupal, like everybody at previous Next is very active in the Drupal community and the people supporting the platform and helping teams deploy their apps on Skipper aren't just supporting the platform, they're also building and shipping applications on the Skipper platform as a part of their daily. And then ultimately we're here to empower developers, so. And two that I just wanna quickly run over are Service New South Wales and newsouthwales.gov.au, which are running on the Skipper platform and these are two sites that are very, like very dear to me given the current climate and the current say year, year and change that we've had, especially with COVID and being able to service and us being able to make sure that these sites were up and scaling and running well during the pandemic and these sites being, having a meaningful impact on clients, like it's a big deal. So yeah, these are the two case studies that I really, really like to talk about. But for the developers in the room, I'll start to talk about the Skipper workflow. So I'm gonna go through the four core tenants of Skipper and we'll just step through. So right from the beginning, there's packaging your application. So the first thing that you're gonna do when taking your application and deploying it to infrastructure is you're gonna have some kind of packaging mechanism which is extremely important now, especially the Drupal 8, Drupal 9 or Drupal 8 Plus. Drupal 8 Infinity if you spin the eight to the side. But yeah, it's all about packaging the application and the stack has changed, especially in Drupal 8 and beyond. Like we're all using Composer now and we're all using Node and we're downloading the internet. So it's not just the code base that we're handing, we're actually packaging an application and putting it into an artifact and then sending it to the infrastructure to be run. And for us, it kind of breaks down into this. You compile the application and then you split it into the three components. So anybody that's run Drupal is most likely familiar with an Nginx FPM stack. So we split the application into these two containers as well as a command line for shell and for Cron type tasks. And by splitting it out into these three components we have a highly scalable spread out deployment for your application. Nginx and FPM all scale independently. And that looks a bit tricky, but we take care of all that for you. Did I drop? No, okay, I'm back. Sorry, I just lost audio on my headphones. Yep, so skip a package takes care of it for you. It's orchestrating that build strategy for you. It's gonna help you compile your application and then package it into those three artifacts that then Skipper will use to then make highly available and then elastic. So here we're packaging up zero to zero to one of the application. Anybody that's familiar, a little bit lower, anybody that's familiar with the Docker file would be also familiar with this packaging format. So while it looks like it's extremely custom it's actually just a really nice shim over a Docker build, like running Docker build four times in a very nice way, yielding an elastic infrastructure. Cool. So now that things are packaged, it's time to deploy. So we've packaged zero to zero to one and it's spread out. Now you can do a skip a deploy. And in this example, we're deploying to dev with our zero to zero to one version. And then you can use the exact command to run as many or as little commands as you want to actually migrate the application. So, and that really kind of encapsulates that whole workflow. That's it, it's a deploy and then it's an exact afterwards to migrate your application to that new known state. It's very simple and folks can see this and really articulate what's going on. It's deploying the application then running a set of steps. But we've also smoothed things out. So we have integrations with things like circle CI. So instead of folks going through and then setting those commands every time. So having skip a deploy and kind of building out their own circle CI pipelines. And we actually have some integration here. So we have an orb which is a reusable component that can be used for folks that are using circle CI. They include the orb and then they can use the skip a deploy job provide the environment and some post deploy steps. And then that allows you to then build out a dev staging production workflow or yeah, however you wanna slice it. Cool. We also have a GitHub action. So which folks can try out as well. Or you can just use our Docker image or skip a CLI Docker image as well. Yeah, Kim wanted me to get Kim wanted me this morning in scrum to point out that he wrote both the GitHub action in the circle CI orb and wrote the blog post. So that one's for you, mate. Cool. So we've packaged our application. We've deployed it and now it's time to configure it. And anybody that's used a cloud hosting provider has come up against this quite a bit. So I know with Acquia, there's things like including a settings.php file to then wire up your MySQL, your application to your database to discover directories to set keys and the like. And it varies from cloud provider to cloud provider. So for us, we took a step back and we have a very cloud native implementation or so the idea is that folks can get, set, delete, list config for their stack. And these here are the ones that are provided by default from the infrastructure when you create an environment from the get go. So you have access to a client. So you can wire up your application to Clam AV for antivirus scanning. You have a perspective of where your mount pods are for the application, your database connectivity. You can see here, we provide a read only endpoint for database connectivity, for high, like very expensive queries. And then your application includes a library and then you can just consume it using a get.