 All right. Good morning, everyone. Thanks for piling in. Thanks for finding space at the back. My name's Toby Bellwood. I'm the Lagoon Lead at AMAZIO. And for those of us that don't know AMAZIO or Lagoon, well, have I got some slides for you? So my talk is building a Drupal hosting platform for all users. How to ensure everyone has the information and tools they need to do their own job. So what I'm going to talk about is developers, why we think developers are really important and why we think building tools for developers is cool. But building tools for people aren't developers. It's also really cool because it stops those people from bugging developers. So my name's Toby. I've been at AMAZIO for two and a half years now. And we've done quite a lot on our platform and our hosting over the last two and a half years. We've gone to Kubernetes. We've built all sorts of really cool features and enhancements and really started working more with customers who've got a really large site holding. So I think our largest customer's got almost 500 sites on the platform at the moment. And before joining AMAZIO, I did some GovCMS stuff. I did some DataGovU stuff. I did some national map stuff. I've been around. Has anyone not heard of AMAZIO? Whether people whose booth you wait next to when you're going to get your meals or your snacks. We're a zero-ups application to the platform and created by developers for developers. I'll come back to that. But basically, we do web hosting. We do web hosting for Drupal. We do web hosting for all sorts of platforms out there. Today I'm really going to focus on Drupal. Lagoon is our application delivery platform. It underpins AMAZIO. Lagoon is open source. So the code's out there on the internet. You're free to poke holes in our logic, pick a piece, pick apart some of our technical directions or contribute, or contribute, please. Really happy to talk to you about Lagoon, about AMAZIO, about any of those things if you come and find us at the booth. So by developers for developers, what does that really mean? We talk about it quite a lot, AMAZIO. We're all developers. I'm going to loosely call myself a developer here. But we use these systems. We build things all the time. The by developers for developers was a really good tagline for us and it's been really good in connecting with our target audience. But over the years, we've started to realize that more people are using our platform other than just developers. So developers, so who would consider themselves to be a developer here? Who would consider themselves an ex developer? Few hands up, cool. Who would not classify themselves as a developer? Who hasn't paid attention to previous three questions and just want to put that in there. Okay, keep it cool. Developers, rationalization, like their own tools, they're like their own processes, developers need to develop. If we're not writing code, if we're not putting stuff down, we're kind of lost, directionless, aimless beings driven by deadlines. We want predictability. We want to be able to know what we're doing, what we're doing is working, what we're doing is getting into customers and clients hands. So the solutions we build should build on developers' existing experience. So preferably not introduce too many new tools, too many new functions, too much new functionality, multi-purpose and reusable. I've spoken to a number of people over the last day also who've got 28 different platforms that they use, so 28 different things and one client's job is here and one client's job is there and you've got to tear down your machine so that you can reinstall some things so you can have the CLI to update this client. So multi-purpose, reusable solutions, relearning, having to context-switch between one project and another, one platform and another, one tool and another. They all take time. They all take time away and focus away from your day-to-day job. Developers like automating things or telling people they'll automate things and just doing it manually and pretending you automated it months ago. But one of the things I really want to focus on is allowing other users to sell service because the biggest time killer for people who are technical doing technical stuff or in technical flow is someone hovering over their shoulder saying, excuse me, can you tell me about blah blah blah? It's, I'm one of those people. I can do the voice because I am that person. But asking those questions, is this done? Where's this at? Are we using this version of this application in our tool? What's the route for the thing that we built for the person the other day? We should be really allowing other people to find and discover that information for themselves. So I'll talk about tools that developers are familiar with. In the Drupal world, Lando, Composer, Drush, their standards, Drupal's lucky and it's got some really good tool standardization. So when we talk about our platform Lagoon, we got to make sure that sites work with Lando, that sites work with Drush, that everything is Composer-based because this is the 2020s after all and if you're not building with Composer, how are you building your sites? So we've written all sorts of processes and tools around that. So we use the Composer core scaffold stuff quite a lot on our platform to help put files in the right place in folders. The more people are doing this, the more normal it's becoming, the more understood it is. But if you want to customize your site, you can sort of extend our integrations package and you can drop in your own settings files and you can overwrite our aliases and you can do clever stuff like that. But that all lives within the bounds of what Composer was made to do, what Drush was made to do. We've written some of our own tools to make life a little bit easier. We've written a CLI tool, trying to keep it as simple as possible so that people can use that CLI tool as part of their automation work. They can deploy branches, pipelines, et cetera. We've written some quite nifty other tools that are intended to take stuff like Drush that little bit further. So we've got a nice syncing tool that can sync database to database. It can sync files to files. And because it's not Drupal specific, you can use the same tool to do a WordPress site or a Node.js site, or you can do whatever because it's basically application agnostic. So the idea of that one solution for multiple purposes, if you're developing constantly in different application frameworks, you've got the same tool available, you've got the same process and the same scripts. Delivering outputs in formats that are familiar. Now, this is something that we took a long time to bring in, but our deploy logs were a massive wall of text, which is great. If you know what you're searching for in the wall of text, which eight of us do, and the other two and a half thousand users were just faced by this giant wall of text, our original solution was to have a really nifty up-down button, a down arrow that became an up arrow when you hit the bottom, and that solved our problem for about six months. But moving to an accordion, accordion's got timings. This is the same kind of display as you see in GitLab, as you see in GitHub, as you see in SQLCI. Trying to put the logs in a format that people understand. We released this in about three days later, someone said, oh, I quite like the old one. So there's now a sneak PR that will emerge soon that has a button saying just show me the old logs. We made that for one person to keep them happy because that's how much we care. So a lot of this, this part is developer focus. So once developers are doing their job or in their groove, why do we want to avoid piling work onto these poor people, engine room of the office? Are we going to make you learn Kubernetes just to use a platform? We don't want to do that. We don't really want to learn Kubernetes ourselves, but it's our curse. It shouldn't be a developer's curse to have to know about Kubernetes. You need to be a cyberwiz. You need to know everything about security, everything about application testing and penetration testing and all that stuff. Do you need to learn new languages, tools? The developers even need to do half of the stuff that we're asked to do. So let's start thinking about self-service. How can other people self-service? How can other people use some of these tools? How can we put some of this information in the right people's hands? So project owners, product owners, project managers, I'm a question-asking person. So I feel like I'm throwing a bit of shade at myself here, but time spent doing work, others could do themselves is a productivity killer. So if your developer is getting this information, is doing this report, is finding this stuff for you, they're wasting your time, you're wasting their time, you're wasting clients' time, wasting customers' time. Put yourself in the shoes of someone who isn't a technical person. What do they need to do? So what do they need so that they can basically get off your back and have the information they want, discover the information they need? So when we talk about building apps, these apps should be usable for all users, not hidden away behind some CLI and some obscure set of commands that I don't wanna give a project manager a GraphQL query to get the answer to a question they have, I wanna be able for them to find it quite easily themselves. So when we look at the front page of our UI and our UI is in the process of being overhauled, but we try and create it pretty simple. We can show what environments, we can show Git repos, we can see whether branches pull requests, how many development environments. One of the most common questions we get from people is, my project's not deploying development environments. And when you look at the front page of their thing, it says you're using five of five development environments. That apparently isn't enough of a clue for people that that might be why your development environments aren't going through. Bit more information in the screen, sort of if you're running in multiple clusters, multiple regions, there's a bit of information loaded into those little environments tabs that's quite hard to read because the project is at 720p. More information on an individual project you can sort of see when it's created, when it's deployed. You've got the route there so that someone who wants to go and visit that route for that particular environment can visit it without having to get you to email them the particular route to check the pull requests that you just made. If you've done a piece of work, your client, your customer user can visit there and just hit that route straight away. We give information on backups and deployments and people can download their own backups to their local machine, so a developer could develop with last night's backup. If you've got government customers, they can download backups and put them into TRIAMIF. That's what they want to do. And we snicker, but people do that. Again, you don't have to ask someone to generate a backup for you and send it to you. Someone can just go to the UI and download it. Running tasks, running tasks is something that we've done a lot of work on recently. So Lagoon has always had a full suite of drush tasks to do SQL dumps, askings, generate login links. We've been able to extend this recently to do more and more custom tasks, so being able to help users with some tasks specific to their own environments. I'll cover a couple of those in a bit. We've started collecting facts about people's sites, so whenever you do a deployment, the Lagoon can record what versions of particular applications are in use. So we only collect a few at the moment, but we're gonna make it so that we can collect more and more, but that will tell someone what version of drush is in use, what version of Drupal, what version of PHP. If you wanna know whether you're affected by the latest Drupal call vulnerability, someone can go to that screen and they can see what version Drupal is in use in this site without having to email you, send you a slack message at 6 a.m. The person that needs the information can just get it straight from here. So we're trying to automate some of these tasks for users the same way we automate tasks for developers. So looking at these tasks, we've got the ability to customize these tasks. So we saw the Drupal ones, nice and easy. We've also got the ability to add additional tasks in. So this is one of our customer sites which is why I've obscured some of them, but they can publish new base images from their tasks. They can clear the cache on their site, they can pull down databases, they can copy files about and around because they've not got a Drupal site. So the drush commands that we have on the platform don't work for them. So they've had to make their own synchronize their own published tasks, but anybody who's got the right permissions can go in and run those things rather than having to hit a developer up to say, hey, I need to get new base images published, I need to copy a database down from main. We've created a task, put a task in the UI that anybody can go and run themselves. The ability to deploy environments in bulk is a big thing that our customers are looking at as they've got multiple sites. You're running 20, 30, 40, 50 sites. You've got to deploy all of them for some reason. Maybe you're running a base image extension and you've got an update to go through. Being able to deploy all of those sites at the click of a GraphQL query. But that's simple. But that will create an individual page for that deployment. So once you've triggered that deployment, you can send someone that page and say, this is all the things that I've deployed today, let's watch them all go through, watch them all complete successfully apart from that one that we made fail on purpose just to show that not all deployments are successful first time. Being able to see and monitor that means that someone else can have insight into what's going on and doesn't need to keep pinging you to find out where it's up to. Likewise, you can track that and see how it's going. We talked a little bit about security and Richo gave a really good talk at Drupal CompRug. Check it out in the video description talking about how you can, more people can get more involved in security of sites and things you can do. A lot of the security teams aren't developers. They don't have the same access or same level of control as developers. So it's really important that we start to give those people kind of the tools they need to be able to do their security work, ask their security questions and fill in their weird little questionnaires. So, if it's everyone's responsibility, how do we help the people that have got this new responsibility with discharging their responsibilities? So, talking about SiteState, let's talk about uptime, talk about monitoring, talking about reports on software versions, currency, vulnerabilities, scanners, et cetera. So we focus on three main things on our platform. We talk about a bill of materials, so S-bombs, every deployment you do to Lagoon generates a software bill of materials. That's the application state as it's deployed. And the beauty of that is that that application doesn't change between deployments. So you need to capture it once and you can then reuse that S-bom multiple times and I'll show a use for that. Vulnerability scan. So you can create one of those ad hoc tasks to take that S-bom and generate a vulnerability scan on it. So you can run a vulnerability scan direct on the code base. But importantly, because our platform allows similarity between production and local development, the same scans can be done locally as part of your development workflow as well. So insights, observability and status. So we've looked at those S-bombs. Now we use those S-bombs to generate the facts that we put on the screen that showed Drupal version, PHP version, et cetera. And we can create facts and we can create metadata from that application state. So one of the plans is to add more information into the UI so that someone can say, okay, I've got 28 sites to show me which ones are running Drupal 9.2.4, which ones are running Drupal 7. One of our engineers deployed a Drupal 6 site a couple of months ago. I think he did it for the challenge. He's promised it won't be on the platform long. It's migrating to something else, but it'll be there a long time. But how do you see that? How does someone who wants to know what version are we running of this? How can they get observability into all 25 sites? So they have to go to every site, click on the tab. Do they run a report? Do they run some sort of scan? Be really easy if they just had a place they could go and they could filter and they could do a drop down. So looking at this, this is a quick wave seeing these insights. So this is a simple one. It's got image insights and it's got S-bombs insights. That's what an S-bombs look like. It's pretty exciting. This one I think shows that we're running Drupal core 9.24, which is purely for demonstration purposes. Not a production site. It's not a production site. But the S-bombs comes in a standard format. This is a file that can be downloaded as a JSON file. This file can then be used in another tool to generate a vulnerability from it. So this only tells us it's running 9.24. It doesn't say anything about how good or bad it is or judge us. This one, we've now run a scan on it and we've discovered that that version of Drupal has a security advisory for it that's high severity that's got a SA number and everything. So we've been able to run that scan on that file to find out, hang on, there's a problem here. Someone's been able to do that without having access to the underlying application, without having access to the platform, without having to do an image scan. They've been able to take that S-bomb off the UI and run a really simple command to read it, to pull out all the vulnerabilities that are present in that particular image themselves without needing to SSH into a system. It's much simpler and that way, whenever they want to do a scan, as long as the application hasn't, every time the application is deployed, it generates a new S-bomb and you just rescan it. We talked a lot about the tools that we build and the tools that we've deployed. One of the things that we look closely is whether we should integrate with at all or whether we should build into the platform. So we get requests from a lot of our customers, hey, it'd be so cool if Lagoon had this, it'd be so cool if Lagoon did that, so cool if he included this. And we do a lot of these sort of decisions and we try and work out, is it something that's worth doing, is it something we should bring in? We've been asked about billing tools, FinOps, like can we see the state of containers, more application monitoring. There's tools like New Relic out there that really could at application monitoring. Let's facilitate someone to use New Relic, but we don't need to build a New Relic clone inside our platform. Antivirus scanning is a great example. You can run an antivirus scanner on a Kubernetes quite easily that you can integrate with your application, it doesn't need to be joined into Lagoon. Logging, we integrate with logging systems, but we don't stream those logs, don't bring those logs straight into Lagoon. And threat and intrusion management is something that's really popular with some of our customers, it's more popular with our customers than it is with us because almost invariably, it means breaking everything we do so that they can have a demon set running to keep their security team happy. But there's better solutions out there than trying to lump everything we can into our platform. So we sort of talk about, we talk to customers, we talk to our own teams about is this something that we need? Is there a better choice out there? We made a notable exception to add front-end plug-inness to our UI though, because Vincenzo who runs our support is really nice to us. But yeah, a way of extending our UI so we can do a little bit of extension stuff on that. So we did let that one through. His wider plan to build something deep and integrated we. We should have done on, but we're allowing front-end plug-ins. So our users are the expert at using our tools and a number of the people here that I've spoken to in the last couple of days have told us how they use our platform. So we love hearing those use cases. We love hearing what people are doing, how people are using it. We love it when you tell us what we should be doing genuinely, even if we don't seem it. When that's my receptive face. That's not my noise face. We love it that you give time to help us make something better. We love it when you contribute. We love seeing pull requests in from people, even if it's just documentation. It means someone's read the documentation. If it's pointing to the exact piece of code that you think we've done wrong, we'll take that gladly as well if you can fix our code for us. That's awesome. That's really, really good. But we love that feeling of building this thing together. So where we're at, learn by using your own tooling. We learn more by deploying sites on Lagoon because we don't really build websites. We build a website hosting platform. It's only when we deploy sites ourselves, we're like, oh, actually, it'd be so much easier if you could just do this or you could just do this or you just had that thing available. We learn an awful lot by doing that. All user requests are equal, but in Animal Farm, some are more equal than others. Trying to keep the users in the right application for their needs. And this comes back to that, where is it's a better tool, this is a better place to do something, make sure the person's there. Use the platform again and don't be afraid to not build things. Our team does a lot of building stuff that doesn't work. We're like, okay, that's two hours. I know now that that isn't gonna work, that isn't gonna fix us. So not being afraid to do that. I've probably got a few minutes, four minutes for questions, but come see us at the booth. Our swag supplies are dwindling. I think we've run out of hats. I think we're about to run out of bottles, but there's still some sweet, sweet, stick erection and multipurpose buff, that apparently a photo of me wearing a buff on my head is now being used as our recruitment tool on Twitter. I'm not overly confident that that's gonna be successful. Get us to talk about Lagoon. We've got a really cool demo built where you can press a button and it triggers a deployment and you can see lights and robots and cool things. If you're interested in working with us, azio.io slash careers, we've got some really awesome jobs up and we'll have some really awesome jobs coming up in the next few months.