In my view, the serverless revolution is stalled because of lack of interoperability with other more complex application architectures. Serverless is IMO best suited as something available in-addition-to other more complex application architectures for a limited but growing set of use-cases. The current architectures I've seen make the "we <3 serverless" folks go all-in on it and then regret their decision and walk back to using services / docker / Kubernetes, or even a Heroku style PaaS for more power and flexibility.
The Serverless Revolution Has Stalled
591–600 of 670 posts
Re: The Serverless Revolution Has Stalled
#592Earlier quoted context omitted.
It's not clear to me how much experience with serverless architectures the author of the parent comment has, but speaking as someone with plenty, the operational costs of serverless are at least equal to managing stateful infrastructure, with much less control when things go wrong. Lambda was a major step up in long term predictability compared to for example App Engine, where there have been plenty of instances of o…
I don't think you're wrong, I just think you're not looking far enough ahead. What we have now is very primitive compared to how app development might work in the future; serverless is laying the foundation for a completely different way of thinking about software development.
I think I understand your point.
It's more back to the mainframe model of software development. I did this back in the 90s and I never had to think about scaling. Granted these were just simple crud / back-office apps.
But I can see how it would work for most modern software.
Re: The Serverless Revolution Has Stalled
#593One of the fundamental problem of serverless is intimately tied to its very selling point: that your code is run on interchangeable servers.
What that leads to is that everyone's code runs on any server. The requires strict inter-server security, authorization and roles.
On a normal server, you can run multiple processes (DB, front-end, back-end, etc) and rely on the fact they're running on the same server to not having to design roles and auth.
In serverless, you need to manage roles and auths for everything.
You see the same issues for data pipes, triggers and queues.
Re: The Serverless Revolution Has Stalled
#594The biggest drawback for me which the article didn’t really touch on was cost. For high volumes of traffic AWS Lambda is way more expensive than an EC2 server.
Re: The Serverless Revolution Has Stalled
#595Earlier quoted context omitted.
Reminds of something that was on the HN frontpage some month ago, where readers are not sure if it's a parody or not, because of the architecture you're required to deploy yourself to use this new "Perspective" product. Direct link to the architecture, that in the end serves the use case of generating a diagram of your AWS resources: https://d1.awsstatic.com/Solutions/Solutions%20Category%20Te... https://aws.amazon.c…
Reading this made me remember that back in the day the AWS selling point was "here you can create virtual machines with few clicks and have it instantly instead of waiting 30 min for you colocated server to be ready" but now it seems to be "here is a bunch of random expensive tools, please, produce as much stuff as possible and share the word that having servers is bad™". This field used to be inspiring, but now I se…
"Also I can't understand why one would prefer to pay that much for such complexity."
If there is one thing that dealing with AWS reps has taught me, it's that this was 100% by customers. I swear to god, AWS doesn't do anything without customers asking for it.
If you are wondering why products are build in AWS, it's because people wanted to give them money for this. Say what you want, but this isn't something are pushing on us. This is something "we" push on them to provide.
Re: The Serverless Revolution Has Stalled
#596It feels like, to me, that most of the comments in this thread that don't "get" serverless have never had to deal with things like maintaining the spaghetti mess of CM(Chef/Puppet/Ansible) that invariably results from trying to manage a traditional infrastructure deployment of any size.
Patching, dependencies, configuration drift, security audits/compliance... these are all non-trivial issues requiring non-trivial operations and engineering hours to solve.
It's fine if Lambda is too complex an abstraction for hobby code or a node.js todo-list app, but that doesn't mean it doesn't solve the right problems in the right problem spaces.
Re: The Serverless Revolution Has Stalled
#597Re: The Serverless Revolution Has Stalled
#598I don't buy into serverless. I went to a webdev convention, and it ended up being a serverless hype train. Industry experts with a financial incentive to promote serverless went on stage and told me they can't debug their code, or run it on their machine. They showed me comically large system diagrams for very simple use cases, then spent an hour explaining how to do not-quite-ACID transactions. Oh yeah and you can o…
Thank you, serverless is the new structure that everyone loves and wants to work in, but no one talks about the downside. I just took over a project that has a serverless architecture.
We can't run it locally because the emulator won't run 7/10 of the code, there are memory limit errors that are totally opaque to us since we can't step through and watch it break. We are getting unexplained timing issues that were being worked on via logs in dev. The costs are insane.
If we want to say serverless is the future, the future isn't here yet. There are many tools that would need to be built to make serverless viable, and the tools that are built are immature and bad. Not to mention, you're tied to the companies support, so Google was outdated from the LTS for Node for a while. The reality is going serverless means you don't have control over what happens to your code.
Re: The Serverless Revolution Has Stalled
#599This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…
We had that utterly compelling framework in the early 2000s. Write generic code, upload to any provider you want, watch it run - that's exactly how shared-hosting PHP worked in ye olden days and to this day no one has made a developer experience as nice and It Just Works as that.
Re: The Serverless Revolution Has Stalled
#600I think we need bare-metal serverless, same like we have bare-metal clouds. For that we need something like kubernetes but for serverless environments instead of containers.