 This is Drupal Sass, building software as a service on Drupal, Drupal North 2019. So, just to introduce myself, I'm an enterprise cloud architect. That is, I do Drupal, IGR, Sasspass, SAP, IAS consulting, all that kind of stuff. I won't explain what those are, because that'll take half an hour. Use Wikipedia, it's great. So, I've been on drupal.org for 13 years as Colin, CLA-N. I'm maintaining over 40 modules, not all of them actively, because I know that could be a question. I worked on the first release of buyandsell.gc.ca, which is the Government of Canada procurement portal. So a lot of your companies probably tried to... Oh, okay. Looks okay now. Thanks for that. Yeah, so that site, I don't know if you... Anyway, yeah, so I'm not sure why it's flickering, just trying to pretend it's not, I guess. So, on that site, it's a procurement portal for Government of Canada. So a lot of your companies probably tried to get government contracts through that. That was, I think, the first big Drupal implementation in the federal government, so I worked on that. I'm a Google Summer of Code mentor, have been for various data encryption projects in Drupal. So it's a bunch of client-side encryption and server-side encryption projects that I mentored students for. Just kind of need... I'm a core maintainer of the Agra hosting system, which you can't see right now, but the screen keeps flickering. If anybody knows any of the media people, feel free to grab them or ping them or something, because I don't know what's going on here. I believe everything's plugged in, so I'll just ignore that. All right, so I'm the founding partner of Consensus Enterprises, which is my new firm I have with some other folks. We do a bunch of different things, generically helping you do big things in the cloud. Davos processes, documentation, self-hosted multi-site solutions, audits, site audits, application lifecycle management, continuous integration and delivery, cloud infrastructure, architecture, and software-to-service engineering. That's pretty much what we do. Some ground rules for this talk, in and around me at any time. It's kind of an open source thing. Jump in, add your feedback, ask questions, all that kind of stuff. You can actually follow along on the website if you want. I'm assuming that site works. That's where this is. So I'm actually using, accessing that now. It's actually Hugo's, the static site generator we use for this. So it's up there. And so a lot of the slides, you're going to see some of these things I'm talking about. They're actually links. They're orange. For those of you that aren't colorblind, feel free to, if you want to go there, you can click on things if you want to go off and check out certain links that I'm talking about. Feel free to do that. I've got a Creative Commons license, so you can reuse some of this stuff if you want. All right. So how many of you are considering building a SaaS product? Anybody here? One, two, couple? Currently working on a SaaS product? So that's a good number. That's four, five. Great. And anybody already selling one? Does anyone have one in production? Not yet, because they already know what they're doing. They don't need to come here? Oh, you do not? Okay. Great. All right. Did anyone realize you're supposed to be somewhere else? You're in the wrong room? No. Okay, great. Excellent. Yeah, so anybody, are there any other interesting SaaS, like wire, please? Yeah. So, Drupal Distributions, there's regularly multiple websites from a single code base. Yep. And how we use it would be a good distribution, get a delta and buy a stock. Right. Kind of expanded business. Right. So Drupal Multicites, basically how you can run a bunch of sites together. Great. Perfect. Any other? Yeah, shoot. Okay. And we run a lot of websites. Staff time? Yeah. Okay. Great. So I'm just looking at angles that we could do that kind of internally. Yeah. Or maybe to other departments. Yeah, actually, we're doing some work for other departments, so let's talk after. You want to help? Sure. I can talk about what we're doing. Yeah. Great. Cool. So, excellent. Like the business aspects of a product, it's a bit different than a project. So normally with, you know, website project, but at work you get paid. You do another one when you get paid. If you're building a product, there's a lot, it takes a lot more time to build something like that with a subscription model. So it's different than development contracts, as you can imagine. You don't, you don't really get paid up front. Like you have to do a whole bunch of work before money can start coming in. There's a, you know, a lot of unpaid work to get your platform built. So you certainly need to have a plan for keeping the lights on, getting paid, that kind of thing. So what we're doing, like we've actually, we're actually, you know, working on some SaaS products as well as doing consulting. And we're trying to bootstrap it like fund it from our consulting work. Now that obviously is not as fast as finding a venture capitalist or, you know, having a rich uncle or, you know, that kind of thing, investors. So these are just things, you know, you have to think about when you're, when you're working on the business aspect. Obviously you're not all here for that, but that's something to keep in mind for that use case, right? So like I said, lots of development. You may not get regular income for this type of thing. Yeah. So it's, you know, money should come in if, if you can sell it, right? I mean, that's what it's all about, right? So great. So let's talk a little bit about hosting. Now, so there are a bunch of Drupal hosting companies which have some pros, right? So you can outsource your infrastructure. You don't have to worry about any of that. Simplify site maintenance. That's often done for you. I know some of them you need to click a button. You get the latest, you know, version of Drupal core. That's great. There's some cons though. So vendor lock in, like you're generally stuck with a particular vendor. It might not always be easy to export and import somewhere else, especially if you've written, you know, infrastructure as code, that kind of thing. That's not portable. You don't have control over hosting costs. So if you get locked in somewhere and their prices start skyrocketing, what do you do, right? So that doesn't even think about a data center location. So this is an issue in Canada because of privacy laws for Americans. It's not, I guess, too big of a deal. But here, so you don't have, I mean, yeah, you might not have control over data centers, right? So if you go with one of the Drupal hosting companies, usually you don't get to choose what country that's in, right? So I know with, in Canada, there are going to be times when you want to, your customer data needs to be not necessarily in Canada, but, you know, your users need to consent to whatever you do with that data. And that won't work in the States generally because other government can get access to any data at any time. And you don't even know that that's happening and users can't consent to it. And so you might want to think about, you know, having, where you want to put your data centers. So configuration as code. So this is using tools like, you know, Ansible, Chef, Puppet, Salt, these kind of things where, you know, you use your code as infrastructure to spin up the ends, that kind of thing. If that's written for particular vendor, then, you know, you might get locked into that. Not great. So in a lot of these companies, they don't support multi-site. And that's actually very explicit with most of them. And I'm not sure why it is, but that's the way it is. And so like we started talking about it, you might want to run multi-site and have a whole bunch of sites using the same code base. A lot of the vendors don't support that, or at least the jubilose companies. So, and also cost is another thing to think about. So cost per site, a lot of these companies will charge you, say, 60 month per site. So if you've got 200 and the same code base, you're paying for 200 sites, where as opposed, you know, you would want it to scale the more sites you have, the cheaper it gets, but it doesn't work that way with these folks, unfortunately. So infrastructure. So there's proprietary infrastructure of the service. And by that I mean things like Amazon Web Services, Google Cloud Services, Microsoft Azure. These are things that are very popular now. But again, it's proprietary, it's not open source. So OpenStack is sort of the IIS implementation that won some other options were Ganity, which is a Google thing, and CloudStack. But OpenStack seems to have sort of taken over now, because I think RACS basically put a lot of effort into that. So yeah, no vendor lock-in, it's open source. You can, you know, take it and you can install it on your own instance if you want to say, you know, you're in the government, you're in a big company, you don't want to go externally. OpenStack is, that's a big one now, like I was saying. So there are a lot of different hosted companies running OpenStack. So, you know, where you normally, you know, you can go to AWS or GCS. There are companies that are running OpenStack and you just, like any other hosted company, you just pay them and it's running on OpenStack and you just do what you have to do, spin up the ads, that kind of thing. A lot of them, so I've worked with several OpenStack hosting companies and they often don't have data in and out charges. So like with AWS, I don't know how many of you know, but they'll often, you pay a lot of money getting your data, uploading your data, getting it out, that kind of thing and that can be very expensive. So with a bunch of these companies, the ones I've worked with at least, they only charge you for storage, which is great. So you can save a lot of money. Like if you, people uploading things, downloading things, that sort of thing. Your configuration as code, again, that would be, you know, like Ansible code, that kind of thing. So that, there's a standard API for OpenStack. So if you want to switch vendors, it doesn't matter. You can reuse that on any other OpenStack vendor. If they jack up the price, you move somewhere else. As opposed to say, you can't switch from AWS to Azure very easily if all your code is written for those APIs, so something to watch out for. Data centers in various countries. So there's actually, if you go to the OpenStack, I don't have the URL in front of me, but if you search for OpenStack Marketplace on the website, they actually, you can search by country by service for OpenStack providers. So now, different services, databases, service, VMs, whatever, that kind of thing. Yeah, data portability. So like I said, switching between vendors, your I infrastructure as code, sorry, I see. You can move that between vendors easily. You can also do the same with your data, not just your code. So you can export your VMs from some company and then import them into another company that's running OpenStack, which is great. More control over hosting costs, right? So again, you have various companies to choose from. But now, let's talk hosting system, right? The platform as a service, I guess. Do you need to write one from scratch? And you don't. So we've got some software that does that. There's something called AGR, which you may or may not have heard of. Has anyone heard of AGR and know about it? I see a lot of hands. You may or may not have heard of it. One, two, okay. So it was originally written to host and manage provisioned Drupal sites. So I think the 11th anniversary just went by, it's been around a long time. So it's open source. It's, yeah, like I said, 10 plus years, right? So it's got a web services API. So it can do a lot of things. Soon it'll be able to host anything. So AGR 3 is stable right now. So AGR 5, which is currently in development, which some of us are working on, that the idea there is to replace the provisioner. So historically it's been Drush, which works great for Drupal, but for everything else. So we're actually replacing Drush with Ansible. So it should be able to provision anything. So any kind of thing you want to host, you should be able to do with AGR 5, which is great. I don't want to talk too much about that, but that's where it's going, a bit to know. And all right. I did this already. Anybody using AGR? No, just me? I know you were. At various times. Cool. So that's the hosting system. So what that is, is that gives you sort of the back end hosting infrastructure, right? So you would sort of, you know, tell that, okay, I need a new site, it would spin one up. I want to take one down. I want to upgrade my sites. I want to run backups on a site. All that kind of stuff. So often you would want to integrate that with, say, e-commerce, you know, how do you get your clients to pay if that's a thing for you? You're recurring billing, right? You have subscriptions, how's that going to work? Right? So there's a module that I've been working on the last couple of years when I have time. It's called AGR site subscription. So that's a link. So it's a Drupal.org module. And so that adds e-commerce to the AGR ecosystem by associating hosted sites with customer subscriptions via recurring billing. It communicates with AGR API over web services. So let's say you had a Drupal 8 site. That was, you know, your customer-facing dashboard, your marketing site. Clients would, you know, customers would create an account there. They would pick the plan they wanted. They would, you know, enter the credit card number, all that stuff. You know, they'd hit go and then, you know, you'd send a message to your AGR back in to say, yeah, spin up the sites for these folks. Or if they stopped paying, their credit card fails eventually, then you can just delete it. Or if you don't want to be that mean, you can keep it around and then, sorry? Suspended. Yeah, that's probably safer. Depends on your policy, right? Something to think about, definitely. So, yeah, I talked a little bit about this. You like to plan, you know, provide your payment info, provision the site, you know, you can get deleted later or you can keep it. Send it to them if they finally do pay you. If not, don't, I guess. So, the way it works is sort of, it acts as a plug-in manager, right? So, it allows you to... Yeah, okay. So, it allows you to choose different subscription providers. So, the big one that it works with now, that was sort of the reference implementation that I got it working with was with Curly. I don't know who's heard of that or not, but it basically allows you to manage subscriptions online. So, whether you want to use PayPal or Stripe or anything like that to actually do the payment processing, Curly would sit between you and those to sort of handle the recurring billing, the dunning. Dunning is basically how to handle what happens when a customer's credit card fails, like do you send them emails, how many times do you try before giving up, that kind of thing, so that's a dunning process. Yeah, exactly. So, yeah, so, Curly's done. So, that's great. Pretty much, there's a prototype up and running. I love more people to try and test it, that kind of stuff. Commerce recurrence framework. So, commerce is basically, for those that don't know, it's sort of the big commerce framework in Drupal. So, they've got a plug-in called the commerce recurrence framework, which tries to do a lot of that subscriptions management stuff within Drupal, so that you don't need a third-party service. So, using, say, Recurly, you need to pay your payment processor. They take a cut, like Stripe or PayPal. Then Recurly takes a cut plus a fee, right? And then you do everything else in Drupal. If you can do the subscription stuff in Drupal, Drupal handles the dunning, subscriptions, all that kind of stuff, then, you know, you can cut down one service provider, which is great. That's not done yet, so I'd like to work on that, but I need funding. So, I'm not working on that, but it'd be great to get that done at some point. And there are many other options in terms of these providers, and, you know, we'd love to add support for that, eventually. Some things to think about. And so, this applies more generally, you know, outside of the business use case. It can be applicable for government is, you know, how do you want to handle installation profiles, which in Drupal is sort of the, you know, different, you know, preconfigured versions of Drupal. So, you can have, or, yeah, distributions, installation profiles, and kind of use those interchangeably. So, you can, you know, you can have sort of base, a base configuration that can apply across all your platforms, which is eager speak for a Drupal code base. So, you're going to have a standard code base. You can have different ones for different use cases. Now, within each one, or within multiple, there's the features module in Drupal, which lets you basically package configuration and reuse that in different places. So, you could have, say, instead of having, say, multiple installation profiles or distributions, you could have one with, like, a common kernel, and then use the features module to turn on different features within different use cases using the same installation profile. So, these are some things to think about. Resource quotas. So, one thing that you want to think about, whether you're in government or private sector or whatever, is, well, you don't want your customers to, you know, upload giga-clouds of data that, you know, blow through your infrastructure, right? So, resource quotas is a thing to worry about. I do have a module called, say, Quota Enforcer, which, right now, what that does is it's a framework to add different quotas to different things, but right now, it cuts off your... You can't add more users if you're at your limit. So, it's a user quota and it's a storage quota. So, you can set whatever you want that to be, and your clients, when they're using their sites, they won't be able to pass that. If they try to add new content, they'll get a nice error message saying, you're out of disk space, basically, contact your admin, get a bigger plan, that kind of thing. Admin access. So, in the SaaS context, things are a bit different from a normal, you know, you build a site, you hand it off to a client, they're the owner, that kind of thing. With SaaS, it works a little bit differently. You typically want, I guess, sort of the... Hosting companies say, if I've got a SaaS product, I'm selling it to you, I would be, you know, user one, the super user on the site, so I could do admin things, turn modules on, turn them off. But the site owner, which isn't a great term, but it kind of works, would be your customer that's subscribing to the site because you're providing it to her, right? So, you'd want that person not to have full access to the site, but some access. So, you have to think about things like, you know, restricting the permissions. You don't want your customers to go and turn on modules and turn them off, say, turn off your quota and force a module, and then they can do whatever they want, right? So, yeah, user one versus owner role. Yeah, user one can do everything in Drupal, so you would probably want your customers to be user two, and then they can delegate down from there, create their own users. Permission subset will take, you know, the big permissions page in Drupal and shrink that to whatever you want, and you can give that to your customers, and then they can delegate a subset of permissions, which I think is a much safer way to do it. So, the story with that is, it's there for Drupal 7, but there's no Drupal 8 part yet, so that's another thing that would need to get down for this type of thing. All right, customer service. So, you know, you obviously need to interact with your clients in some fashion outside of providing them with the service. So, you know, you want a public-facing issue tracker. GitLab has something called Service Desk. You know, everyone knows GitLab for like GitHub for hosting code. They have a Service Desk feature where it lets you turn, like, emails into tickets or issues. That's one option. There are various tools to do that. I won't go into that too much, because, you know, I'm just trying to touch on these issues. Things to think about, right? Yeah, if you're already using GitLab, this might not be a bad option. Most people are. So, I don't know if this is a bit of an aside, but when it was announced that Microsoft bought GitHub, GitLab.com actually went down because everyone was trying to move their stuff over. That's kind of a funny story. So, GitLab actually has more features than GitHub right now, so it's getting more popular. It's open source, you can run it yourself, or at least the community edition. So, that's why it's fairly popular. Is anyone else have thought about this today? What are some good things to do for customer service? Any thought about it yet, or not really? RT. RT? Yeah. Okay, so that's like a big, like that's a bit around a long time, a standard tool, right? It is open source. It's open source, email, ticket tracking. Open source, email, ticket tracking. Okay. So, just email. Right. It's something. Great. Okay, so RT is another option. Good to know. I think that's probably good. I have heard of that one. I forgot to mention it. So, that's sort of the, you know, a little bit of summary of all these things to think about when dealing with these kinds of issues in the Drupal ecosystem. So, yeah, I mean, I'd love to keep talking about this. We still have some time. So, yeah, any feedback, some questions, thoughts, comments, you know, let's talk about it, yeah. Can you clarify the kind of the goals of open stack versus state year? What part deploys its restructure as an open stack? Yeah, so that's a good question. So, what I should have had was an architecture, like technical architecture diagram. Maybe I'll do that next time. But your infrastructure as a service would be things like, you know, open stack, which, you know, you can either go with a company or you can run it yourself in your own data center on your own hardware. So, that's the infrastructure. That would be, you know, in the same class as, you know, it's open stack or AWS or Azure, digital ocean, any of these services, right. That's all infrastructure, whether it's virtual or not, right. And of course, you can just run it on hardware and not have the virtual aspect. So, then I guess the platform, so that kind of said at the bottom layer, right. Your infrastructure, then your sort of platform layer would be basically eager, right. Because that is not infrastructure, but it's not the actual application that the users are running into. But it's a platform that provides the software that it hosts the software, the service that you care about or that your clients care about. That would be installed on a server like Web Open. Right. So, you would say go and take eager and install that on a VM or digital ocean or, you know, AWS or whatever, right. So, that's your platform. So, you know, the platform sits on the infrastructure, you know, you install it, you can, you know, eager is pretty easy to install nowadays. You know, pseudo app to install eager three, for example. But, you know, it depends on the setup you have. That would just give you the default installation. So, you have a platform, you know, would be eager. And then that would host the sites that the clients interact with. So, that's the software. Can eager deploy sites on other virtual machines or deploy a container that's stable or something like that. Yeah. So, there's actually, so in eager three, which is stable now, there are a bunch of modules to do that. I think there's eager cloud. So, what they do, they can actually spin up VMs and other. What we're actually looking at with eager five, which isn't out yet, is that'll happen much more natively, right. So, you'll be able to click on, you know, I want to spin up, you know, this whole system with a load balancer and two web heads and database and that's running a Galera cluster and all this kind of stuff. So, that'll be much easier to spin up the next one. So, now we've got some modules that kind of do it, but it's not really core. So, yeah, but it can do that. Typically, the way you do eager now in eager three is you would create a server however you would normally do it manually or, you know, you'd go in digital ocean, click on all one, two VMs, one's a database. Then what you do is you tell eager where your servers are. That's how it works now. So, you would say, okay, I want to, you know, click on servers, add server. Okay, you know, here's the domain name, here's the SSHT, that kind of stuff, right. So, then once eager knows about it, it can provision sites onto, it can provision a platform onto that server and it'll provision sites onto that platform. And by platform, in this context, I mean like a Drupal code base. So, that's the term that you're using. So, it's basically a Drupal code base without the sites directory. So, that's an eager platform. So, when you install sites onto an eager platform, it's just creating a site directory and sticking it in the platform or in the code base, right. So, that's, yeah, does that answer your question? Yeah, yeah. Can I have a follow-up question? That's a big question as well. Like, in dependencies for Drupal, like PHP and... Yeah. So, like, if you just run, if you just run like sudo apt install eager three, it'll pull in PHP and by default, Apache and MySQL. But, you know, you can run MariaDB or you can run Nginx. I like Nginx. So, you can know Apache to default. Yeah. Can I talk a bit? I'm Dan. I'm also with consensus. I work with Colin and the other guys. Nice to see you. Hi. I'm new to this community. Hi, Dan. Can I also mention, do you want to mention where we're going with the eager policy or can I discuss this? Yeah, please. Do you want to come up? I don't know if they can hear you for the mic, but... Sure. So... Yeah. So, where are we going? Just to follow up on the answer to the question. Nice to see everybody. So, what we're working on is kind of the next step with this. So, remember, a really key thing to understand for those of you who don't know what eager is exactly without having an architecture diagram here is that it's just a Drupal application itself. It just happens to be one that knows how to manipulate other Drupal applications. So, what's nice about that is you get that sort of warm, comfy, I know, how to use this thing feeling if you're a Drupal person. Especially if you're familiar with Drush right now because that's kind of the basis for eager three. However, in the move towards eager five, what we're doing is we're swapping out all the Drush stuff with Ansible. And the nice thing about that is that Ansible is much more platform and technology agnostic in all directions. And also, it is so extensible given that it's Ansible. And so what we're working on right now is a generic way to have an Ansible role that's going to be what's called an eager policy that basically just says this sort of comes back to your question I think that for this particular install of eager we're going to be using NGINX versus Apache, right? So anything that's not the standard eager base config that comes out of what you would get today from the Den package, let's say, anything that you would want to be different, you'll be able to package that as an eager, as an Ansible role of your own. And then you just use it, you just have it as a dependency within the whatever role you're using to install eager itself from Ansible. I want these modules, these eager modules enabled. Maybe you want the remote site import stuff allows you to move sites or to copy sites, deploy sites from one eager installation to another one. So that's useful for things like migrating code from let's say dev to QA to production, right? So there's all these different modules within eager that can do that stuff whereas in production you might want a very stripped down closed down version of eager running that doesn't expose a lot of stuff or you may or just has a lower resource footprint so for efficiency so for a lot of that kind of configurability will be available within this kind of this Ansible role. Yeah. Like roles in Ansible define variables so one can be Web server and the default might be Apache but you can change it and say oh no, I want it. So it'll be it'll be a lot more customizable and it'll also allow you so we're working on ways to support newer versions of so we already support DA today within eager and we're going to be adding support for other stuff as well so I hope that answers Yeah. That's exciting. Yeah. I think I can't remember if the Azure policy role is not on our public facing the lab repo yet. Yeah. I'll get it. Yeah. Just to add to that like Ansible for those that don't know it's a command line tool so you can tell you know on the command line you can type you know I want to provision you know these VMs at this you know hosting company what so when it gives you just to back up way back eager is basically a web front end for DevOps so if you're using eager you don't have to do any command line DevOps anymore like you you know in the old days you'd have to do you know drush SQL sync you know you dump your database in production update your dev and staging eager you don't have to do that anymore that's gone because you just point click from the web front end so it's basically two components there's a front end Drupal site a bunch of custom drush commands which are your back end provisioning system there's also a queue so you do something the front end it adds it adds a task to the queue and then that gets provisioned by drush right so in the future that'll be Ansible which means it can only do Drupal-y things it can do anything Ansible can provision whatever you want the Django site you could have a Jumla you could have something else it doesn't matter so this is really going to be breaking open into a much more you could get eager to provision yeah does it mean that you could be overall pipeline with the the next thing yeah I mean so you wouldn't the eager itself isn't going to provide that you would have whatever Travis or CircleCI but eager I mean from day one it had hooks into the API hooks just as Drupal always had so at any point like before eager provisions a site there's a hook I think a hook pre-provision site and you know you implement that custom module and you could say oh before install a site go and do this other thing and you could say after a site is installed I want to do something so there hooks throughout the system in eager that was the old eager and the new one obviously we're going to do the same thing because people want to be able to do whatever they want with the system so you know you can definitely hook in your whole CI testing suite whatever you want and you can say on provisioning like pre-site provisioning or post-site provisioning you can say okay run all these tests if any of them fail and roll back so eager three now when you try to upgrade a site and it fails it just rolls back to where it was before you don't lose anything so that's a really cool feature that yeah that's on the same servers you might not want to run tests on the server where you have your production site right yeah so you do this on staging environment for example I mean that's another talk but for depth staging probably in eager you'd have three eager instances where you're staging or you're prod eager and you know you do that kind of stuff on staging I guess right and then you know to when you move sites around there's a remote import module and you can just move sites between eager environments like one eager can pull insights from another one and that's how you handle the whole you know deployment depth staging prod and you know about each other yeah they all yeah exactly so the way yeah and that's done in a really secure way uses SSH keys so there's no funny business with web services it's just SSH keys so SSH keys yeah you set that up in the back end and then the front end to make them talk to each other the main the main the main goal with eager is to make stuff make the easy stuff easy when you want it to be easy and straightforward but to also allow you to get as far into the weeds of customization and extension as you want again so we're trying to yeah like the slogan was an easy path and then but it's also it's highly extensible the slogan for eager was always tools not policy so here's a bunch of stuff instead of having to write a bunch of scripts to you know do your dev ops we provide you know that's provided but it doesn't set policy for you whatever you decide what your policy is then you configure eager to do that right and so we're going to do that in eager five right so are there any other yeah sorry that was a bit of a turn into an eager time which is not what we meant to do but yeah there's we'll come back to you here you can do talking about the eager five you've got the 10th time so real soon now yeah I mean like with most open source yeah I was just about to say so with normal open source project it's whenever it's ready now whatever it's ready is determined by several factors including funding right so if we have you know clients or partners of folks that want to do that and they provide funding for us not funding but they provide code like you know you can either provide code or funding or whatever then it'll move along faster right the more help we have or testing exactly so you know funding code testing documentation that's a big thing right so we're we're very poor documentation so if folks are interested in helping with that in various ways it'll it'll get done faster right but eager three is stable now and actually because we're tricking eager to thinking it's Drupal and it's not and that's why it works it was written a long time absolutely so so that's typically like for our clients they're like where we're hosting eager for them or are helping them manage their own eager where we set up we installed it typically we'd have one platform called you know say Drupal 7 you know at a time stamp right and so all the Drupal 7 sites will be there hosted on that say for example you know they're using different modules but they don't have to be turned on for every site it sounds like we need an eager talk where we actually run through what it can do for people it seems like this sorry but yeah it's check it out I mean we're not it's not a product of ours it's just an open we happen to have a couple of core maintainers in our team there are other core maintainers in other parts of the Drupal community we're very happy to have more folks because the more folks that are contributing to it the better it's going to get and a broader set of needs it'll be able to tackle that yeah whatever you're for whatever you're for that's a good question so that's the same kind of question as what happens to PHP 5 no PHP 6 sorry yeah it's kind of a long story but it's kind of like someone started on that and kind of went in a different direction and some other folks wanted to go in and that's sort of I guess the short answer is that's not a bad solution temporarily it's changing a few things but we thought well let's rewrite well because the problem with AGR it's got code still from PHP 4 when it was I think like way back right so this is early days of Drupal so what was like doing symphony stuff right which is great Drupal 8 doing that but the front end is still just Drupal 7 right so well let's sort of Drupal 8 we've got new APIs we can do web services REST more natively all this kind of stuff a long-term yeah so it's kind of like there's AGR 4 but it's basically one person working on it right so it's getting slate kind of starting over and yeah so yeah I mean yeah so to go back to the SAS architecture sure so we talked about Soviet infrastructure we've been hosted and everything but we haven't touched development and source control and so it's one thing to have one site with let's say one repository but do you have a different approach to something more more large yeah I mean the way these kind of things scale is if you have one code base and everybody's using it right so the magic to make that work is Drupal multisite like the fact that Drupal Core supports multisite that's what makes this possible because if you have 200 customers that are running on you know shared code base and you know AGR lets you upgrade all of them at once like you if they're all multisite didn't exist you manually have to upgrade each now there's only one gear refill you're updating and 200 customers get all the benefits right yeah but I mean if you have let's say custom AGR modules and you have some custom code for your infrastructure yeah would you separate all of this or just throw it all in one big repository it depends on what you're aiming to do you have to think about how you want to use it in the future you probably have a private repo with AGR customizations for your AGR installation or for your staff absolutely and the fact that you were noticing that pattern of doing it that way over and over again was what led us to build this idea of an AGR policy that's going to be something that any that and we're going to release it generically and then folks can customize that locally as much as they want to but that would then become something that you can use to install AGR policies depending on so for example if you have five different clients and they actually have different needs in terms of a lot of stuff we were talking about before you can customize it with the use of a different policy for each client like for example by default AGR takes over your web server configuration so by default it doesn't let you upload users upload files more than two megabytes so usually the first thing I do on most AGR projects is okay I have a custom AGR module and I change that to like five or ten whatever the client needs so that's a small example but like I said you can write modules to change any part of the config or whatever it's doing it's a framework just like Drupal's a framework so this is a SaaS framework so same idea yeah so I was thinking because some of those configuration are kind of really intimately related to your SaaS your application right and that's why you have custom private modules yeah just like for Drupal sites usually you're going to have a custom module where it's got it's own theme so same with the platform level I'm noticing that it's new so we may want to continue this conversation over lunch for anyone interested do we have until is it 12 or 12 oh yeah I guess it's over time yeah okay thanks everyone yeah