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

Serverless: slower and more expensive

einaregilsson.com

Post reply on HN
Print view View original

191–200 of 733 posts

Re: Serverless: slower and more expensive

#191

Post by jrochkind1 »

While there is a lot of lambda/serverless hate in this thread, I (who have no experience with it) am reluctant to conclude based on this alone that lambda is useless/stupid. Need more info.

Is there anyone who has had success using lambda, or can anyone find a write-up of a success story?

That would help me (and others) understand/believe better I think; if it's a very rare case where lambda ends up being helpful (which is the opinion of this HN thread apparently), a case study write-up of a real world success story would still help us understand when we _aren't_ in that situation.

Re: Serverless: slower and more expensive

#192

Post by jammygit »

laumars wrote: post #72

It's not as clear cut as the article describes though. For low usage stuff serverless is cheaper. For "spiky" traffic - particularly when those spikes are unpredictable - serverless is often cheaper and sometimes faster too (eg if your spikes ramp up quicker than the spin up times of virtual machines). Also AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn't need benchm…

I thought the main idea behind it was that it was supposed to be easier to develop for. Are there savings there that make up for the aws costs?

Re: Serverless: slower and more expensive

#193

Post by bdcravens »

coldtea wrote: post #69
cryptica wrote: post #17

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…

> We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) That goes without saying! That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. I don't think anybody uses things like AWS or serveless…

If we really want easy, we’d all be writing ColdFusion or Visual Basic.

Re: Serverless: slower and more expensive

#194

Post by snak »

vasco wrote: post #4

> To be honest I hadn't thought at all about the pricing beforehand. I just figured "Pay for what you use" sounded like it would be cheaper than paying for instances that are on 24/7. Deciding to do a whole infrastructure change to save money without even stopping 5mins to do a quick math on the expected savings seems like a recipe for disaster. Just switching from m1.small to t2.small would bring their costs down to…

> It's like renting a car 365 days out of the year instead of purchasing, it only makes sense if you only need it sporadically.

Spot on! Great analogy.

Re: Serverless: slower and more expensive

#195

Post by dave_sid »

tus88 wrote: post #164
cryptica wrote: post #17

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…

This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.

While in most cases I would agree, in this case I have to disagree. I think serverless has been a good idea implemented badly in every instance.

Re: Serverless: slower and more expensive

#196

Post by 1337shadow »

I recently saved a company from serverless: development had completely stalled, continuous delivery was insanely inefficient (you couldn't deploy your set of functions at once because of dependencies), vendor lock-in made it a pain to develop locally (cognito in particular), CI testing was also a big pain (serverless-offline), the project also had reached the endpoint limit so basically they had to split the project (it wasn't even in production at the time ...) a dev implemented an aggregator for serverless config so that they could keep on working locally ... An epic disaster, we all thought there was no way this company wouldn't die, the founder developed suicidal thoughts and I could only understand him.

All my congratulations to the "Agile leading company" that provided a 800€/day consultant (probably going to read this) who just followed the tutorial to setup a new project on serverless without any web framework, because you know, "it's the future", and "i like to sleep at night", after they and some of the team had been brainwashed by an AWS event (my initial review concluded with "I admire the courage to start a project without a framework" which was replied with "what is a framework ?"). A waste of hundreds of thousands bucks, but that was not the only mistake : they had 100% code coverage from tests but all tests like all the runtime code was wrapped in huge try...except blocks, I have never seen a team talk as much about "Clean Code" and have such a pile of debt. The Agile company consultant called in recently and said they were sorry, that actually Lambda wasn't good for the use case, and that the consultant was now senior and twice the price.

The company now deploys with Ansible and Docker with compose and practicing what I call eXtreme DevOps (one ephemeral deployment per branch on branchname.ci.example.com), development is back on track, new versions every week... They also trashed the serverless code in favor of a Django Rest Framework app that I coded in 3.5 hours during a night after being there for 2-3 weeks (it was the 6th or 7th week that development had stalled "refactoring" "making lambda happ" "trying to have a local environment"), basically presented it to the team the next day at the retro (where we could see nothing creating value was actually moving forward) and said: make your serverless thing work, or let the frontend people choose what they want to build on : a backend code that became an unusable pile of debt or a backend code that works, presents a self-documented REST API, with an administration interface that they needed, and save the company by creating value instead of "just trying to fit into the proprietary framework that is serverless lambda".

Re: Serverless: slower and more expensive

#197

Post by ilimilku »

tedk-42 wrote: post #12

I disagree with all the comments posted so far. This should be a perfect use case for lambda, not "oh you're API is receiving more than 10M req/day? Use Elastic Beanstalk instead with an EC2 instance and ELB". This kind of comment is just to abuse the free tier that AWS provide you with. The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fo…

Exactly. This guy nails it. The serverless paradigm is a managed service, so you are paying extra for that management. Serverless also is built for automated connectivity within the AWS ecosystem, i.e. as a nerve center for all of AWS's nifty gizmos. This is why Amazon places such an emphasis on training certified solutions architects who know what works best for each situation.

Re: Serverless: slower and more expensive

#199

Post by cameroncf »

abiro wrote: post #50

PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article: 1. Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go. 2. Use managed services whene…

> PSA: porting an existing application one-to-one to serverless almost never goes as expected.

Came here to post this and agree 100%. Moving to Serverless requires evaluating the entire stack, including the server side language choice, and how the client handles API calls.

Often a move to serverless is better accomplished gradually in stages than the quick "lift and shift" that AWS like to talk about so much. Sometimes you can simply plop your existing app down in Lambdas and it runs just fine, but this is the exception not the rule.

Re: Serverless: slower and more expensive

#200

Post by Hokusai »

neuronic wrote: post #144

It's concerning how typical the hype machine is in IT. I believe Serverless has its place and value. So does Kubernetes or many other products that are often discussed on HN. But let's be clear, we are talking about commercial products and there is a capital interest in selling these services to all of us devs and engineers. So while use cases exists and benefits wait to be reaped, as a consultant I strongly feel tha…

> It's concerning how typical the hype machine is in IT.

Software engineering is still a young discipline. Probably half of the people have less than 4 years of experience. They learned from other employees that also had less than 4 years of experience. And that can be repeated for 10 generations of developers.

We are learning, and re-learning the same lessons again and again. Everything seems new and better and then we are surprised when it's not a silver bullet.

Software and cloud vendors do not help. They are the first ones to hype their new language, framework or platform. Technology lock-in is a goal for tech companies offering hardware or services.

> This is not engineering with objectives in mind

Curriculum driven development is a thing. And I cannot blame developers for it when the industry hires you and sets your salary based on it.

We need to be more mature and, as you suggest, think about our technical and business goals when choosing a technology instead of letting providers lock us in their latest tech.

Post reply on HN