 How long can I make it wait before people get restless? So I'm relying on Dan, basically. There's people coming in there. I missed my chance. All right, I might click Start now, let these people come in. Good afternoon, everybody. My name is Toby. I'm the Lagoon Lead at AMAZ-IO. And I'm here to talk about how to build a Drupal hosting platform for all the users. Subtitle, how to ensure everyone has the information and tools they need to do their own job. The own bid in brackets wasn't in the official notes. That's what I really want this talk to be about. Good afternoon, evening, to everyone I know. Everyone I don't know. Good afternoon, and evening. So about me, my name's Toby. I'm the Lagoon Lead at AMAZ-IO. Been here for two and a half years overseeing the transition of our hosting platform into Kubernetes. And I think that's the last time I say Kubernetes in this talk. So that'll be a relief to some people. Done an awful lot of enhancements around managing multiple sites, bringing new features on board. Before joining AMAZ-IO, I ran web and data teams for the Australian government. So yes, I am Australian. And yes, it did take me 42 hours to get here. No, I haven't got over jet lag. And yes, I do have to fly 42 hours back afterwards. AMAZ-IO, if you haven't been past our booth today, why not? We're a zero ops application development platform, operating delivery platform. And we're created by developers for developers. And that's sort of a frame you'll hear sort of throughout today. But we're basically taking your Drupal sites, hosting them in production, and trying to make the whole experience as painless as possible for you. There's the other stuff we say about solving problems for developers and busy teams, managing infrastructure and operations. But this talk is really about people that use the platform. So abbreviated Kubernetes to Cates down there. So that's technically not a Kubernetes reference. Lagoon. Lagoon is the open source application delivery platform that underpins AMAZ-IO. We're fully open source, codes available on the internet, run it yourself. If you can get it running yourself, come and see me. Seriously, it's not that easy. Basically, the whole idea is to streamline the delivery of these applications. So what you can develop locally, we can take into the cloud and make amazing and fantastic and wonderful and run without a problem at all. It's never our fault. It's always your code. Platform was open sourced in August 2017. So over five years of pull requests and issues, some of them are five years old. And for that, if anybody's are there, I apologize. So what it uses. By developers for developers. What does that mean? Technically, or what we mean that's mean is that we're application developers. We're not Kubernetes engineers. We're not infrastructure engineers. We come from a land of building Drupal websites. So we're really focused on what people need to build and run Drupal sites. What the workflows look like. What the tooling looks like. What the users and a really sort of keen idea of what the use cases for Drupal are. In my experience at GovCMS, I dealt with a very non-technical workforce, trying to be polite. In case anybody records this and tells them. But a large amount of people who are just site editors, they're just editing content. They're not committing code. They're not writing themes. They're not making modules. They're not even doing config management. They're pretty much just putting words on the page. So how do we build a platform that works for them as well as it works for people who are pushing code, who are doing sort of custom theme development, who are building modules, et cetera? Developers, as we all know, rash generalization. Who would call himself a developer in here? Everyone. Oops. Developers, generalization, you like your own tools. You like your own processes. You like to do things your way. Developers need to develop. That's what you're paid for. It's what you're employed to do. It's what you're best at doing. Dreadline-driven development, we all know it's best. I did my slides weeks in advance. Obviously not driven by the deadline of 5.15 today. And developers want predictability. They want things to work in their time frame. They don't want to spend time building, fixing, repairing things that they shouldn't have to. So these solutions, they need to be multi-purpose. They need to be reusable. You need to be able to make sure that you can do this thing many times over. If you're managing 20, 30, 50 websites, you want to know that the process used for one is the same as used for another and another. So you don't have to relearn. You don't have to keep picking up. You can pick up easily from where you left off, basically. Allow minimal focus is sort of, you shouldn't have to babysit every step of every process. You should be able to go in, do your job, do your task, let it run, check on it later. You shouldn't have to spend hours watching curses, ticking across, et cetera. Automation's key. We all have the way we like to do things, the way we like to make processes work. And most importantly, allow other users to self-service. We've all read books by people on developers and people on DevOps where there's one guy, there's always one guy who's the person that does everything. They answer every question, they run every report, they get every piece of information. If your developer is that person, they're not spending time doing the work that they're there to do, they're not needing to develop. So being able to help other users self-service is really crucial. One of the things that we looked at when we're building Lagoon is how do those users actually self-service? So talk about developers like in tools, we've got Drash, we've got CLI tools, we've got that kind of stuff. It's very developer centric. Developers are happy here. Average users starts to get a little bit scary if you're telling people, just copy and paste this into your command line and the next question is, what's a command line? You know that you're gonna have a really painful next hour or so. I'll just do it for you. I'll do it and I'll email the result. It's fine. Instead, moving to a bit of a user interface that's got a little bit of understanding, a little bit of familiarity. This is a deployment of DrupalCon demo and we can see the various steps it's going through. It gives developers the information they need. They know that this Lagoon linter found no issues with this file. You can see how long it took, but someone else stepping into that. Maybe not a developer, maybe a project manager, maybe a product owner wants to know if our site deployed, they can check this and they can find out quite quickly whether that's something that they need to worry about, they need to speak to someone. They can try and do a little bit of that triage themselves rather than asking a developer, why is my site not deployed? Information may be in there. Hopefully they can self-service that little bit. So yeah, let's not try to give our developers more work. And in the end, we're a Kubernetes development platform. Kubernetes is becoming a bit of a de facto standard. I don't want Drupal developers to learn Kubernetes. I think it's complicated. I've been doing it for a few years now and I think I'm at the capable novice stage. I'm really proud of that. So, but yeah, it's a lot to learn. So let's keep developers in developer tools. We'll talk a little bit about security as well. Do you need to know everything about security or can developers just develop? So yeah, how do we get the rest of the team doing that self-service thing? How do you get people outside the team? And we've all worked in teams where we've got stakeholders, we've got managers, we've got people who want updates on things. So how do we keep projects, product owners and managers happy or at least asking you less to questions? Time spent work that others could do themselves is a productivity killer. For every hour, you spend servicing someone else's request. That's an hour that you could be building products for customers. It could be billable time, et cetera. So how do we work out what these non-technical users want? I've got quite a good opinion on this because I'm essentially, I was a non-technical user. I ran and installed a large lagoon before joining Maze.io from a product owner point of view. So there's a lot of things that I wanted to see. I wanted to be able to do. There's a lot of insight that I wanted into our running applications that just wasn't at my fingertips. I knew enough to be able to go into CLIs and pull that information. But there's a lot of people out there that couldn't do that. So how do we get that information out? Again, taken Dilbert Cartin. It's got to be a Dilbert Cartin in any presentation. But from a simple screen, being able to see what environments we got, what are our git things, how many branches, how many of this kind of stuff, being able to put the information that anyone can log into, anyone can see, and you can tell what's your production site. We can add more information here. We can tell where things are deployed if you know what your clusters are called, what your regions are. Someone can look at this screen and go, oh, we're running in Europe West 6. I know exactly where that is. If you had different environments in different regions, you'd be able to see, at a glance, where that application's running. You look at an individual application. We've got a bit of information. When was it created? When was it last deployed? You can click on a link. So if someone wants to know the status of a pull request, give them a link to be able to go to that. Don't send you an email saying, what's the link for the latest piece of work? Put it in a user interface. Make it available to people. Things like backups, being able to download and retrieve backups. Again, something that a developer would traditionally do. Maybe the developer doesn't need to do it. I've worked in organizations where they take their backups out of their backup system and put them in their document management system, because governments. Again, not a job a developer should do. We should empower someone to do that, who's not gonna be better at spending time doing development work. Tasks, being able to run a simple task. Do an SQL dump, copy an environment from one place to another, run a simple demo process, generating a login link for your site. Being able to put these tasks in a user interface. Again, someone with the appropriate permissions can run that kind of task. Being able to customize these tasks for your particular site, for your particular project, for your particular install. That's a really big selling point. And you know what your tasks that you do as a developer could be, the things that you're most frequently asked to do. Rewrite those tasks for someone to be able to go in, click generate, run a report, see what they need, get the information themselves. We've introduced some new features into Lagoon that help give a little bit more insight. So this is an automated process that will tell you some facts about your running application. So this application that's running is running on Alpine 316, it's running Drupal 9.4.5, don't judge me. Drash 11, PHP 8.1, because we're all up to date with PHPs. Someone can see that. And rather than having to say, what sites are we running? What do we got PHP 8? What do we got PHP 7? Being able to see straight away without having to go into a command line or a site. Where that is. And on a larger scale, being able to generate a report using an API, using an interface that can say, show me all my sites that are running Drupal 9.4.5, show me all my PHP 7.4. Being able to retrieve that kind of information without having to ask someone to do it for you, that's a game changer in terms of productivity. So we can automate this stuff. Tasks, we can deliver those custom tasks. We can deliver custom steps. We can do some of that audit analysis stuff. The ability to run those tasks against not just one environment, not just five environments. Let's run them against our entire suite of 600 sites. Maybe not every day, that's overkill. But being able to do that kind of thing really helps with automating those people's workflows. Being able to chain some of those tasks together. We start to get into a little bit of a continuous deployment thing. So if it deploys a site, we can copy a database, we can run a B-hat test, we can do this, we can do that, we can generate a URL, we can send a notification to someone. Again, helping automate, helping move away from one person being the linchpin. And those workflows we can make dependent on each other. Doing that bulk reporting, so whether it's application versions, whether it's pulling in sort of audit metric data, et cetera, getting timings of builds particularly. That's something that product owners are super keen on. They're super keen on making sure that everything builds as fast as possible and successfully as possible, surfacing that information for them so that you don't need to run a report as a developer is gold. Quick example, this is a bulk task. I can generate a deployment of six, five sites at once. I can see at a glance which ones have failed, which ones are running, which ones are complete. I can do that from a user interface from a simple command, I can see where they're at, I can see where they've run. I can know at a glance how my infrastructure is doing without having to go outside of my comfort zone, my individual application comfort zone. So security comes up. Security is a big thing. We know we're being told to shift left all the time. But what does shift left really mean? How do we give people the power? We saw some of it, that sort of the application, versions, et cetera. We know, I don't know what time it is in Europe, but it's 6 a.m. Thursday in Australia. We get through pull vulnerabilities. It's brilliant for us, because it's just before our workday. We can come in, fix stuff. We know to check then, we've got a really good finger on the pulse of what version's just being released, what modules are just being patched. But not everybody has that. Being able to run those ad hoc scans, being able to have access to that kind of data on what you're running, what's potentially vulnerable, being a set up notification so that I know that this module that had a vulnerability, we've got 200 sites, but we're only running it on three. We're only running it on four sites. You can really target your work just with that little bit of insight. So to do that, we can do various things. We can generate software bill of materials. Software bill of materials are all the rage nowadays. It's basically, it's a list of all the application versions running in any particular, in our case, container image, but any particular application. We can generate those facts. So the facts we saw a couple of pages back, they all come out of a bill of materials. Every time we build and deploy an environment, we generate a new software bill of materials that we save in the AI and people can access that. Running vulnerability scans, so there's all sorts of vulnerability scans you can run on Docker images. Being able to run those ad hoc, so have we got any vulnerabilities? Yes, we should be running them all the time. We should be running them more frequently. But you know, as a security person, if a security person really wants to know what's the status, they can run a task on the spot to analyze that software bill of materials to see what are their criticals, what are their highs, what are their lows. And then being able to use some of that state data to create those facts, use the UI to identify what's running and really empower those people to be able to take some charge themselves rather than getting the email on a Wednesday afternoon and saying, hey, are we running this? Are we running this application? It's been all over the news. Is this a problem for us? So we can do this. Here we've generated a couple of S-bombs and image scans for the DrupalCon demo application taken screen of Kodi stuff. But you can see here, this is showing us that Drupal core 9.24 is installed here and I'll point out that we installed that just to make sure that it came up with a vulnerability, not because we haven't updated it for a long time. And sure enough, there's a vulnerability. There's an improper input validation in Drupal core. But it's fixed in the current version 9.2, or the latest version 9.2.13. It's got to link through to the Drupal information. That's all generated out of that S-bomb. So someone can find that piece of information quite easily. Other things quickly that we've looked at over the years, whether to integrate or whether to build it into our application. So things like billing and FinOps tools, the state of running containers, application monitoring, and for scanning logging, et cetera. Ultimately, we haven't built these into the actual platform themselves because these tools, there's really good implementations of them. And we could try and rewrite them in our application, but we think they're better integrated into where the application actually runs because the target market for a lot of these tools, container state people, product owners, project managers, don't need to know container states. That's an operations thing. The ops team, we've got ops team tools for that. Threat intrusion management is a security thing. It's not a shift-left security thing. That's a security team thing, and the security team is gonna have their own applications for that. So this is things that we've looked at along the way and worked at. It's really better off having those applications where they should be. So, do a bit of wrap-up lessons we've learned along the way. Really using our own tooling has been quite informative for us. Obviously, I've spent time using our tooling before I joined our team, but user requests, a lot of our users have good ideas. We pay attention to all of them equally, honestly, and don't be afraid to not build things. Those things that we didn't implement in the end, we didn't implement for a reason. So, a couple of follow-up things. Check out Richo's talk tomorrow. He's gonna talk about security for everyone. Yep. So we use SIFT, Ancors, SIFT product to generate S-bombs, open source, it's fairly available. We integrate that and we use gripe to scan those S-bom. Again, Ancors, gripe. Come and see us, Masio Booth. We look like a big container. We hand out drink bottles for a minimal conversational interaction. We've got a demo of Lagoon running. We can show you a little bit more in depth. Most of us know how to use it at this point. Check out Masio Careers. We've always got jobs going, so more than happy to have people on the team. Got a couple of talks. Michael, Basti, and Alana's talking right now. We're not gonna encourage everyone to get up and leave, but catch those talks afterwards when they're recorded and available. Contribution opportunities, slide. I think that's me. I've probably come in close to 20 minutes. Any more questions? If you do have any questions, come and see me. I'll be here all week down at the Masio IOU desk.