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

31–40 of 79 posts

Re: Serverless and startups

#31

Post by jxub »

arnvald wrote: post #24

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…

There are frameworks like Serverless (the kinda default choice, `npm install -g serverless`), Zappa (in Python, not really up to date) and Apex (simple and nice option that is installed as a single Golang executable), that automate the back and forth between the API Gateway and Lambda in a config file.

Re: Serverless and startups

#32

Post by petra »

joekrill wrote: post #12

I would think the biggest concern with "Serverless" would be vendor lock in. If a large portion of your SaaS product is "serverless" it's going to be very difficult to move when company A raises their prices, or company B comes in with a much more compelling product or price point. Admittedly I don't know enough about the details to know how big of a deal this could be, or whether there is work toward a universal "se…

>> But I don't want Amazon/Google/Whoever suddenly raising their rates 2 years from now causing my startup to go under because the margins are so tight.

What kind of businesses run on very tight margins, that even some increase in the IT bill can cause them to fail ?

Re: Serverless and startups

#33

Post by jasonkester »

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 had one guy build his entire product in a day as the equivalent of the "20 Minute Rails Blog Demo". Then shipped it via any of the thousand-odd boring ways to deploy such a thing.

He'd still have the same number of months to worry about stacking all those blocks into that unmaintainable tower of pain, but in the meantime his product would be out in the wild. Possibly even attracting the users that might one day make such a silly architecture necessary.

As it is, he'll still ship one day. But my money is that he'll never see traffic that would overload a single server.

Because that's what happens with 99% of the things one ships. The other 1% you can fix as needed. Possibly using AWS Lambda for the pieces that need it.

Re: Serverless and startups

#35

Post by qaq »

scarface74 wrote: post #22
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.

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 HA configuration so you need floating IP some heartbeat service etc.

Re: Serverless and startups

#36

Post by matwood »

arnvald wrote: post #24

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…

Have you done much with a framework like Serverless? The simplicity comes in because you can start writing business logic functions immediately. Plain Node typically uses a library like Express or Hapi. While not complicated, it is one more thing that is boiler plate and doesn't provide any business value.

If the app needs a queue or messaging, sticking to plain node does not really change the need.

Re: Serverless and startups

#37

Post by scarface74 »

qaq wrote: post #30
scarface74 wrote: post #23

Earlier quoted context omitted.

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?

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 AWS for more than just hosting VMs, you would have to learn AWS anyway. Even if you are hosting a bunch of VMs, you still need to know about security groups, VPCs, subnets, ELBs, route 53, autoscsling etc.

Creating a lambda is adding one function to your code.

Easy to debug? Your code should not know nor care that you’re running serverlessly outside of your lambda handler. You test and debug your lambda code just like people have been testing APIs forever.

You dry up a test harness that calls the entry point of your domain logic. I don’t mean real AAA automated test, just an entry point for manual debugging.

Re: Serverless and startups

#38

Post by scarface74 »

qaq wrote: post #35
scarface74 wrote: post #22

Earlier quoted context omitted.

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.

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.

Re: Serverless and startups

#39

Post by [deleted] »

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…

[deleted]

Re: Serverless and startups

#40

Post by slobodan_ »

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 early phase. It's about financial incentives — also, about focus, ability to move fast and test ideas, and the ability to grow without shooting future self into the foot.

We still often fail to do things fast enough, but we are aware of the problem and working hard to fix it.

Post reply on HN