Microservices vs. Monolith Code Architecture

[Phade]

Hey Everyone!

When the site was first written, I wrote everything in basically one big monolithic chunk of code. Later on, I added the forum as its own sub-service (microservice) and integrated it into the site as a whole. Now that we're recreating the site, we have the opportunity to incorporate and integrate microservices as parts of the site code in order to speed development, isolate coding activities, and more easily update and maintain site functionality.

The definition of a microservice for our project goes something like this: A microservice is an independent codebase that can be integrated into the main website with an integration configuration (usually a config file); the microservice codebase can be updated independently of the main site without interfering with the main site. Example: Linux runs a server. HTTP via Apache is a service. A forum via phpBB is a microservice since it has its own enclosed codebase but requires multiple services (like Linux, Apache, and MySQL) to run.

What site functionality could benefit from a microservice architecture rather than being lumped into a monolith of a main site?

Authentication and Security

Since we are likely to use several independent services, having an independent user authentication service like OAuth (or something like it) seems essential. Expanding that to hold backend shared secrets (like database passwords, cloud service credentials, etc) also seems a straightforward candidate as a microservice.

The Forum

Once a user is authenticated, the forum code is essentially independent from the rest of the site. We can expand the base forum functionality by recreating our own plugins for the [vidid] tag and integrating some user information replication. But after that, the forum code should be independently upgradable regardless of the rest of the site.

The Wiki

As part of a phase 2 deployment, an education center consisting of a wiki should equally be independent after user authentication is configured. Again, we can create some plugins to automatically pull video information and/or create links to video entries. But, any change to the base wiki code would not affect the main site.

Donation Management

I don’t think we should recreate our own local payment service, but instead use PayPal, Patreon, or others like them as a payments microservice, and then use API calls to manage the transactions, reporting, and reconciliations. Interchanging payment services should not affect the main site code, only the authentication.

Video Uploads / Downloads

This is already set up as an independent homegrown microservice within a container in the current architecture. I think it’s a good idea to keep it that way, but also update it to make it more robust.

Video Streaming

This is another independent container within the current architecture. The site should be able to swap out streaming engines and/or independently expand or contract the number of streaming sub-servers without affecting the main site.

GetYou2b

I’ve already successfully created a method to add video entries using the information found in YouTube so that creators who have only uploaded to YouTube can migrate entries to the Org with a single click. This service should absolutely be an independent container since it needs a VPN service to work correctly. Given some generalized configuration options, this service itself can be deployed to any organization that manages a similar music video site (Godzilla Music Videos, maybe).

Anime Autodetection

Trace.moe and similar services to autodetect the anime are already set up as microservices by their creator. Sticking with that architecture seems natural rather than merging their entire codebase into ours.

Org Merch

It would be nice to get back into the merchandise side of things again. This will either be an independent function within the site or more likely just an integration with an external merch vendor.

AMV Search

This one could be either-or. There are independent search services we could install and run on the site. But, we could also build our own from scratch. Perhaps we will use a bit of both: an external search service installed locally for the quick one-line search tool and a separate homegrown service for the “power search” feature.

Events Calendar

We can probably find and integrate an events calendar into the site instead of recreating that service. It would be especially helpful if we are aggregating multiple calendar sources into one.

All of these functionalities and more could have independent codebases that would branch out from the main site with an integration configuration stored in the secrets management system. Encouraging or forcing each of them to become part of a monolithic system seems like it would be much more difficult to integrate the code and manage long-term.

Do you have experience creating microservice-based architectures? What went right and wrong with your projects? Let us know so we can learn from your hard-earned lessons!

Phade.

[Phade]

Hey Everyone,

Here is a crosspost from the "What has Phade been up to?" thread since it is relevant to this thread.

I'm trying to visualize the internal server structures so that I can create a similar development environment to start coding against. Some of the things that I must consider are the physical servers, virtual server containers, and services within each container. Containers help separate functionality so that they are easier to maintain and update as well as being able to restart sections of the site without having to restart the entire server itself.

I've created a rough draft diagram to help me visualize what needs to be done. The main site container will likely have more open products as services/microservices, but I put in some for now as placeholders. Up next: How to get it done!