Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is interesting, but having been down the "serverless" road a number of times in different languages (mostly node.js and ruby) I've found it to be more complex to manage all the services rather than just using RDS and a container orchestrator (these days I'm all in on K8s. I'm happy to explain why if there is interest, but I'm not advocating using it for everything so plz don't flame me) and all the framework features of my chosen platform (currently in love with Elixir/Phoenix).

It also wouldn't help much with the primary PHP challenge I've run across, that of a stateful Wordpress box (and to be fair, the article doesn't claim to help with that. It assumes a 12-factor app). Most PHP I've had to deal with is not stateless, thus making horizontal scaling a challenge. Luckily you can scale pretty far vertically with PHP as long as you haven't made Big O mistakes.



What do you mean by "Most PHP ... is not stateless"?

Usually, the state of PHP app is in the DB. Other "state data" are: 1) sessions. By default saved in files, can be moved to DB, making PHP stateless 2) storage (i.e. user's attachments). To decouple from PHP server, - need to switch to object storage service.

So, it's not hard.

But most popular PHP application - WordPress if failing to be stateless, because of number 2: it uses local storage for plugins, media, user's data.


> To decouple from PHP server, - need to switch to object storage service.... So, it's not hard.

If you are the developer of the app, that's true. If you're the ops guy to whom the app was lobbed over the wall to, it's not quite that simple without making code changes to the app. In the case of Wordpress also, it's been my experience that many of the "developers" are just marketing people and don't actually write code. These people are not equipped to remove state from the app either.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: