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

241–250 of 670 posts

Re: The Serverless Revolution Has Stalled

#241

Post by crehn »

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…

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

Re: The Serverless Revolution Has Stalled

#242

Post by StavrosK »

darkteflon wrote: post #204
whalesalad wrote: post #173

Earlier quoted context omitted.

Yes, it (Python) was chosen because we could leverage existing internal code that was written in Python and it happens to be my strongest language. If I could do it all over, I would still choose Python. That being said, I have been working professionally (building apps like this) for almost 14 years so my willingness to bite off a homebrew Python framework endeavor as I did here is a lot different than someone just…

Could you elaborate on why you dislike Django? Would be great to hear from someone with extensive Python experience.

On the flip side, not being able to use Django is one of the reasons against serverless for me. There's immense value in having a library for anything you might think of, installable and integratable in minutes.

You have to roll your own way too often in Flask et al, so much so that I don't see any reason to use Flask for anything other than ad-hoc servers with only a few endpoints.

Re: The Serverless Revolution Has Stalled

#244

Post by [deleted] »

jpdb wrote: post #144
nickjj wrote: post #25

Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…

I used to be complain about the same thing and even asked someone who was head of BD for Serverless at AWS what they recommended, and didn't get an answer to my satisfaction. After working with more and more serverless applications (despite the development pains, the business value was still justified) I realized that local development was difficult because I was coupling my code to the delivery. This is similar to t…

[deleted]

Re: The Serverless Revolution Has Stalled

#245

Post by konjin »

Demiurge wrote: post #227
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…

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 you need two servers.

One to run the application.

One to run the application while the first is being upgraded.

Now you need three servers, one to run the application, one as backup and one as load balancer.

99.99% uptime means you can be down no more than an hour a year. Which is really easy to overshoot when you're dicking around with a dist upgrade on three linux boxes.

So that's why you end up with a server farm starting from your one small server.

Re: The Serverless Revolution Has Stalled

#246

Post by pbalau »

tybit wrote: post #225

I don’t believe that the FaaS revolution has stalled, though I fear it will follow the tech adoption curve because people are over hyping it. I do wonder if AWS’s leadership in the area has stalled though. GCP has innovated with their hybrid Cloud Run to allow running more traditional apps in a serverless way. Azure and CloudFlare have paved the way to what I believe is the future with stateful functions with Durable…

> GCP has innovated with their hybrid Cloud Run to allow running more traditional apps in a serverless way.

AWS has Fargate, run your containers without caring where they run.

Re: The Serverless Revolution Has Stalled

#247

Post by mark242 »

crehn wrote: post #241
mark242 wrote: post #235

Earlier quoted context omitted.

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…

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.

Re: The Serverless Revolution Has Stalled

#248

Post by eghri »

k__ wrote: post #160
nickjj wrote: post #25

Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…

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.

Re: The Serverless Revolution Has Stalled

#249

Post by uglygoblin »

hermanradtke wrote: post #65
nickjj wrote: post #25

Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…

GCP has https://cloud.google.com/functions/docs/functions-framework but I will not use it. I have found the best solution is to abstract away the serverless interface and create a test harness that can test the business logic. This adds some extra complexity in the code, but iterations are fast and do not rely on the overly complex and bug prone "platforms" like SAM and Functions Framework.

This is precisely what I do when I write code destined to be an AWS Lambda Function. It really feels like the only sane way to do it. It also makes it easy to mock the incoming request/event for integration tests.

Re: The Serverless Revolution Has Stalled

#250

Post by jay_kyburz »

emilsedgh wrote: post #176
alpb wrote: post #168

Kind of also surprised I think this author has not heard of Google Cloud Run ( https://cloud.run/ ). Cloud Run employs a vendor-neutral container runtime and API (from Knative open source project). It simply accepts any OCI container that can listen on $PORT number. Similarly, the author talks about serverless not being able to run "entire applications", which again, doesn't apply to Cloud Run. Many people run fully-…

To me, Google Cloud Run is the sweet spot between Heroku and Serverless. I pay as much as serverless but there's no vendor lock in or specialized programming environments. Fantastic job. By the way are websockets ever going to be supported on managed cloud run?

When you say there is no vendor lock in, are there other companies that will host the container for you?

Can I just deploy my container to three different places and choose where to point my URL?

I'm right now faced with re-wiring a Python 2.7 App Engine App and feeling the pain of the lock in.

Post reply on HN