Live data from Hacker News

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

news.ycombinator.com

121–130 of 150 posts

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

#121

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.

I highly recommend using AWS's own Chalice library as it makes local dev _and_ deployment very easy.

If you need more complex cases like deploying docker containers to a Lambda function, take a look at AWS's SAM library. Also supports local dev _and_ makes deployment easy (its essentially a wrapper around Cloudformation so its very powerful).

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

#122
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.

Don't leak my playbook, spiffytech..

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

#124
You’ve lost this battle. Prepare for the next: figuring out what full serverless even means.

It should mean “keeping state to an absolutely minimum, and relying on event-based architecture.”

Are you familiar with event-based architecture? Are you familiar with functional programming?

This is your time to shine.

There’s a strong possibility you’ll end up with Lamdas (or whatever) that are just CRUD endpoints.

That would be bad.

So be prepared to fight out what comes next.

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

#125
What is the reasoning being provided? Will it save money due to your users using the application during business hours? Are there assumptions being made that are not applicable/valid in your case?

Personally, I was excited for serverless, but after using API Gateway and Lambda to serve a simple REST API it seemed like more work compared to using a load balancer to route requests to a container running in ECS. ECS can autoscale too, so you can scale up and down as required.

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

#126

> The consensus on the internet seems to be "serverless has its use cases" but it's not clear to me what those use cases are. My $0.02, having used serverless before. Those use cases are: * Very very low traffic apps. POST hooks for Slack bots, etc.. Works well! * Someone who is an "architect" can now put "experience with Serverless" on their CV and get hired somewhere else that is looking for that keyword in their C…

There's tons of low traffic parts of apps. So if you're building in more of a 'microservice' architecture instead of a giant monolith, serverless has it's place. Most of your app is serving requests to users, but your signup and login flows might only run 100's of times per day and they are simple workflows, check if user exists > create new users > add password > send email verification. Then, the email verification…

If the load is so minimal for those functions and you are already running other infra for the rest of your app why would you "outsource" those functions to a serverless runtime? What do you gain besides another system you deploy to?

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

#127
A lot was said good about serverless, and I was a big proponent of going ”all in”, but now as CTO of small startup I am careful with it.

From my experience of 4 years with serverless in AWS following problems have been identified:

- Difficult to debug

- Difficult to collect logs - Lambda@Edge

- Slow cold starts

- Frontend and NodeJS bundling are problematic - size limits, slow and unpredictable problems

- Pricing are difficult to estimate

- Careful planning needed for network and architecture - how lambdas work together

- Workflow orchestration might be needed

What is serverless good for?

- Queue processing

- Event processing

- Internal infrastructure code

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

#128
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…

How to derail this dynamic early: "Does this solve a problem we have?" "Of the top five things that we are trying to build, does this add any of them?" Often the problem isn't that the new methods/tech is bad but that all the effort spent transitioning to it could be better spent directly attacking the goal in the first place.

Yeah that doesn't work with things as hugely hyped as the cloud, agile, etc. Obviously it's a cult and it doesn't solve anything in and of itself, but you're not allowed to say that.

Rather, I'd go for:

"Let's solve this problem we've been having with Azure Cloud Functions!"

"Of the top five things that we are trying to build, let's build them with Agile!"

Otherwise, you are not a team player, part of the problem not the solution, etc. It sucks, but that's politics.

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

#129
I think the main reason to undertake the serverless route should be OPEX savings. We expect the serverless infrastructure to cost less than the current Azure App Services/ VMs set up.

Here are questions to ask

What is the current monthly spend? What is the estimated monthly spend in the new system?

Perhaps the new serverless system is easier for operations and deployments. Does the new system provide for better uptime/monitoring? How is monitoring done on the current system? If there is a problem, like the service returning 500s, do you have the tooling to diagnose the issue? How does this change in the new system?

What is the developer experience on the new system? Is it easy to deploy to staging and production environments? How long does it take to create a new feature? What does the develop/test/debug loop look like in this system? How does this compare to the current system?

Ask yourself and others these type of questions. Maybe migrating to serverless is better, but it should depend on the answers to questions/concerns that I listed above.

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

#130

Earlier quoted context omitted.

I have limited time before my next meeting so I'll type real quick: GCP Cloud Run is like the best of both worlds between AWS ECS Fargate and AWS Lambda. (Yes, the comment is in the context of containers. Sort of.) * Like Fargate, Cloud Run hosts containers and takes care of figuring out where they actually live. Unlike Fargate, you don't have to say exactly how many containers you want running at once; GCP will auto…

A couple of points: 1. Cloud Run is more analogous to AWS App Runner than Fargate. 2. Cloud Run isn't a great analog to lambda. Lambda is built to host functions. Cloud Run is built to host applications. Lambda is more analogous to GCP Functions. 3. Cloud Tasks should probably be built with EventBridge + Lambda or EventBridge + StepFunctions or EventBridge + ECS. I don't profess to be a GCP expert so it's hard for me…

Huh. I had this long call with our AWS Account Reps (+ Support Engineers) the other day and no one mentioned App Runner! This is the first I've heard of it. Looking at it now.

Ah I see, launched originally in May 2021. That's probably why they weren't aware of it. Yes, this looks cool. Very much what I was looking for.

The differences that I can see are...

* AWS App Runner lacks an advertised free tier. Not a big deal for all but the smallest projects though.

* AWS App Runner bills rounded up to the next second, whereas GCP Cloud Run rounds up to the next 100 millisecond.

* AWS App Runner doesn't charge per request (?!), whereas GCP Cloud Run charges $0.40/1M requests.

* AWS App Runner has fewer CPU/RAM configuration options. The lack of low end options may be a blocker for us.

* It's cheaper than GCP Cloud Run - $51.83 @ vCPU/1GiB, but 2GiB minimum, in Runner vs $69.642 @ 1 vCPU/1GiB (v1) $97.50 @ 1 vCPU/1GiB (v2) in Cloud Run.

* I'm confused by the networking model. In App Runner, you have to make an ENI for your App Runner service to access your VPC? Weird. There's some extra cost there I think.

Things that I can't determine based on the documentation...

* Does App Runner support committed use discounts?

* Does App Runner throw a SIGTERM before shutting the container down? I hope yes but I can't find docs on it.

* Is there a file system accessible on App Runner and is it just in memory or is there actually a disk to write to?

* The quotas & limits page on App Runner feels incomplete and I'm left with a lot of questions about it.

* Is there an SLA?

* In fact the documentation for App Runner just feels a little incomplete.

It looks like AWS definitely wants App Runner to be the answer to Cloud Run, but to me, it feels like it's not quite there yet.

It's also weird, that ECS Fargate lets you run a container without thinking about the server that it runs on, and App Runner does too, just with a few extra things. Why is it a whole separate service? Why didn't they just add it onto Fargate?

Re: Other services. I've only heard of API Gateway, DynamoDB and Lambda@Edge; I'll have to spend time investigating the other ones. Thank you for mentioning them!

Post reply on HN