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

601–610 of 670 posts

Re: The Serverless Revolution Has Stalled

#601

Post by gnarcoregrizz »

treespace89 wrote: post #592
randomsearch wrote: post #570

Earlier quoted context omitted.

I don't think you're wrong, I just think you're not looking far enough ahead. What we have now is very primitive compared to how app development might work in the future; serverless is laying the foundation for a completely different way of thinking about software development.

I think I understand your point. It's more back to the mainframe model of software development. I did this back in the 90s and I never had to think about scaling. Granted these were just simple crud / back-office apps. But I can see how it would work for most modern software.

The mainframe model is viable (and legitimate) again because you can buy 128 core machines. That’ll have no problem running at people’s businesses

Re: The Serverless Revolution Has Stalled

#602

Post by smoyer »

> Is This a New Idea?

I haven't seen it noted in the discussion below but there's an earlier incarnation of the so-called serverless architecture. Early mainframes could be leased outright or you could buy time on them, in some cases on an ad-hoc basis for one-time batch workloads.

Re: The Serverless Revolution Has Stalled

#603

Post by thaeli »

t0astbread wrote: post #327
SiVal wrote: post #314

Earlier quoted context omitted.

A very good point. Exchange the risk of a problem taking you offline, losing sales, for the risk of a problem not taking you offline, costing you a fortune. That's a big selling point for DigitalOcean: you sleep easy knowing what your bill will be. If you have an unexpected spike in traffic--whether a great opportunity, a mistaken test run wild, or a DDoS--it doesn't increase your bill. AWS offers the opposite: no ma…

A middle ground between both would be ideal. Does AWS offer settings to cap your spendings? (I googled and found AWS Budgets but it seems to be only an alerting system, not a cap.)

The recommended solution is, ironically for this topic, to have your billing alerts trigger Lambda functions you've written to shut down your infrastructure.

Re: The Serverless Revolution Has Stalled

#604

Post by lstamour »

nickjj wrote: post #528
lstamour wrote: post #417

Earlier quoted context omitted.

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

So there’s an argument that the future deployment model is actually Kubernetes Operators, which means you could have test code that deploys and sets up AWS APIs... thus if your code responds to the trigger, it’s up to another bit of code to make sure the trigger is installed and works as expected against AWS APIs?

And yes, I think the problem here are APIs you use in multiple places but can’t easily run yourself in a production-friendly way. Until AWS builds and supports Docker containers to run their APIs locally, I don’t see how this improves... end to end testing of AWS requires AWS? ;-)

Re: The Serverless Revolution Has Stalled

#605

Post by mylons »

autotune wrote: post #597
mylons wrote: post #262

Earlier quoted context omitted.

AWS Lambda logs to Cloudwatch, and has monitoring out of the box.

Very poor logging and monitoring, in my experience.

Poor how? Do you not like the UI? The UI is not the best, but there’s no issue in reliability.

Re: The Serverless Revolution Has Stalled

#606

Post by jacques_chester »

myrloc wrote: post #240
jacques_chester wrote: post #157

Earlier quoted context omitted.

> I realized that local development was difficult because I was coupling my code to the delivery. Of interest, I've spent some free time crunching on CNCF survey data over the past few months. Some of the strongest correlations are between particular serverless offerings and particular delivery offerings. If you use Azure Functions then I know you are more likely to use Azure Devops than anything else. Same for Lambd…

I’d be interested in seeing more of your results, no matter how raw they are.

My email address is in my profile. Personal is best, I've been crunching it on my own time.

Re: The Serverless Revolution Has Stalled

#608

Post by nickcotter »

znpy wrote: post #539
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 view the serverless, specifically aws lambda, as nice way to hook into the aws system and add some code to handle certain events. Basically, to customize the behavior of "the cloud" where aws falls short (for whatever reason). But developing with "serverless" as base stack? Nope.

That’s what we’ve been using it for, for the most part. Plugging holes in CloudFormation etc.

Re: The Serverless Revolution Has Stalled

#609

Post by TheCoelacanth »

f1refly wrote: post #419
crehn wrote: post #330

Earlier quoted context omitted.

I’m assuming this is a joke, but this is exactly what most people who just want to run some code don’t want to deal with.

I like how people here pretend like this is some hard task that should only be done by experts when I know fifteen-year olds who figured this out all by themselfes for backing up their game servers

It's not monumentally hard or anything, but it still takes time and attention that I don't want to spend.

For a small business, it makes sense to outsource things like that, even you if you could conceivably do it in-house.

Re: The Serverless Revolution Has Stalled

#610

Post by methodin »

michaelt wrote: post #442
methodin wrote: post #430

Earlier quoted context omitted.

I disagree. Every AWS Lambda function I've ever written can be ran as a regular node/python process. The lambda-specific part is miniscule. If I wanted to run these on Azure or Google only the most inconsequential parts of the function would need to be changed.

In my experience, having started and abandoned side projects in both aws lambda and google app engine, half your project becomes: * Well, obviously we use a hosted database * And obviously, AWS provides our logging and all our analytics. * Obviously when people call our lambda functions, they do so either through an AWS-specific API, or one constrained to a very limited set of forms. * Of course, we can't blindly let…

Most of your points are not relevant to my original statement of the code being generic - they are talking more about the architectural decisions. If I want to use DynamoDB I can do so in EC2 or Lambda, serverless doesn't dictate that. You also seem to believe one chooses Lambda because of complexity reduction and that's not really the only reason. I can very easily port a node/express API backend that connect to RDS to any other cloud provider. What about serverless makes you think that's not the case?
Post reply on HN