4 ms·

Also a common spec for serverless is badly needed. Serverless code should be portable between different cloud providers, otherwise there's vendor lock in and mu

Also a common spec for serverless is badly needed. Serverless code should be portable between different cloud providers, otherwise there's vendor lock in and much greater opportunity to price gouge. Anybody know if a common API for serverless components is being worked on?

gardnr 5y ago
There's the serverless framework which is easy to use and there is terraform which is more powerful. Relevant: https://xkcd.com/927/ https://xkcd.com/927/
- huijzer 5y ago
  It doesn’t avoid vendor lock-in. Instead of a cloud provider, it is now Terraform.
phphphphp 5y ago
Check out knative, it’s used for Google Cloud Run: https://knative.dev/docs/ https://knative.dev/docs/
- algorithmmonkey 5y ago
  What is the common spec for Knative? It seems like one runs an app as normal in a container and then the special scaling sauce is handled by Knative. When I think of a portable spec for serverless, I think of something more like a Trait of an Interface that needs to be implemented, less a app hosting model. If you think about it like that, then Web Assembly component model [1] would be a great fit for defining an interface that could be implemented in a variety of languages. [1]: https://github.com/WebAssembly/component-model/blob/main/design/high-level/Goals.md https://github.com/WebAssembly/component-model/blob/main/des...
  - adam_arthur 5y ago
    Yes, exactly. Of course experimentation and competition is good to settle on a solid set of building blocks, but in the long run serverless code should absolutely be portable between vendors. There's a strong incentive for vendors to not allow this as it reduces their pricing power... But think we will see it eventually one way or another.
  - spankalee 5y ago
    That would only be implementable by languages with a WASM output target though. Knative says that any container that responds to HTTP will work, and you could host those in different environments. It's much more general.

gardnr 5y ago

There's the serverless framework which is easy to use and there is terraform which is more powerful. Relevant: https://xkcd.com/927/ https://xkcd.com/927/

huijzer 5y ago
It doesn’t avoid vendor lock-in. Instead of a cloud provider, it is now Terraform.

phphphphp 5y ago

Check out knative, it’s used for Google Cloud Run: https://knative.dev/docs/ https://knative.dev/docs/

algorithmmonkey 5y ago
What is the common spec for Knative? It seems like one runs an app as normal in a container and then the special scaling sauce is handled by Knative. When I think of a portable spec for serverless, I think of something more like a Trait of an Interface that needs to be implemented, less a app hosting model. If you think about it like that, then Web Assembly component model [1] would be a great fit for defining an interface that could be implemented in a variety of languages. [1]: https://github.com/WebAssembly/component-model/blob/main/design/high-level/Goals.md https://github.com/WebAssembly/component-model/blob/main/des...
- adam_arthur 5y ago
  Yes, exactly. Of course experimentation and competition is good to settle on a solid set of building blocks, but in the long run serverless code should absolutely be portable between vendors. There's a strong incentive for vendors to not allow this as it reduces their pricing power... But think we will see it eventually one way or another.
- spankalee 5y ago
  That would only be implementable by languages with a WASM output target though. Knative says that any container that responds to HTTP will work, and you could host those in different environments. It's much more general.