[ADMINSTRATIVE] Miscellaneous thoughts and questions on CI/CD, DevOps, and infra about website

[driscoll42]

Can I suggest this issue also include the discussion around the servicing accounts from #8? I think it fits better here in this discussion

[disposedtrolley]

Firebase will be much simpler than rolling our own infrastructure (but arguably less fun, and likely more expensive).

If I take a conservative guess at our scale, a $5/mo Digital Ocean or Linode box would probably do the trick. We're mostly serving static content at this point, with authentication being the next "interactive" component we build out. We can probably get quite far with a single box and a SQLite database running on the same machine for persistence.

We absolutely should not roll our own auth, but we can use that component of Firebase separately to their storage (it looks like it's priced separately too).

[tran-christian]

Hi @disposedtrolley,

Hopefully I can answer your questions:

Infrastructure

1. The current live pages for omshub.org and dev.omshub.org are being hosted off of Vercel right now. omshub.org for the main branch and dev.omshub.org for the development branch
2. In terms of user data/reviews, it's still in discussion but it seems like folks are in favor of having the database hosted on FireBase.
3. We currently do not have an infrastructure in-place for managing secrets. We can definitely discuss this when the time comes. Currently, Vercel handles all the deployment along with the secrets involved. When the time comes, you can also transfer ownership on that platform.

Deployment

1. The NextJS frontend is being deployed via Vercel. The repo was created off of a starter template and configured with Material UI.
2. Currently, the community hasn't discussed what time of rendering we want so we can leave that up for discussion.
3. Right now, I just have to environments: Dev and Prod where the branch that deploys to Prod site is protected with reviewers. We can add as many environments as we want in the future. I believe Vercel automatically creates subdomains for any branch in the repo.
4. I am definitely a fan too! Currently right now, that is what the repo is setup to do. I have it configured to build and deploy to dev.omshub.org when changes are made to dev and respectively for main (omshub.org). Only difference is that the main branch protected and requiring several reviewers.

Monitoring

1. That I don't know haha. I believe Vercel might have something included so I would look into that more. Discussions will be made with the community.
2. In terms of logging and error, Vercel has something included for the build and deploy process. It will also show during the deploy/build process on Github that it failed (red X next to recent commits)

[disposedtrolley]

Thanks @ctran4347, that’s really helpful!

It looks like Vercel is happily doing the heavy lifting for us right now. Am I correct in assuming that the branch deploys have been configured from Vercel’s end (I.e they’re monitoring our repo for changes to know when to deploy)?

[tran-christian]

Yes! Branch deploys are done on Vercel's end. We just have to specify the branch and the domain/subdomain as long as we have it in the configuration. Any changes will essentially reflect within a few minutes onto the respective sites. (omshub.org or dev.omshub.org)

[adamwespiser]

What's the argument for/against Firebase?
Would it be cheaper/more cost effective to either host a database, use a cloud database service, or something else?

My concern with Firebase is basically that we'll get hosed on server costs, run over the limit, then whoever owns the account will be personally on the hook. I understanding using Firebase would be easy, but we have the dev cycles, or at least the interest, to implement something a little more boring that could be cheaper in the long run.

[CBlumini]

What's the argument for/against Firebase? Would it be cheaper/more cost effective to either host a database, use a cloud database service, or something else?

My concern with Firebase is basically that we'll get hosed on server costs, run over the limit, then whoever owns the account will be personally on the hook. I understanding using Firebase would be easy, but we have the dev cycles, or at least the interest, to implement something a little more boring that could be cheaper in the long run.

So this is me being a noob. Is the idea with Firebase that it makes it easier to host our database? So the frontend is hosted by one company and then the database is hosted by another?

I hadn't head of it before so this was interesting to me: https://www.geeksforgeeks.org/firebase-introduction/

My point of reference right now is a Heroku site I've been working on where that houses the Dashboard I've built in dash and then the data eventually goes into a Postgre DB also hosted there. Maybe I am thinking too small when I think of what "backend" involves.

[awpala]

Among other things, firebase also streamlines things like single-sign on (e.g., via gmail account, etc.), which are otherwise more tedious to implement from scratch

[awpala]

But not strictly married to using firebase, it may be better to go with something like Linode or DigitalOcean. Definitely something we need to explore further...

[awpala]

Closing issue for relevance. We have elected to move forward with Firebase as of mid-to-late July 2022. We will benchmark usage/cost to determine its suitability for longer-term use (and have thus far attempted to optimize our data modeling and usage patterns accordingly in conformance to Firebase's stated cost models, which are relatively generous, even at the free tiers). However, due to lack of any substantial progress/activity on backend work as of early June 2022, there is no other feasible/suitable alternative as of this writing (i.e., up to this point, the stalled backend was a major blocker/bottleneck; at this point in time, it's either Firebase, or no site/project at all--in the latter case, the debate is moot either way!).

Along this line of reasoning, while keeping costs minimized is indeed a key design parameter/objective for the long term, Firebase vs. managed backend is a bit of a premature optimization at this point, practically speaking. Unless Firebase ends up costing more than $10-15/month or so (which, based on my initial calculations, is rather improbable)--which is still on par with what a server app + db hosting would cost anyways--sometimes it's just "better to pay the pros" to get rid of that burden/maintenance/overhead of managing the server/db, auth, etc. in the first place. But if we do eventually hit that level of usage (i.e., particularly during peak usage periods / post-semester review dumps), that will be "a good problem to have" (i.e., people are actually using the site in the first place) at that point...

Anecdotally, per more recent related discussions, the admin for UT-Austin's equivalent MSCSO review page indicated they are running on Firebase currently, and that their operating costs are practically negligible. That was actually what made the most compelling case for ditching a managed backend for Firebase in the first place, for the record...