Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

Post reply on HN
Print view View original

311–320 of 733 posts

Re: Serverless: slower and more expensive

#311

Post by claudiusd »

I did the same experiment as OP and ran into the same issues, but eventually realized that I was "doing serverless" wrong.

"Serverless" is not a replacement for cloud VMs/containers. Migrating your Rails/Express/Flask/.Net/whatever stack over to Lambda/API Gateway is not going to improve performance or costs.

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.

I have been experimenting with this approach lately and have been having some success with it, deploying relatively complex, reliable, scalable web services that I can support as a one-man show.

Re: Serverless: slower and more expensive

#312

Post by zemo »

cryptica wrote: post #17

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…

if you work for an org that has cash on hand but not a lot of developer talent, the tradeoff is worth it. If the difference is going to cost you $50k a year but let you hire one less programmer, it's worth it.

Re: Serverless: slower and more expensive

#314

Post by falcolas »

tapoxi wrote: post #241
mbrumlow wrote: post #238

Earlier quoted context omitted.

>> emergency CVE mitigation across multiple regions, compliance requirements These don't go away because you went serverless. They are jut now outside your control -- and you will have to wait for somebody else to fix them, usually with no insight into how long it will take leaving you with a very poor messaging you can give your clients as to when things will be back on line. Simply hand-waving -- this is running on…

> Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. It shifts blame, especially if it's in the contract with the provider.

Shifting blame doesn’t help much when you lose customers (or pay financial penalties) due to non—compliance.

You learn quickly that while AWS is “compliant”, they have enough legal sway to never be on the hook if they aren’t actually compliant.

Re: Serverless: slower and more expensive

#315

Post by [deleted] »

jrochkind1 wrote: post #183
peterwwillis wrote: post #56

Earlier quoted context omitted.

> The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route. If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really con…

> You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy. You can consider it so theoretically, but for many teams, especially small teams, OS-level systems admin is a different skillset and non-trivial burden that they are glad to pay a premium for, which is why offerings like heroku are successful. It may work that way for…

[deleted]

Re: Serverless: slower and more expensive

#316

Post by mywittyname »

scarface74 wrote: post #119
tedk-42 wrote: post #12

I disagree with all the comments posted so far. This should be a perfect use case for lambda, not "oh you're API is receiving more than 10M req/day? Use Elastic Beanstalk instead with an EC2 instance and ELB". This kind of comment is just to abuse the free tier that AWS provide you with. The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fo…

Docker can also be serverless and gets rid of all the limitations of lambda - Fargate.

Fargate is not a replacement for Lambda. While there's some capability overlap, each have their own respective niches.

Re: Serverless: slower and more expensive

#317

Post by tybit »

rdsubhas wrote: post #114

This 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…

The keep alive is still practically scale down to zero, you’re paying for 100ms every 5 minutes.

I’d be curious about how much memory/cpu was allocated in your experience and the OPs, there’s nothing magical about lambda to make it slow.

Re: Serverless: slower and more expensive

#318

Post by k__ »

johnfactorial wrote: post #286
rdsubhas wrote: post #114

This 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…

> Lambda seems to be a fast prototyping tool. My thoughts EXACTLY. The great power in "serverless" architecture (i.e. AWS Lambda + AWS RDS + AWS Gateway) is how it empowers prototyping a new product. Counterintuitively, it's future-proofing. You should know in advance that it's too slow & expensive. But you get to spin up a prototype backend very rapidly, pay only for what you're using while prototyping, and Lambda's…

The problem is mainly that people think "Cool I can build everything with FaaS and it will be cheaper and scale well"

Which is wrong and can be attributed to bad serverless evangelism in the past.

Serverless is building your system with managed services and only drop-in a FaaS here and there when you need some special custom behavior.

See how far you come with AppSync, Firestore or FaunaDB. Throw in 0Auth or Cognito and then when you hit a wall, make it work with FaaS.

Re: Serverless: slower and more expensive

#319

Post by TickleSteve »

eternalban wrote: post #211
TickleSteve wrote: post #172

Earlier quoted context omitted.

No. It depends on the IoT application. The one I'm involved with (smart metering) produces data at regular 15 minute periods 24/7. This is a very predictable and constant traffic load and not at all suitable for serverless/lambda. In fact, its the complete opposite. Many IoT applications are very predictable (anything with regular sensor-readings for example or with repeatable patterns such as people returning from w…

What you need to consider [is] that there are a lot of applications like yours hosted by an IoT SaaS. (I work on one.) So the patterns are (obviously) predictable, but the 'dynamic range' of the load is extremely wide, ranging from stampedes on the cardinal points of the clock face (0/15/30/45 min) to crickets the rest of the time. Some form of elasticity is required unless you are willing to pay for idle servers siz…

Thats not really true as generally IoT nodes will manage the traffic they generate to avoid synchronisation with other nodes.

For example, to avoid the 00/15/30/45 issue you offset yourself randomly over a few minutes within that range to avoid overloading mesh & cellular radio networks.

This has a smoothing effect on the traffic as a whole (as seen from the server) which reduces the "dynamic-range" as you're terming it.

Post reply on HN