4 ms·

Then why not call it “scalable”, “elastic”? All these neologisms are tiring.

derefr 4y ago
The other key feature of "serverless" is that the store-of-record for a "serverless" system isn't a part of the running system — i.e. the system's state doesn't live on any particular server / cluster that is run as part of the operations of the system. Instead, a "serverless" system's store-of-record is some external and semantically-abstracted storage system — e.g. "a remote git repository" (GitOps); "an object-storage bucket" (Snowflake); "a document store" (Lambda); "a blockchain"; etc. Where all that's important about this storage system is its API, such that the design is portable to any backing storage service that supports the same API. This means that, in serverless systems, the mutable state in the cluster is just an ephemeral cache representation of the externally-managed data-at-rest. Another way to think about this is by thinking of "a server" as a thing with durable state that you have to worry about — e.g. protect from disk corruption, make backups of, etc; vs. something like "an ephemeral immutable-infrastructure container workload" that can die and be recreated with no problems. Serverless systems are systems without any "servers" in this sense — nothing to back up; nothing to disaster-recover; etc. Nobody operating these systems ever needs to think about individual servers. Nobody ever needs to SSH into a server, upgrade a server, restart a server, etc. The operations for such systems can be handled entirely at the "cluster" and "ephemeral workload" levels. Nodes within the cluster that "go bad" can simply be drained and deleted — this may even be automated. And further, because of this lack of local durable state, there's no need to worry about "allocating" that state, and thereby allocating customers to particular clusters. Serverless compute clusters are usually just one huge cluster (per region), where customers' individual request workloads just get scheduled onto that cluster wherever they'll fit. Of course, the external store-of-record for a serverless system must have "servers" — the data-at-rest ultimately has to reside durably on some disk somewhere. But 1. they're not your servers, and their ops problems are not your ops problems; and 2. because they're a much lower-level abstraction, they can scaled much more robustly, and so can have far fewer operational problems in the first place; and 3. because they're a much lower-level abstraction, they benefit from economies-of-scale in shared tenancy in ways domain-specific compute/DBMS/etc. clusters usually don't; and so your system can benefit from a storage layer that's hyperscaled + hyper-robust from serving millions of tenants' low-level needs.
derefr 4y ago
Also, simpler answer than I already gave: “elastic” and “scalable” X don’t imply a lack of committed resources, but rather just a control plane that auto-scales your commitment to ensure that you’ve always got more than you need. E.g. AWS Elastic File Store: an auto-resizing NAS-like abstraction, but at any given point, a committed size where you’re paying for unused space. Vs. Amazon S3 (which might as well stand for “serverless storage service”) — where you only pay for what you use, with no committed capacity beyond current usage.
ignoramous 4y ago
Marketing doesn't care about your personal preferences :) And Marketing is King, for bottom-up SaaS businesses (businesses selling to individual developers), which most companies open-sourcing their core projects most often are.

The other key feature of "serverless" is that the store-of-record for a "serverless" system isn't a part of the running system — i.e. the system's state doesn't live on any particular server / cluster that is run as part of the operations of the system. Instead, a "serverless" system's store-of-record is some external and semantically-abstracted storage system — e.g. "a remote git repository" (GitOps); "an object-storage bucket" (Snowflake); "a document store" (Lambda); "a blockchain"; etc. Where all that's important about this storage system is its API, such that the design is portable to any backing storage service that supports the same API. This means that, in serverless systems, the mutable state in the cluster is just an ephemeral cache representation of the externally-managed data-at-rest. Another way to think about this is by thinking of "a server" as a thing with durable state that you have to worry about — e.g. protect from disk corruption, make backups of, etc; vs. something like "an ephemeral immutable-infrastructure container workload" that can die and be recreated with no problems. Serverless systems are systems without any "servers" in this sense — nothing to back up; nothing to disaster-recover; etc. Nobody operating these systems ever needs to think about individual servers. Nobody ever needs to SSH into a server, upgrade a server, restart a server, etc. The operations for such systems can be handled entirely at the "cluster" and "ephemeral workload" levels. Nodes within the cluster that "go bad" can simply be drained and deleted — this may even be automated. And further, because of this lack of local durable state, there's no need to worry about "allocating" that state, and thereby allocating customers to particular clusters. Serverless compute clusters are usually just one huge cluster (per region), where customers' individual request workloads just get scheduled onto that cluster wherever they'll fit. Of course, the external store-of-record for a serverless system must have "servers" — the data-at-rest ultimately has to reside durably on some disk somewhere. But 1. they're not your servers, and their ops problems are not your ops problems; and 2. because they're a much lower-level abstraction, they can scaled much more robustly, and so can have far fewer operational problems in the first place; and 3. because they're a much lower-level abstraction, they benefit from economies-of-scale in shared tenancy in ways domain-specific compute/DBMS/etc. clusters usually don't; and so your system can benefit from a storage layer that's hyperscaled + hyper-robust from serving millions of tenants' low-level needs.

derefr 4y ago

Also, simpler answer than I already gave: “elastic” and “scalable” X don’t imply a lack of committed resources, but rather just a control plane that auto-scales your commitment to ensure that you’ve always got more than you need. E.g. AWS Elastic File Store: an auto-resizing NAS-like abstraction, but at any given point, a committed size where you’re paying for unused space. Vs. Amazon S3 (which might as well stand for “serverless storage service”) — where you only pay for what you use, with no committed capacity beyond current usage.

ignoramous 4y ago

Marketing doesn't care about your personal preferences :) And Marketing is King, for bottom-up SaaS businesses (businesses selling to individual developers), which most companies open-sourcing their core projects most often are.