Why we are building Easy LMS in a microservice architecture | Development Talks

A lot of work is done behind the scenes to make our LMS available online for you. Putting everything together requires lots of development work.

Many things have changed since the company first started building Easy LMS. Would you like to know more? Our Marketing Owl Priscila interviewed one of our developers to learn how we build Easy LMS using a microservice architecture, what that means, and how that affects the work we do as a team and the end-users. 

Priscila: Thanks for joining me for this interview, Thomas! The first thing I want to know (and I believe most of the readers) is what microservice architecture is. Could you explain? 

Thomas: No problem. Microservice architecture is a way of building code into multiple parts or repositories. We can say we split the way we build code into multiple instances instead of building one big code block.

Priscila: Interesting. So it means that the development team builds pieces of independent code that fit together with the rest of the software, right? But it wasn’t always like this in Easy LMS. Why did the development team see the need to change the way you build the code? What led to it? Was that a new trend or something?

Thomas: Yes, it’s a trend, but that wasn’t the main reason. We always knew about microservice architecture. But in the beginning, we built Easy LMS as big chunks of code, or what is called a monolith. When we started growing as a company, we had much more traffic on the website, which created lots of trouble, such as unresponsive pages and bugs. We realized that we needed to change the way we build the code so that the website could adjust and scale automatically. 

It’s like having a “big factory” that gets easily overwhelmed with a lot of work. We realized that we had to build some “smaller factories” to handle other parts of the work

We found that some parts of the code weren’t practical, and we could improve them. Then we thought it was easier to execute the improvements as smaller bits instead of taking them on as a giant project. It’s like having a “big factory” that gets easily overwhelmed with a lot of work. We realized that we had to build some “smaller factories” to handle other parts of the work. 

Priscila: Can you give an example of something that we built in a microservice architecture?

Thomas: A recent example of a microservice we implemented is the new exports function for the Exam session export and participant data export. We made it in the last two cycles. The old exports ran in our old “big factory” together with multiple things and weren’t optimized. 

We could create a “tiny factory” that specialized in creating these new exports. With the exports, we ran into lots of problems. For example, when clients had too much data to export, their requests overwhelmed the main system. Now that we have a separate service for the exports, they can run smoothly. We actually built a code for the exports and another to inform the admins that their exports are ready. They are self-contained units, not big chunks. 

Priscila: Cool! Are there any other parts of Easy LMS that we built with microservice architecture?

Thomas: Yes, there are. One of the most interesting ones is the Academy’s new design. We built the new Academy with React, which is a framework for building interfaces. We built it from the old architecture (the monolith), took pieces from that chunk, and created a self-contained part. We also built an API (application programming interface) for fetching data to show in the interface. We now have two self-contained parts: fetching data and the other for displaying that data. They are smaller and easier to maintain. 

Priscila: Ok, based on what you told me, we still have some old code. Is it a problem that we now have two types of code in the system 😁? Are there plans to update it?

Thomas: No, it’s not a problem. It’s a process. We built the first parts of the system using the ‘big chunks of code’ method. There are plans to replace them. But the clients can’t notice the difference. We build the new code in a way that it can seamlessly work with the old code.

Priscila: Understood. So as a developer, what do you prefer? Is it easier or more complicated to build code with microservice architecture compared to the previous process?

Thomas: Yes, it’s much easier to think in small bits and maintain the new code. We are considering updating the participant interface in the future, so it works better in combination with the Academy and itself. If we build it with microservice architecture, it will be much easier to add features because we can work on every part individually. 

Priscila: So, how did working with microservices change the way you work? 

Thomas: We can develop faster and better. Microservices help us to maintain the website and enable us to release things more quickly.

We can also decide the best way to complete a job because each piece of code is a self-contained unit. That means we can determine what programming language we want to use and what kind of service we want to run. 

When we used the old system, if we wanted to update a build using a certain language, we had to continue building the code in that language. Now we can choose between different languages based on what we think it’s best for that feature. We work in teams. If we start a new microservice, we explore our options, and then we decide what works best for us. It gives us more options. 

Priscila: Does that affect touching unwanted parts of the system, like, when you try to solve a problem and end up creating another (such as a bug)? 

Thomas: Yes, even a year ago, when we tried to solve things that involved a lot of code, we ended up working on too many unnecessary things. For example, if we were going to solve X, we solved Y and then created bug Z. Working with microservices has reduced this problem. 

Priscila: Ok. I see that microservice architecture makes the work easier to handle for the development team. But how does it affect our clients and their participants?

Thomas: Well, as I said, the clients don’t (and shouldn’t) notice different parts of code. Everything should work together to create a smooth experience. Clients can benefit because now we can release new features faster and improve based on their feedback.

It is a drastic change from the way we did things before. For example, when we released the new Exam admin dashboard, it took us around six months of development until we released the whole thing at once. If clients loved it or hated it, there was no going back (luckily, they loved it 🤓). Now, we’ve changed the way we create and release new features. 

The new Course builder, for example, was first released as a Beta feature. We built it with React and released it bit by bit, adding minor new features until it had all the functionalities to replace the old course builder in its entirety. In the meantime, we could see what worked, how clients used it, improved it, iterated it, and then made changes. That wouldn’t have been possible with big chunks of code released at once. 

Priscila: That makes a lot of sense. From what I remember, it aligns with the principles of Toyota’s Improvement Kata that we apply in the company. It’s better to make a prototype, get feedback, and improve the feature instead of spending a lot of time without knowing how the clients will receive it. Thanks for joining me for this interview!

Thomas: Yes, I think that works better. I hope I could shed some light on how our development team works at Easy LMS! You’re welcome.