The discussion revolves around the possibility of running Discourse as a serverless application. rootsh3ll asks if it’s possible to run Discourse on AWS Lambda, inquiring about potential benefits such as performance, bandwidth, and cost. supermathie clarifies that “serverless” means relying on someone else’s server and notes that while it may be possible, Discourse isn’t designed for this setup and isn’t supported. InstanceOfMichael expresses interest in exploring this option, specifically with Google Cloud Run, but highlights several challenges that need to be addressed, including uploadables, MessageBus, and long polling setup for notifications.
I am quite new to this buzzword “serverless”.
All that I understand is that at minimum you need one server for any deployment. In serverless you just don’t have to manage the server side of things and only focus on code development.
Since Discourse is a SaaS, I wanted to know if it’s possible for Discourse to be run as serverless application?
Like on AWS Lambda? If yes what are the benefits over running on normal instances.
performance? bandwidth? cost?
Serverless just means “running on someone else’s server”. Kind of like calling takeout kitchenless.
In this case what serverless means is that you as the application owner don’t need to think about the server - the first example that comes to mind is probably Google App Engine.
While it may be possible with a lot of effort, Discourse isn’t expected to run this way and we don’t support it.
I’m interested in this, but it needs what could be a lot of work.
Google Cloud Run came out recently, instead of “Functions as a Service” it’s more like “Serverless Docker”.
I think the big issues that would need to be resolved are:
I’m assuming the current long polling setup for notifications is going keep your lambdas/cloud runs running past their timeouts, destroying all your bill savings.