3 ms·
At the moment. Is there anything stopping an organisation from defining some standard types of serverless environments? Is there anything stopping someone fro
by 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 agoThat 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 agoThe 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 agoI 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