6 ms·

> developers can produce generic code There is nothing generic about the code that runs on serverless services. It’s the ultimate lock in.

reilly3000 6y ago
Most actual FaaS code is quite portable; the configuration is what can’t move easily. And things like OpenFaaS and kNative make self-hosted runtimes completely flexible- it’s just a short-lived container.
jfoster 6y ago
At the moment. Is there anything stopping an organisation from defining some standard types of serverless environments? Is there anything stopping someone from turning that standard into implementations to help cloud providers offer it, or even be a fallback option that could be deployed on any generic cloud infrastructure? I think those are the way forward from here.
- technimad 6y ago
  That standard could be something like CloudABI [1] which already exists, but is too limited (no networking) to replace generic serverless workloads. [1] https://lwn.net/Articles/674770/ https://lwn.net/Articles/674770/
- toyg 6y ago
  The point of serverless for vendors is lock-in. Everything else about it is an annoyance, from their side (having to manage lifecycle, controlling load in shared engines, measuring resource usage...). But it locks people in and can be slapped with basically-arbitrary prices. The incentives to set standards are exactly zero, because once all providers support them and easy portability is achieved, it becomes a race to the bottom on price. Unless vendors can come up with some extra value-added service on top and choose to commoditize away the serverless layer, there won’t be any standard.
- rzwitserloot 6y ago
  > Is there anything stopping an organisation from defining some standard types of serverless environments? Yes. Basic economics. There is nothing _technical_ stopping 'an organisation' from making a federated twitter or facebook. But there are (evidently) insurmountable non-technical reasons: It hasn't happened / there have been attempts which have all effectively failed (in the sense that they have made no significant dent in these services' user numbers). Why would e.g. Amazon (AWS) attempt to form a consortium or otherwise work together or follow a standard, relegating their offerings to the ultimate in elasticity? Economically speaking, selling grain is a bad business: If someone else sells it for 1ct less per kilo then the vast majority of your customers will go buy from someone else, there's no product differentiation. Serverless lockin (such as GAE or AWS Lambda) is the opposite. No matter how expensive you make the service, your users will stay for quite a while. But make a universal standard and you fly in one fell swoop to the other end of the spectrum. If I have a serverless deployment and the warts of serverless are fixed (which would, presumably, involve the ability to go to my source repo, run a single command, give it some credentials, and my service is now live after some compilation and uploading occurs) - then if someone else offers it 1ct cheaper tomorrow I'll probably just switch for the month. Why not? This cycle can be broken; but you're going to have to paint me a picture on how this happens. Government intervention? A social movement amongst CEOs (After the war, there was a lot of this going around)? A social movement amongst users so aggressive they demand it? Possible, but that would require that we all NOT go to serverless until the services offering it come up with a workable standard and make commitments to it.
  - jfoster 6y ago
    I think it can happen simply through one serverless offering becoming very popular and other services (or open source projects) trying to reimplement the API of that offering. To some extent, this happened with Google App Engine. (AppScale) I think cloud customers are savvy to the lock-in. That we're having this conversation in evidence of that. Perhaps AWS can achieve adoption of Lambda without needing to cater to customers who are cautious about getting locked in, but any challenger might find that it's much easier to gain customers if they also provide some form of an escape hatch. As Jeff Bezos would say about retail, "your margin is my opportunity."
- chriswarbo 6y ago
  > Is there anything stopping an organisation from defining some standard types of serverless environments? We have some already, e.g. RFC3875 and its descendents https://tools.ietf.org/html/rfc3875 https://tools.ietf.org/html/rfc3875
methodin 6y ago
I disagree. Every AWS Lambda function I've ever written can be ran as a regular node/python process. The lambda-specific part is miniscule. If I wanted to run these on Azure or Google only the most inconsequential parts of the function would need to be changed.
- Lucasoato 6y ago
  Using a stack like serverless framework the amount of lock-in is negligible.
- michaelt 6y ago
  In my experience, having started and abandoned side projects in both aws lambda and google app engine, half your project becomes: * Well, obviously we use a hosted database * And obviously, AWS provides our logging and all our analytics. * Obviously when people call our lambda functions, they do so either through an AWS-specific API, or one constrained to a very limited set of forms. * Of course, we can't blindly let everything access everything, so naturally we have IAM roles and permissions for every lambda function. * Well, the cloud provider will look after secrets and things like that for us, no need for us to worry about database passwords. * Naturally, with all these functions and IAM roles to look after, and we need tagging for billing. We should define it all with CloudFormation scripting. * Well, the nosql database the they provide comes with their specific library. And as it shards things like this, and doesn't let you index things like that, you've got to structure your data this specific way if you want to avoid performance problems. * You don't want your function to take 200ms+ to respond, your users will notice how slow it is. So no installing things with apt-get or pip for you, let me get you a guide on how to repackage those into the vendor-specific bundle format. * You want to test your functions locally, with access to an interactive debugger? You're living in the past, modern developers deploy to a beta environment and debug exclusively with print statements. * And so on. In this case, a lot of the 'complexity' one hoped to eliminate has just been moved into XML files and weird console GUIs.
  - nicbou 6y ago
    This, but it was told by serverless experts, on stage, in front of hundreds of people. If that was their sales pitch, their reality was likely even less impressive.
dbergamin 6y ago
I don't agree, serverless code in itself tends to be portable. It's the surrounding services that lock you in.
- thinkharderdev 6y ago
  That depends a lot on the use case. The ephemeral nature of serverless environment generally require you to proprietary solutions by the cloud provider to have things like DB access and such. So you end up using DynamoDB instead of Postgres (as an example). You CAN make portable serverless code but it generally requires a fair amount of work to do so.
gorbypark 6y ago
I use Google Cloud Run to run my serverless code for exactly this reason. GCR is literally just a container that runs on demand (with scaling to 0). Literally the only GCR specific part is making sure the service listens on the PORT env. If I was so inclined, I could deploy the exact same container on any number of services, host it myself and/or run it on my laptop for development purposes. There's also Kubernetes Knative which is basically (afaik) self hosted GCR.
- jononor 6y ago
  How is the spin-up time for such a container?
  - nikon 6y ago
    In my experience pretty good, even for a Django app. I believe the container sticks around for a while and is throttled to 0 CPU.
  - Simon321 6y ago
    a few seconds apparently: https://thenewstack.io/comparison-aws-fargate-vs-google-cloud-run-vs-azure-container-instances/ https://thenewstack.io/comparison-aws-fargate-vs-google-clou...
  - ko5ta 6y ago
    It varies massively based on the tech stack. I have seen both simple Spring Boot and Quarkus apps take in excess of 10 seconds to start up in JVM mode. However, Quarkus compiled to native binary with GraalVM starts consistently under a second (in the ~500ms range). This is still brutal compared to running it on a vanilla MacBook which usually takes less than 20ms.
- Can_Not 6y ago
  Cloud Run is excellent if I wrote my own application. My biggest issue is that most off the shelf open source software that has a docker container often use a complicated docker compose file so if they can be deployed, they might be waiting on each other's cold starts (which can be very long and expensive) and/or need more databasesish things than I want. So obvious mistakes and unrealistic expectations aside, I have several nodejs and crystal apps on cloud run which is running well and just the concept "lambda for docker containers" is pretty awesome. Cold starts are pretty harsh ATM, hopefully they improve.

reilly3000 6y ago

Most actual FaaS code is quite portable; the configuration is what can’t move easily. And things like OpenFaaS and kNative make self-hosted runtimes completely flexible- it’s just a short-lived container.

jfoster 6y ago

At the moment. Is there anything stopping an organisation from defining some standard types of serverless environments? Is there anything stopping someone from turning that standard into implementations to help cloud providers offer it, or even be a fallback option that could be deployed on any generic cloud infrastructure? I think those are the way forward from here.

technimad 6y ago
That standard could be something like CloudABI [1] which already exists, but is too limited (no networking) to replace generic serverless workloads. [1] https://lwn.net/Articles/674770/ https://lwn.net/Articles/674770/
toyg 6y ago
The point of serverless for vendors is lock-in. Everything else about it is an annoyance, from their side (having to manage lifecycle, controlling load in shared engines, measuring resource usage...). But it locks people in and can be slapped with basically-arbitrary prices. The incentives to set standards are exactly zero, because once all providers support them and easy portability is achieved, it becomes a race to the bottom on price. Unless vendors can come up with some extra value-added service on top and choose to commoditize away the serverless layer, there won’t be any standard.
rzwitserloot 6y ago
> Is there anything stopping an organisation from defining some standard types of serverless environments? Yes. Basic economics. There is nothing _technical_ stopping 'an organisation' from making a federated twitter or facebook. But there are (evidently) insurmountable non-technical reasons: It hasn't happened / there have been attempts which have all effectively failed (in the sense that they have made no significant dent in these services' user numbers). Why would e.g. Amazon (AWS) attempt to form a consortium or otherwise work together or follow a standard, relegating their offerings to the ultimate in elasticity? Economically speaking, selling grain is a bad business: If someone else sells it for 1ct less per kilo then the vast majority of your customers will go buy from someone else, there's no product differentiation. Serverless lockin (such as GAE or AWS Lambda) is the opposite. No matter how expensive you make the service, your users will stay for quite a while. But make a universal standard and you fly in one fell swoop to the other end of the spectrum. If I have a serverless deployment and the warts of serverless are fixed (which would, presumably, involve the ability to go to my source repo, run a single command, give it some credentials, and my service is now live after some compilation and uploading occurs) - then if someone else offers it 1ct cheaper tomorrow I'll probably just switch for the month. Why not? This cycle can be broken; but you're going to have to paint me a picture on how this happens. Government intervention? A social movement amongst CEOs (After the war, there was a lot of this going around)? A social movement amongst users so aggressive they demand it? Possible, but that would require that we all NOT go to serverless until the services offering it come up with a workable standard and make commitments to it.
- jfoster 6y ago
  I think it can happen simply through one serverless offering becoming very popular and other services (or open source projects) trying to reimplement the API of that offering. To some extent, this happened with Google App Engine. (AppScale) I think cloud customers are savvy to the lock-in. That we're having this conversation in evidence of that. Perhaps AWS can achieve adoption of Lambda without needing to cater to customers who are cautious about getting locked in, but any challenger might find that it's much easier to gain customers if they also provide some form of an escape hatch. As Jeff Bezos would say about retail, "your margin is my opportunity."
chriswarbo 6y ago
> Is there anything stopping an organisation from defining some standard types of serverless environments? We have some already, e.g. RFC3875 and its descendents https://tools.ietf.org/html/rfc3875 https://tools.ietf.org/html/rfc3875

methodin 6y ago

I disagree. Every AWS Lambda function I've ever written can be ran as a regular node/python process. The lambda-specific part is miniscule. If I wanted to run these on Azure or Google only the most inconsequential parts of the function would need to be changed.

Lucasoato 6y ago
Using a stack like serverless framework the amount of lock-in is negligible.
michaelt 6y ago
In my experience, having started and abandoned side projects in both aws lambda and google app engine, half your project becomes: * Well, obviously we use a hosted database * And obviously, AWS provides our logging and all our analytics. * Obviously when people call our lambda functions, they do so either through an AWS-specific API, or one constrained to a very limited set of forms. * Of course, we can't blindly let everything access everything, so naturally we have IAM roles and permissions for every lambda function. * Well, the cloud provider will look after secrets and things like that for us, no need for us to worry about database passwords. * Naturally, with all these functions and IAM roles to look after, and we need tagging for billing. We should define it all with CloudFormation scripting. * Well, the nosql database the they provide comes with their specific library. And as it shards things like this, and doesn't let you index things like that, you've got to structure your data this specific way if you want to avoid performance problems. * You don't want your function to take 200ms+ to respond, your users will notice how slow it is. So no installing things with apt-get or pip for you, let me get you a guide on how to repackage those into the vendor-specific bundle format. * You want to test your functions locally, with access to an interactive debugger? You're living in the past, modern developers deploy to a beta environment and debug exclusively with print statements. * And so on. In this case, a lot of the 'complexity' one hoped to eliminate has just been moved into XML files and weird console GUIs.
- nicbou 6y ago
  This, but it was told by serverless experts, on stage, in front of hundreds of people. If that was their sales pitch, their reality was likely even less impressive.

dbergamin 6y ago

I don't agree, serverless code in itself tends to be portable. It's the surrounding services that lock you in.

thinkharderdev 6y ago
That depends a lot on the use case. The ephemeral nature of serverless environment generally require you to proprietary solutions by the cloud provider to have things like DB access and such. So you end up using DynamoDB instead of Postgres (as an example). You CAN make portable serverless code but it generally requires a fair amount of work to do so.

gorbypark 6y ago

I use Google Cloud Run to run my serverless code for exactly this reason. GCR is literally just a container that runs on demand (with scaling to 0). Literally the only GCR specific part is making sure the service listens on the PORT env. If I was so inclined, I could deploy the exact same container on any number of services, host it myself and/or run it on my laptop for development purposes. There's also Kubernetes Knative which is basically (afaik) self hosted GCR.

jononor 6y ago
How is the spin-up time for such a container?
- nikon 6y ago
  In my experience pretty good, even for a Django app. I believe the container sticks around for a while and is throttled to 0 CPU.
- Simon321 6y ago
  a few seconds apparently: https://thenewstack.io/comparison-aws-fargate-vs-google-cloud-run-vs-azure-container-instances/ https://thenewstack.io/comparison-aws-fargate-vs-google-clou...
- ko5ta 6y ago
  It varies massively based on the tech stack. I have seen both simple Spring Boot and Quarkus apps take in excess of 10 seconds to start up in JVM mode. However, Quarkus compiled to native binary with GraalVM starts consistently under a second (in the ~500ms range). This is still brutal compared to running it on a vanilla MacBook which usually takes less than 20ms.
Can_Not 6y ago
Cloud Run is excellent if I wrote my own application. My biggest issue is that most off the shelf open source software that has a docker container often use a complicated docker compose file so if they can be deployed, they might be waiting on each other's cold starts (which can be very long and expensive) and/or need more databasesish things than I want. So obvious mistakes and unrealistic expectations aside, I have several nodejs and crystal apps on cloud run which is running well and just the concept "lambda for docker containers" is pretty awesome. Cold starts are pretty harsh ATM, hopefully they improve.