Scalelite deployments in a right way (Part I): A new chapter
Tags: opensource, bigbluebutton, scalelite
Published: 2022-11-24 21:52:21

A lot has happened since the last time I wrote an article [[1](https://medium.com/@JesusFederico/scalelite-lazy-deployment-part-ii-240ffddfbbf5)] about how to deploy Scalelite [[2](https://github.com/blindsidenetworks/scalelite#readme)] for scaling BigBlueButton [[3](https://en.wikipedia.org/wiki/BigBlueButton)]. While it helped many around the world to get started, after two years and many hours of customer and community support, I recognize that my work is far from done.

So I am going to start a new series named **Scalelite deployments in a right way** that hopefully will help as well to improve some of the current deployments that are out there.

The topics I will be covering in the next few weeks (or months, let's see) are:

- Basic deployment on AWS with Docker Compose
- Scaled deployment on AWS with Docker Compose
- Highly Available Deployment on AWS with kubernetes
- Clustered deployment on AWS with Docker Swarm
- Provisioning on AWS with Terraform
- Scalelite systemd deployment demystified

I must warn the reader that there are many ways of accomplishing a successful deployment. And I am not claiming that this is "The" right way. It is just "A" (which may well stand for another) right way.

But before that, a full disclosure and a little bit of context.

**Background story**

When we (some of the BigBlueButton core developers working at Blindside Networks [[4](https://blindsidenetworks.com/about-us/)]) started this journey, we did not know where we were going to land. It turns out that an application we originally wrote for helping one single University in China [[5](https://campustechnology.com/articles/2020/03/03/coronavirus-pushes-online-learning-forward.aspx)], ended up being adopted as the de facto tool for scaling BigBlueButton around the world during the pandemic up to a level we had never seen before [[6](https://bigbluebutton.org/2021/06/23/bbb-case-study-baden-wurttemberg/)].

So yes, we are the first in recognizing that the stack we have chosen could be different. And that neither the architecture of the application nor some of the algorithms we use are perfect. In fact the application is far from perfection.

But let us remember that the tool was rapidly crafted to solve one particular problem.

_"To allow balancing the load required for connecting a single instance of Moodle with a pool of (20 to 30) BigBlueButton servers, and to centralize the recordings they produced."_

And we succeed on that in just a couple of weeks and many cups of coffee (and tea, because that one guy who doesn't drink coffee :)).

We open sourced the code and many-many people started reaching out right away asking for help to deploy it.

A lot of them, even with an IT professional background and experience administering Moodle and other tools used for online learning, had none or very limited expertise with BigBlueButton system administration, or with the components used in our stack. This includes Docker (our platform of choice for shipping Ruby on Rails applications) or Linux services such as systemd, rsync, power shell, nfs etc.

And that is the reason why I decided to write some scripts based on docker-compose (my tool of choice for integration development and prototyping) and the first article, [Scalelite lazy deployment](https://medium.com/@JesusFederico/scalelite-lazy-deployment-e3cd0af76d39), published on April 27, 2020 [[7](https://medium.com/@JesusFederico/scalelite-lazy-deployment-e3cd0af76d39)].

Not as a recommended way to deploy scalelite for production, but as I mentioned, a first step to help people get started and have a working solution right away.

**Consequences**

The problem is that while many experienced system administrators were able to tweak the scripts and turned them into an amazing piece for deployment, not everybody was able to solve adapt them by themselves nor to solve the many common problems that may arise when these kinds of applications go live. 

And given the limited resources we had at a time, as much as we wanted, we were not able to help everybody with their particular needs. And not even able to cover all the ground we would have wanted with scripts and documentation.

**Steps ahead**

But now that madness is over (hopefully), and some of the stress has been put off our shoulders, we have discussed internally and agreed that we are going to continue working on this project.

- Therefore there are a few things that we need to address.
- Bring the current version up to date, with particular focus on security, performance and stability.
- Implement some essential enhancements needed and required by the community and user base since long ago.
- Improve the documentation!
- To establish process and leadership in the hopes that we bring more developers on board.

With this, I hope to hear from you soon. Stay tuned.

**References**

[1] Scalelite lazy deployment (Part II). In Medium.com. Retrieved Nov 24, 2022 from https://medium.com/@JesusFederico/scalelite-lazy-deployment-part-ii-240ffddfbbf5

[2] Scalelite. In GitHub. Retrieved Nov 24, 2022 from https://github.com/blindsidenetworks/scalelite#readme

[3] BigBlueButton. In Wikipedia. Retrieved Nov 24, 2022 from https://en.wikipedia.org/wiki/BigBlueButton

[4] Blindside Networks. In Blindside Networks website. Retrieved Nov 24, 2022 from https://blindsidenetworks.com/about-us/

[5] Schaffhauser, Dian (Mar 03, 2020). Coronavirus Pushes Online Learning Forward. Retrieved Nov 24, 2022 from https://campustechnology.com/articles/2020/03/03/coronavirus-pushes-online-learning-forward.aspx

[6] How German Schools Use BigBlueButton To Provide Online Education. BigBlueButton Blog. Retrieved Nov 24, 2022 from https://bigbluebutton.org/2021/06/23/bbb-case-study-baden-wurttemberg/

[7] Scalelite lazy deployment. In Medium.com. Retrieved Nov 24, 2022 from https://medium.com/@JesusFederico/scalelite-lazy-deployment-e3cd0af76d39