3 ms·
Because the main premise of "serverless" is function-as-a-unit-of-deployment, it's actually quite suited for distributed computing and works quite well in decen
by ewindisch 10y ago
Because the main premise of "serverless" is function-as-a-unit-of-deployment, it's actually quite suited for distributed computing and works quite well in decentralized architectures. Using serverless, it's easier than ever to build "hybrid" clouds constructed of resources both locally and on public clouds (Google, Amazon, Azure, BlueMix, and others).
We can even deploy that code to IoT devices and embed it inside of desktop and mobile apps.
Serverless frees us from lock-in, but it does not have its own state, so it's easy to become locked into various web services. However, it's also easy enough to rely on your services (microservices) for state, avoiding lockin to other IaaS/SaaS products.
- Joeri 10y agoUnless and until there is a standard for function-as-a-service so you can move your functions between services at a moment's notice, you're very much locked in; and locked in without any guarantees of quality of service.
- ewindisch 10y agoI am involved daily in precisely an effort to do just this. The differences between the big 3-4 providers is relatively marginal (call arguments and versions of interpreters such as NodeJS). Take it as a plug if you must, but being able to handle the former is one of the goals of https://github.com/iopipe/iopipe https://github.com/iopipe/iopipe. The version of language runtimes is where the most lock-in will occur, and really, that's kinda marginal, too. Language runtimes should be as stable and standard as, say, the Linux kernel's userland interface. If language runtimes can't deal with this, then they'll fail.