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

391–400 of 670 posts

Re: The Serverless Revolution Has Stalled

#391

Post by iCarrot »

nickjj wrote: post #239
kortilla wrote: post #202

Earlier quoted context omitted.

It was actually pretty good if you had an IDE with sftp/scp support because you could save a file, refresh your browser, and have immediate new results.

Yeah this wasn't too bad and it was what I used to do back in the day with Notepad++. By the time you hit save in your editor, your changes were ready to be reloaded in the browser. With SAM we're talking ~6-7 seconds with an SSD to build + LOCALLY invoke a new copy of a fairly simple function where you're changing 1 line of code, and you need to do this every time you change your code. That's even with creating a cu…

The workaround my team uses is to make two entries to start the webapp: one for SAM, one for local. For fast iteration we just `npm start`, and when we're ready to do more elaborated testing we run with SAM. This works pretty well so far.

Re: The Serverless Revolution Has Stalled

#392

Post by nuker »

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…

> Kind of surprised the article didn't mention ..

What does it mention?

Re: The Serverless Revolution Has Stalled

#393

Post by mark242 »

ethanwillis wrote: post #316
mark242 wrote: post #295

Earlier quoted context omitted.

I have run AWS vs colo at scale. For the cost of precisely 1 engineer fully loaded, I can have 500TB of bandwidth per month, every month. Guess what, it isn't going to take just 1 engineer to maintain your homegrown worldwide CDN. Does it make sense for FAANG to run their own datacenters? Yes of course. Does it make sense for you? No. This is what I don't get about arguments for running a bunch of VPSs-- for literall…

Maybe it's hubris, but I'm 99% sure I could run a homegrown worldwide CDN for the cost of one engineer salary. I'd be willing to take that bet from anyone who thinks it can't be done.

If you are not in the CDN business, why on earth would you want to do this?

This is my point-- I am not in the hosting business. I am in the application creation business. Every minute that I even have to think about modifying /etc/localtime in order to make sure that the instance is running in UTC is a minute I'm not being productive. Multiply that by those million little things that you have to do in order to keep even an ec2 instance running, and it's such a colossal waste of time and effort. Similarly, I am not in the database tuning business. I plan out my data relationships, create the required Dynamo table or tables, and I never need to worry about replication or backups or any of those ancillary tasks that keep me from being productive.

Re: The Serverless Revolution Has Stalled

#396

Post by gouggoug »

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…

As someone in charge of cleaning up the mess in a company that has 800+ employees and 300+ developers, I can only agree.

My company's infrastructure was never tended to and was apparently a free for all for a few years. A year or two ago, it was finally decided the free for all needed to end and all the developers saw their SSH root access removed.

My team of 5 SREs is now facing a constant backlash from developers frustrated at the rotten infrastructure, constant bugs, and impossibility to ssh into machines. We're slowly fixing the mess, migrating to Kubernetes and things are starting to get better, but god, how painful it is.

So yea, in its infancy a startup's infrastructure can't be perfect, but every single shortcut you're taking now, you'll pay double down the line. Choose your path wisely.

Re: The Serverless Revolution Has Stalled

#397

Post by wokwokwok »

nafey wrote: post #389
wokwokwok wrote: post #376

Earlier quoted context omitted.

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.

That's such a straw man, it pains me to even respond to it.

Doing it 'quick and dirty right now with the tools I happen to know' instead of 'doing some research, then doing it in a way that is maintainable using standard tools and taking a bit longer' isn't 'endangering the survival of the company', it's professional level practice.

Failing to do so is, a) negligent, and b) incompetent.

I'm certainly not suggesting the OP isn't competent; they seem on the ball, and maybe serverless is the best choice for them because (insert reasons here)...but I think its fair to say, if you're using your one tool (ie. serverless) for all your tasks, you probably haven't done your due diligence.

Specifically in this case, using a standard ETL tool to do ETL type tasks... would probably be suitable.

Anyhow; no. Long term thinking isn't what this is about; it's about behaving like a professional when you do a professional job.

You pick the label you want to wear as an engineer, because, your practices define you.

Re: The Serverless Revolution Has Stalled

#398

Post by Toutouxc »

x86_64Ubuntu wrote: post #354
whalesalad wrote: post #299

Earlier quoted context omitted.

It’s still a very young ecosystem. Serverless hasn’t had its Rails moment (yet). I don’t think it’s as bad as people make it out to be.

What's the Rails moment? It's already hit the part where people speak about it as if it will save the world.

I believe it's the moment when there's a solution that just makes sense and works well for most people. A gold standard that other solutions will try to develop more and spice up, instead of reinventing it.

Re: The Serverless Revolution Has Stalled

#399

Post by akkartik »

nojvek wrote: post #346
akkartik wrote: post #317

Earlier quoted context omitted.

I favorited your comment, but I'll be curious to see how rosy your outlook is in say 10 years time. My prediction: all the use cases you're using it for are not the ones that it's designed for (i.e. which pay AWS's bills). And historically, unintended/illegible customers have a way of being caught out as the vendor shifts between strategies. Certainly, I hope you can be the remora to this shark for a long time to com…

I don’t think cloud functions in any of the providers are going anywhere. In fact seeing how google is investing in cloud run (docker images as cloud function) and other providers are catching on, this will be a growing trend. The ability to take whatever crazy code with spaghetti dependencies and freeze it into an image and have a cloud provider auto-scale from 0 to ludicrous in seconds is phenomenal ability. I love…

You misunderstand; I'm not saying cloud functions will disappear. My claim is that the _details_ of how cloud functions work will gradually mutate in strange and subtle ways you can't anticipate today, in a manner akin to the way that Google Chrome's behavior has gradually mutated. Just because successful services will tend to follow their most lucrative customers' use cases. The long tail running tiny lambdas will lose influence over time.

This may take many forms. Pricing models may change. Use cases that gradually see diminishing use may get discontinued (Google Chrome). You might get on some sort of treadmill of having to update details every so often (Facebook API). I can't predict what exactly will happen, but I believe that if your use case doesn't fit "we run a bazillion Lambdas and send tens of thousands of dollars (at least) into Amazon's bank account every month," any service you receive is accidental and contingent.

Re: The Serverless Revolution Has Stalled

#400

Post by tastroder »

rogerkirkness wrote: post #289
mark242 wrote: post #222

Here's why I love serverless. I cannot tell you the number of times I have implemented "upload your photo and it'll get resized to (profile avatar size from design specs)". It's ridiculous, and it's one of those things that everyone burns time implementing their fun hook into Imagemagick. Now I have one lambda that gets pointed at a new record stream from an S3 bucket, and I'm done. I cannot tell you the number of ti…

It would be nice if someone made a machine that would run all three of those discrete, generalized computing tasks on a single general purpose "thing". That way, you could infinitely scale your work up or down within available memory based on what needed to be done. It would even intelligently free something from memory if it wasn't being used. Servers.

I was hoping you'd end with "LAMP" for a second there. Many of the non critical path use cases that come up here sound like something you'd have deployed to a shared PHP hoster at the end of the 90s. Does a bunch of php files on one of those count as a serverless API gateway yet? For those use cases it doesn't seem all that different, just with added buzzwords, nicer languages and better developer ergonomics. At the cost of replacing skills in maintenance and debugging of what's going on in the stack with maintaining and debugging whatever abstraction cloud provider X put on top of it.
Post reply on HN