7 ms·

> mainly as a weapon against rising cloud deployment costs. Cloud Functions is literally code you're running in the cloud. And the moment you approach their li

> mainly as a weapon against rising cloud deployment costs. Cloud Functions is literally code you're running in the cloud. And the moment you approach their limit(ation)s, you will see the same "rising cloud deployment costs" > Running a WASM engine on the cloud means ... a fraction of the overhead of a container or nodejs environment You do realise that there are other languages than javascript in nodejs? That there other environments than cloud functions? And that you can skip that overhead entirely by running with a different language in a different environment? Or even run Rust in AWS Lambda if you so wish? > so there’s no lock-in with the language that the Serverless provider mandates. And at the same time you're advertising for a runtime lock in. This doesn't compute. > Web pages that are as ancient as the early 90s are perfectly rendered even today... Basically, it means a WASM binary is future proof by default. It's not future proof. Web Pages from the 90s are not actually rendered perfectly today because browsers didn't agree on a standard rendering until late 2000s, and many web pages from the 90s and 2000s were targeting a specific browser's feature set and rendering quirks. Web Pages from the 90s are rendered good enough (and they had few things to render to begin with). As web's standards approach runaway asymptotical complexity, their "future-proofness" is also also questionable. Chrome broke audio [1], browsers are planning to remove alert/confirm/prompt [2], some specs are deprecated after barely seeing the light of day [3], some specs are just shitty and require backtracking or multiple additional specs on top to fix the most glaring holes, etc. > I've published my (ranty) notes on why Serverless will eventually replace Kubernetes as the dominant software deployment technique "Let's replace somewhat unlimited code with severely limited, resource constrained code running in a slow VM in a shared instance" is not a good take. [1] https://www.usgamer.net/articles/google-chromes-latest-update-broke-a-bunch-of-browser-games https://www.usgamer.net/articles/google-chromes-latest-updat... [2] https://dev.to/richharris/stay-alert-d https://dev.to/richharris/stay-alert-d [3] https://chromestatus.com/feature/4642138092470272 https://chromestatus.com/feature/4642138092470272 and https://www.w3.org/TR/html-imports/ https://www.w3.org/TR/html-imports/

atoav 5y ago
I sought to unserstand "serverless" but every deployment diagram I have ever seen show things that look an aweful lot like they run on... servers? Maybe I don't get the idea (and honestly I was too lazy to put in the legwork), but when I hear something like "serverless" I imagine some p2p javascript federated decentralized beast where the shared state is stored through magic and tricks with the users clients and there is literally no server anywhere to be found. Instead it seems like a buzzword (?) for a weirdly niche way of running things that someone with a 4 Euro/Month nginx instance that hosts 10 websites will probably never understand. Maybe I also don't need to understand because I know how to leverage static content, caching, fast Rust reverse proxy services and client side javascript to develope fast web stuff that gets the job done).
- dmitriid 5y ago
  > Instead it seems like a buzzword (?) for a weirdly niche way of running things that someone with a 4 Euro/Month nginx instance that hosts 10 websites will probably never understand. That's exactly it. It's a way to intermittently run a piece of code in a managed environment. You're basically guaranteed that the environment is setup, and that the code will start up and execute. That is basically it. People are extremely enamoured with it, for no apparent reason. The only usecase I've found for myself so far is running small analytics BigQuery queries to look for easily detectable anomalies once a day and send a Slack message if something's wrong. This way you avoid etting up a separate Kubernetes job etc. Makes no sense outside of GCP.
- ithkuil 5y ago
  "Server" can mean many things. A few (obvious) meanings: * A role in the client-server model. One machine makes requests and asks for info or things to be done, and the other end executes the request. * The physical (or virtual) machine that runs the processes that fulfill the server role * A class of "serious" machines that do important stuff somewhere not directly facing the end user (desktop or mobile device). * A unit of administration: the thing you log in with ssh, install/update software, rotate logs, organize user accounts on, create groups, handle file permissions, craft backup scripts, cron jobs, handle disk space, and generally care about filesystem health etc etc etc As you correctly pointed out, the "serverless" buzzword clearly talks about code that has to run on some machine, which is not your desktop or mobile device, so it's still about the client-server model and it's still running in servers, which ultimately have ti be administered by somebody somehow. The "less" suffix in the buzzword means that that person is not you. You don't have to manage the server. It's hard to find a better word. Sysadminless? NoPet? JustRunIt? FocusOnMyCode? All names have their drawbacks. My main qualm with serverless is not that there are servers involved, but that it's not clear what is serverless and what it's not. For example, is kubernetes a serverless platform? As a user if it (not an admin) you don't need to worry about any of the good old sysadmin chores, i.e. you don't manage the actual servers where your code runs. Otoh generally when people talk about serverless they don't talk about abstractions like kubernetes but usually about going on step further in the abstaction ladder and imagine a world that's not only "serverless" but "processless", where you don't build software and deploy it somewhere but where you write some "functions" and map of them to some endpoint and the system takes care of figuring out how to build, deploy and manage the full lifecycle.

atoav 5y ago

I sought to unserstand "serverless" but every deployment diagram I have ever seen show things that look an aweful lot like they run on... servers? Maybe I don't get the idea (and honestly I was too lazy to put in the legwork), but when I hear something like "serverless" I imagine some p2p javascript federated decentralized beast where the shared state is stored through magic and tricks with the users clients and there is literally no server anywhere to be found. Instead it seems like a buzzword (?) for a weirdly niche way of running things that someone with a 4 Euro/Month nginx instance that hosts 10 websites will probably never understand. Maybe I also don't need to understand because I know how to leverage static content, caching, fast Rust reverse proxy services and client side javascript to develope fast web stuff that gets the job done).

dmitriid 5y ago
> Instead it seems like a buzzword (?) for a weirdly niche way of running things that someone with a 4 Euro/Month nginx instance that hosts 10 websites will probably never understand. That's exactly it. It's a way to intermittently run a piece of code in a managed environment. You're basically guaranteed that the environment is setup, and that the code will start up and execute. That is basically it. People are extremely enamoured with it, for no apparent reason. The only usecase I've found for myself so far is running small analytics BigQuery queries to look for easily detectable anomalies once a day and send a Slack message if something's wrong. This way you avoid etting up a separate Kubernetes job etc. Makes no sense outside of GCP.
ithkuil 5y ago
"Server" can mean many things. A few (obvious) meanings: * A role in the client-server model. One machine makes requests and asks for info or things to be done, and the other end executes the request. * The physical (or virtual) machine that runs the processes that fulfill the server role * A class of "serious" machines that do important stuff somewhere not directly facing the end user (desktop or mobile device). * A unit of administration: the thing you log in with ssh, install/update software, rotate logs, organize user accounts on, create groups, handle file permissions, craft backup scripts, cron jobs, handle disk space, and generally care about filesystem health etc etc etc As you correctly pointed out, the "serverless" buzzword clearly talks about code that has to run on some machine, which is not your desktop or mobile device, so it's still about the client-server model and it's still running in servers, which ultimately have ti be administered by somebody somehow. The "less" suffix in the buzzword means that that person is not you. You don't have to manage the server. It's hard to find a better word. Sysadminless? NoPet? JustRunIt? FocusOnMyCode? All names have their drawbacks. My main qualm with serverless is not that there are servers involved, but that it's not clear what is serverless and what it's not. For example, is kubernetes a serverless platform? As a user if it (not an admin) you don't need to worry about any of the good old sysadmin chores, i.e. you don't manage the actual servers where your code runs. Otoh generally when people talk about serverless they don't talk about abstractions like kubernetes but usually about going on step further in the abstaction ladder and imagine a world that's not only "serverless" but "processless", where you don't build software and deploy it somewhere but where you write some "functions" and map of them to some endpoint and the system takes care of figuring out how to build, deploy and manage the full lifecycle.