> yes we should probably be using t2.small
Go with t3.small. It's cheaper, faster, and you don't have to watch your CPU credits like you do with a t2.
Serverless: slower and more expensive
301–310 of 733 posts
Re: Serverless: slower and more expensive
#302While there is a lot of lambda/serverless hate in this thread, I (who have no experience with it) am reluctant to conclude based on this alone that lambda is useless/stupid. Need more info. Is there anyone who has had success using lambda, or can anyone find a write-up of a success story? That would help me (and others) understand/believe better I think; if it's a very rare case where lambda ends up being helpful (wh…
For my organization, Lambda has been instrumental in allowing us to take some highly trafficked, small API services, and migrate them from NodeJS based servers that we manage to Lambda and Application Load Balancer that just works with no involvement. We're not relying on the API gateway (which is expensive and better suited for non-public APIs).
Many of these APIs are Ajax type status updates, JWT issuers, authentication handlers and other utilities. We use the serverless framework to deploy the code, and it works very nicely for us.
The hate is real in these comments, but for us we are able to move 500 million+/month API requests with minimal code changes, easy scaling up and down, and we were able to learn a little something about serverless architectures and their viability for other possible things in the future.
Re: Serverless: slower and more expensive
#303I thought commenter W. Van Dam made some good points: “ First, you don't need API Gateways if you use an AWS SDK. Like this guide shows. And of course you don't need a load balancer, because that's precisely one of the things that serverless takes care of for you :-) More importantly, you didn't actually compare serverless to your current situation. With serverless solutions you can typically save cost in terms of se…
You can do the same thing with Lambda @ Edge and CloudFront for .60 per million requests and there is a free tier. ( https://aws.amazon.com/lambda/pricing/ )
Workers are pretty significantly different. They don't have a meaningful cold-start time, for one.
Re: Serverless: slower and more expensive
#304"Serverless", or "App Engine" as it was called for the few years prior the hype, actually delivers pretty good results for a range of parameters. It might even be a wider range of parameters than the ones where the results are subpar... Or not, I'm not sure how to weight the "I have a predictable base load large enough for its cost to dominate the other factors" vs the other cases. But as always - popularity of a too…
App Engine is a PaaS, not serverless/FaaS
It's interesting how many still seem to (in this thread) believe you either have to run your own Linux servers in your basement or do FaaS (much better word to avoid the confusion), when there are many great in-between options.
Re: Serverless: slower and more expensive
#305Earlier quoted context omitted.
I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring and log in a more large scale serverless application is larger than managing several linux servers.
Whenever I've spoken with engineers from AWS and Google Cloud they saw serverless as a platform for glue code, webhooks, cronjobs and the like. In that role it works great: you don't care if it takes 300ms to start and it's genuinely easier and cheaper than running that code on a server. But somehow in marketing materials and blog posts it's instead discussed as if it was a good idea to run everything serverless. May…
Marketing latches onto that because 1) executives understand front-end use cases better than glue cases; and 2) it's way more profitable.
Re: Serverless: slower and more expensive
#306Earlier quoted context omitted.
You can do the same thing with Lambda @ Edge and CloudFront for .60 per million requests and there is a free tier. ( https://aws.amazon.com/lambda/pricing/ )
Workers are pretty significantly different. They don't have a meaningful cold-start time, for one.
Lambdas @ edge don’t either. There are different optimizations than regular lambdas and you wouldn’t use a heavyweight environment and of course they wouldn’t be running attached to a network.
Re: Serverless: slower and more expensive
#307Earlier quoted context omitted.
> We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) That goes without saying! That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. I don't think anybody uses things like AWS or serveless…
> That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle. Other forms of serverless might save time. However there's always edge c…
> Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle.
This has not been my experience at all. Maybe because I have a lot of experience with Lambda, but I find them to be a very fast way to get code written and running.
Granted, Lambda is a great tool for a specific category of task. Namely, when you need to programmatically respond to some event which was triggered by another AWS service and can do so in under 5 minutes. But it's poorly suited for tasks outside of that domain. In that sense, it's like Bash: you don't want to do everything with it, but there are situations where it's the best tool.
Re: Serverless: slower and more expensive
#308This 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…
It's a good sign that people who only talk about FaaS when they say "serverless" didn't understand serverless at all. And I see this as a failure on the serverless proponents side.
The serverless proponents are selling their paradigm as simple solution, which leads many people to believe simple means FaaS.
Throwing Lambda on all backend problems is a setup for failure. Often transfer and simple transform of data can be done serverless without a Lambda, which cuts costs AND leads to better performance.
Re: Serverless: slower and more expensive
#309I don't find this so surprising really. Serverless removes a significant amount of initial work and ongoing maintenance. No server, no patches, no initial setup, no lots-of-things. Seems like a premium offering with premium pricing.
I also don't find it the least bit surprising that a semi-cold box in a data center can't accept a request, associate it my my account, spin up a worker thread with my stack and service my request in the same time as a box running my stack with a pool of ready worker threads.
It's nice to see someone put some real metrics on it though.
Re: Serverless: slower and more expensive
#310Earlier quoted context omitted.
That's more steps than 'just use containers and ignore the serverless meme'.
I don’t think anybody advocates for rewriting all existing projects as serverless. But if you’re starting a startup, going all in on serverless will let you deliver better products faster. If Paul Graham’s Beating the Averages would be written today, the secret weapon would be serverless, not Lisp.
I will argue the opposite. Startups take on enough risks as it is. Unless your startup requires or is about a novel architecture. Why add more risks with non battle hardened technology.
Software professionals often sees benefits without understanding the tradeoffs.