3 ms·

What kind of evil genius devised a term that suggests peer-to-peer, to describe something that relies more than ever before on central services and authorities?

What kind of evil genius devised a term that suggests peer-to-peer, to describe something that relies more than ever before on central services and authorities? It feels like "intellectual property" all over again —which suggests the rules used for rival goods can be used for ideas, hence ignoring the difference between moving and copying.

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 ago
  Unless 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 ago
    I 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.

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 ago
Unless 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 ago
  I 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.