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

571–580 of 670 posts

Re: The Serverless Revolution Has Stalled

#571

Post by joana035 »

diggan wrote: post #511
sippingjippers wrote: post #486

Earlier quoted context omitted.

AWS in particular seem to have a carefully refined technical sales/certification/advocacy channel whose main product is those fucking stupid architecture diagrams. Hello world service with $4000/mo. worth of geo-replicated backing databases, CloudWatch alarms, API Gateway instances, WAF etc. But don't let it encourage you to think serverless has no value, or it can't be done portably or cheaply. It has its sweet spot…

Reminds of something that was on the HN frontpage some month ago, where readers are not sure if it's a parody or not, because of the architecture you're required to deploy yourself to use this new "Perspective" product. Direct link to the architecture, that in the end serves the use case of generating a diagram of your AWS resources: https://d1.awsstatic.com/Solutions/Solutions%20Category%20Te... https://aws.amazon.c…

Reading this made me remember that back in the day the AWS selling point was "here you can create virtual machines with few clicks and have it instantly instead of waiting 30 min for you colocated server to be ready" but now it seems to be "here is a bunch of random expensive tools, please, produce as much stuff as possible and share the word that having servers is bad™".

This field used to be inspiring, but now I see the ideia of having a server being sold as the plague and lots of negativity towards people who are good at servers. They are not seen as another human being but the "other".

Also I can't understand why one would prefer to pay that much for such complexity.

It seems unsustainable for me, not to mention the new generation being spoon fed that that is way to go makes me concerned about the future of open computing.

Re: The Serverless Revolution Has Stalled

#572

Post by unclebucknasty »

sippingjippers wrote: post #471
randomsearch wrote: post #406

This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…

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…

>training an operations team to take over maintenance of a nested spaghetti of random interlinked services and bits of YAML trapped in random parts of the cloud is a total nightmare. The amount of documentation required and even the simple overhead of enumerating every dependency is a long term management burden in its own right.

Upon learning about it some time ago, this was exactly my conception of what a Lambda-like serverless architecture would yield.

And it would seem difficult, if not impossible, for any dev to maintain a mental map of the architecture.

Re: The Serverless Revolution Has Stalled

#573

Post by joana035 »

ForHackernews wrote: post #565
xorcist wrote: post #560

Earlier quoted context omitted.

It's even easier if your application is just (an equivalent of) a binary, or a tarball.

Unless it relies on any system libraries, in which case you're in dependency hell when you upgrade or change the OS.

This is a solved problem, and dependency hell happen when not choosing dependencies wisely when creating programs.

Re: The Serverless Revolution Has Stalled

#574

Post by Can_Not »

gorbypark wrote: post #476
noncoml wrote: post #415

Earlier quoted context omitted.

> developers can produce generic code There is nothing generic about the code that runs on serverless services. It’s the ultimate lock in.

I use Google Cloud Run to run my serverless code for exactly this reason. GCR is literally just a container that runs on demand (with scaling to 0). Literally the only GCR specific part is making sure the service listens on the PORT env. If I was so inclined, I could deploy the exact same container on any number of services, host it myself and/or run it on my laptop for development purposes. There's also Kubernetes K…

Cloud Run is excellent if I wrote my own application. My biggest issue is that most off the shelf open source software that has a docker container often use a complicated docker compose file so if they can be deployed, they might be waiting on each other's cold starts (which can be very long and expensive) and/or need more databasesish things than I want. So obvious mistakes and unrealistic expectations aside, I have several nodejs and crystal apps on cloud run which is running well and just the concept "lambda for docker containers" is pretty awesome. Cold starts are pretty harsh ATM, hopefully they improve.

Re: The Serverless Revolution Has Stalled

#575

Post by joana035 »

slightwinder wrote: post #566
nicbou wrote: post #487

Earlier quoted context omitted.

I don't do any server admin. My code runs in docker on pretty much any server I can get my hands on. Some of my code runs on a ThinkPad stashed behind my desk, on DigitalOcean, on my Macbook. I could deploy to a Raspberry Pi and it would run just the same. It takes 10 minutes to deploy an exact copy to a new environment. None of that requires OS maintenance. My house plants require far more maintenance than my softwa…

> None of that requires OS maintenance. My house plants require far more maintenance than my software. I sometimes forget where some things run because I haven't touched them in years. Then how do you know they are still secure and even working? Yes, deploying servers is very easy, maintaining and securing them is the hard part. Sure, you can automate the updates and it will work with a good OS-Distribution for some…

The best practices of private networks, updated software and being conservative when exposing ports to a public network everyone knows already.

Also no need to be that scared about servers.

Re: The Serverless Revolution Has Stalled

#576

Post by recursive »

cblconfederate wrote: post #554
tarruda wrote: post #462

Earlier quoted context omitted.

> As I understand it, the main draw of WASM is running non-JS code in a web browser. Simplified deployment + automatic sandboxing? AFAIK with x86 you can't just write a client app and have it automatically run on any computer that visits your website.

Are people reinventing java as if it never existed?

No. Only as if the user experience was seriously flawed.

Re: The Serverless Revolution Has Stalled

#577

Post by liv-io »

1337shadow wrote: post #529
raxxorrax wrote: post #520

Earlier quoted context omitted.

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.

This could have been written by me. And for who ever doesn't have time to maintain roles, there is Ansible Galaxy or tons of roles in GitHub, including mine: https://github.com/liv-io

Re: The Serverless Revolution Has Stalled

#578

Post by liv-io »

joana035 wrote: post #571
diggan wrote: post #511

Earlier quoted context omitted.

Reminds of something that was on the HN frontpage some month ago, where readers are not sure if it's a parody or not, because of the architecture you're required to deploy yourself to use this new "Perspective" product. Direct link to the architecture, that in the end serves the use case of generating a diagram of your AWS resources: https://d1.awsstatic.com/Solutions/Solutions%20Category%20Te... https://aws.amazon.c…

Reading this made me remember that back in the day the AWS selling point was "here you can create virtual machines with few clicks and have it instantly instead of waiting 30 min for you colocated server to be ready" but now it seems to be "here is a bunch of random expensive tools, please, produce as much stuff as possible and share the word that having servers is bad™". This field used to be inspiring, but now I se…

Your response made me smile. Glad to see there are still reasonable folks out there. Working for a startup without a "resume-driven-development" CTO gave me the freedom to go "servermore" architecture with max flexibility.

Re: The Serverless Revolution Has Stalled

#579

Post by raxxorrax »

unclebucknasty wrote: post #572
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…

> training an operations team to take over maintenance of a nested spaghetti of random interlinked services and bits of YAML trapped in random parts of the cloud is a total nightmare. The amount of documentation required and even the simple overhead of enumerating every dependency is a long term management burden in its own right. Upon learning about it some time ago, this was exactly my conception of what a Lambda-l…

We had a microservice craze a few years ago. What about that, did they all crash?

Re: The Serverless Revolution Has Stalled

#580

Post by kevinmannix »

deepstack wrote: post #525
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.

Your second point broadly makes sense. In fact, it's almost a truism: if you don't put time into learning, you won't have the skills necessary to be able to execute.

However, it seems detached from your first point.

If one's role is a front-end developer, is it necessary that they know about back-end development? If it is outside their intended job function, why would they need to know about it, if it doesn't get in the way of performing their job? If you are a backend developer, do you need to know about how to host your own infrastructure? Handle your own networking? Chip design? Your logic could be applied to any job function. Each level of the stack benefits from the levels below it being abstracted. We all stand on the shoulders of giants, and we're all much better for it.

Overall, I do think it's better that one has a good understanding about the various components one interacts with. Having a grasp of the overall system will come in handy. A curiosity into other parts of the system is beneficial, and likely is one of many indicators of success. However, if job functions can be simplified and superfluous context removed, why should we fault those for taking advantage of that?

This issue with "lowering the bar" and being glad that a simplification has "failed" (which, is yet to be determined), reeks to me like gatekeeping. The same logic could be applied to any job role which benefits from simplification. In an extreme example, this logic could be extrapolated to support the notion that anyone who cannot build their own machine from the ground up should never work in a programming position. What height is appropriate for the "bar"?

Post reply on HN