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

171–180 of 670 posts

Re: The Serverless Revolution Has Stalled

#171

Post by cle »

tupputuppu wrote: post #110
cle wrote: post #84

Earlier quoted context omitted.

Among other reasons, enterprises love serverless b/c it relieves them of many server maintenance costs and risks. This includes things like: - OS patches and emergent fixes - Compliance certification - SSH access control and auditing - Secret distribution - Log rotation and storage - TLS termination - Configuring and testing auto-scaling policies - Deployment configuration (rolling deploys, blue/green deployments, co…

You don't need serverless for that. Any PaaS such as heroku provides those benefits.

I'm not really interested in having the 1,000th discussion about the definition of "serverless". The parent was wondering what the value of the paradigm is, so I provided a list of specific features that many companies consider valuable with serverless offerings.

Re: The Serverless Revolution Has Stalled

#172

Post by jacques_chester »

oblio wrote: post #163
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 think his point was that you should be able to run and test the Lambda code independently of Lambda. After all the entry point is just a method with some parameters, you can replicate that locally.

... ah.

Re: The Serverless Revolution Has Stalled

#173

Post by whalesalad »

fizixer wrote: post #145
whalesalad wrote: post #93

Earlier quoted context omitted.

I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to mak…

> ... stack is vue/python/s3/lambda/dynamodb/stripe Did you chose python for backend dev? Any framework like flask or django? Also no preference of single-language for both backend and front-end, by using node.js backend? Just trying to get into web-dev.

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 getting into the field.

Django: avoid unless you have a highly compelling (read: $$$$) reason to learn and use this tool. I cannot think of one, honestly.

Flask: fantastic, but be conscientious about your project structure early on and try to keep businees-logic out of your handler functions (the ones that you decorate with @app...)

Sophisticated or more sugary Node.js backends are not something I have ever explored, aside from the tried-n-true express.js. I tend to leverage Python for all of my backend tasks because I haven't found a compelling reason not to.

Re: The Serverless Revolution Has Stalled

#174

Post by eddiegroves »

parsley27 wrote: post #129

The Serverless Revolution is still happening all around us, with products like Netlify and the new DO App platform, not to mention all the enterprises moving into the cloud and moving more of their systems into managed products, using serverless components to tie it all together. Serverless is part of many different mini-revolutions that have been going on for around the same amount of time, with micro services, reba…

> DO App platform

Can you expand this reference please, Google/Github search didn't give me any obvious results.

Re: The Serverless Revolution Has Stalled

#176

Post by emilsedgh »

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?

Re: The Serverless Revolution Has Stalled

#177

Post by TheOtherHobbes »

rektide wrote: post #103
whalesalad wrote: post #93

Earlier quoted context omitted.

I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to mak…

A lot of these DX (developer experience) concerns are, imo, rooted in what the article describes as "Vendor Lock". Sure, you can write a bunch of tools to work around the crufty, terrible development environment's shortcomings. But ultimately, you are just locking yourself further & further & further in to the hostile, hard to work with environment, bending yourself into the bizarre abnormal geometry the serverless e…

AWS is shaping up to be Oracle 2.0.

That isn't a compliment.

Re: The Serverless Revolution Has Stalled

#178

Post by RedShift1 »

fennecfoxen wrote: post #36
aeturnum wrote: post #7

I never quite understood what problem serverless platforms were solving for companies that already deployed their own SAAS solution. As the article says, serverless is one of many (many) ways to wrap a quantum of functionality inside an internet-accessible environment. You could have a chunk of python in a serverless setup, a small flask server in a container in k8s, as an endpoint in a monolith, etc. Each of these e…

Another niche where it shines is the small, low-volume tool. You don't want to give it an entire VM, because that's a major waste. You don't want to have it share one "tools box," because it is awkward sharing like that, security becomes more of an issue, and it generally devolves into a mess. So if you've got other things running on AWS, then AWS Lambda is great for this. Do you need a random web-facing snippet to r…

I use Node-RED for this. Cheap and very flexible.

Re: The Serverless Revolution Has Stalled

#179

Post by beoberha »

eddiegroves wrote: post #174
parsley27 wrote: post #129

The Serverless Revolution is still happening all around us, with products like Netlify and the new DO App platform, not to mention all the enterprises moving into the cloud and moving more of their systems into managed products, using serverless components to tie it all together. Serverless is part of many different mini-revolutions that have been going on for around the same amount of time, with micro services, reba…

> DO App platform Can you expand this reference please, Google/Github search didn't give me any obvious results.

DO == Digital Ocean

Re: The Serverless Revolution Has Stalled

#180

Post by ugh123 »

john-tells-all wrote: post #87
spcebar wrote: post #66

Earlier quoted context omitted.

I found firebase functions pretty easy and painless. Worth a look.

Keep in mind Firebase has a big caveat. Firebase is great... for what it does. However, there's no way to easily migrate the Firebase resources to the larger GCP ecosystem. Firebase does what it does, and if you need anything else, you're out of luck. Firebase is magic... but I never recommend it for anyone, until there's some sort of migration path.

Are you referring to performance capabilities or some other connectedness to GCP resources?
Post reply on HN