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

41–50 of 79 posts

Re: Serverless and startups

#41

Post by tirumaraiselvan »

thegeomaster wrote: post #27

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

Why do the problems that you state with RDS not true for DynamoDB? Does DynamoDB not run in a VPC?

Re: Serverless and startups

#42

Post by thegeomaster »

tirumaraiselvan wrote: post #41
thegeomaster wrote: post #27

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

Why do the problems that you state with RDS not true for DynamoDB? Does DynamoDB not run in a VPC?

It's a managed service by Amazon and you access it using the AWS SDK, for which you need an IAM role, so everything is secure. Whereas with RDS, Amazon maintains a database for you, which you just connect to using ordinary TCP. IIRC it's not even possible to run an RDS database exposed to the Internet (well, you can always install Postgres on an EC2 instance, but that's even crazier).

Re: Serverless and startups

#43

Post by falcolas »

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?

Because you're immediately having to go to a MSA, which immediately adds a whole new layer of complexity, monitoring, network latency, API coordination, and configuration to otherwise simple webapps.

Re: Serverless and startups

#44

Post by jasonkester »

slobodan_ wrote: post #40
jasonkester wrote: post #33

Which of the following is the more likely failure mode for a new product: A.) So many customers wanted it that we couldn't scale fast enough. B.) We ran out of time or money before we shipped. The author appears to be worried about A, but in my experience it's B that you need to think about when starting out. Imagine if, instead of building any of those crazy 30-node-diagrams of an architecture in the article, he'd h…

I am not worried about A at all. This was a technical article, but here's the explanation I posted to twitter: Although I enjoy talking about technology, and I enjoy working with serverless, it's important to note that using serverless for @slackvacation is not a technology decision. It's a business decision. Not because the auto -scaling, that's nice to have, but that's not a problem startups are facing in their ear…

It sounds like part of your decision was that Lambda comes out cheaper for hosting. That also doesn't pass the arithmetic I use to evaluate such things.

A dev, fully loaded, will cost you $200/hour. A half cage at a colo with a really fast machine in it will cost $800/month. So if you choose a stack that adds 4 hours of work each month (or 80 extra hours upfront), you're behind.

Given that (as I touched on above), your chances of outgrowing a beefy box in a colo (or its managed equivalent) can be thought of as zero until you see the big success event that proves otherwise, my money is still on boring tech and boring hosting.

Granted, Lambda is cool. I love building stuff on it for other people on their dime. But as a guy who also builds businesses on my dime, it remains a tool for tiny niche cases that can safely go down on a saturday morning without making me cancel my weekend.

Re: Serverless and startups

#45

Post by slobodan_ »

jasonkester wrote: post #44
slobodan_ wrote: post #40

Earlier quoted context omitted.

I am not worried about A at all. This was a technical article, but here's the explanation I posted to twitter: Although I enjoy talking about technology, and I enjoy working with serverless, it's important to note that using serverless for @slackvacation is not a technology decision. It's a business decision. Not because the auto -scaling, that's nice to have, but that's not a problem startups are facing in their ear…

It sounds like part of your decision was that Lambda comes out cheaper for hosting. That also doesn't pass the arithmetic I use to evaluate such things. A dev, fully loaded, will cost you $200/hour. A half cage at a colo with a really fast machine in it will cost $800/month. So if you choose a stack that adds 4 hours of work each month (or 80 extra hours upfront), you're behind. Given that (as I touched on above), yo…

Serverless is so much more than just Lambda functions.

Re: Serverless and startups

#46

Post by matwood »

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.

Every startup wants to reach the point where vendor lock-in is an issue. IMO, it's a useless boogeyman. If vendor lock-in lets the start up move faster, find the business, and make it 2-3 years down the road, they should pick vendor lock-in every single time.

Re: Serverless and startups

#47

Post by falcolas »

jsty wrote: post #19
jlangenauer wrote: post #9

Earlier quoted context omitted.

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.

Then again if you're aiming at high growth, you'll be looking at some degree of re-architecting at least every few years anyway to cope with the 10x system problem. If using FaaS can be a quick bandaid solution to get you up and running without worrying about having to design your own equivalent of the fail whale, then a certain degree of lock-in might be worth paying.

A couple of years down the road, however, will give you both personnel and money to handle a re-architecture.

FAAS (Or, MSA) adds a ton of complexity right off the bat. Why take on that risk when you have little money and less time?

Re: Serverless and startups

#48

Post by qaq »

scarface74 wrote: post #38
qaq wrote: post #35

Earlier quoted context omitted.

Ive seen people having to wake up way more often when running overarchitected systems that is beyond their ops capability vs having simple solution that requires manual intervention a few times a year. So the proper solution would be what say for PG: HAProxy in HA configuration + Patroni (so ETCD). So from running 2 postgres instances you went to running 3 postgres instances a distributed database Patroni HAproxy in…

Or I can just let AWS do the work and not worry about it running HAProxy, Patroni, etc.

Sure but at a very different price point.

Re: Serverless and startups

#49

Post by qaq »

scarface74 wrote: post #37
qaq wrote: post #30

Earlier quoted context omitted.

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?

If by “persistent processes” you mean storing state locally. You usually shouldn’t be counting on that anyway. My VMs are just as disposable as lambda. API Gateway - we use API Gateway even for our VM hosted APIs for the other features it provides. We also integrate with swagger so creating and maintaining our API Gateway set up is basically automatic. Not having to learn a bunch of AWS services - if you are using AW…

there is startup cost you pay in latency. You have to debug systems in prod not just in dev and debugging lambda used to be pretty crappy experience. "if you are using AWS for more than just hosting VMs" thats the thing the original question was how is better for avg starup than simple DO setup?

Re: Serverless and startups

#50

Post by falcolas »

scarface74 wrote: post #38
qaq wrote: post #35

Earlier quoted context omitted.

Ive seen people having to wake up way more often when running overarchitected systems that is beyond their ops capability vs having simple solution that requires manual intervention a few times a year. So the proper solution would be what say for PG: HAProxy in HA configuration + Patroni (so ETCD). So from running 2 postgres instances you went to running 3 postgres instances a distributed database Patroni HAproxy in…

Or I can just let AWS do the work and not worry about it running HAProxy, Patroni, etc.

Sadly, you'll still encounter pages in the middle of the night (well, if you implement the monitoring) when AWS services fail and you need to write up a support ticket.

Granted, they're usually already aware of it, but it can still take tens of minutes to hours to resolve - time during which you are down.

Post reply on HN