Jerrett Fowler has designed a server system that automatically scales up when numbers of learners peaks, and then disappears into the ether when learners do! He tells Susie Finch about his journey into previously unchartered new technologies.

 SF: So what is this Flex that I’ve heard so much about?

JF: Flex is an ingenious way of quite literally balancing the load of more than 500,000 users accessing our e-learning – not necessarily all at the same time, but you get the picture.

In the past we’ve had several servers all operating around the clock, whether learners are online or not. That obviously wasn’t the most efficient system. More recently we had just one, very large server, which creates a different problem – of vulnerability. So I decided to try and create a totally new system. What if I could invent something where servers were automatically created at exactly the moment they were needed, and effectively ‘disappeared’ when they weren’t? I knew this could be done, and was determined to make it a reality.

More interviews

Action mapping to improve L&D performance for the business

What is the value proposition of L&D?

How do you design and facilitate a year-long MOOC?

Spotlight on…Martin Couzins

SF: How did Flex come about? 

JF: It was an idea that I first had in the winter of 2013. We were using static servers at that point, and Rackspace had just announced they were going to release autoscale. I saw its possibilities immediately and started to plan Flex. Two years later we have a very sophisticated server setup.

 SF: How was Flex created?

JF: I used Rackspace’s autoscale feature, a system that uses a load balancer and a ‘recipe’ (which I created) to build a server. If you don’t know what a load balancer is, imagine an old fashioned set of scales – when one side starts tipping in either direction, with more or less learners online, this is when Flex either scales up (adds a server) or scales down (removes a server).

For our specific setup, there’s always a minimum of two servers behind the load balancer. When capacity is reached on our two servers, the Flex system scales up, a new server is built, and it becomes available for users – even though they are blissfully unaware of it, as it all happens in the background.

SF: What problem does it solve?  

JF: I created Flex because we had times of extremely high traffic as well as times of extremely low traffic. Extremely low traffic doesn’t hurt end users, but extremely high traffic can. Before Flex, when we had moments of really intense activity, we’d just have to grin and bear it and hope that the entire system didn’t crash. We really needed something that would allow us to up-scale capacity at a moment’s notice – it’s that immediacy that’s really important – so there was a real need. 

 SF: What are the benefits of using the Flex system?

JF: In infrastructure projects, the idea of a ‘single point of failure’ is pretty horrifying. But before we had Flex that was what we had, a single point of failure: one very large, single server that was managing all our customers, jobs, databases, sessions, files and Moodle as well. We have around 130 separate Moodle installations – one for every member of the Consortium – each with their own databases. The larger we became as a Consortium, the more learners were using our system, and the more challenging this became to manage, or predict. 

We’d frequently hit moments of extreme sluggishness. We’ve always prided ourselves as an organisation on our customer care, so this was incredibly frustrating. Now the Flex system is able to scale up and down so that we only ever use what we need – and when we need a lot, we have that extra capacity immediately. This all happens without my interaction, it’s automatic, but there’s a fair bit of maintenance involved.

We’re also using Moodle in a way that’s a bit different from others. We have a multi-tenancy system, where we use one Moodle base code for all of our customers, which basically means that we have significantly reduced the amount of resources that Moodle needs to host all our customers. 

SF: Will learners – or learning professionals – notice any difference? 

JF: Both learners and learning professionals, no matter what their role, should have noticed a gradual increase in speed using our learning resources over the last couple of years. Not only has speed and responsiveness increased, stability has also become a large part of what Flex offers. As an example, one customer was having extremely slow load times, sometimes of 20 seconds. With Flex we’ve reduced that to, on average, a fraction of a second. 

Everyone’s expectations of using technology are now incredibly high, and there’s nothing more frustrating than waiting for something to load, so I’m thrilled to have designed a system that improves the user experience.

SF: How many hours has gone into creating it and who has contributed? 

JF: Let’s just say that it’s taken the better part of two years to create this! It’s been a hard, trying project but I knew it was possible and I kept on it, with Rackspace’s help. It was mostly my design, and then Christian Trocchi and Simone Soldateschi at Rackspace and I worked on the implementation. I couldn’t have achieved what I have without them.

SF: What have you learned along the way? 

JF: It was essential to learn new skills. I’ve become intimate in several programming languages, technologies, and methodologies. There’s still a lot to learn, but I’m loving it.

SF: Anything that you wish you’d done differently in hindsight?

JF: There were a few instances where I hadn’t anticipated the scale at which our learners use Moodle, and I needed to seriously increase my estimates. There were also a few rocky moments where there was some impact on end users, and that’s not something I’d like to make a habit of. It’s something that I’m working on, but it can be hard to predict Moodle’s behaviour. 

SF: What next? 

JF: Well, firstly, I’d probably like to change the name of Flex to something that better describes what it is. Some plans for the future include centralising all our server logs, so that when a server spins down, we don’t lose critical information about activity on that server.

SF: Finally, could this method be adopted by others?

JF: Unfortunately Flex isn’t a solution that can be packed up and shipped off to other organisations. But it’s definitely something that I could either collaborate or consult on, as I have learnt so much by doing it myself.