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

The Serverless Revolution Has Stalled

infoq.com

Post reply on HN
Print view View original

521–530 of 670 posts

Re: The Serverless Revolution Has Stalled

#521

Post by sippingjippers »

nebulous1 wrote: post #509
sippingjippers wrote: post #471

Earlier quoted context omitted.

It's not clear to me how much experience with serverless architectures the author of the parent comment has, but speaking as someone with plenty, the operational costs of serverless are at least equal to managing stateful infrastructure, with much less control when things go wrong. Lambda was a major step up in long term predictability compared to for example App Engine, where there have been plenty of instances of o…

> try rebooting the instances I haven't done anything with serverless, but surely the class of problems that would be fixed by an instance restart don't happen in the first place on serverless

It was intended more to invoke general ideas about management ease than being a specific remediation, however elsewhere in the thread there is an example of a diagramming tool split out across 37 individual AWS services/service instances. In a traditional design, this is conceivably something where all state and execution could easily fit in one VM, or perhaps one container with the state hoisted off to a managed service. In this case we could conceivably fix some problems with an app like that literally just by kicking the VM

Re: The Serverless Revolution Has Stalled

#523

Post by ajsnigrutin »

nicbou wrote: post #492
jeroenhd wrote: post #483

Earlier quoted context omitted.

One reason serverless isn't the solution for most applications is that you're basically making yourself entirely dependent on the API of one specific cloud host. If Lambda decides to double its price, there's nothing you can do about it but pay. If you need to store your data in a specific place (for example, in Russia, because all Russian PII must be stored in Russian borders), then you're out of luck. And best of l…

You can also predict the costs, and shop around if your provider gets greedy. If Amazon changes its pricing structure, what are you supposed to do?

It's a lot easier to change providers, if your service is an (eg.) docker image(s), than to move something relying on amazons api.

Re: The Serverless Revolution Has Stalled

#524

Post by VHRanger »

nicbou wrote: post #492
jeroenhd wrote: post #483

Earlier quoted context omitted.

One reason serverless isn't the solution for most applications is that you're basically making yourself entirely dependent on the API of one specific cloud host. If Lambda decides to double its price, there's nothing you can do about it but pay. If you need to store your data in a specific place (for example, in Russia, because all Russian PII must be stored in Russian borders), then you're out of luck. And best of l…

You can also predict the costs, and shop around if your provider gets greedy. If Amazon changes its pricing structure, what are you supposed to do?

If you built everything in proprietary infrastructure, porting is a lot more work.

Using lambdas tie you to AWS because as soon as you use a few step functions, or you have a few lambdas interacting, changing to Azure or GCP becomes a huge pile of dev work and QA.

Having everything "just run" on linux instances let you be perfectly portable and now you can actually shop around.

Re: The Serverless Revolution Has Stalled

#525

Post by deepstack »

nicbou wrote: post #478

I don't buy into serverless. I went to a webdev convention, and it ended up being a serverless hype train. Industry experts with a financial incentive to promote serverless went on stage and told me they can't debug their code, or run it on their machine. They showed me comically large system diagrams for very simple use cases, then spent an hour explaining how to do not-quite-ACID transactions. Oh yeah and you can o…

Serverless is meant to make bar lower for front-end developer so they don't have to learn the basics about web back-end development and be able to develop apps. I'm very glad if failed!

People who don't put time into learning development should not do it.

Re: The Serverless Revolution Has Stalled

#526

Post by swiley »

mark242 wrote: post #222

Here's why I love serverless. I cannot tell you the number of times I have implemented "upload your photo and it'll get resized to (profile avatar size from design specs)". It's ridiculous, and it's one of those things that everyone burns time implementing their fun hook into Imagemagick. Now I have one lambda that gets pointed at a new record stream from an S3 bucket, and I'm done. I cannot tell you the number of ti…

This sounds like libraries but with an extra spot where you can be charged money if something breaks.

Re: The Serverless Revolution Has Stalled

#527

Post by finnthehuman »

mark242 wrote: post #235
Demiurge wrote: post #227

Earlier quoted context omitted.

How is owning an AWS account easier than a cheap dedicates server? You should have a code repo and backups in either case. At least some people mention "but I can scale this lambda x1000" and that's one advantage... But you can do all those tasks on a hetzner server in same amount of type, just python scripts.

Because that "cheap dedicated server" isn't all that cheap. Just the documentation for backups on your Hetzner server is ridiculous. Why, in the 21st century, should I as an application developer ever have to worry about that? Let's say that Hetzner server goes completely toast at 2am and you get a pingdom message. You log in, realize you have to restore from backup. You fire up a new instance, and go through your re…

>Just the documentation for backups on your Hetzner server is ridiculous. Why, in the 21st century, should I as an application developer ever have to worry about that?

I dunno, that's a problem for the ops team. It was in the 20th century too. The only reason you would have to worry about it is if you're pulling double duty as under-trained ops. If that were the case the right answer to every "build or buy" question is "buy" because you don't have anyone with the domain knowledge to bring more architectural options to the table than 'half-ass server management with internet tutorials.'

Re: The Serverless Revolution Has Stalled

#528

Post by nickjj »

lstamour wrote: post #417
nickjj wrote: post #252

Earlier quoted context omitted.

> Instead, you can write a function that takes parameters from elsewhere and call your business logic there. This is what I tried to do initially after experiencing the dev pain for only a few minutes. But unfortunately this doesn't work very well in anything but the most trivial case because as soon as your lambda has a 3rd party package dependency you need to install that dependency somehow. For example, let's say…

Unless I’be misunderstood, every knock against serverless above has actually been a knock against the complexity of having tiny, de-coupled cloud native services and how difficult it can be to mock... to which the answer is often “don’t mock, start by using real services” and then when that is less reliable or you need unit tests, then mock the data you expect. In the case of SNS, mock a message with the correct SNS…

> In the case of SNS, mock a message with the correct SNS signature, or go one layer deeper, stub out SNS validation logic.

SAM already provides a way to mock out what SNS would send to your function so that the function can use the same code path in both cases. Basically mocking the signature. This is good to make sure your function is running the same code in both dev and prod and lets you trigger a function in development without needing SNS.

But the problem is locally invoking the function with the SAM CLI tool is the trigger mechanism where you pass in that mocked out SNS event, but in reality that only works for running that function in complete isolation in development.

In practice, what you'd really likely want to do is call it from another local service so you can test how your web app works (the thing really calling your lambda at the end of the day). This involves calling SNS publish in your service's code base to trigger the lambda. That means really setting up an SNS topic and deploying your lambda to AWS or calling some API compatible mock of SNS because if you execute a different code path then you have no means to test the most important part of your code in dev.

> In the case of Postgres, you could use an ORM that supports SQLite for dependency-free development but at a compatibility cos

The DB is mostly easy. You can throw it into a docker-compose.yml file and use the same version as you run on RDS with like 5 lines of yaml and little system requirements. Then use the same code in both dev and prod while changing the connection string with an environment variable.

> That’s not exactly a knock against serverless itself, is it?

It is for everything surrounding how lambdas are triggered and run. But yes, you'd run into the DB, S3, etc. issues with any tech choice.

Re: The Serverless Revolution Has Stalled

#529

Post by 1337shadow »

raxxorrax wrote: post #520
nicbou wrote: post #478

I don't buy into serverless. I went to a webdev convention, and it ended up being a serverless hype train. Industry experts with a financial incentive to promote serverless went on stage and told me they can't debug their code, or run it on their machine. They showed me comically large system diagrams for very simple use cases, then spent an hour explaining how to do not-quite-ACID transactions. Oh yeah and you can o…

I bought into hosting stuff on AWS, specifically on EBS which I assume is meant by a 'serverless' infrastructure, but I don't know crap about it. Still think it is mostly awesome and the services are solid. But such infrastructure comes with its own caveats. EBS now bugs me about some 'HealthCheckAuthEnabled'. I don't know what it wants, just that I have limited time to react. Cannot understand the clearly auto-trans…

> Hosting your own server is a lot of work and isn't fun.

For me it's easy because i just maintain my ansible roles.

It's fun because I get to keep up with OSS and be part of an amazing community.

And I get much better hardware for the price.

Re: The Serverless Revolution Has Stalled

#530

Post by k__ »

eghri wrote: post #248
k__ wrote: post #160

Earlier quoted context omitted.

SAM is okay-ish. Felt still better than K8s to me. Have you tried Amplify?

I found Amplify excellent to get up and running quickly. I’d highly recommend it for anyone without a well-oiled CICD setup who wants to quickly get a website up to test out an idea. Unfortunately, I quickly hit the limits of its configurability (particularly with Cloudfront) and had to move off it within a few months.

Care to elaborate on the limits you hit?
Post reply on HN