This post is an order of magnitude higher than any other post on the front page. I think people are finally starting to see through the serverless hype.
Serverless: slower and more expensive
601–610 of 733 posts
Re: Serverless: slower and more expensive
#602PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article: 1. Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go. 2. Use managed services whene…
So, to summarize, you should:
1. not use the programming language that works best for your problem, but the programming language that works best with your orchestration system
2. lock yourself into managed services wherever possible
3. choose your api design style based on your orchestration system instead of your application.
4. Use a specific frontend rpc library because why not.
...
I've hacked a few lambdas together but never dug deep, so I have very little experience, but these points seem somewhat ridiculous.
Maybe I'm behind the times but I always thought these sort of decisions should be made based on your use case.
EDIT: line breaks.
Re: Serverless: slower and more expensive
#603Earlier quoted context omitted.
Only 2 endpoints per month? What exactly are you comparing to that doing it twice a month would waste way more time adding an endpoint vs serverless?
With Firebase if I need a new env I just type 1 command and get it. With VMs I have the joy of managing my own keys. VMs need security patches, updates, and I have to maintain images. I have to think . It is hard to explain how simple firebase functions are. There is literally no mental overhead. There is no worrying. There is nothing to maintain or think about, no settings up quotas or managing what machine somethin…
Ah ok so you're 100% serverless so functions are saving you all the headaches of running your own infra? That makes sense. It sounded like the time to add an endpoint was your main criteria and just seemed strange.
Re: Serverless: slower and more expensive
#604Earlier quoted context omitted.
Firebase does a lot of stuff. Originally it was a small company that focused on providing a real-time JSON-like backend store for web apps. But then they got bought by Google and seem to have evolved into Google's answer to a lot of AWS services, ie hosting, real-time DB, serverless, and probably more I'm not aware of.
I've often looked at and played with Firebase since it does so much of what I need to back a React Native-based app for simple mobile games and utilities. I always end up talking myself out of it due to Google's history of pulling the plug on (what seem to an outsider to be) perfectly good, stable products that wouldn't do any harm to keep around indefinitely. As a hobbyist, I wouldn't have the time or motivation to…
It would be nice if there was a dead-simple Firebase-like tool you could self-host. ie just a single instance that you could point all your toy apps at to give them a little real-time persistence.
Re: Serverless: slower and more expensive
#605PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article: 1. Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go. 2. Use managed services whene…
So, to summarize, you should: 1. not use the programming language that works best for your problem, but the programming language that works best with your orchestration system 2. lock yourself into managed services wherever possible 3. choose your api design style based on your orchestration system instead of your application. 4. Use a specific frontend rpc library because why not. ... I've hacked a few lambdas toget…
> I've hacked a few lambdas together but never dug deep
Then why comment? You clearly don't understand the use-case that AWS fits.
I've had jobs that took 18 hours to run on single machine finish in 12 minutes on Lambda. I could run that process 4 times a month and still stay within AWS's free tier limits.
For the right workloads it is 100% worth realigning your code to fit the stack.
Re: Serverless: slower and more expensive
#606Earlier quoted context omitted.
I've often looked at and played with Firebase since it does so much of what I need to back a React Native-based app for simple mobile games and utilities. I always end up talking myself out of it due to Google's history of pulling the plug on (what seem to an outsider to be) perfectly good, stable products that wouldn't do any harm to keep around indefinitely. As a hobbyist, I wouldn't have the time or motivation to…
It would be nice if there was a dead-simple Firebase-like tool you could self-host. ie just a single instance that you could point all your toy apps at to give them a little real-time persistence.
Parse was a Firebase competitor that got bought by Facebook and later open sourced, I don’t know if it’s dead simple though.
Re: Serverless: slower and more expensive
#607This is how a conversation with a colleague who were enthusiastic about Serverless, and who's company was mostly on Java/JVM stack went: Colleague: Lambda is awesome, we can scale down to zero and lower costs! We love it! We use cool tech!! Me: What did you do about JVM warm up? Colleague: We solved it by having a keepalive daemon which pings the service to keep it always warmed up. ... Me thinking: Uhh, but what abo…
Your “thoughts” are applying his solution to the wrong problem. “Start small and stay small” I’m not sure what that even means. Are you saying every service has to grow to some size or required amount of compute? LOL The 100ms extra time is nothing. I mean - are you trying to solve at Google or Amazon scale? I run simple Lambdas that read from some SNS topics, apply some transforms and add metadata to the message, an…
100ms of unneeded latency IS NOT nothing (except for some limited use cases). Anything user facing shouldn't be slower than it needs to be.
Re: Serverless: slower and more expensive
#608Earlier quoted context omitted.
"No because Lambdas are proprietary which means you can't run it in a CI or locally." It kinda is, but not really. You get an event object as param and often only need a few fields from it. Also, you can run Lambda locally, AWS SAM CLI lets you run them in Docker for debugging purposes.
I found SAM to be extremely difficult to use, especially on windows where docker is just plain old terrible.
Tried getting SAM to work on OS X, no luck, lots of pain.
Re: Serverless: slower and more expensive
#609Earlier quoted context omitted.
> You really have to architect your app from the ground-up for serverless by designing single-responsibility microservices that run in separate lambdas, building a heavy javascript front-end in your favorite framework (React/Ember/Amber/etc), and taking advantage of every service you can (Cognito, AppSync, S3, Cloudfront, API Gateway, etc) to eliminate the need for a web framework. At least I don't have to learn that…
I am similarly, reading this list and wondering
One day people will rediscover installing a Linux box with an Apache server and call it novelty.
Re: Serverless: slower and more expensive
#610Earlier quoted context omitted.
So, to summarize, you should: 1. not use the programming language that works best for your problem, but the programming language that works best with your orchestration system 2. lock yourself into managed services wherever possible 3. choose your api design style based on your orchestration system instead of your application. 4. Use a specific frontend rpc library because why not. ... I've hacked a few lambdas toget…
> I've hacked a few lambdas together but never dug deep Then why comment? You clearly don't understand the use-case that AWS fits. I've had jobs that took 18 hours to run on single machine finish in 12 minutes on Lambda. I could run that process 4 times a month and still stay within AWS's free tier limits. For the right workloads it is 100% worth realigning your code to fit the stack.
>Then why comment?
Because the instruction list from above isn't backed with any solid reasoning and because commenting is what people do on HN.
>You clearly don't understand the use-case that AWS fits.
Pray tell, what is this enviable use case that I so clearly do not grasp?