4 ms·

To me, the definition of Serverless is this: Developer writes code and the management of resources for running that code is taken care of by a Serverless platfo

To me, the definition of Serverless is this: Developer writes code and the management of resources for running that code is taken care of by a Serverless platform. As a developer, I don't have to deal with servers, disks, networks, logs, metrics, ...

doubleplusgood 9y ago
So your code assumes that the network/storage/DB are fault-free? You don't emit logs?
- obulpathi 9y ago
  > You don't emit logs? I emit logs. I mentioned that in my above comment as well. > So your code assumes that the network/storage/DB are fault-free? No, it does not assume that the network/storage/DB are fault-free, completely. It assumes they are fault free with the SLA limits provided by your Cloud provider. The software is written in a way that enables the platform to know about errors when then happen and remediate them. Like, when you build a website, you make the app serving layer stateless and choose a backend datastore that is replicated across regions and is highly available (like Cloud Datastore or Spanner). If your platform detects that a disk failed and your app is returning errors, then that instance is killed and an another instance is brought up. Very similar mechanisms exist for the above-mentioned data services as well for auto scaling, sharding, ... If your Cloud provider can not guarantee the SLA's or shows a green sign even when the service is down, IMO they are not competent enough.
takeda 9y ago
> As a developer, I don't have to deal with servers, disks, networks, logs, metrics, ... Yes, until things don't work as they supposed to. Disks and networks also don't matter if your application is simple. Disks are pointless if you don't keep a state. Networks will suddenly matter more when you start hiring its capacity. If your application is simple, you can also run it on a single machine and don't care about any of the things you listed. But just because those things were abstracted from you doesn't mean they don't exist and their limitations don't apply.

doubleplusgood 9y ago

So your code assumes that the network/storage/DB are fault-free? You don't emit logs?

obulpathi 9y ago
> You don't emit logs? I emit logs. I mentioned that in my above comment as well. > So your code assumes that the network/storage/DB are fault-free? No, it does not assume that the network/storage/DB are fault-free, completely. It assumes they are fault free with the SLA limits provided by your Cloud provider. The software is written in a way that enables the platform to know about errors when then happen and remediate them. Like, when you build a website, you make the app serving layer stateless and choose a backend datastore that is replicated across regions and is highly available (like Cloud Datastore or Spanner). If your platform detects that a disk failed and your app is returning errors, then that instance is killed and an another instance is brought up. Very similar mechanisms exist for the above-mentioned data services as well for auto scaling, sharding, ... If your Cloud provider can not guarantee the SLA's or shows a green sign even when the service is down, IMO they are not competent enough.

takeda 9y ago

> As a developer, I don't have to deal with servers, disks, networks, logs, metrics, ... Yes, until things don't work as they supposed to. Disks and networks also don't matter if your application is simple. Disks are pointless if you don't keep a state. Networks will suddenly matter more when you start hiring its capacity. If your application is simple, you can also run it on a single machine and don't care about any of the things you listed. But just because those things were abstracted from you doesn't mean they don't exist and their limitations don't apply.