Live data from Hacker News

Serverless and startups

aws.amazon.com

11–20 of 79 posts

Re: Serverless and startups

#11
post #8

I was recently talking with some folks at an incubator about a website I was building, and one of the technical guys suggested I consider switching to serverless before launching (and I thought it was a good suggestion). Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability. This is purely anecdotal, but the majority of startups I've seen - including my own work - do n…

> Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability.

Only as long as you (like Amazon's post) don't have a relational database in that architecture graph.

Serverless makes it way easier to scale your application server logic, but not necessarily your persistence layer. If you choose a relational database, you can run into peak load problems where you can't scale the database fast enough to meet huge spikes of load. It's completely up to you to either set a processing limit somewhere, or avoid persistence layers with peak scale problems.

I look forward to the day when AWS Aurora Serverless Postgres is in GA, but until then, if you want to deal with really bursty loads (like suddenly going from zero to thousands of simultaneous requests scaled out across Lambda when an ad runs), you either have to manually scale things up ahead of time, or be prepared to deal with Aurora Postgres cluster failovers and outages. You can't go from zero to huge on the relational database side without minutes/hours of infrastructure changes (or huge ongoing bills for capacity you're not using.)

Re: Serverless and startups

#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 "serverless" standard. 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. And for those that say this will never happen, look at what Google just did with their Maps pricing.

Re: Serverless and startups

#13
post #8

I was recently talking with some folks at an incubator about a website I was building, and one of the technical guys suggested I consider switching to serverless before launching (and I thought it was a good suggestion). Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability. This is purely anecdotal, but the majority of startups I've seen - including my own work - do n…

> Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability.

But is that kind of scaling really the hard part? If you're already using AWS for example, it is trivial to set up an autoscaling group that will add more EC2 instances the keep up with the rate of traffic. IME, scaling data stores is the hard part of scalability.

I'm not saying serverless doesn't make it a little easier, but it is a different tradeoff. AWS Lambda for example has a lot of limitations too. Maybe I'm interpreting your comment wrong, but I don't think it's fair to imply that serverless is the obvious choice for startups just because it helps overcome scalability.

Re: Serverless and startups

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

The useful thing is that in the case of at least Azure Functions, their back-end is open source. There's plenty of open source alternatives, so you can migrate to a bare metal hosted alternative if it brings down costs and maintains the same level of scalability. This also emphasizes the need for cloud agnostic frameworks.

Re: Serverless and startups

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

Well, at least you have a business. I find vendor lock in to be about the lowest priority on my list. Also, the lock in is pretty exaggerated. Just make sure to keep business logic separate from the cloud plumbing, as per the OP example.

Re: Serverless and startups

#16

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…

For a startup, though, if it succeeds, you have to assume that a good portion of the code will eventually be refactored at some point, or retired as the buisiness is flushed out.

I have a feeling we'll also see some projects for transferring Lambdas between IaaS providers, including on-Prem at some point. I'd be more concerned about lockin at the DB-level but even that could be accounted for with up-front decisions to not use Dynamo, etc. if you were really concerned.

Re: Serverless and startups

#17
post #10
post #7

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

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

Re: Serverless and startups

#18

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…

Lock in is very easy to avoid. Keep you business logic in separate modules and wrap any specific cloud sdk calls in helper functions. Any major move to a new provider should be much easier. Lock in is often a non-concern if you stick to basic engineering principles.

Re: Serverless and startups

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

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.

Re: Serverless and startups

#20

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…

The boogie man about serverless is overrated.

In the grand scheme of things, at least for AWS, the only thing you do to make your app “serverless” is add a function with two parameters as your entry point. If you’re following standard software engineering principals of keeping your interface and your business logic separate, it’s not that hard.

On the other hand, the fear of “vendor lock in” is overrated. You’re always “locked in” to your infrastructure. Companies hardly ever change their infrastructure wholescale. The risk of regressions are too high and it’s usually not worth it.

Besides, if you rely on AWS services and are letting AWS do the “undifferentiated heavy lifting”, converting lambdas is the least of your issues.

If you are just using AWS to host a bunch of VMs, congratulations, you now have the worse of all worlds. You’re spending more than baremetal and you still have all of the management overhead.

Post reply on HN