Serverless Flarum

SteveSmith

JoshyPHP I don't see any resemblance to the serverless concept. And if you google this thing, you'll see that its an April Fool's joke.

Furthermore, assuming that it actually had anything to do with serverless, you argument still doesn't hold water. Just because something similar existed before doesn't somehow negate the progress the new concept has to offer. You could also say that Flarum is nothing new, 12 years ago it was called BBS Forums.

See how that makes no sense whatsoever?

JoshyPHP

SteveSmith I can't tell them apart. I have read the pitch from the website you linked and I understand the general idea behind the framework misleadingly named "Serverless" but if there wasn't a public repository for it I would believe it's a similar prank.

The Serverless manifesto reads a lot like a sales pitch for cloud hosting. A big selling point is that "as a developer you don’t have to think about those servers. You just focus on code." What does that even mean? PHP programmers write their software without spending a single moment thinking about the servers it will run on.

Maybe it's good for people who are developing in JavaScript and are having troubles deploying their application but I don't see any tangible benefit compared to the average PHP application.

Franz

SteveSmith Thanks for getting back.

Can you outline the steps we would need to take to make Flarum compatible with a serverless approach? If it means self-hosting Flarum isn't possible anymore, then I don't think it's going to happen. ?

SteveSmith

Well, I don’t know the architecture of Flarum so I can’t say what steps exactly but what I can do is tell you how its usually done. Please observe the diagram.

https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcS1oeknjwKVKnUSVm5z2hcctIDNcLfjM6RGRk20-3anCIZfpV0VTB25GafrLA

First things first, you place your static content, and javascript in an Amazon S3 bucket, which is simply a key-value store. This is where you actually host your forum, by simply enabling the web hosting option.
You then enable the API Gateway which will be used to communicate with the backend. Meaning, any clicks, posts, edits on the forum will be channeled here.
Your PHP code goes into AWS Lambdas. These are nothing other than functions you can execute on demand. Yes, you actually write PHP code, publish it and invoke it as a service. This is why its called FaaS, short for Function as a Service. These will be invoked by your API Gateway.
Any Lambda invocations, which represent data in posts, user info, etc… will go into the DynamoDB, which is a document store. Instead of having a relational database, you simply store your posts as documents.

Everything from then on is provisioned for you, security, auto scaling of servers, distributed lambda execution with respect to user count, etc. Furthermore, if you want to include GraphQL, then AWS actually offers a managed GraphQL + Apollo service called AWS Appsync. Have a look at the following video. And let me know whether this looks promising to you. I believe it simplifies development and the interaction between frontend and backend a lot.

And just for the record, I do not think you should proceed with this approach any time soon, unless you have a dedicated team of people to do it. My initial suggestion was to just let you guys know where things are moving to and what you could do in the future. I see no reason why, if your dev team grows large enough, you wouldn’t cater to the serverless community as well and simply fork Flarum so that you have a serverless version too.

Franz

SteveSmith Your PHP code goes into AWS Lambdas. These are nothing other than functions you can execute on demand. Yes, you actually write PHP code, publish it and invoke it as a service. This is why its called FaaS, short for Function as a Service. These will be invoked by your API Gateway.

Honest question: What is the conceptual difference to having a bunch of PHP files (instead of a single front controller) on a public web directory? The "on-demand execution" would then just be a HTTP request to exactly this file...

SteveSmith And let me know whether this looks promising to you. I believe it simplifies development and the interaction between frontend and backend a lot.

Well... from my current level of ignorance, it looks to me as though the "traditional" way of building PHP applications means anybody can deploy it on any type of server, and tune it to their wishes. (Yes, making things scalable requires extra effort and knowledge - but I doubt that that can be avoided when going serverless.) With serverless, it looks like you're locked in to a specific cloud ecosystem?

SteveSmith

JoshyPHP Then you have a bunch of bad developers. If you don't think where your code will run, how can you write code in the first place? How do you write a function which allocates 64 GB of ram, when you only have available 32GB. Please, let me know, I would really like to know how you pull that off.

Franz

Please keep this discussion to the benefits / feasability of making Flarum compatible with the serverless approach.

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.

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?

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?

« Previous Page Next Page »