Reflections on Learning Management Cloud

Reflections on LMC

On June 1 2016, Cybera officially transferred the operations of the Learning Management Cloud (LMC) to the University of Alberta. This was a bittersweet moment for us. We were sad to say goodbye to something that we had grown and developed since its inception in 2012. In a way, it was like sending our child off to university for the first time. However, like many a proud parent, we were excited to see the project move on to an organization like the University of Alberta. In their capable hands, the LMC will continue to grow, mature, and hopefully expand.

When LMC started, we saw a way to assist educators by simply managing a shared infrastructure for them. However, we quickly found that collaboration was actually the most important intangible aspect of the LMC. Yes, there are definite benefits to sharing infrastructure, but thanks to the in-person sessions held every six months, and regular virtual bi-weekly operations meetings throughout the year, staff from participating organizations had the opportunity to get to know their peers better. This, in turn, created a community of educational facilitators who could learn and share from each other on a variety of topics, not just Moodle.

Over the course of the four years working on LMC, I think Cybera also grew as an organization. We learned to develop tools, techniques and practices that have influenced every project that we have since undertaken.

At the start of LMC, we expected to find many opportunities to use software development techniques and cloud technology to run infrastructure automation in a maintainable and scalable way. And we are delighted with how far we were able to take that. However, as we started down the path of infrastructure automation, we discovered that Cybera also needed to change its organizational procedures and adopt DevOps practices, in order to effectively deliver infrastructure automation. These DevOps practices really started to emerge in 2012, so there was a lot of growing and learning that we and the industry needed to do. As one of the key members of our staff, Preethi Kumar, explains:

“As a developer, I've always considered the application code we write to be the ultimate shippable product. But the knowledge gained from practising DevOps processes like ‘infrastructure-as-code’, ‘continuous integration’, ‘continuous deployment’, ‘monitoring’, and so on has helped me understand that the shippable product also includes so many other moving pieces in the underlying infrastructure.”

The DevOps path let to the exploration of a number of different tools to assist us, which we described in our Tech Radar blog posts, including:

  1. The use of ELK stack for Monitoring

    1. Introduction to Logstash: Getting Started

    2. ElasticSearch cluster rebuild post.

  2. The use of Chef for infrastructure-as-code

    1. Lessons learned from ChefConf 2012

    2. Modular Configuration with Chef

Something else that took us by surprise was how much more we needed to learn about the tools we were automating, before we could even begin automation! We had gone into the project with the assumption that we would only look after the infrastructure, and the institutions would take care of the application — with a clear distinctions in roles. However, in order to automate the build of a virtual environment — including the creation of a new Moodle instance — we first had to understand how Moodle worked, perhaps even more than if we had install and maintain it by hand. This deeper knowledge gave the application teams at the institutions the freedom to create their own virtual environments as needed. Prior to this project, they would have had to wait weeks for a similar request to be delivered.

As another member of our team, David Ackerman, puts it: “Coming at DevOps from the software world, it's hard to look at software development in the same way now as when we started. After working on LMC and seeing the benefits of everyone (developers, systems administrators, application developers, etc) having a better understanding of the entire deployment stack, the old days of software developers finishing a feature and tossing it over the fence for someone else to make work just seems downright irresponsible.”

The LMC journey has been an exciting one, full of ups and downs. But we believe that Cybera has been able to hand over the operations of LMC to the University of Alberta in a better package than when we took over the reins four year ago. And that is no small achievement!