5 ms·

I'm still trying to figure out the benefit that "serverless" architecture offers over a simple Apache + PHP + Sqlite setup. PHP isn't my favorite language, but

by sea6ear 10y ago

I'm still trying to figure out the benefit that "serverless" architecture offers over a simple Apache + PHP + Sqlite setup. PHP isn't my favorite language, but it's deployment story seems as good as a lot of these "serverless" solutions once set up (which takes 5-10 minutes on Ubuntu). Unless you need the scaling potential of the "serverless" platform, or are completely unwilling to setup/maintain a simple $5 a month VPS, I don't see much benefit to the platform lockin of a specialized service, when there is a boring but predictable way to achieve the same thing, with the same (or possibly less effort). Once PHP is set up the process seems like it would be: 1. write your page to accept the query parameters or post data and return the results (the page is the function essentially). 2. Use SQLite for storage (either per user or per "function" maybe?). Other storage options are also fine, but SQLite is pretty simple and flexible. 3. Deploy the .php file using scp or sftp to your /var/www/whatever directory. At this point you're done and can call your "function" via http.

niftich 10y ago
The draw is another buzzword: "NoOps" -- in that you spend no time managing the actual environment. Instead, there is just code and nothing but the code.
- sea6ear 10y ago
  Maybe I'm stuck in the "sunk costs" fallacy (that is, I've already invested the time to learn how to do this, so it seems trivial to me), but to me once I've done the 15 minutes "setup", I can basically ignore the server, and at that point basically the code is the only thing to deal with. I don't spend much time "maintaining" my server for this kind of setup. Once it's setup I basically ignore it, accept for uploading new code. I suppose I do occassionally run the system update command. I don't run any other kinds of PHP applications (WordPress, Drupal, etc) on an environment that I use this way, so I don't feel the constant need to check for security vulnerabilities.
  - niftich 10y ago
    You can basically ignore that server, until your basically ignored server goes down or breaks for some silly reason unknown to you in advance. At that point, you have to intervene, troubleshoot, and fix the problem. But if you had gone the Functions-as-a-Service route, you'd avoid such occurrences altogether. For some people, that's an appealing trade-off.
    - sea6ear 10y ago
      Ok, that's a fair point. I feel like I have the skills to handle that, or to create redundancy if necessary for reliability, so that doesn't bother me, but I can see the appeal of ignoring all of that. I still like the idea that I'm not trusting a "black box" to run my code. I know how it's set up and what it's doing. And if I add replication or load balancing, I also understand what's actually happening there. But you're right, once you get to that level, you're out of the realm of "simple". Maybe I can still hide behind my earlier comment "unless you need the scalability..." to say that covered your caveats, but I'll admit I wasn't explicit about the considerations that guide the optimal use cases.

by sea6ear 10y ago

niftich 10y ago

The draw is another buzzword: "NoOps" -- in that you spend no time managing the actual environment. Instead, there is just code and nothing but the code.

sea6ear 10y ago
Maybe I'm stuck in the "sunk costs" fallacy (that is, I've already invested the time to learn how to do this, so it seems trivial to me), but to me once I've done the 15 minutes "setup", I can basically ignore the server, and at that point basically the code is the only thing to deal with. I don't spend much time "maintaining" my server for this kind of setup. Once it's setup I basically ignore it, accept for uploading new code. I suppose I do occassionally run the system update command. I don't run any other kinds of PHP applications (WordPress, Drupal, etc) on an environment that I use this way, so I don't feel the constant need to check for security vulnerabilities.
- niftich 10y ago
  You can basically ignore that server, until your basically ignored server goes down or breaks for some silly reason unknown to you in advance. At that point, you have to intervene, troubleshoot, and fix the problem. But if you had gone the Functions-as-a-Service route, you'd avoid such occurrences altogether. For some people, that's an appealing trade-off.
  - sea6ear 10y ago
    Ok, that's a fair point. I feel like I have the skills to handle that, or to create redundancy if necessary for reliability, so that doesn't bother me, but I can see the appeal of ignoring all of that. I still like the idea that I'm not trusting a "black box" to run my code. I know how it's set up and what it's doing. And if I add replication or load balancing, I also understand what's actually happening there. But you're right, once you get to that level, you're out of the realm of "simple". Maybe I can still hide behind my earlier comment "unless you need the scalability..." to say that covered your caveats, but I'll admit I wasn't explicit about the considerations that guide the optimal use cases.