 Rhaid i chi'n ziwadau i'ch cyfnodd! Rhaid i chi'n gwybod i'ch meddwl am y ffynol i chi'n ffynol i chi'ch meddwl am y ddechrau. Wrth gwrs, dyna'r canolist I.T. Dyna'r meddwl 25 ynglyn â bydd y rhan iawn, ymgrifoedd y cyfnodd o'r cyfnodd ymlaen, gydaar hynny ymdweithiant yn ystafell 200. Mae'n ffordd o'r gyfnodd o'r plattfornol yn y cyfnodd o'r cyfnodd o'r cyfnodd o'r cyfnodd o'r cyfnodd. The world of inferioritys, and and a very big part of what we do at Catalyst, particularly in the organization that I lead, which is based in the UK and Ireland, and in this time-zone slice is work with Moodle, and most of you have probably heard of us maybe using some of the plugins that we've released or have probably seen us, because we've benefited from a very bright brand that you will see around the place. We also have decided to take care of your 80s needs for the party tomorrow, so if you can come along and get yourselves some of 80s. One of the key areas of focus for us is to provide moodle services or moodle products or moodle manage services for the higher-ed sector. There's a really good reason for that. It's quite clear to see. This slide is now two years old, but it's still widely used, significantly the majority platform in use in the higher education sector around the world. Actually, Martin had some updated slides for this yesterday, which I need to get my hands on, but the numbers were still strong. So you can see here that represented in orange, moodle across most of the world, the US aside, still is a significant leader in the platform utilising the education space. And of course it comes with complexities. This is just a quick example of some of the probably known or maybe recognisable higher education institutions that we currently support in our moodle manage service. Now, during that time, sorry, and this slide here just represents some of the tooling or additional open source technologies that we utilise to provide what I'm about to show you in the next 10 or 15 slides. So the key thing to note first and foremost is that for many people there's a horrible term that we really dislike, which is the open source is free. Sure, you can go and download moodle now. We can all go download moodle. We can turn it on. We can run it and then very little beyond that. It's free like a puppy. We use this term a lot. You have to feed and water it. And the watering or feeding of your open source technology is the piece that Catalyst has spent many years developing. And we refer to this as our service wrapper or our managed service wrapper. And I want to talk through today some of the key pieces that we've developed over the past 25 years around ensuring that your moodle application, your moodle platform is well watered, well maintained and capable. And in particular today I want to focus on these key pieces here. So we're talking about very large scale, very high performance or high performance requirement platforms. And at those scales and at those load levels, moodle requires additional consideration, just like any application. So I want to walk through today some of these key points. First and foremost today, particularly in your moodle application, it holds a lot of data and that data must be duly taken care of. We are all significantly or commonly giving away data of our own personal nature, which we trust the receivers of that data to take care of. But in the university sector in particular we're talking about huge amounts of data that are passed over as a mandatory requirement to complete your university programme. So it's important that when that data is handed over it's taken care of. With a system like moodle, anybody essentially can write code or enhance the product. And that is both wonderfully beneficial and somewhat high risk. You are assuming that the moodle core product, which is very well secure and very well written, but also all of the fleet of plug-ins that you might add to that moodle platform are well written and secure. That's a big assumption, and you can't just carry that assumption forward. You must verify it. So a really key part of what we ensure to do, or that we think you have to do if you're going to run a large scale moodle platform, is ensure that there is a good level of security vetting and security consideration. There's a number of standard industry practices for this. But humans, developers, will make mistakes. So it's really key to ensure that you carry out due diligence, peer review, code review and so on. The other thing to note is that in high performance moodle, moodle core out of the box runs really well. Once you layer lots of plug-ins into it that maybe weren't designed with the high performance, high load use case, it actually can significantly change the performance of the platform. You must take that into consideration. We don't run any moodles with no plug-ins. All of our moodles have plug-ins in them. But it's really important that you verify that that plug-in is not going to cause you a spectacular disaster. Funny enough, for us in the UK today, on the first day of term, when all the universities go back. That's a good example. We believe there's a couple of basic pillars of security. This is not an exhaustive list, but it's important to look at the three key risk areas that you have, which is the software code itself, the infrastructure on which that software is running on, and then the people and processes around maintaining and managing that system as a whole. Within those areas, we carry out some, and this is not an exhaustive list, as I know, key elements in every single case. All code is peer reviewed. All code should be peer reviewed. There should be no path on which somebody can write code and deploy that to your production system. That would be crazy. Don't do that. Infrastructure. We're now working with cloud infrastructure provision, as you probably understand. It's not okay for you to just have unprotected direct access to that infrastructure, or to use keys and tokens. That's the people and the systems themselves. We're pushing towards much more standardised infrastructure security. Of course, on the people side, MFA now should be everywhere, along with a number of other standard practices to ensure that your systems are kept secure. Ultimately, the data within your systems is kept secure. We use AWS. I'm not going to describe this slide here, but the AWS shared security model is something you should be aware of. If you're using AWS, it really clearly lays out what AWS can make to take care of and what you, as the AWS operators or adopters, need to take care of. We talked a little bit about customisation. Customisation is a fantastic benefit of using an open source technology or a technology such as Moodle, but it comes with huge responsibility. If you're wondering who made the quote at the bottom, it's Uncle Ben from Spider-Man. Obviously he's very colour aligned with us. Yes, we can write lots of custom functionality on to Moodle that enhances the overall delivery of the product, but in doing so, we need to make sure that we're carrying our due diligence and due consideration about performance and about future sustainability. You've ridd a lot of customisation. We find a lot of Moodles in this case. You've hacked away at the core code base. That looks great now, but when you come to upgrade next year or when you come to deploy new functionality or features into your Moodle, it's actually a huge burden, a huge burden. Unfortunately, we find a lot of Moodles in a sorry state because there wasn't due consideration taken care of in the customisation space. So don't do some of those things. We run this basic test across a lot of the ideas or innovations that are being considered. So we call it the 5S test. Is it simplified and standardised? Are you building something that's so sort of unique to one use case that it actually doesn't have a wider appeal or a wider use case down the line? Can your requirements be broadened? Could you make it broad enough to be open sourced and shared back so as other people may actually engage and involve themselves in your new feature or functionality? Is it scalable? Okay, it works with 100 users on the platform. Will it work with 10,000 users on the platform? Will it work across multiple platforms? Is it secure? Probably should be at the top of that list. And then is it sustainable? Are we going to be able to upgrade and maintain this functionality into the future? The other piece is that you can't have your system go down when you're operating a university in the modern day and age and nobody do anything about it until 8am tomorrow morning. So actually having a full 24-7 coverage which enables you to also lean on a team of individuals who are awake at their desk, ready to carry out whatever incident response actions might be required is hugely important for high performance, high load mission critical platforms, which is what we're talking about. And then finally, we talk about high performance. We are using technologies which are cloud native by design. So you need to be utilizing or reaping the benefits of the tooling and resources that are given to us in the modern cloud systems. So just jumping, and I'm going to skip this slide, but ultimately the architecture that you might expect to see on a large platform nowadays no longer just looks like a server or a couple of servers with a load balancer is actually a highly cloud native design. And finally, we tried to use analytics to inform behaviour and preparation. And so if we see high stakes exams on the horizon which must not fail, a high stakes exam cannot fail, then we make sure that we scale and prepare accordingly at the system and infrastructure level. And actually if we can use Moodle tooling, Moodle technology to inform us of when a high stakes exam is on the horizon and we can actually prepare accordingly and not be reactive to those kinds of events which can cause you significant pain in the event that your platform receives a surge of traffic that you were not prepared for or did not have prior warning of. So the high stakes examination is a good example of what I wanted to just talk about. Examination in Moodle or in any method is a really high stress period for anybody who works in this sector. If your students receive any performance issue, performance blip or performance failure or if the system does not hold up, then ultimately you've got a number of very, very upset and rightly so students and your credibility and reputation can be significantly impacted. Exams are stressful for everybody, they cannot fail. Just to give you an example of what is capable in Moodle if well architected, one of our partners, this partner being the National Open University of Nigeria, very large Moodle, 150 daily active students, they're actually in exam mode right now, lots of courses and programmes. A good example is that we frequently see 10,000 concurrent examinations taking place using the Moodle quiz which can be a relatively heavy module in Moodle and the Moodle assignment submission is used frequently to gather tens of thousands of assignment submissions. It scales up and down accordingly and as required, talking about some of the things we touched on previously. So that's it from me. Just a little bit here about some of the acceptance or feedback from some of those users at National Open University but I'm out of my 15 minutes. So thank you very much everybody and if you want to talk about any of that of course we're over at the stand in bright red.