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

51–60 of 79 posts

Re: Serverless and startups

#51

Post by martimatix »

arnvald wrote: post #29
jlangenauer wrote: post #2

I do wonder if, in a few years time, if we're not going to be seeing a new genre of technical blog posts: "How we migrated off serverless to reduce our costs"

It's already started: https://medium.com/coryodaniel/from-erverless-to-elixir-4875...

The article talks about moving away from a serverless architecture due to the cost of API gateway.

I wonder if the fact that application load balancer can now invoke lambda functions could've made serverless viable. https://aws.amazon.com/about-aws/whats-new/2018/11/alb-can-n...

Mind you, the post was written in August 2018 and the above announcement was made in December 2018.

Re: Serverless and startups

#52

Post by dustingetz »

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…

the point of serverless is that everything is much simpler, it is just functions! it is more a question of how early do you break even on ROI in simplicity, and maybe that isn’t in the first 6 months of a startup’s life yet. But in the future the break even point may be zero minutes.

Re: Serverless and startups

#53

Post by scarface74 »

qaq wrote: post #48
scarface74 wrote: post #38

Earlier quoted context omitted.

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.

And too often, developers (smaller companies) and ops (larger companies) time is considered free because they are salaried and are expected to work more than 40-45 hours per week.

Yes, earlier in my career I would have accepted that, but I’ve successfully pushed back a few times and said I won’t babysit a process/server etc but I will design a method where it is auto healing, autoscaling, etc.

Re: Serverless and startups

#54

Post by scarface74 »

falcolas wrote: post #43
scarface74 wrote: post #23

Earlier quoted context omitted.

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.

In the case of .Net at least, you write your API like you always do and the SDK provides a wrapper. You can have multiple actions/controllers just like you would with a traditional Web API project.

https://aws.amazon.com/blogs/developer/serverless-asp-net-co...

You test locally just like you would any other WebAPI project.

Re: Serverless and startups

#55

Post by scarface74 »

qaq wrote: post #49
scarface74 wrote: post #37

Earlier quoted context omitted.

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?

You debug systems in prod with lambda just like you do with anything else - via a good logging infrastructure.

As far as how it’s better for a startup?

With AWS I get hosted Load balancers, multi AZ redundancies, autoscaling, managed queues, databases with failover, a mobile push infrastructure, unlimited storage, etc.

All stuff I don’t have to manage myself. There is absolutely no way that I could both develop and babysit infrastructure if it was all just a bunch of VMs. The money we save by not having a dedicated ops department and just one guy who does the grunt work more than makes up for the cost of AWS.

Not to mention, the speed at which I can stand up infrastructure.

Re: Serverless and startups

#56

Post by tirumaraiselvan »

thegeomaster wrote: post #42
tirumaraiselvan wrote: post #41

Earlier quoted context omitted.

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).

I see, but security aside I am not sure how the latency is impacted by having a serverless on a DynamoDB VPC endpoint.

BTW, you can expose RDS out to the internet.

Re: Serverless and startups

#57

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…

This is very good insight and I suppose lot of people would be facing the same issues.

I think latency is an issue when you use Lambdas for sync operations. Fundamentally when using serverless, I think your application should become fully async i.e. event-driven. You may look at the 3factor pattern[1] to see if it's any better. Basically, 3factor says that all you should do in your application is simple operations, like CRUD, and emit events which trigger serverless functions (which create more events and so on). You should asynchronously receive updates via something like realtime GraphQL.

[1] https://3factor.app

Re: Serverless and startups

#58

Post by dyeje »

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…

There are frameworks like Serverless [1] that allow you to deploy to different public clouds so vendor lock in isn’t a huge issue.

[1] https://serverless.com/

Re: Serverless and startups

#59

Post by joekrill »

petra wrote: post #32
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 ?

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

Well, Startups! That's sort of common for startups, isn't it? I realize the term is basically being used to describe almost all "small businesses" these days, but I think it's fairly common for startups to have very short runway. That would (ideally) get longer as the startup matures. But I don't think it's uncommon at all.

Re: Serverless and startups

#60

Post by collyw »

dustingetz wrote: post #52
jasonkester wrote: post #44

Earlier quoted context omitted.

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…

the point of serverless is that everything is much simpler, it is just functions! it is more a question of how early do you break even on ROI in simplicity, and maybe that isn’t in the first 6 months of a startup’s life yet. But in the future the break even point may be zero minutes.

Its just moving complexity from one place to another though, isn't it? From the application layer to the deployment layer.
Post reply on HN