 So, look, to cloud is often the term you get thrown around with these sorts of things, so I'll move right along. So, disclaimer here, ladies and gentlemen, you know, I'm going to give you some opinions. These are my opinions. These are related to the company I work for, but these are based heavily on the experience we've gathered doing, you know, providing services for a number of clients in the Moodle space as well as other IT experience. I'm going to throw some information out as well. I hope this information is useful. This is, you know, the aim is to sort of broadcast knowledge, but ultimately the decision around any kind of hosting change, because if you've got a Moodle, any change in terms of being internal versus external, it's a change, and you need to understand what the implications of that are and take some ownership and, you know, and sort of assess various options as there will be. So a little bit of a terminology cheat sheet. There's a lot of marketing speak. There always has been in the enterprise hosting game, right? In the hosting game, there's all sorts of sort of noise and various bits of metrics that may or may not be terribly relevant. So Cloud, I like this one as someone else's computer, you know? So not the one that you're holding in your hand, which is probably a phone, or the one that's under your desk, which of course, Cloud providers like Amazon will argue with that that it's not at all, but to some degree it is, right? You don't know where it is, you just know it's a computer. You know, an internal hosting put simply as a machine that you at least know which room it's in, and if you've got the right sort of pass card, you can walk up and actually touch it, and you can turn it off and on, and you might have the responsibility to actually fix it, like, you know, put new disks in it or replace it or call the manufacturer based on a warranty fix. So dedicated versus shared, you know, I think that's pretty obvious. Shared clusters are where you have lots of moodles sort of hosted together. Moodle, this is the context of the discussion, as opposed to sort of one physical machine or one cluster hosting one big Moodle. On-prem to me, it just means internal. Virtualize would probably be the way that if you are running internal infrastructure, most people are probably running virtualize at this point in time, the arguments for bare metal stuff fewer and fewer, and, like, hybrid, to me, that's just marketing speak. I mean, different people have got different ideas of what that even means, but it gets thrown around a lot in the current sort of cloud discussions along with terms like workload, right? So, you know, these things sometimes don't actually mean too much. So, as a Moodle, let's think about a Moodle as sort of almost a living thing. So, I'm a hosted Moodle, right? So, I'm a hosted Moodle either internally or externally. Like, I live somewhere, I exist, I'm being interacted with, I'm a central part of, you know, organizational change, you know, and like in a reasonable size Moodle engagement, let's say a university of some sort. You know, here's Kevin, he's the Moodle product owner. He sort of owns the product. He is in charge with the decisions and responsibilities around the platform. He is the one that the business sort of yells at when things go wrong or explains what the roadmap is or these sorts of things. And here's Barry from Australia. Here's Barry, the sys admin. So, you know, he cares about the environment. I mean, this is leaning more towards probably internal hosting setup, but there's someone who cares about the bear infrastructure. This might be an external vendor, but they care the systems up. They care that the disk doesn't fill all these sorts of things that, you know, everyone's had outages, right? That are related to these sorts of things. It happens. And here's Wayno, the Moodle developer. He fixes bugs. He works on the integration stuff. He writes some plugins. You know, he sort of contributes to core. And here's Sue, the support manager. You know, she's the one who people call. She's the one who answers the phone. She's the one who understands if people's passwords aren't working or there's some sort of integration problem. So, you know, this is sort of the, and you know, there's some educators and some students. So, thinking about that in terms of your Moodle is a good way to understand any kind of change in the hosting setup, how it will affect the people on that list. So, I'll just run through this recently quickly. Sort of a month in the life of a Moodle, right? You know, learn is learn. Teachers engage. You know, support team deals with students. You might do an upgrade. There might be some sort of issue that people triage. You know, there's some new plugins or modules get released. Okay, so just sort of the things that happen a day in the life of a Moodle. Once again, this is sort of almost a cheat sheet of the things you might need to understand when you're talking about, you're moving from one particular hosting to another. So, value points in Moodle hosting, okay? Now, please think about, like, because sometimes the metrics that sort of clients discuss are not necessarily things to focus on. So, I started off here with, and it doesn't matter whether we're talking about internal or external or cloud hosting, whatever. These things are still core to a Moodle that is a central part of your organization. So, the first thing I'll say there is Moodle Streetcred. Now, what I mean by that is, you know, essentially, is this provider a Moodle partner? Or do they know Moodle well? Have they engaged with the Moodle community? Do they really get Moodle, right? Because some providers will just say, oh, it's just a PHP application with MySQL, the Postgres, no worries, we can host that, we know what we're doing. But, you know, it matters that they understand what Moodle is, right? Like, you know, I'm not saying that's the only way to do it, but it is something to understand. Ask some questions, see what they've done. Please tell us, please convince us that you understand Moodle well, and obviously support the Moodle partnership network. So, reliability, I mean, you know, you want the Moodle hosting to be reliable. You want it to be there. You don't want it to be going up and down, right? Performance is important. Performance means pages load snappily. Performance means that you have, you know, you don't have people saying to you, oh, I tried to use it last night and it was slow or these sorts of things. Performance means that when you schedule a quiz at the same time that the site handles it, that the Moodle site handles it, you know, it is important. People are very used to using snappy interfaces. Like, you know, the masses out there, especially the younger generation, do not want to wait for a page to load. And there's all sorts of research done, you know, Google search ratings are attached to page load performance. So performance matters. Support processes, you know, really think about what the mechanics of getting support from either your internal responsibility team or your external team means. Like, what questions are you allowed to ask them? How many times can you ask these questions? You know, what are the promises around response times? Do you have to use a ticket system? You know, these sorts of, you cannot understand too much about these sorts of things because support is very easy to get wrong. Support is very easy to do badly, right? Like, you know, everyone's had engagements with internal infrastructure teams or whoever where it wasn't very good and you don't feel like you're being listened to and your problems don't get fixed. Flexibility as well, you know, you want to be able to, it's an open source system. Moodle was designed to be, was built to be flexed to be customized and optimized. So you should be able to push your Moodle in the direction you want to do. So just some reasons why you might want to host internally, right? And these are things that we see out there in the market. We need control, okay? We just want control. This is our organization. Great example, one of our clients, Victoria Police. Okay, so to them, the idea of, and to say to Victoria, to them the idea of having Moodle outside of their own infrastructure is just not feasible. It doesn't matter, you know, money, where, how, it just is not feasible for them to host their system outside of physical machines that they control. You know, so there might be on-site usage patterns that mean that you want to host internally. For example, a school, one of our schools in Sydney, they're reasonably remote and the internet connection outwards is not always that great. I mean, it's good, but it needs to be very big with the school of 1,000 people and the best guarantee of having Moodle available all the time is essentially on their land, right? So for them, it does make sense to be internally. You might have a very capable infrastructure team that just manages these responsibilities very well. Good, they're not all like that, as people will know. You know, you've got internal developer capacity, you have very complex and bespoke systems integration requirements where your Moodle is talking to a lot of other systems that are sort of on the same network and facilitating that externally is challenging. It can be done, of course, but it's challenging and it is a bottleneck to change. And simply, it ain't broke, right? Like if you're hosting internally well at the moment and it's working well and you're happy, then there isn't necessarily a huge argument to change. External hosting, you know, i.e. cloud in these days, sometimes it's just not feasible to host internally, right? You just don't have the skill set, you don't have the will. Sometimes there was a big mess of a Moodle. We've certainly been engaged by organisations where they made a big mess internally, you know, staff changes, poor decisions, whatever, these things happened and they pushed it externally as sort of part of the move. Like, we just want to get this off our plate. Sometimes Moodle outgrows the internal team. Sometimes they need the data center, they need the access that a data center and the internet, the data center provides as opposed to being internal. Corporate policy, let's push everything off site. You know, that's certainly a big noise in the university market in Australia at the moment. They want to get stuff off site, they want to get stuff off their infrastructure. Cost considerations, I mean costing internal, comparing the cost of internal versus external in reality is actually a bit of an accounting, it's a bit of accounting trickery as to how you cost these things in all honesty, but some people will make the argument that it's cheaper to be external, right? You may just have no willingness to take on more infrastructure. Now, I mentioned Cloud in the title and I'll sort of say clearly what I think is good, what we think is good about Cloud hosting, right? Cloud Moodle hosting makes sense for big sites where there's a lot of scalability and performance requirements of a reasonably hefty site. Okay, so we're talking sort of university level, hundreds of thousands of page views a day, big load spikes around particular time events, that sort of size, like you can still do that internally and we've got clients who do it, but it's start the arguments towards the flexibility and sort of capacity that Cloud gives you are reasonable and worth investigating. So a big Moodle with big usage footprint, it's worth thinking about what is this feasible or not and do you want to do it. Massive load spikes, the flexibility that Cloud-based AWS, for example, gives you in terms of just being able to double the size of your database when it's melting down on some huge period of heavy use. There is no way, I mean, sure, with VMware, you can sort of double the size of the machine but it's pretty nifty and it saved us on more than one occasion. It was a new capability. So if that's something that you have to think about in your Moodle, then maybe Cloud's something you should consider. But Cloud isn't a magic wand and if you want to move into a really proper Cloud architected solution, that may require investment and it may require rearchitecture and it may require solving other integration problems. It isn't just a matter of lift and shift. I mean, it may be but be prepared that with change come costs. So just want to throw out some problem signs in terms of your Moodle and some things that should make you think about whether or not your approach is perfect. Moodle version upgrade lag, common problem but you shouldn't be way behind versions of Moodle. There are so many tools and models that allow you to ease the pain of upgrades compared to back in the old days. We've earned a fair amount of money over the years doing Moodle upgrades for people but we don't see that as a sustainable revenue stream moving forward. We want our clients to be on the newest version of Moodle. We want to embrace continuous integration and automated upgrade processes because it's not good when Moodle uses upgrade shy because there's a lot of cool stuff coming out in new versions of Moodle. So you should be running on new versions of Moodle, right? I understand all the reasons why that's hard but you should be looking at ways to make yourself using newer versions of Moodle or liability. If your site has regularly got performance issues or is slow or is ropey, that's not good, right? That's not good. It's a core part of your infrastructure. Performance, same thing. Ask yourself the question in terms of application ownership. Ask yourself the question sometimes when you're doing a review, who owns Moodle? Some universities can't actually, well, in Australia, some universities can't actually accurately answer that question. They'll sort of point at various departments and people but someone, a single line of responsibility, right? And that's an important thing. It's someone who owns it, someone who can make decisions, someone who can drive things, someone who can veto things, you know? It's hard sometimes inside large bureaucratic organizations but it's important. You know, obviously anything to do with infrastructure or bandwidth or storage, you know, these things should not be a problem. In the modern world, they just shouldn't be a problem, right there. You either turn up the volume on what you've got or you change your approach. You should not have to negotiate with infrastructure people to get another terabyte of storage. You just shouldn't, right? That's not the way we live anymore. We certainly sometimes have to but you shouldn't, right? Take a deep breath. Lots of information, okay? That's sort of the information end. We're drawing to the end. What to do next? Think about your strategic plan, you know? Have a sit down, get some people in a room. You probably have to do it more than once. Where are we going? What are we doing? Right? What's the current state of play? Oops, missed the C on the bold there. What are our problems? Draw them on a board. Put them in a backlog, rate them. You know, what are the bits that we're not happy with? What are the priorities? Which are the most important ones to fix? You know, what options do we have organizationally? Can we hire someone if we make a business case for it? Can we find some money to go and talk to a vendor? You know, make use of Moodle consultants and getting them to come into your organization and provide you and propose things, propose solutions to them, right? But that doesn't cost you anything. Get someone in there and say, look, here are some of our problems, right? Help. Give us some options. How much do we have to spend or, you know, what can you offer us? Like, why not, right? Make use of their time. In those discussions, we're certainly more than happy to have, but we're not the only ones. Walk around the room down there or, you know, Google, Google, Google, Google, Google. Think about who your potential partners and vendors are and there are plenty of them and there are plenty of good ones. One more thing about performance metrics. It's not, I'll just sort of fast forward to the end because I'm sort of getting low on time. Things like uptime, storage and bandwidth, they're way down the list, right? Way down the list. Really, uptime, anything over 99, like guess what, uptime, yes, the site's not allowed to go down, never. Right, 99.99, 99.5, 99, whatever. It just means that the site is not allowed to go down. It's actually much more valuable to understand what the escalation responsibilities are if there's an issue and the guarantees they're saying about when they're gonna call you back and how long, how quick it is before they're gonna resolve things, then uptime. But that's, that's all the time for. That's great. Well done. Front of the floor. Thanks very much. Thank you.