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

Serverless and startups

aws.amazon.com

Post reply on HN
Print view View original

21–30 of 79 posts

Re: Serverless and startups

#21

Post by thinkingkong »

This is great marketing but suggesting some symbiosis between serverless and startups is odd. Startups for the most part dont have scaling issues that are experienced on the server. They’re usually people, process, and financial issues.

I see posts like this and wonder how many people will use some new paradigm because people say “its fast” when they still have no traction (not suggesting the author doesnt) or they dont even understand the scaling properties of their software or business.

Re: Serverless and startups

#22

Post by scarface74 »

qaq wrote: post #7

Honest question how is it easier for a startup vs DO with few VPSes and say manual DB fail-over.

I would never work for a company that wants to save a few bucks by having as part of their process “manual failovers” that might cause me to wake up in the middle of the night when they could have just allowed me to properly architect the thing in the first place.

Re: Serverless and startups

#23

Post by scarface74 »

qaq wrote: post #17
adzicg wrote: post #10

Earlier quoted context omitted.

Two things, based on my experience (we migrated from Heroku to Lambda in 2016, so been there for a while) 1. you don’t need to worry about reserving capacity, so you don’t need to pay for growth you expect to happen, or worry about not meeting a spike in demand if it happens 2. Most of the operations stuff (apart from packaging) is included in the price, so things like monitoring, alerts, dead-letter queues, traffic…

That the thing though the dev overhead and limitations for startup with avg compute needs might be more $ than tiny savings (e.g who cares if it is $200/month vs $70/month) if it will cost 50k extra in dev time to architect for lambda

How is “architecting for lambda” harder than traditional architecture?

Re: Serverless and startups

#24

Post by arnvald »

I think I fail to understand how Lambda works better for startups. I see primarily 2 arguments.

The first one is simplicity. You pack your Node.js application, upload to lambda and it works. But then in the article I see a chart with API Gateway, then Lambda, then SNS and then Lambda again. How is that simpler than deploying a single Node.js application on DigitalOcean?

The 2nd argument is scalability. I see how this is relevant, I'm wondering though how often it becomes really useful. How many products experience unpredictable spikes in traffic that cannot be handled by a single server costing $250/month? (that's one c5.2xlarge server on demand).

I believe FaaS and Lambda are very useful, but I think I miss the point why would people move their whole applications there.

Re: Serverless and startups

#25

Post by tnolet »

thinkingkong wrote: post #21

This is great marketing but suggesting some symbiosis between serverless and startups is odd. Startups for the most part dont have scaling issues that are experienced on the server. They’re usually people, process, and financial issues. I see posts like this and wonder how many people will use some new paradigm because people say “its fast” when they still have no traction (not suggesting the author doesnt) or they d…

This completely depends on what the startup is doing. For my use case (company name in profile) auto scaling is a god send due to individual users being able to influence how much work our jobs backend needs to do. This impossible to calculate and plan upfront so we totally rely on Lambda for this.

Re: Serverless and startups

#26

Post by scarface74 »

jlangenauer wrote: post #9
tnolet wrote: post #6

Earlier quoted context omitted.

Absolutely. Saving 30% on a cloud bill is not a super high priority for new companies. Staying frugal is important, but I find this mostly applies to unnecessary expenses, not necessary but slightly more costly expenses. Don’t get the 27” inch iMac, get a second hand office chair. This will free up enough cash so you can take the more expensive but quicker hosting / infra options like Heroku and Lambda.

One of the things with Lambda etc is that while they are cost-effective (and flexible) when a business starts, they also can also lead to lock-in (not just with the serverless functions themselves, but queueing services etc). A few years down the track, a business may find themselves spending quite a lot of money with Amazon, and being unable to move away without a major re-engineering effort.

When that time comes, hopefully you have found product market fit and are capitalized well enough to make the move - see Dropbox.

Re: Serverless and startups

#27

Post by thegeomaster »

In retrospect, going serverless (using Serverless Framework) has been a terrible decision for us.

First, exposing an API served by AWS Lambda has the infamous cold start problem. It's not fun to wait a couple of seconds for a mobile app to respond just because the request hit in an unfortunate time. One solution we found is to use a Serverless Framework plugin to periodically ping lambdas to keep them hot. But each concurrent lambda execution is a separate container, so you have to anticipate a number of concurrent requests you will be receiving at peak, or want to handle without a ~1s latency. Ouch - what happened to effortless scaling? And Amazon API Gateway adds another 100-200ms of latency on top of Lambda.

If you want to use an SQL database, you have to add your lambdas to a VPC, unless you want to expose your database to the Internet. But if you need to access the Internet from your lambdas, then you need a NAT (which you pay for). And you get another couple of seconds to cold starts while AWS attaches a network interface to your lambda. So, if you don't want this, you're stuck with e.g. DynamoDB. DynamoDB is optimized for scaling but it's a poor fit for relational data. Very basic support for indexes, no transactions, and data model migrations are very painful. There is also no spatial data story for DynamoDB, whereas if we had used Postgres, we'd be able to make use of PostGIS which is awesome.

The tooling is terrible. Serverless Framework is very rigid and riddled with bugs - we ended up maintaining our own fork of Serverless alongside forks of 3 plugins and another custom plugin we wrote to support our very simple workflow. There's no faithful offline reproduction of the API Gateway -> Lambda environment. We frequently ran into issues when the code is deployed that wouldn't show up when testing with a "simulation" plugin locally.

There's a lot of other problems we ran into, but these are the biggest ones I could think of. It didn't help that we didn't have much experience with this technology before deciding to serve our API using it (this was probably our biggest mistake). I guess we should have stuck with what we're faimiliar with - normal, "serverful" apps. And with the DyanmoDB provisioned capacity costs, I'm not sure we saved that much in the end.

Re: Serverless and startups

#28

Post by tnolet »

qaq wrote: post #17
adzicg wrote: post #10

Earlier quoted context omitted.

Two things, based on my experience (we migrated from Heroku to Lambda in 2016, so been there for a while) 1. you don’t need to worry about reserving capacity, so you don’t need to pay for growth you expect to happen, or worry about not meeting a spike in demand if it happens 2. Most of the operations stuff (apart from packaging) is included in the price, so things like monitoring, alerts, dead-letter queues, traffic…

That the thing though the dev overhead and limitations for startup with avg compute needs might be more $ than tiny savings (e.g who cares if it is $200/month vs $70/month) if it will cost 50k extra in dev time to architect for lambda

I would say architecting for Lambda is easier and quicker than “traditional” by now. Was a bit flaky in the beginning, admittedly.

Re: Serverless and startups

#30

Post by qaq »

scarface74 wrote: post #23
qaq wrote: post #17

Earlier quoted context omitted.

That the thing though the dev overhead and limitations for startup with avg compute needs might be more $ than tiny savings (e.g who cares if it is $200/month vs $70/month) if it will cost 50k extra in dev time to architect for lambda

How is “architecting for lambda” harder than traditional architecture?

having persistent processes ? Not needing API gateway? Not having to learn a whole bunch of AWS services? Not having to work around latency? Having a simple system that easy to debug?
Post reply on HN