Serverless Flarum

luceos

Making flarum serverless will close it down to only a limited number of people. Even worse than our decision to go with composer.

I feel a lot of effort is placed in discussing something which has no merit to flarum in the first place.

SteveSmith

luceos Which is why I said that this should be a different version of Flarum, which you could work on, once you have enough resources. And its not like this is not going to be the future. The cloud is already here and its not going anywhere, its just going to become bigger.

Do you think there is ANY, and I do mean ANY chance of the IT moving back to manually managed servers? That's like saying that regular TV stations are gonna come back into fashion and companies like Netflix are gonna fade away, or that music services like Spotify will fall out of fashion and we will go back to buying CDs and. This is not going to happen.

So my suggestion is nothing else but pointing out to you guys where the future lies. And if you do decide to go down this route, you will have 2 version of Flarum, and in the not so distant future, as technology moves forward, one will be scrapped in favor of the other.

Guess which one is going to be abandoned?

SteveSmith

Franz Well yeah, but its obviously more than that when you go full serverless, right? If you only focus on this one part, meaning you have a remote place where you make function calls, then you are still better off with lambdas because there is no server to manage. You publish and that's it.

As for being locked in, well you could use some framework to setup your infrastructure, like Serverless Framework which allows you to provision resources on different cloud services. Sure, some features are specific to certain services, but that's a small price to pay for the flexibility that you gain by sticking to one. And yes, there really is nothing to do with the servers when you start using lambdas. You literally write code and publish it. The rest is handled by the cloud provider.

https://aws.amazon.com/lambda/

So, your biggest concern then might be that you would be locked into a specific provider. I understand that and its a valid concern. But then again, if you do decide to go serverless, then you just have to pick one of the providers, and once you do, there's no reason not to stick with it. It's not like you'll be moving every 5 months to a different one and its not like Microsoft or Amazon are going anywhere soon.

Franz

SteveSmith That's like saying that regular TV stations are gonna come back into fashion

I do still see a lot of these around, don't you?

couldn't resist, sorry ?

jordanjay29

I'd like to add that Flarum is licensed under the MIT license, which makes it possible for someone to fork Flarum and make it compatible with whatever architecture they prefer. While I'm not trying to dismiss this discussion, far from it, it doesn't look like this is a direction that Flarum is inclined to head down considering two of our core developers have weighed in already. That doesn't mean it isn't possible at all, it just may mean that someone else, not our core devs, will need to develop this ability and bring it forth.

Honestly, I've seen a version of this with Sandstorm.io, but I'm not a big fan of it for dynamic, public-facing software. Sites that can be updated periodically by a single person or single group, like a blog, work better in this kind of situation than a community site like a forum. But that's just my take on it, I'm not against someone pursuing this for the benefit of those who prefer serverless architecture.

SteveSmith

jordanjay29 Which again, is why I said that if your team grows, you should consider it. I didn't say that all the hard work which was done on this forum should be scrapped and that the serverless version should be started from scratch. Forking it to a parallel version, some time in the future is the way to go in my opinion.

Franz Yup, that's a real thing and so is vinyl resurgence and I should know, since I'm an audiophile. ? But in both cases, the trend, that is the general trend of where things are headed, is obvious.

I hope I gave you guys something to think about.

Sanguine

SteveSmith Thanks for sparking this interesting discussion!

I like the abstraction from a developers perspective, but locking yourself into the power of the worlds biggest company (Amazon) feels abhorrent to me. If only there was a cross industry standardized interface for lambda execution...

Now I see why companies are moving their business apps en masse to aws (simple cost calculation) but open source developers are probably more concerned about ideals.

JoshyPHP

Sanguine open source developers are probably more concerned about ideals.

I think it's the other way around. The idea of an infinitely scalable web application that spins up server instances to match the current load is a pie in the sky. Most forums can run on a $5 / month cheapo hosting plan, their database doesn't exceed 1 GB and their biggest table will hardly reach a million rows.

This whole discussion sounds foreign to me because it's made up of highly hypothetical scenarios that don't seem to apply to anything related to web applications in general and Flarum in particular. I think there is an inverse relation between one's enthusiasm for something like the Serverless framework and the amount of code one produces.

SteveSmith

JoshyPHP Stories and assumptions aside, the serverless concept is being accepted with open arms by large corporations. That does not mean that it's the right way, but it points to where the future of development and hosting is.

I'm ready to accept that future, are you?

As far as Flarum goes, I think I've repeated myself many times and therefore, this will be the last time. Flarum might not necessarily gain on performance if it was implemented in the serverless fashion, but if you already have a large infrastructure, with many websites and databases, all built serverless, you will probably not go back to the server ways of doing things just to accommodate the use of Flarum.

My suggestion mostly has to do with what the future brings and that is cloud and serverless. If Flarum does not prepare for the future, that is pretty much just around the corner, it might be dead on arrival, and I'm willing to bet nobody here wants that.

This was a word to the wise, peace.

JoshyPHP

SteveSmith I'm sorry but it's all empty rhetoric. I still don't know what practical benefits there would be to Flarum.

Here's what it sounds like to me: the future is clearly in quantum computing so let's run Flarum on quantum computers. Sure, right now there aren't too many of them but you don't want to live in the past, do you?

SteveSmith

JoshyPHP is it possible that many large corporations simply went serverless for fun? There is a risk and an initial expense for them to switch their architecture, so saying there is no evidence and is in the realm of quantum computing is incorrect. Nobody is switching to QC, but they are to serverless.

The reason why they are switching is primarily for the cost benefit. Initial development and switching will cost you, but after that, you pay less, since you only pay for what you spend when it comes to service calls. There is no server for you to pay for. There is no server for you to maintain. How is that not a benefit?

BartVB

Changing a project like Flarum from it's current programming paradigm to serverless comes very close to a complete rewrite.

The ideas behind serverless are pretty fascinating and a good match for some services/organisations. But in my opinion Flarum is not one of them. A prime feature of Flarum is that it's written in PHP and that it can run on 'traditional' hosting without a lot of fuss. Everyone and their uncle can set up their own Flarum site as soon as running composer isn't needed anymore.

Serverless is a whole different ballgame. That paradigm certainly does have it's advantages but most of them do not apply to Flarum. The disadvantages do make a pretty big impact though. You would force everyone to either host their forum in the cloud or go through a very complex installation process. Tooling for developing serverless is close to non-existant. Debugging is difficult at best.

If Flarum was in the planning stage and if it was going to be a SaaS offering then serverless might be an option. But for 99% of Flarum's target audience such a move would not make sense.

SteveSmith

BartVB Serverless framework makes it easy to set up a serverless infrastructure. Have you not seen that the link was posted to it earlier?

And again, I clearly said that there should be no rewrite of Flarum, but a future fork of it, so that we have both a regular and a serverless version.

Please read the whole thread before replying, it's not that long.

JoshyPHP

SteveSmith If your argument is "others are doing so why not you?" then you can replace the Serverless framework with quantum computing and see that it's not a compelling one. Large corporations have invested millions into quantum computing but since it bears no relevance to an application such as Flarum it would be ludicrous to try to run it on a quantum computer.

The Serverless framework may be a good way to process some data or run some applications, but that's not what Flarum needs. Flarum doesn't need "automatic scaling" or "rapid deployment" on new server instances.

SteveSmith you pay less, since you only pay for what you spend when it comes to service calls. There is no server for you to pay for.

Those service calls that you pay for, what do you think serves them? A server, right? The server serves the service calls that you pay for. You effectively pay for a server. If your argument is that it costs less to be billed per-request rather than on a flat monthly rate, I'm open to the argument but I'll wait for you to publish the math.

SteveSmith There is no server for you to maintain.

What maintenance do you think an average PHP server requires?

SteveSmith

JoshyPHP QC is in its infancy, serverless is not. Research institutes have invested in RESEARCH of QC, not practical use. QC is not a proven technology, serverless is. Big difference. The same rules apply to Flarum as to any website. Both need to minimize costs.

You pay for the server while its running, that means 24h a day. In some cases, you can save up to 70%.

https://read.acloud.guru/how-going-serverless-helped-us-reduce-costs-by-70-255adb87b093

I don't know what maintenance PHP server requires, aside from any regular maintenance other web servers require, but it requires it none the less. Serverless does not. That's a fact, which can't be overlooked. And if I have a choice between maintenance and no maintenance, guess which one I'll choose?

JoshyPHP

This article describes an AI application that processes data in batches on literally hundreds of servers. Their new infrastructure reduced their server footprint to only "211 instances." Can we agree that it's very different from Flarum?

SteveSmith I don't know what maintenance PHP server requires, aside from any regular maintenance other web servers require, but it requires it none the less.

Ok, then let's talk about what you know. What regular maintenance do other web servers require that the Serverless framework would eliminate?

SteveSmith

JoshyPHP Yes, it's absolutely different. My point is serverless can cut costs. Let's not dispute that anymore. As for Flarum, the main point is to stay consistent. Why would I bother with setting up servers just to run a form, when I don't have to for anything else? Makes no sense.

Irrelevant, even though I already mentioned security, backups, etc... because thou need to take care of it whatever it is. None of that exists with serverless because there are no servers that you directly deal with to begin with!

JoshyPHP

SteveSmith My point is serverless can cut costs. Let's not dispute that anymore.

I don't dispute that changing infrastructure can reduce costs, I'm asking how it would apply to Flarum, an application that does not perform batch processing on a multitude of servers. So far I am unconvinced.

SteveSmith Why would I bother with setting up servers just to run a form, when I don't have to for anything else? Makes no sense.

The same argument applies to AWS or whichever cloud computing provider you would use. The Serverless framework currently supports 7 providers: AWS, Azure, OpenWhisk, Google Cloud, Kubeless, Spotinst and Webtasks. I do not believe that the people who want to host a Flarum instance are more likely to have an account on one of those providers than they are to have an account on a traditional web host such as HostGator.

SteveSmith Irrelevant, even though I already mentioned security, backups, etc... because thou need to take care of it whatever it is. None of that exists with serverless because there are no servers that you directly deal with to begin with!

Automated backups (database and/or server imaging) is a service that many web hosts sell as an option. Cloud computing providers sometimes offer it as an option, and sometimes bundle it with the service.

What maintenance related to security do you think need to take place?

jordanjay29

SteveSmith many of your arguments can be applied the same to SaaS. Which would be more compatible with Flarum, and I believe still may be one of Toby's future goals, to have a managed hosting solution so users can focus on running their forums instead of maintaining servers. This doesn't require new technology or a code rewrite, though, just a middle man to manage the servers for you.

SteveSmith

JoshyPHP I don't dispute that changing infrastructure can reduce costs, I'm asking how it would apply to Flarum, an application that does not perform batch processing on a multitude of servers. So far I am unconvinced.

It would apply like it applies to any other regular website. The main point, besides cost saving is streamlining your infrastructure for future use. No point in having diverse infrastructure when you can have everything simplified.

JoshyPHP The same argument applies to AWS or whichever cloud computing provider you would use. The Serverless framework currently supports 7 providers: AWS, Azure, OpenWhisk, Google Cloud, Kubeless, Spotinst and Webtasks. I do not believe that the people who want to host a Flarum instance are more likely to have an account on one of those providers than they are to have an account on a traditional web host such as HostGator.

This is your problem, you live only for the present while I'm talking about the future. Do you want Flarum to forever be used by individuals, or do you want it to become universally accepted? If you want it to be widespread, then you have to take into account corporations, and for them serverless is the future.

JoshyPHP Automated backups (database and/or server imaging) is a service that many web hosts sell as an option. Cloud computing providers sometimes offer it as an option, and sometimes bundle it with the service.

What maintenance related to security do you think need to take place?

And for all those additional things, you need to pay for. With serverless you don't, its already included. And if you're not noticing, with the inclusion of all these services, you are moving closer and closer to a serverless architecture. From self hosting, to a remote hosting, to cloud to SaaS and finally, serverless. I just took this train of thought to its logical limit, you still haven't.

jordanjay29 many of your arguments can be applied the same to SaaS. Which would be more compatible with Flarum, and I believe still may be one of Toby's future goals, to have a managed hosting solution so users can focus on running their forums instead of maintaining servers. This doesn't require new technology or a code rewrite, though, just a middle man to manage the servers for you.

Same as above, that's fine for now, but soon enough people will move more and more to serverless. That's where everything is pointing to. I'm simply showing you the way. Why stop at SaaS when you can enticipate the future with serverless?

BartVB And of course there are frameworks to ease development of serverless apps/platforms. But these are highly incompatible with how Flarum works today. Most of the backend would need to be replaced.

And as I said, which you haven't read or haven't understood, once there are enough dev resources for Flarum, it can be done as a parallel version along side regular Flarum.

BartVB Besides, there is a whole world between setting up a LAMP server with Flarum and going serverless. If you go with shared hosting the hosting provider will take care of server maintenance. And if you use containers with a cloud server you also don't have to worry about server stuff. That would also result in a highly scalable solution where you won't go down to 0 $/month if the site isn't used, but for a small site cost will be low.

Most cost savings with serverless are for larger services which need to scale up and down quite often.
Great, and if you agree with that's all fine and well, why not take one more step and go serverless?

BartVB Anyway. It all comes down to demand, project scope and development resources. As I see it currently demand for a serverless version of Flarum is low, it's not within scope according to @Franz and development resources are focussed on getting a 'traditional' stable version out the door. Of course you are free to fork the project or create a serverless version of the Flarum backend.

Unfortunately, I'm working on my own project, so I'm not the right person to go to. I'm here to point to the future.

BartVB

I did read the whole thread ofcourse ?
And of course there are frameworks to ease development of serverless apps/platforms. But these are highly incompatible with how Flarum works today. Most of the backend would need to be replaced.

Besides, there is a whole world between setting up a LAMP server with Flarum and going serverless. If you go with shared hosting the hosting provider will take care of server maintenance. And if you use containers with a cloud server you also don't have to worry about server stuff. That would also result in a highly scalable solution where you won't go down to 0 $/month if the site isn't used, but for a small site cost will be low.

Most cost savings with serverless are for larger services which need to scale up and down quite often.

Anyway. It all comes down to demand, project scope and development resources. As I see it currently demand for a serverless version of Flarum is low, it's not within scope according to @Franz and development resources are focussed on getting a 'traditional' stable version out the door. Of course you are free to fork the project or create a serverless version of the Flarum backend.

« Previous Page Next Page »