 My name's Toby Bellwood. I'm the product lead for Lagoon at the Maisie IO. I'm not based in New Zealand, unfortunately but I am based in Canberra, Australia and Maisie IO has quite an extensive team all around the world, but we're particularly proud of our New Zealand and Australia teams We've got eight people now between Australia and New Zealand and we do an awful lot of we've got an awful lot of work down here. So We view ourselves as having sort of two homes So I apologize for not being a true New Zealander, but I am in heart and spirit So yeah, we'll be talking a little bit about Kubernetes a little bit about Lagoon a little bit about Maisie IO But as I said before more than welcome to sort of take questions if you want to try and interrupt my flow go for it I'm more than happy to do that either ask a question in the chat or I meet yourself and button. I'm happy either way So quickly, I'll go through a Maisie IO Maisie IO is a global managed service provider Delivering secure enterprise-grade web ops solutions and services And the Maisie IO's key Platform is Lagoon. It's a product called Lagoon and it's specifically built for Kubernetes based modern cloud environments The company itself we we sort of pride ourselves on being able to host anything anywhere in the world. So We deal with a number of infrastructure providers vendors Our team is based all across the world. So Australia, New Zealand Europe, South Africa, North America, we've even got a presence in the Caribbean so I'm not sure that was business driven, but he Sends us lots of photos and we're very jealous We pride ourselves on our 24 24-hour day chat-based support. So because we're a global company because we've got people all around the world We do support our customers all over Everything is open source we believe Strongly an open source so Lagoon product itself is open source a lot of the products we use inside Lagoon are open source And we think our for our customers and our users having full visibility Into what we've built and what we're doing is the only way to go So we're fully committed to transparency Globally clients include governments healthcare financial services education media travel You name it. We've pretty much covered it and We've worked really hard on being Trusted for our security and our support and in the last few months We've also launched a partnership model to bring ourselves a lot closer to the people who are Running sites on our platform and people who are working with their customers. So Yeah, we believe strongly in their collaboration cooperation So I'll quickly from the top. I'll just quickly go through what Kubernetes is for anybody that doesn't understand what Kubernetes is This will be a very quick intro for anyone who does understand Kubernetes. I apologize if I've missed anything But basically it's a portable open source platform for containerized workloads Facilitates declarative configuration automation. So basically you The platform itself is all defined in code. So everything you do in Kubernetes is written down as a piece of code So you have to write Every element you want to build in communities You write in code. It's not pointy-clicky draggy-droppy like the some of the systems of old. It gives you a lot of flexibility It's a natural successor to virtualized environment. So In the old old days, we used to have one server per site or one server per Web presence. We then went to virtualize so one server could host multiple VMs and each VM could do multiple workloads Kubernetes and containers are the natural success of that So they can be you can have really really tiny sites or applications that only serve a static page and Receive 500 hits a month up to sites that host millions and billions of page views and can scale off the charts Sean Hamlin one of our technical managers did a really good talk yesterday about The need to scale during the COVID-19 Response for the Australian government So there should be a recording somewhere around if you can dig that out That's a really good example of what Kubernetes can do and how it can scale massively in a way that Virtualized servers couldn't in a way that physical servers definitely couldn't It's used all around the world. Everyone's talking about Kubernetes. Everyone wants Kubernetes It is not for the faint of heart. It's not something that's easy and straightforward to deploy We at amazing. Oh, we're a very big Drupal Very big part of the Drupal community and there's a brilliant Slack channel in the Drupal chat called Kubernetes in which almost every month someone steps in and says Hey, I'm trying to deploy my site to Kubernetes and I've come across this error and there's sort of a collective sigh as everyone realizes that We've been doing this for two three four or five years And we understand the nuances and someone coming in cold trying to deploy particularly a CMS application Into Kubernetes is in for a whole world of learning It's a fairly comprehensive Undertaking all the examples you see of Kubernetes will be how to deploy a little node app or a little Python app or real world implementations are far harder and far more complicated So Kubernetes as I alluded to It's based on containers, so if you're familiar with Docker Docker has this model of Building applications from containers each container has a specified purpose and those containers can interact with each other To so you'd have a database container and you'd have a web application container and if you've got search you'd have a search container So these containers They're called pods and they sort of host these individual components of the applications Kubernetes has deployments and sets which tell Kubernetes how to deploy these pods So what ports should they open if they? Whether that how many of them there should be Whether they should tear them down when they die whether they should recreate them How much resources to give them and there's a whole raft of things on the right-hand side? You can see a very small part of what a Kubernetes deployment looks like Rolling updates unavailable search replicas templates. It's Ready seconds and it's there's there's a whole lot of information. It's really really controllable, but it's really hard to get right services, so if your application needs connecting to the outside world, so Whether that's a web service or whether that's a database service or whether that's a search service Kubernetes controls all of those so it knows what ports to open it knows what external Endpoints to give them what web domains etc Storage every application needs well most applications need to store stuff somewhere When where do you store that data? What kind of storage is it if you've got an application that? Has multiple pods because we've got massive traffic. You've got lots of replicas You've got to have a way that that storage can be accessed by multiple people at the same time so You might need multiple Different pods writing to an app to a storage at the same time So you might need to make that read write many read writes once if you've only got a single writing stream Whereabouts does that go what kind of storage and how does that interface for the underlying provider? Communities has jobs a job is just a short running task. It's not necessarily a website It's more a cron job or something small that you need particularly in the CMS world Drupal WordPress Laravel. They all have Short running tasks that can be used a little little bit of gardening a little bit of tidy up behind the scenes and labels Kubernetes has a lot of labels and labels are what's used to control all manner of things and they've also got annotations which can help Kubernetes decide where it puts things and a Kubernetes install Has multiple nodes and each node can have a certain amount of pods and those pods can go on nodes depending on What I'm trying to get at is that Kubernetes it's really hard. There's a there's a lot to understand and it's a very different mental model Each of these applications that we build then live inside an individual namespace. So a Pod from one namespace Bod from your website can't talk to someone else's websites unless you specifically allow it There's a lot to get your head around and Coming from a simple if you've got a simple web application Lampstack if you're used to using Apache my SQL PHP It's very different. It's very different because you don't have direct access You don't have direct control to a lot of the environments that are running You can't just go in and make a change to a production file the production files got to be deployed via one of those deployments We you can make a change, but the next time a deployment comes through it will overwrite whatever change you've made So you've got to put that change back through the process Application delivery in Kubernetes is something that we have identified as being something that Lagoon can solve So as we've just covered we're talking about pods. We're talking about deployments. We're talking about storage There's a lot of configuration needed to just run an application And that's without any of the extras that you'd want to run in production So yeah when we're talking about storage talking about ingress. We're talking about strategies. We're talking about replicas. We're talking about Resource allocations. There's an awful lot That you need to do and web application is naturally a very complex If we're looking at a typical Drupal Installation you might have a PHP Process you might have an engine X to serve the sites. You'd have Maria Maria DB or my SQL or postgres database You might have solar or elastic search. You might have Redis To do caching you might have mem case. You might have varnish You could have like easily seven or eight different services inside those applications and each of those services need all of that Configuration they need to be configured to talk to each other. They need to be configured. You Generally don't scale your database The same way you'd scale your web in Kubernetes and If you have Kubernetes is built to be disaster tolerant. It's supposed to be fault redundant So a node that has pods in it if that node becomes unavailable and unresponsive those pods can automatically schedule somewhere else Your application has to be able to handle That pod scheduling on a different node There may be a few seconds where Kubernetes has to work to find out where that pods gone to So your application has to be that little bit tolerant of that In order to do all this your developers need to know a lot about YAML and for those that don't know a lot about YAML Don't it's horrible It's like Jason, but made complicated for For reasons we'll say But yeah, the slightest error in a YAML format can cause things to not deploy in unintended circumstances, etc there's a few UIs for Managing a Kubernetes cluster, but not many for doing the sort of the Configuration aspects of Kubernetes a lot of it. You're in notepad. You're in visual studio. You're editing YAML or if you're Brave editing YAML directly in the the Kubernetes UI And While Kubernetes knows about these strategies rolling strategies, it knows about the pod failover. It knows about the redundancy aspect This isn't automated out of the box. You still need to program and configure your applications to do this And also the base images for applications are often very customized So Troopal has custom Elements inside it that it needs to have on top of PHP to work WordPress has similar I know Silver Stripe in New Zealand does similar there need to be a couple of extensions enabled and There's sort of no real broad standard about How to do that Kubernetes doesn't come out the box with this stuff It's something that you need to build you need to configure yourself and and There are a lot of tools out there for anybody that's ever looked at the cloud native compute Foundations landscape the CNCF landscape. You'll see there's an awful lot of tools around application delivery around continuous delivery and We've looked at them I've got a super spreadsheet with about a hundred tools on it at this stage that we regularly look through and try to Identify what are they doing? How are they doing it? The primary focus of a lot of these tools is for the deployment of a single site. So if you've got an application That you want to build and configure to put on the web if it's a single app You can use flux Argo tecton Waypoint There's almost a new tool every week that comes out These are really good for individual applications where your DevOps team knows that app and it can make those changes As soon as you want to deploy more applications You've got to build an individual pipeline for every single application you deploy For our point of view at amazing IO as a managed hosting provider We host thousands of sites and managing thousands of pipelines for thousands of sites Is a huge burden and while we could template some of it We've gone a different route and we've really trying to sort of tailor application delivery To web applications and really look at what are the web applications most commonly in use And that's why we've decided that a lot of the sensible defaults that come out of Kubernetes aren't the best for what we're particularly doing so We're looking to add and augment those defaults with the settings that are best for our particular applications and The other aspect that comes to this is that once you've got your application running on Kubernetes it comes with a bit of Sort of infrastructure monitoring, but it doesn't come with application monitoring. It doesn't come with logging. So if you need to collect logs with our application logs or container logs or Administration logs if you need to come to backups, you're sort of more back-upping a Kubernetes object so one of the things we've wrapped into as well as Adapting those sensible defaults is we've put in what we think is the optimal monitoring logging and backup stack for web applications so Into Lagoon We we like to think that Lagoon drastically reduces the time taken to bring web applications to Kubernetes so we'll provide that configuration tooling insights and We've got a lot of experience running these sites in production at scale securely so Lagoon is developer focused the idea is we put the power back in the developers hand So not having to write Kubernetes YAML if you're a Drupal or a WordPress or a Silver Stripe dev is going to be One less thing to worry about. I know that a lot of our team Here an amazing IO have spent a year two years getting to grips with Kubernetes and This is all day every day. This is their job and we learn and discover and understand stuff every day So having to learn Kubernetes YAML on top of your job as a Drupal developer or WordPress developer is a pretty big ask One of the things we really pride ourselves on and that's because we're using that Containerization method popularized by Docker local development Runs using those same base images that Kubernetes does so you can do an Awful lot of development work locally and be really confident that it's going to work in production as it does on your local We've really worked to emulate to really streamline that local to production workflow for our developers to give them the confidence in that process But it's all based on get-ups and infrastructure as code So the same as Kubernetes, but we've brought it down to the application level so Fundamentally all you need to do to make an application run on Lagoon is add a couple of files and a couple of lines of configuration and It will do the rest obviously because we want to be configurable We do have options to control routes and to control storage and control some of those jobs, but broadly What's in the code base is what's in Lagoon? So we've got a user interface so we can trigger those So people who aren't Familiar with command-line interfaces who haven't maybe got the permissions on the git repo But as a project manager or as a product owner You can trigger a redeployment. You can see how that has worked From straight from the UI Because it's based on get-ups When you've got PR branch at PRs you've got git branches We can generate automated environments from those So if you're doing a new piece of work on a new section of your website You can submit that as a pull request to your repo and Lagoon will see that pull request and it will create a branch for you separate to your main one that you can then go through and you can look at and you can share with the client or the customer or the executive or Your family member if you're proud And really show them what it looks like and that because that's running in Lagoon That's as close to production as you'll get so you can really iron out any last-minute kinks at that stage and that all comes Automatically generated as part of the git ops pipeline The UI has got a Large amount of the same functionality as the API in the CLI do so there you're able to see your deployments You're able to see your environments. You're able to delete environments You can get a rich understanding of the current state of Way or application is that without having to dig into the code that would you go deep? And part of what we do is Lagoon is provide some of those base images I was talking about so If you want to run PHP web application, we've made a docker image for PHP that's optimized Towards running in docker and Kubernetes. There's optimized to running in production securely and The sites on our platform don't have to use our base images But well over 95% of them do because they've got that tooling They've got that configuration built in the how to send mail how to Configure robot headers how to automate some tasks how to set up cron jobs Um So we've basically we've used We've put a lot of thought and knowledge into those base images to be able to automate The deployment process and I'll pick up quickly that question from Rodney How much is our product and how much of his packaging open source Kubernetes tools? So in terms of Rancher, we sit in a slightly different space to Rancher Rancher Broadly is used to automate the clusters Whereas we're automating the deployments into the clusters. So we we do actually use Rancher to manage our clusters But we use Lagoon to manage the deployments within the clusters We do stand on the shoulders of Other opens a lot of open source tools so we use A Kubernetes backup tool called k8 up we use Projects like scope. Yeah, we use elastic search. We use Grafana Prometheus So read the next part of your question When we talk about being a managed service provider, are we meaning for off-the-shelf apps or for customers that are bringing their own applications? broadly Our strong preference is for Sort of running off-the-shelf apps if you're bringing your own application to Kubernetes that's got your own Sort of infrastructure setup and configuration that sort of It's going to be quite hard to message that into the Lagoon model. The Lagoon model is loosely opinionated will say towards That sort of traditional web application structure The non cloud native one if you can architect your application itself to be cloud native from day one You're gonna have a better experience in Kubernetes But as yeah, as we went through a lot of these web apps. We're talking about aunt cloud native Right. Yeah Sorry Toby. I'll just get to the chase here, you know, we have a containerized application that does run under Kubernetes I'm just I'm just wondering when you talk about being a managed service provider whether you are actually Providing that option. Maybe this is a conversation. I'd be better to pick up later With you guys Because it's might not be Fitting the mainstream of what you're going through today. Yeah, thanks anyway. It's kind of it's kind of similar. It's not a similar line but yeah, I think Once you're looking at the kind of application I think you're talking about without seeing it I'd find it hard to know but the We're trying to simplify Kubernetes for web application developers and if you've already got a DevOps process Like certainly I'd like to have a look and and see we can sort of tell quite quickly whether it's we're gonna be Offline, I don't want to divert you from the main That's right So yeah, essentially we provide a similar function There's a number of tools out there that can do something similar the where we've Targeted is the market that needs a bit of help sort of to cross that divide And we can also capable of running and managing the goon works on multiple Clusters, we've got dozens of them from an amazing. I point of view so we can sort of split and segregate workloads So in a Kubernetes stack Basically, we've got the underlying providers. So we've got AWS Google Cloud is your in New Zealand. We've also got Catalyst Cloud. We've got a partnership Onshore in New Zealand with Catalyst We can also deal with on-premise Kubernetes clusters So the Kubernetes sits on top of that infrastructure and we're using the managed Kubernetes services from all of them. So the infrastructure provisioning comes as part of the the AWS Google Cloud, so we're not having to install or an Operating systems. We're not having to maintain Patch levels and stuff like that that all comes out of the box. So Kubernetes is there Lagoon sits on top of that Kubernetes and then running on Lagoon. You've got these sort of languages So PHP node Python And we've got the applications that they're still on top of there. So Drupal, WordPress Laravel, Silver Stripe, etc. all sit on top of those applications Also on top of those languages So yeah, strongly focused on web applications such as CMSs because those CMSs are a little bit more confusing But we would have a look at containerized applications. And yeah, as I said, we can sort of quite quickly judge whether It's going to be a good fit for Lagoon or not Depending on how much control basically the application wants and needs over the infrastructure So the only requirement essentially is Kubernetes to run Lagoon So yeah, we've got it tested and running on all of those clusters around the world. We've built a large collection of templates for Drupal WordPress Laravel and Silver Stripe on Silver Stripe particularly Tom Is going to give a talk on Silver Stripe on Lagoon on Friday I think and that's the process we went through to convert a Silver Stripe install to work on Lagoon because essentially Silver Stripe is PHP engine X And my SQL So it fits that mold quite nicely One of the extra values in here is that Lagoon manages the database Vacation and that logging that we spoke about from a database point of view um the major cloud providers all provide managed databases, so Whether it's Aurora or RDS whether it's cloud SQL Whatever the is your version is called We've built tools that can interface with those managed databases at services So if your project requires my SQL requires postgres We can run that in a docker container On your local machine But Lagoon will take that And instead of running a postgres container In production Lagoon will convert that to being a table in a database as a service offering so you get the large scale scalability you get the performance and It makes it a lot more manageable For for from our point of view because database scaling is one of the hardest things to do um in kubernetes, so we've basically put a layer in there that will help Be able to run those at scale for you caching again. We can interface with Elasti cache or whatever the version for Google and azure are we can provision Tables and entries inside there so we can run Redis caches logs so The lagoon installs run by mazio all have Open distro for elastic search running and kibana And we can ship logs to there, but we've also got plugins to be able to ship logs to Anywhere else so data dogs sumo logic Splunk we've built a logging system that can put the logs that you want where you need them to be And yeah, as I covered in the slide before we provide those base images We would strongly encourage people to use them if they're running a A application on lagoon because they've got a lot of the configuration built in there already and the sensible defaults but there's a lot of people that use our base images outside of lagoon because We've got a rigorous process behind releasing them. We've got a lot of experience in in making them and in running these kind of applications So lagoon has been around for a surprisingly long time Lagoon zero was launched in december 2016 because Someone needed to run a node application in an open shift About eight nine months later the lagoon 0.5 Was released and that's where it was released publicly. That's when the decision was made To make lagoon an open source project A lot of work went in between august 27 2019 um and over in australia the australian government Federal government and the government victoria made a lot of investment into lagoon um Lagoon one included a full rback support. So um role-based access control so Users and customers can really easily control what permissions their users have what their users are available to do um in the In the application itself so you can give finally granular find granular permissions to people um Last year april 2020 kubernetes support came you'll see initially that um lagoon worked on open shift open shift is red hats implementation of kubernetes um We went with native kubernetes support Just over a year ago and that was a lot of our customers were looking for that real managed kubernetes options So being able to run on um as your kubernetes service or elastic kubernetes or google kubernetes engine having the the abstraction of um open shift in there for some of our customers who had existing kubernetes installs or existing relationships it was really important to them and we've taken that one step further and There's little till the may 2021 lagoon two Lagoon two has basically been re-architected to run natively on kubernetes. So lagoon itself runs in kubernetes um Which means that people who are wanting to build and deploy their own lagoon and we now have a number of customers We're working with who are deploying their own lagoons managing themselves um Has really facilitated that and it's a lot easier and simpler to deploy a lagoon on kubernetes now than it was before um token architecture slide um because I wouldn't feel I was being um authentic if I didn't have a at least some confusing looking slide with arrows and pictures over the place, but basically As we've said the developer pushes code to git Git tells lagoon about This code push lagoon tells A kubernetes cluster that there's something to do that we've got to do a build So lagoon goes ahead checks out that git repo looks through it works out what services it needs pulls those images builds those images Um looks at what deployments what services what storage what databases it needs configures the logging sets up backup sets up security um, if you've got additional jobs or tasks to run lagoon will do that in this stage um We'll watch the build going through once the build is ready. Um the cluster Will tell lagoon that yep That builds ready. It's good to go and the developer gets a slack message or an email or a Microsoft teams or a notification that says hey your site's deployed you're good to go. Um It's a lot more complex than that obviously, but that gives an idea of You basically as a developer you push the code and the goon does the rest When it comes back to you the notification comes back and says hey your site's been deployed Hopefully your site's been deployed successfully if it hasn't The goon will provide you with logs that should provide an understanding of what's gone wrong. Um, and 90% of the times the problem is with the application itself. Um that A drush config import hasn't worked or some WordPress startup process hasn't worked but because it's git You can check out that code and you can deploy it yourself locally and you can try and replicate the problem And most of the time it does. Um, those problems are replicatable if not Slack support, um, it's there to try and help people over this Um, one of our strongest things that that we think lagoon is really good for his portfolio management. So um, although lagoon was built to Run a single site. It's capable of managing multiple sites. So from some of our customers have one site Some of our customers have hundreds we think, um One of the things that's really That we really like about lagoon and we've Worked on with our users Is trying to get easy to understand intelligence about your site. So what's your site's doing? How are they looking? How are they running if you're running multiple Drupal sites? um What version of Drupal are they running if you're running Drupal, Laravel WordPress sites? Can you easily tell which one's which? Um, and what kind of information can we collect about those? so um, can we collect The version information obviously How can we use that and part of the work we're doing at the moment is around making it easier to surface that kind of information? If there's a vulnerability announced in a certain module or a certain package, how do we find out about that? One of the things that lagoon does is integrate with image scanning tool. So, um trivy for example, um is a Docker image scanner and that can scan a docker image and it can pull out all the Components in there and it can identify which ones have security vulnerabilities And that information comes straight out of trivy and going to the goon. So a lagoon user will be able to see Hey, there's a critical vulnerability with this package. I wonder where that's come from How do I fix that and they can they don't understand? That that's something that needs to be remedied If there's a Drupal vulnerability being able to alert someone that the version of Drupal they're running is compromised Having a task system is another thing we're working on. So having this really extensible task system So when you're doing routine tasks and it could be clearing your caches or it could be Doing a database dump or it could be synchronizing a database between a production and a development environment or the other way around Having a task system that can do that kind of work for you without you having to manually SSH into a remote server and dump a database to your local and then push it back up to the remote and hope everything works We built this kind of functionality into lagoon so you can do that kind of work in lagoon itself um So we'd spoke about facts there's the ability to add metadata to projects So if you've got a way of classifying projects or a way you need to record additional information about them We can do that. We can collect those problems and vulnerabilities from a number of sources um And it works across frameworks. So it's not just php and Drupal. It could be Python and Django. It could be node and express. It could be Gatsby. It could be ghost It could be silver stripe. It could be any one of a number of things We're trying to build a tool that can really deploy anything um Continuous development is something that we're really proud of in our team. It's we do a lot of work with our customers building features our customers want um A lot of people in our team are former customers So we've also got a fairly strong insight into what we wanted and how we used The tool and the product. Um, but yeah, we do a lot of work with our existing customers to Take feedback on features to seek and solicit UX research and a number of our customers because it's an open source project have identified um opportunities to add additional functionality add additional features um someone the other day picked up that the Created data on ssh key is Incorrect in our ui found out where it is and submitted as a pull request to fix The ssh key display date in our ui and that's brilliant. That's the kind of relationship that we want with our customers um In the wild. So I think I've already said that lagoon Powers all of the amazio websites from amazio. That's over 2000 production environments 5 000 development environments There's about two and a half thousand developers developing sites built on lagoon on amazio we're doing Almost a thousand deployments a day. It's probably slightly more than that at the moment, but These are um across our 40 something clusters all over the globe. So there's a there's a fair amount of use of this tool Um in the wild and yeah, as I said, there's two or three other customers who Are running their own websites and their own hosting platforms using lagoon separate to amazio and they're part of our community and they've helped contribute towards the product as well We're strongly open source. So yeah, we use a number of other um cloud native tools under the hood. So Yeah, helm flue and dig refiner open policy agent k8 up It's almost exclusively it is exclusively open source tools that make up a lagoon install We do as I said integrate with a few other non open source. So when we're talking about Splunk or datadog for logging um But the primary concept of lagoon is that it's all open source. So we've made a commitment to donate um Lagoon to the cloud native compute foundation as a sandbox product. So We've got a dedicated product lead and team building and developing lagoon Um amazio is going to help do the marketing and yeah, we're working with non amazio organizations on making it a bigger broader open source thing So briefly um up ahead. We're going to do more on the sandbox process. We're going to um Because lagoon was released four years ago. It makes it a little harder to Untwine from amazio. There's still a lot of amazio defaults in it, but that's a process we're going through. So um Lagoon will be standing up as a as a standalone product With its own website socials, etc Um, but amazio is still The strong number one supporter of lagoon and will be continuing to provide the bulk of the developer Work for the foreseeable future. Um, so that we can yeah go through that sandbox process Um, we're always looking at expanding the applications So whilst a lot of our examples have been talking about Drupal and wordpress and laravel We are looking to push into other applications We've got some work on ccan the data management system We've got a bit more work in the python space that some customers are looking for us to do So to build out that set of templates so that people can build and deploy their applications using our sensible defaults more simply um Never any security push as we provide Lagoon to a lot of government customers, particularly um in australia and around the world There's a never-ending sort of circle of compliance and audit So we're looking strongly at sort of rootless policies how to apply network policies um more and more work in application image scanning Um to try and ensure the continual compliance of workloads running in lagoon and uncubinities um that work in uh mass application management that's recovered so more work on facts more work on intelligence more work on automation and Our team will keep managing and maintaining lagoon. We've got grand ideas about where we want to go and what we want to do with this um we do so for people that um I'll put the links up to the github organization But there's a couple of github orgs there and we do operate sort of discussions and we do have um a lot of engagement with customers Through those channels to find out what they're doing or whether they can help us Whether we can help them and whether we're going in that right direction Um, so yeah website lagoon.sh our twitter handle is use lagoon. We've got some docs there um, we currently split across those two github organizations. Um The I mean the lagoon project itself is currently in amazing io But we'll be in use lagoon in the next um week or so so it's very much a work in progress moving that across um Thank you very much for listening