You can also predict the costs, and shop around if your provider gets greedy. If Amazon changes its pricing structure, what are you supposed to do?
Re:The Serverless Revolution Has Stalled
by VHRanger on Tuesday October 13, 2020 @07:40AM
(#24764539)
If you built everything in proprietary infrastructure, porting is a lot more work.
Using lambdas tie you to AWS because as soon as you use a few step functions, or you have a few lambdas interacting, changing to Azure or GCP becomes a huge pile of dev work and QA.
Having everything "just run" on linux instances let you be perfectly portable and now you can actually shop around.
Re:The Serverless Revolution Has Stalled
by ajsnigrutin on Tuesday October 13, 2020 @07:31AM
(#24764486)
It's a lot easier to change providers, if your service is an (eg.) docker image(s), than to move something relying on amazons api.
Re:The Serverless Revolution Has Stalled
by xorcist on Tuesday October 13, 2020 @10:12AM
(#24765697)
It's even easier if your application is just (an equivalent of) a binary, or a tarball.
Re:The Serverless Revolution Has Stalled
by ForHackernews on Tuesday October 13, 2020 @10:15AM
(#24765734)
Unless it relies on any system libraries, in which case you're in dependency hell when you upgrade or change the OS.
There's also the long-time guarantee; if you write an application that runs on Ubuntu Server or Windows Server now, you can bet your ass that it will still run, unchanged, for another 10 years. The only maintenance you need to do is to fix your own bugs and maybe help out with some database stuff. If you deploy a Lambda app now, you have nothing to guarantee compatibility for such a long time other than "Amazon probably won't change their API, I think".