 I am Michael Richardson. I'm the co-founder and manager director of a small company called Einstein. We are an enterprise focused Drupal pass product. We've been in operation for four years now and our mission is to win our partners larger projects by enabling enterprise Drupal. So my own background in hosting has gone, I stopped counting at 20 years. It's slightly longer than 20 years, but I feel like 20 years is enough time to count. But in that time I've worked, oh please, okay. I have worked with very large brands on very large sites. I have hosted sites like Bunnings.com.au, KFC.com.au, Meyers, e-commerce site, Australia.com. And these were very, very large sites that were multimillion dollar investments by these brands that were built primarily on Sitecore and AEM. And everything that these brands wanted out of the hosting side of things, aside from not being terribly interested in the hosting side of things, was about having a host who owns the problem, who is responsible for very high levels of availability, very high levels of security, because for these brands, for a site like Bunnings.com.au, which at one point was 100 developers working on this site full time, an hour of downtime is measured in six figures. It's a very major thing. And in 2016, when I started working with Drupal, one of the very, one of the things that I noticed very quickly was that there aren't sites like this on Drupal. And I don't think that's because Drupal can't do sites like, I'll just skip forward here, Australia.com. Australia.com is a brochure site. It's built in AEM. I can't tell you what they spend building it because I legitimately don't know, but I can tell you that for a site like this and the infrastructure they had at the time, the Adobe Experience Manager site, which is sorry, Adobe Experience Manager license, and this is an AEM site, would have been in the six figures just for the license to operate the CMS. This is a site that could have and should have been in Drupal. And I think there are, we could and should talk for a long time about why sites like this are going to proprietary solutions. But I think a part of it is that at least in 2016, there weren't providers who could match the sort of requirements that these companies when they work on these really high end sites are looking for. If you spend millions of dollars on a website, you don't expect to spend $1,000 a year on hosting. You expect to spend a lot more and you want someone who, when you have a problem and you call them and say, my server's not working properly, my site's not working properly. You don't want the hosting provider to go, well, our network's fine. Everything seems okay. And I know from the response that we've all had that conversation with a hosting provider of my site's not working properly and they go, well, servers up. Good luck. That's not something that these brands expect. That's not something that these brands have. But when a site like Australia.com goes to tender in 2014, and they have their set of requirements that Drupal very easily could have satisfied. There isn't a host that can deal with this stuff. There might be one, but not everything on this list that hosting provider can offer. But for Sitecore and AM and Kenta code, there are half a dozen to a dozen hosts that can satisfy that. And what I set out to do in early 2017 was to build a company that would fill that gap that could provide a hosting solution for Drupal that was able to offer four nines of availability that was able to offer built in disaster recovery that was able to provide this ability to, as I mentioned before, to own the problem to receive that call from a client or even better to call the client and say your site's not working properly. We know about it. We're looking at it. And we're going to work with your development partner to fix it. And we don't care if it's the server. We don't care if it's the network. We don't care if it's the application. We care that the site's not working properly. And that's, you know, we're all on the same team. We're all trying to work to fix that. And I just didn't traditionally exist with Drupal and I felt like it should. We felt like it should. So that's, that's the mission of Einstein build a better Drupal enterprise hosting solution and help our partners have the ability to pitch for things like Australia.com and other really large sites that Drupal can do. And the world needs to see the Drupal can do that. And longer term, to be able to make Drupal more competitive in that digital experience platform space. There are things that AM can do and Cycle can do and these other proprietary solutions can do that Drupal can't do. But Acquia can because Acquia is invested in those capabilities. And we want us to be able to help Drupal bring out capabilities like personalization and campaign management and digital asset management and analytics. And I want those to be part of Drupal because I want, I don't want to work in an industry where the only option that government education and large corporations have is proprietary. I want to talk to you a little bit tonight about the stuff that Einstein does. This isn't an idea. This is a business that's in operation. We have coins now that we are that are running high end production sites that host medical data that has government data that has corporate data. They all have an expectation of very high levels of availability. They all have an expectation of very, very high levels of support. And that exists now and we're delivering on that now. So the stuff that I'm going to show you tonight is already in and it's been in for a long time. And we've just sort of now at this point after four years of building the platform where we've gone right this is the core products finished. And now we're ready to go out and start looking at that next phase of the story in terms of digital experience and bringing this to other markets going outside of Australia and growing the capability of growing a client base. So we do deployments on Einstein. I think we've all had deployments that haven't gone well. Raise your hand if you've had, if you've never had a deployment that failed. Good. That feeds into my narrative. That's lovely. Thank you. Thank you very much. Most hosts will give you a git repo that is a remote you push to. They from there, they might do a build system, they might not build, they might just straight deploy, but it's their git repo. And if there's a build system involved in each time you want to do deploy, if you want to repeat a deploy, you're not necessarily guaranteed to get the exact same result. When you do it, there might be a problem with packages to some other upstream system that stops the build from happening. They probably configured version constraint that if you're trying to repeat this build two weeks later, you might not exactly get the exact same version of a module that you did the first time around. So when we do a deployment, the process starts with us getting a table or package we call it of the site that is guaranteed to always be the same and it's repeatable. And you can deploy it to any environment and if the deployment goes wrong, you can roll back to that package, and you'll be guaranteed to have the exact same result. You'll be guaranteed not to be beholden to an upstream dependency or a build system that's not working at that exact moment because the build process has happened. As you can see here, each of these packages has metadata or attached them, you can see which branch they came from, which tag they came from, which git shot they related to. You can see which environment they're running in. And for each of these, if I was to click into them, you'd be able to see which environments they've gone to previously so you can see 1004 there had previously been to prod or they've gone to stage and then gone to prod, you can see a bit of the history there. But that idea is that you can completely redeploy that those names those funny names. It's probably the best thing that we've ever built four years of constant research and development and the coolest thing we've built is this system that randomly generates names like really pretty dinosaur. I love it. I wish I could sell it, but that's not a product. But you can you can go into any of these and you can redeploy it. You can roll back. And when you do it you can see in this dashboard here. I wanted to go with screenshots. I know it's a little bit less exciting but I wanted to go with screenshots because they're reliable. But in this dashboard you can see this is a real time dashboard that shows you the instances that are running in your environment in this example we've got a pod environment with two application replicas they're hosting PHP and engine X. There's a chron instance that's doing scheduled tasks. There's an SSH instance. And down the bottom there you can see system pods that are doing cache medication you relic. The system pod there does things like any virus and prevention of permissions entropy and a whole bunch of other sort of internal scripts. And when you do a deployment you'll see these get replaced as the deployment goes through the process so a new app replica will come online and when it's online, the older app replica will be destroyed, and then another one will replace it. And all of this is leading to this idea that we have deployments that are guaranteed to be repeatable. You can rapidly roll back in the case of failure. We have a feature called. She's just called pre deployment backups we have a feature that will in an environment when you request the deployment, it will take a backup of the database wait for that to succeed. And then go ahead with the deployment so something goes wrong with the deployment. You have that backup right before the deployment was and out of 10s of 1000s of deployments that we've done now only one customer has ever needed that longs, and I was really glad that that was there. But that's the, you know, this, this whole idea of building a hosting company that is about avoiding downtime but accepting the fact that if downtime happens we need to be able to recover from it quickly. These techniques are there to enable that mission. In terms of data integrity. I will talk a little bit in a bit about availability and performance and disaster recovery. Anything that happens in that space we can recover from if a server files if a data center explodes. We can recover from any of those events, but if data is lost or stolen or manipulated in a live environment that is an unrecoverable event. Once that genius out of the bottle, we're screwed. So we have invested tremendously in working on data integrity of the platform. The environment has its data and it's file system sorry it's database and it's file system distributed across at least two data centers. And if you were to write something to disk, once you've got confirmation that it's available on disk, it is in at least two data centers at that point in time. So for data center just disappears in the middle of the day. At most you're losing a few seconds of data from the database but you're not losing anything from the file system. Backups out of band to make sure that if you want to go into a backup at any point in time, you're not going to be draining CPU from your web servers in order to do that. And backups when they take place they're stored off site in three data centers and they're out of band. No one who has access to your site on our platform. That is your your account with us can delete scheduled backups. No one can go in and modify that backup store it's not a folder in your server it's entirely detached from it. So you can always have that confidence that right okay something's gone horribly wrong somebody's broken in and they've deleted all my data. They can't have deleted your backups. You will have that data available to you. There's a self service backup and restore and sync capability I'll show you a couple of screenshots that in a second, and you can download any of those backups at any time using our seal. There's very strong encryption in transit and at rest we're currently going through a process of being certified to host classified government data. And in doing that we're complying with the Australian cyber security centers information security manual, which I wondered after the beer if I'd be able to do so. The SM as it's more easily referred to is 813 controls that the federal government has established that you have to maintain whether you're a private enterprise or a government agency that you have to adhere to if you want to host classified data at official protected secret or top secret level. There is currently to the best of my knowledge only two hosts in the country who can comply with these requirements at the protected level. And we are one of them and we're now going through that process of being credited for that. So there is understandably very strong encryption in transit and at rest we actually have policies in place that prevent us from, for example, mounting a file system without that encryption in place. There are, you can have custom backup and retention schedules we have one customer who backs up their production database every 15 minutes. We keep that back up for hours. And we did that once, and we were all very glad that it was there. One of the worst situations is you sort of like three o'clock in the afternoon you realize that something horrible has happened and you've got to restore to a backup. When's your backup. Well it's from last night, which is perfectly normal everyone does that you always have nightly backups, but really when you think about a site at a high scale that's servicing thousands of customers a day. 12 hours 24 hours 18 hours of lost data is. It's, it's not ideal and we have an outbound firewall that really severely restricts the ability for data to leak. If someone is able to break into your server, install a barter script that's sitting there and trying to phone home to some server somewhere else and siphon your data out. You can have a firewall in place that will prevent that. And as far as I know, we're the only pass provider for Drupal that can do that. But really quickly, this is the backup window. This is granular. You can back up public files private files individual databases or all databases. You can restore them. Excuse me. You can restore them at any time. And again, you can restore components of it, and you can sync data between environments. This is not very easy to see if you're not right in front of the monitor like I am. One of the key parts of this is that you can choose the restore strategy for a backup. So for example, if you find out two weeks down the track that a directory in your file system has been deleted and you need to restore it. In some platforms that restore is going to override everything that's changed since in the last two weeks. This platform will give you the ability to say, right, I want to. For stuff that's in the target environment, but not in the backup. I want you to do this for stuff that's in the backup but not in the target environment. So there's a lot of power in there and it's really been built on that idea of these are very expensive sites that have really serious requirements. In terms of availability performance and disaster. I've lumped these all together because they're all combined in this idea of this distributed architecture that we built. There are some app replicas in this example that are the two web servers. They are in different data centers. You can't see the databases represented here because they're kind of outside of the system a little bit, but the database service is an active and a passive and they're in different data centers, and it's not a capability that you have to opt into as a client as a client you don't have to call us and say, can you please make sure that I have two copies of everything because that seems like a good idea. The system's built on the assumption that okay if it's a good idea we're going to do it from the ground up. As I mentioned earlier, there's four nines availability for the platform. We have been operating for four years now, and we know that that's a guarantee that we can commit to and it's financially backed. We haven't had to pay credit for it yet. I'm not saying that that can never change. It's certainly can technology does fail. But the whole idea again is that I feel like I'm a repeating record here, but in the event of a disaster, a data center just explodes suddenly. There's very little downtime if any there's very little data loss if any in the event of an individual component failure like an app instance going offline, there is replacement hardware ready to launch it at a moment's notice. It's very rare for us to have downtime from maintenance. The last time we had downtime for maintenance was 18 months ago. We do patching every two weeks, but because it's distributed we can take down half of it, patch it, update it and then bring it back online and do the other half. And it's very easy to have rapid or automated scaling. Security. I already talked about the AC SC ISM. And that has informed a lot of what we do about security it's informed a lot about we do about security from a workstation perspective as well product didn't need a lot when we started going through this ISM piece. But I wanted to highlight a couple of things that, again, to the best of my knowledge, we are the first in the world to be doing this stuff. It all has perspective. If you have like a triple managed service that's specifically built for your application, you can have this stuff because it's being built bespoke, but this stuff all comes out of the box without platform. You have dedicated logins for SSH access. A lot of platforms if you SSH in your, your username will be like admin web everyone's using the same username but they're using their own keys. It's very hard to identify who did what in the platform because we're all sharing a user. And the one thing that we're all taught when we start getting into it is don't share your login with anyone. You can have a separate inbound and outbound firewall for SSH and HTTPS. We have two factor authentication for SSH so we try and SSH in, authenticate with your private key and then you need to provide an MFA token. We support custom authentication token and expiry timeouts for our API keys. So if, for example, you're a government department and you want to say, if somebody doesn't use their account for two weeks, I want you to disable it. Because maybe they've gone on leave and they forgot to tell you, or for whatever reason, if they're not logging in frequently, there's something unusual going on there. So to disable their account for them, our customers can modify those times for themselves. The same thing for things like idle timeouts. One thing that's painful but fun is this idea for us, and this is an ISM thing, privileged and unprivileged users. An unprivileged user is a regular user inside your corporate network. A privileged user is an account that has the ability to bypass security controls. So it's an account that, for example, can turn off logging or it's an account that can modify a firewall. We have a system in place where if a privileged login is used, there's an internal alerting system that we haven't documented that will notify everyone in the team and a privileged account is being used. And that helps us capture if a token for a privileged account is stolen, or if an individual goes rogue and is acting against the company's interests. So I thought that was really cool that that even exists, but that's a thing. So screenshot there of the security controls that one did not come out well at all. I'm going to move past, but you can just sort of see the level of granularity that we're giving in terms of security because that's really what it's all about. Monitoring and support really quickly. I got a couple of screenshots in here of the monthly reporting dashboard that we've built. For each environment we collect over 300 metrics in terms of what's happening. We actually collect more. Oh, right. Yes. Different value for me. Yeah. Yeah. It would be somewhere close to a thousand. That felt more right. Yeah. Yeah. I was only counting metrics that have a specific label. Okay. All right. So we collect a lot of data for each environment and some of the stuff that we collect we we don't alert on everything obviously but some of the stuff we collect we alert on. And the stuff that we alert on that I think comes back down to that whole idea of owning the problem that I that isn't common is we will alert ourselves if an application starts throwing an unusual number of errors that is HPP errors. And we will get a page for that 24 seven. And if a production deployment fails, we will get an alert for that 24 seven. And that just comes down to that idea for our clients and our development partners if they're pushing something out and it doesn't work. We don't want them to have to go through the written role of right well I'm going to call a host and let them know and ask them to help me. If the site's not working we care whether or not we're at fault or whether or not it's something that we can fix. We want to get an abridged mode work through that because downtime can't happen. So just another screenshot there. So some samples of the stuff that we were that we monitor and alert on. And in terms of what we're doing next. Now that we've kind of built that platform. I don't know if anyone here, aside from the obvious people that I know have heard me talk about Takaido before ever heard of that. Okay, so Takaido is an open source platform that we built that's a local environment manager. It's not a land or a DJ but it's aimed to be significantly easier to use in the sense that you can hand it to a junior you can hand it to a site builder and say right you need a local environment run this one command and off it goes. You don't have to learn the tool. It's kind of unobstructive. So we're going to keep working on that we want to start working on the digital experience side of things for Drupal in an open source way doing analytics personalization digital asset management that sort of stuff. That's it. I know I told you this would be a 10 minute talk and obviously wasn't. But yeah that's us where where I'm star. Like I mentioned we, we are not new we are self funded our clients fund us by paying their bills. And we use that to make sure that we're building a platform that's exactly what those clients want. So, and if you want to find me, I'm on Twitter as a Taku Mike or triple slack as Richard. Thank you. Thank you everyone online. And if anyone has any questions like gladly answer them otherwise thanks very much for