I’ve been in the Education business since the beginning of my career and because of that, I got to know Moodle pretty well, as most educational institutions in Brazil use it heavily.

Moodle is an open source eLearning platform developed in the early 2000s which was the very first online platform to popularize the concept of Learning Management System (LMS). I still remember the feeling of deploying Moodle for the first time in Plesk and getting some content published up there. I’m old, I know, but let’s get over it.

The fact is, twenty years have gone by and Moodle is still out there, more consolidated than ever hitting the top of every market share list published for LMS across the world and growing even faster after the pandemic. To give you an idea about how relevant it is these days, in Latin America alone, Moodle represents 67% of the market while Blackboard only 12%. That trend repeats itself for every other region in the world, except by Central America.

Moodle and Google

Google’s history and education tangles themselves together. Google was born in Stanford University and since its creation, it has always solutionized with deep roots in academia. The influence of education practices in every product Google builds and commercializes is evident. 

Obviously, Google Cloud is no different. It is very interesting to see how Google solutionize on top of core services to deliver unique products and services tailor made for Education, helping customers to accelerate embracing digital education. A great example of that practice is Google Cloud’s Learning Platform, which leverages Google’s ML models and applies them to educational scenarios.

But, what does that fact have to do with Moodle? I’ve been working with educational customers for over fifteen years now and know for a fact that hosting a twenty-year old application (like Moodle) in today’s demanding internet isn’t a simple task, and as a leading cloud provider we had to do something different, innovative to help our customers succeed with their Moodle-based strategy.

We did!

Technical challenges with Moodle’s architecture

Like every other application built in the early 2000s, Moodle is a classic strongly coupled PHP-based three layer architecture: visualization, middleware and data access, as depicted in Figure 1.

Figure 1. Moodle’s three-layer architecture

In other terms, Moodle is a big monolith that works pretty well. However, it usually requires brute force (multiple virtual machines burnt) to work properly. That’s mainly because:

  1. Frontend and backend are one single thing. If you need to scale one, you have to scale it all, which is usually a heavy lift.
  2. Moodle’s deployments are usually stateful, which means that both user and application data are sustained in the hosting server’s memory.
  3. Moodle usually relies on a hosting server file system to host “/moodledata”, which makes it complex to maintain as scalability becomes something critical.
  4. It is configurable but traditional deployments of Moodle leverages the hosting server file system to store uploads and static files managed by platform. As your scale grows, it becomes almost impossible to keep up the organization within the environment.

Due to those limitations, what usually happens when a big Moodle environment needs to be hosted in its traditional fashion is the addition of multiple servers (virtual machines) running either Apache or NGINX under a given load balancer. Moodle’s traditional hosting model looks like what is depicted by Figure 2.

Figure 2. Moodle’s traditional hosting model

In fact, the model described by Figure 2 does increase computational power and reduces response time of each request. However, it comes with a price (see list below.) usually high to pay.

  1. Virtual machines are time consuming and usually very expensive.
  2. IT teams have to manage every single aspect of the environment: from network to OS patching.
  3. Hard to keep up with security best practices.
  4. High likelihood of outages due to unexpected peaks (under provisioned).
  5. Single point of failure spread all over the environment.
  6. Hard to scale up and down and horizontally properly.
  7. Strategies of Disaster Recovery (DR) and Backup get very complex to put in place.
  8. Business continuity problems are prone.
  9. Scale storage capacity means stopping the environment to replace/add more disks.

That’s why we wanted to come up with something different and innovative to reframe our 20-year-old customer.

Modernizing Moodle: the rationale

If you have been playing with cloud computing concepts over the last two or three years you have probably heard something about a set of best practices gathered and documented by all main cloud providers called Cloud Adoption Framework (CAF). Google Cloud one is available here.

Overall speaking, what CAFs do is nothing but suggest a bunch of best practices to be applied in a cloud adoption journey in each step of the way, including what to do with a given application to be migrated taking in consideration functional aspects of it.

That modernization guide (focused on how to migrate all sorts of applications) is also known as “Cloud Computing 6Rs”: Rehost, Re-architecture, Re-platform, Refactor, Rewrite and Replace. I won’t get into details of when to do one or another here because all CAFs do a great job explaining it. When it comes to illustrating different strategies to migrate workloads (applications included) to the public cloud, the multi-path schema depicted by Figure 3 summarizes the art of possible.

Figure 3. Migration journey

However, I wanted to guide you through the mental process in which Ernani and I got into to create the “Modern Moodle on Google Cloud”, described in this official announcement in Google Cloud’s blog.

Rehost, Re-architecture, Re-platform, Refactor, Rewrite or Replace Moodle?

Rehost. Well, we discussed parts of it already, right? I mean, simply re-hosting an application like Moodle doesn’t really solve the problems we listed earlier. What it does in this context actually, is just move those problems from one place to another. No value added there so, leave it.

Re-platform. Replatforming an application usually means replacing underlying platforms where the application used to run for a new one (or at least, a new version of those). As mentioned earlier, Moodle is PHP-based and was originally designed to run on top of Apache web servers and MySQL over Linux environments. A replatform could mean, for instance, moving Moodle from Apache to NGINX and MySQL to SQL Server over Windows to pursue some benefit that the current stack doesn’t provide. Not what we’re looking at, as Apache, PHP and MySQL over Linux have proven themselves the best technology for Moodle over the years.

Rewrite. Rewriting an application usually means re-develop it from the ground up towards modernizing its operational model to attend to current and future market demands which the current one would not be able to. Classic examples of those applications developed 30-years ago to run specifically over mainframes. Most of these applications are performant and handle pretty well the types of demands they were projected to support. However, if a company relying heavily on those apps want to do something more modern like adhering to the API economy or create new generation of business applications based on consumption model, for instance, a Cobol-based application might be very challenging to re-architect, re-platform or even refactor. So, the best (perhaps unique) alternative will end up being rewriting it. We are not interested in rebuilding Moodle so that was not the selected approach here.

Refactor. An application that usually gets refactored when it is identified that pontual code adjustments or modifications could dramatically improve performance, cost optimization, so on and so forth. This is not the case for Moodle, as it has its modules strongly coupled providing some flexibility through attachment of plugins. Again, refactor isn’t our thing in this project.

Replace. We are empowering Moodle rather than replacing it with something else, so we didn’t even think about it.

The approach we’ve chosen to modernize Moodle is Re-architecture. After understanding Moodle’s working model, it felt natural for us to think about third-partying certain aspects of the platform, separating responsibilities and putting each piece of the application to work on top of built-in and high-scalable services in Google Cloud. Next session is going to guide you through the new hosting model we’re proposing for the solution.

Modern Moodle’s architecture

Modern Moodle’s architecture does a great job on separating responsibilities between application’s main components and third-partying responsibilities to Google Cloud built-in services. On top of that, we’ve been able to attach a couple of services that can greatly increase performance and resiliency for the application itself, as discussed later. Figure 4 shows what modern Moodle’s architecture looks like.

Figure 4. Modern Moodle architecture

Solution’s general communication flow happens as described:

  • Entrant requests first hit Cloud Load Balancer (it has the certificates in place and apply policies for backend communication with Kubernetes cluster). It also applies policies for both Cloud CDN and Cloud Armor (GCP’s WAF solution).
  • Cloud Load Balancer then redirects requests to be processed by Moodle’s web application in the backend, which is either Google Kubernetes Engine (GKE) or Cloud Run (smaller scenarios).
  • GKE’s ingress then does distribute the load among Moodle’s pods. It will automatically allocate more pods and cluster nodes (if needed) to accommodate a growing demand.
  • Moodle’s pods will read and write information both from Filestore service (where moodledata sits on) and Cloud SQL for MySQL.
  • User and application data will be persisted in Memorystore service through a built-in configuration Moodle has for those scenarios. It will make Moodle’s pods stateless and enable it to horizontally scale pretty efficiently.
  • reCAPTCHA enterprise is an alternative that can be turned on if there is no centralized authentication process in place. 

All that configuration currently sits on modern Moodle’s GitHub repository and you can run through it yourself. The only thing you’re going to need is a Google Cloud account. If you don’t have one and would like to try it out, just follow this link to create a free account.

The repo does a good job on highlighting the execution flow, prerequisites and so on, so, do as you please. We’re also happy to receive and analyze any contributions coming out of the community. Please, help us build an even better solution. 

Soon we’re going to be publishing a couple of load tests results and technical recommendations in regards to sizing and costs tied to it so, stay tuned.

Benefits this modern architecture brings to Moodle’s customers

Quick go-to-market. Everything you need to deploy this solution has been scripted and made available in this GitHub repository. That means institutions can simply follow the steps described in the repository’s documentation to get things running quickly. Google Cloud customized every step of the deployment to give you optimal resources and cost savings with the initial setup.

Cloud-native. This implementation of Moodle is 100% cloud-native. That means that all the services utilized by the solution are built-in Google Cloud services—meaning no more Virtual Machine management—and you get all the default benefits enabled within Google Cloud.

Highly scalable. The solution makes Moodle stateless, allowing it to scale up and down with no damage to users’ in-memory data. With GKE, you can also horizontally scale Moodle’s pods and cluster nodes, allowing web applications to always be on. All underlying services can follow GKE’s auto-scalability.

Open-source. The implementation of this solution is publicly available on GitHub. Institutions can collaborate with our engineers, or take it as a starting point for building something tailor-made.

Continuous Integration (CI) and Continuous Deployment (CD) ready. The solution was designed to work smoothly with DevOps automation practices. For that, Google Cloud recommends leveraging Google Cloud’s Artifact Registry and Cloud Build services.

Multi-sized environment options. We’re starting the project with an enterprise version for Moodle using GKE as the base for running Moodle’s instances. This is most suitable for bigger environments (5,000+ users). We will soon bring Moodle to a serverless model as well, allowing smaller environments and institutions to run at a lower cost.

Security embedded. On top of the web security layer provided by Cloud Armor and reCAPTCHA, modern Moodle deploys in private mode, meaning that all the underlying services supporting Moodle instance get enclosed to its network boundaries. Only internal resources (from the same Virtual Private Network) can access the services.

That’s it. Hopefully this is going to give some insight about how to think app modernization and get know a bit better what it took us to modernize one of the most utilized Learning Management Systems in the world.



Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *