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

Ask HN: Skeptical about my company going “full serverless”. What am I missing?

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 150 posts

Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?

#81

Post by x0x0 »

birdstheword5 wrote: post #76
hbrn wrote: post #61

Any "architect" joining the company and pushing for drastic changes like that is either an idiot chasing the hype, or a malicious actor trying to boost their importance. Good news: your gut feeling is correct. Bad news: you will likely lose this battle, unless you're good at playing company politics. Here's how it typically goes: 1. A new lead/architect/manager joins the company. 2. They push for a new hyped technolo…

Sadly, I think you are completely correct, and this exact sequence of events will go down. I don't think they're an idiot or malicious - I think they're clever and mean well, but perhaps they're blinded by their enthusiasm after getting certified

Or it's pure RDD (resume driven development.)

That said, you can figure out (just ask!) if this person was brought in as the result of an already-made decision to move to this type of development, or if this person is pushing it. As an EM, I'd have no problem with a report directly asking that question.

If the answer is the decision was made, and this hiring was a downstream result, then your choice is likely to deal with it or move on. If the decision hasn't been made / this architect is advocating for it, then a cost benefit analysis (which you'd think would be a standard part of any work) will be illuminating. My understanding of the tooling / debugging / monitoring tooling for serverless is that it's still quite raw. Although my bias is towards not wasting innovation tokens on things like serverless / I align strongly with the choose boring technology view advocated by Dan McKinley [1], amongst others.

[1] https://mcfunley.com/choose-boring-technology

Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?

#82

Post by tasn »

suzzer99 wrote: post #58
tasn wrote: post #37

Having maintained a service that uses Lambda. I think Lambda is probably fine for one-shot tasks, or taking from a queue (which is what it was built for), but I would never use it for API endpoints. The main issues: 1. Unpredictable performance - latency (with cold start), concurrency limits (how quickly can we scale to X concurrent requests), etc? We spent many hours with AWS support before moving away from lambda.…

Our app is mostly hit during business hours. So we wrote a pinger to "wake up" the back end lambdas when a user visits the website (not log in, just hit the site anywhere) *and* it's been more than 5 minutes since the last ping. It's not perfect but it helps a lot with the cold start times.

Our problem wasn't with zero traffic cold starts (nothing is calling the Lambda), but rather with scaling up cold starts (oh damn, traffic! We need more lambdas!).

Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?

#83

Post by spiffytech »

hbrn wrote: post #61

Any "architect" joining the company and pushing for drastic changes like that is either an idiot chasing the hype, or a malicious actor trying to boost their importance. Good news: your gut feeling is correct. Bad news: you will likely lose this battle, unless you're good at playing company politics. Here's how it typically goes: 1. A new lead/architect/manager joins the company. 2. They push for a new hyped technolo…

5.5 - the new hire adds this project to their resume, uses that to land a new job with a fancier title, and leaves the project to fall apart because there's no longer anyone committed to its success.

Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?

#85

Post by coredog64 »

tra3 wrote: post #67
adameasterling wrote: post #25

This is from the perspective of a small startup CTO: We've used AWS Lambda for about 4 years, and it's been so good and so cheap that I'm shifting literally everything (except Redis) to serverless. Also, GCP has a better serverless offering (Cloud Run, Spanner), so we're switching from AWS to GCP to take advantage of that. I bet we're going to see a massive cost reduction, but we'll see. Things I like about serverles…

I just started working with Lambda, so my experience may just be the teething pains, but. I find the developer experience a bit jarring. My lambda is in python, but every time I want to test my code I have to "build" the lambda with the `sam build` tool and only then can I exercise it. It takes a non-trivial amount of time to build. The deployment story looks good though, with the `sam deploy`, but for now I can't ge…

My recommendation is to invest in testing now while it’s easy. You can mock the incoming events and use something like moto for service mocks. That catches dumb mistakes sooner.

Also, don’t put any logic in the handler itself unless it’s extremely trivial.

Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?

#86

Post by larrik »

Lots of different opinions here, but:

My company has moved several "regular" websites to serverless. In fact, we just took the existing websites (which were often Django, sometimes huge ones) and dumped them into Lambda. The exact opposite of every "what serverless architectures are for" article you've ever read. And you know what?

It's awesome.

It's way cheaper than running it on EC2, and I never have to reboot a server or worry about their disks filling up or anything. Then when traffic spiked hard during the covid lockdowns? I did nothing. Lambda just handled it.

The only serious change we made to the setup was preloading a percentage of machines at all times to remove cold starts.

I'm not saying it's trivial (zappa, serverless, CDK), but usually one guy gets it working and the rest of the dev team changes nothing at all.

Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?

#87

Post by tra3 »

coredog64 wrote: post #85
tra3 wrote: post #67

Earlier quoted context omitted.

I just started working with Lambda, so my experience may just be the teething pains, but. I find the developer experience a bit jarring. My lambda is in python, but every time I want to test my code I have to "build" the lambda with the `sam build` tool and only then can I exercise it. It takes a non-trivial amount of time to build. The deployment story looks good though, with the `sam deploy`, but for now I can't ge…

My recommendation is to invest in testing now while it’s easy. You can mock the incoming events and use something like moto for service mocks. That catches dumb mistakes sooner. Also, don’t put any logic in the handler itself unless it’s extremely trivial.

Sound advice, but that ship has sailed. This is an existing lambda that I'm refactoring so I need to be able to "go through the front door", as it were. Once I become more familiar with the code, I'll be able to test individual pieces are you're recommending.

Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?

#88

Post by jedberg »

larrik wrote: post #86

Lots of different opinions here, but: My company has moved several "regular" websites to serverless. In fact, we just took the existing websites (which were often Django, sometimes huge ones) and dumped them into Lambda. The exact opposite of every "what serverless architectures are for" article you've ever read. And you know what? It's awesome. It's way cheaper than running it on EC2, and I never have to reboot a se…

Did you just dump the entire app into a single Lambda? I've been wracking my brain trying to figure out how to turn Django apps into services, but it never occurred to me that it could just make sense to dump the whole app in there.

Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?

#89

Post by spiffytech »

adameasterling wrote: post #25

This is from the perspective of a small startup CTO: We've used AWS Lambda for about 4 years, and it's been so good and so cheap that I'm shifting literally everything (except Redis) to serverless. Also, GCP has a better serverless offering (Cloud Run, Spanner), so we're switching from AWS to GCP to take advantage of that. I bet we're going to see a massive cost reduction, but we'll see. Things I like about serverles…

Does your team do local dev?

Every team I've known that adopted Lambda + DynamoDB (or equivalents) gave up on running their app locally, adding a lot of friction to the development process.

Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?

#90

Post by bilalq »

I've used serverless for both big and small loads while working internally at AWS and also continue to do so now that I'm running a small startup.

The advantages are:

* Lower costs from much better resource utilization rates. Comparisons against a perfectly sized fleet of servers is inherently flawed. Sure, you can make sure auto-scaling happens, but that costs time and energy to get right. Even then, you're always going to be having to leave some buffer room. Instead of saying serverless is good for bursty/low traffic, I'd frame it as serverless is great for any workload that isn't close to a fixed load. Dev and other non-prod environments also basically cost nothing instead of potentially being quite expensive to replicate multi-AZ setups. In practice, serverless is going to be cheaper for a lot more use cases than you may think at first.

* Tight integration with IaC. Your application and infra logic can be grouped based on logical units of purpose rather than being separated by technology limitations. This is especially true if you use things like CDKs.

* Zero need to tune until you get to massive scale. We went from our first user to hundreds of thousand of users with no adjustment needed at all. Even at millions of users, there's little you'd need to change from the infra side beyond maybe adding a cache layer and requesting limit increases. Obviously app/db optimizations might be needed, but for the most part, scaling problems become billing problems.

* A simpler threat model. If you're running servers, keeping them secure is not trivial. There's just a lot to less to do to keep serverless apps secure.

* Ability to avoid Kubernetes and other complicated infra management. One could argue that you're just trading Kubernetes complexity for cloud specific complexity. That's true, but it's still a net reduction in complexity.

* Operational overhead is way down. A base level of logging/tracing/metrics comes out of the box (at least on AWS, not sure about Azure). No need to run custom agents for statsd/collectiond/prometheus/opentelemetry/whatever. No need to spend any time looking at available disk space metrics or slow-building memory leaks that creep up over weeks. It just works.

* Easy integration with lots of cloud managed services. Want to deploy an API endpoint? Want to build a resolver for an AppSync GraphQL field? Want to write code that runs in response to some event or alarm going off? Want to process messages from a queue without spinning up a fleet to longpoll from it? Want to write code that applies transforms on a data stream before writing to your data warehouse? The infra definitions for all of these all share a foundation. You have a unified API for everything.

Post reply on HN