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

381–390 of 670 posts

Re: The Serverless Revolution Has Stalled

#381

Post by [deleted] »

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…

[deleted]

Re: The Serverless Revolution Has Stalled

#382

Post by ashtonkem »

0x008 wrote: post #378

I find that this is such a bold claim, when the original study cited only states that 63% of respondents did not plan to deploy any microserve-based architectures in the upcoming years. However, 37% do. That is a LOT. And there is not a single data point relating to the years prior, so a claim that the "revolution has stalled" is actually impossible to make, because we do not know if there ever was one.

Micro services are one of the most thorny naming issues in CS. What exactly do you mean by “micro services”? The breadth of definitions for that specific term means that by some counts, there is basically no company in the world that doesn’t deploy some micro services, or there are basically no companies that do. Depends on who you ask.

Re: The Serverless Revolution Has Stalled

#383

Post by ChicagoDave »

ChicagoDave wrote: post #29

I take issue with all of the complaints here... - performance: first rule of architecture is that you don't build the entire thing on the needs of high performance...you only address performance as-needed - vendor lock in: this is the worst reason. Most companies choose cloud vendors and stick with them over many years. I'd love any survey that showed some massive migration between vendors on a regular basis, but it…

Replying to my own comment because I went looking for a current article on vendor lock-in. This is anecdotal and I get that, but I agree with it:

https://www.cloudtp.com/doppler/is-vendor-lock-in-keeping-yo...

We’re not buying into IBM mainframes anymore and although there are still customers tied to Oracle databases, vendor lock-in just isn’t that big of a deal anymore.

Re: The Serverless Revolution Has Stalled

#384

Post by ashtonkem »

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…

So get a cheap EC2 machine instead. There are reasonable steps between “buy your own hardware” and “everything is a Lambda”.

Re: The Serverless Revolution Has Stalled

#385

Post by pm90 »

spyspy wrote: post #277
crehn wrote: post #263

Earlier quoted context omitted.

The psychological effects of technology seem often overlooked—and they’re hard to quantify. I wish there was some easier way to quantify the “soft” aspects of everything that surrounds us, e.g. the long-term impact of beautiful and usable UI design, the reduction in “ambient” psychological stress, the impacts of chaos/consistency on how we feel, any robust measures of happiness, excitement, relaxation, etc. They seem…

My joke around the office is some people optimize for latency, some for throughput, some for memory usage. I, however, optimize for sleep. My entire goal is for my services to never wake me up. And if they do it had better because I clearly messed up and am the sole human alive able to fix it.

> I, however, optimize for sleep.

Bravo.

Having been on call for some truly monstrous amount of things and seen things break in all kinds of ways... I can't agree more with this principle.

While the cloud isn't cheap, if your org can afford it, there is no question about it: go with managed services. Focus on building things, leave the OPS to AWS/GCP/Azure.

Re: The Serverless Revolution Has Stalled

#386

Post by ashtonkem »

x86_64Ubuntu wrote: post #355
justinram11 wrote: post #220

As someone on a two-man-team who runs a lot of little "utility" functions in AWS Lambda with the Serverless Framework[1] to support our DevOps / Build processes, it's been one of the most productive tools in my toolkit (after the initial learning curve, of course). It allows me to stand up a practically maintenance-free endpoint in a matter of hours (usually to glue separate services together): * Want to run a quick…

Is anyone else worried about the proliferation of disjoint processes that people can whip up using Serverless? At least with a monolith, you've got a relatively coherent grouped together codebase. But with Serverless, you can have some lambda that is infinitely important, but not documented or well known to anyone else in the org.

If you deploy enough Lambdas that depend on each other you effectively end up with a monolith, but the call paths are done through HTTP instead of method dispatch. Arguably this is worse, since discoverability and modification can become extremely difficult.

Re: The Serverless Revolution Has Stalled

#387

Post by justinram11 »

wokwokwok wrote: post #376
justinram11 wrote: post #220

As someone on a two-man-team who runs a lot of little "utility" functions in AWS Lambda with the Serverless Framework[1] to support our DevOps / Build processes, it's been one of the most productive tools in my toolkit (after the initial learning curve, of course). It allows me to stand up a practically maintenance-free endpoint in a matter of hours (usually to glue separate services together): * Want to run a quick…

Sounds like its working for you, which is great, I guess. However in general what you're doing isn't devops, its 'devs creating a big old mess for someone else to cleanup later'. All you're doing is trading long term maintainability and quality for 'getting it done right now'. Sure; it works. I get it. ...but I've also been on the receiving end when that 2-person team has 1 person leave and gets scaled up to a 5-pers…

While I think that there is definitely a worry of it turning into a big old mess (especially if they start depending on and talking to each other), I don't really know that I'd consider cron-job style independent one-off tasks any more maintainable in a monolith. I also don't know that I'd consider that specific to serverless (it's easy to create a ball of mud in anything).

All of our serverless projects are located in a single repository, and each little service gets its own little google doc that explains what it does, what functions it has, and any resources that it uses.

As mentioned below, as soon as an ETL gets multiple steps I agree that pure-lambda is not the right tool for the job (Airflow would be my preference, though we've also successfully used Step Functions)

Re: The Serverless Revolution Has Stalled

#388

Post by mrmonkeyman »

mark242 wrote: post #247
crehn wrote: post #241

Earlier quoted context omitted.

And I’d argue the mere possibility of the server breaking at any time contributes to non-negligible amounts of sustained psychological stress.

Yes, this exactly. The fact that I can guarantee that my code is running, and have entire massive teams at Amazon whose literal job title is to keep my code running, it is such a freeing feeling. I might be able to delete rows from Dynamo from my code messing up, but Dynamo will never go offline.

Yet outages are everywhere and data leaks all over the place..

Re: The Serverless Revolution Has Stalled

#389

Post by nafey »

wokwokwok wrote: post #376
justinram11 wrote: post #220

As someone on a two-man-team who runs a lot of little "utility" functions in AWS Lambda with the Serverless Framework[1] to support our DevOps / Build processes, it's been one of the most productive tools in my toolkit (after the initial learning curve, of course). It allows me to stand up a practically maintenance-free endpoint in a matter of hours (usually to glue separate services together): * Want to run a quick…

Sounds like its working for you, which is great, I guess. However in general what you're doing isn't devops, its 'devs creating a big old mess for someone else to cleanup later'. All you're doing is trading long term maintainability and quality for 'getting it done right now'. Sure; it works. I get it. ...but I've also been on the receiving end when that 2-person team has 1 person leave and gets scaled up to a 5-pers…

This assumes that survival is guaranteed if you do it the right way. Long term thinking can work in firms that are larger. For smaller firms with limited resources, motivation and technical expertise getting velocity is crucial. This is one of the reasons startups run into issues when they have to scale. I think it has to be a well thought out balance of speed and quality that is required in such environments.

Re: The Serverless Revolution Has Stalled

#390

Post by zaarn »

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…

That's why you have three hetzner servers, so if one goes toast, you still have a redundant operation as you can easily failover while you recover the other host.
Post reply on HN