Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

621–630 of 670 posts

Re: The Serverless Revolution Has Stalled

#621

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…

They are good for message queue handlers. But not good for production REST API endpoints in my experience. In the context of AWS Lambda, you are talking a 29 second timeout in API Gateway. API Gateway is fairly expensive. Also, is connection pooling a solved problem? Many times you can do better with an EC2 instance running PM2 and Express, or whatever. Like, what does Serverless Framework do locally anyway? Express?…

I have a production REST API endpoints backed by PHP on Lambda that are called 12k/sec on the high end. no problems since ~2017.

The best part is, I never have to worry about scaling the underlying resources, if sales brings in large clients. Worst case is I ask AWS for a greater Lambda concurrency limit.

Re: The Serverless Revolution Has Stalled

#622
post #403
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…

It definitely doesn’t have to be that way. I work on Firebase and I’ve spent most of the last year specifically working on our local development experience for our serverless backend products: https://firebase.google.com/docs/emulator-suite Still very actively working on this but our goal is that nobody ever has to test via deploy again.

I'm currently working on a little project backed by Firebase. Really interesting. Good to hear you're doing this - at my day job one of our key factors in choosing a technology is whether we can spin it up in docker-compose in CI and do real-as-possible ephemeral integration tests.

Re: The Serverless Revolution Has Stalled

#623
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…

I believe one of the main reasons Serverless will never be more than a low-tier niche is the combination of the following:

In the end, you are just renting well maintained server farms (well, a specific percentage of operational time of some of the servers in them). There is absolutely no appeal for large technology-based companies do this once they can (the following is the lowest scale example) afford to maintain their own servers, while potentially renting a few offsite backups in other areas of the world (again, this is just the lowest-scale architecture starting at which Serverless is always the worse option).

Existing solutions are extremely over-engineered. It can be excused with "officially planning for the use-case where maximum scalability is required", but it's almost certainly a pretense to sell "certifications", aka "explaining our own convoluted badly documented mess". What this actually means is that many SWE's who are good enough to learn to use Serverless effectively, can learn any other framework that allows building distributed systems across server nodes with equal effort. Why would I base my whole business on your vendor locked, sub-optimized dumpster when I can do the same on an infinitely scalable VM networks, that can be ported to literally any vendor who supports $5/mo VMs (or, you know, self hosted if my company is large enough)?

Re: The Serverless Revolution Has Stalled

#624
post #91

Because it sucks . We’ve been working with serverless for 2 years now and we’re still dealing with issues for which the only solution appears to be to move back to ECS.

It sounds to me like maybe serverless just wasn't the right solution to your problem.

Re: The Serverless Revolution Has Stalled

#625

Because serverless is not serverless. Fundamentally this doesn't work because if you've gotta have a server in the end, why not either admin yourself or use one of the cloud vendor's other products for more control?

Do we really have to have this conversation every time the term "serverless" is used?

Re: The Serverless Revolution Has Stalled

#626
While I believe that the serverless hype is mostly, well, hype, this article makes some odd points against it.

> One is to optimize your functions for whichever cloud-native language your serverless platform runs on, but this somewhat undermines the claim that these platforms are "agile."

Like this one, don't see how optimizing for a specific language makes something less agile. Then again, "agile" means so many things in the field that I might just be misinterpreting.

Re: The Serverless Revolution Has Stalled

#627

Earlier quoted context omitted.

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.

Yes! I have an application I can deploy to Heroku, Dokku, Google Cloud Run, AWS Fargate, old-fashioned VPS host, and I suppose a bunch of other hostings like DigitalOcean's newly announced PaaS which I haven't tested yet. It's just a 12 factor app with a Dockerfile. What makes Google Cloud Run special between all these is that it's fully managed with an easy auto-scale model and only charges you only for the time req…

Thanks. That sounds like exactly what I'm looking for.

Re: The Serverless Revolution Has Stalled

#628

I'd point out two other aspect not mentioned here - first is that the complexity doesn't go away. Application architectures running on a 'serverless stack' have a lot more moving parts than a traditional server based equivalent. Try showing the you from 10 years ago a modern serverless architecture and they'll think you're mad. More moving parts is more maintenance/problems, but on the plus side, does allow you to th…

Infrastructure is always much harder to maintain (and test) than application code. Serverless architectures can risk moving complexity from (easy-to-test) application code to (hard-to-test) infra.

Hmm, I think that, as usual, it depends (TM).

For stateful systems such as databases, that typically require complications like replication and backup, configuration, testing and maintenance is hard to get right.

But for stateless systems, IMO infrastructure is pretty straightforward.

Re: The Serverless Revolution Has Stalled

#629
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…

One serverless scenario I find useful is for processing messages from low-volume queues. It avoids having to stand up "real" infrastructure that would be under-utilised.

Of course, if you already have servers with something like k8s or Swarm running, you might deploy a container there instead.

Re: The Serverless Revolution Has Stalled

#630

Earlier quoted context omitted.

Learning how to deal with it is great, until you find out what you don't know. Dealing with server infrastructure isn't business differentiating. Doing it poorly can certainly be business terminating, though.

> Dealing with server infrastructure isn't business differentiating I agree, for most businesses no it isn't. However, saving on cloud hosting costs to replace them with a handful of dedicated servers in different data centres can make a large difference to costs, depending on what the cloud usage is. For a funded rocketship startup with lots of free AWS credits it makes sense to use AWS; for a steady state or long-t…

Are you taking into account the salaries needed to do this?

Even assuming that you save 100% of your hosting costs, you have to be spending quite a lot to even cover the salary of one full-time employee.

I can believe that larger businesses can save quite a bit, but I don't see how it makes sense for anyone spending less than seven figures a year on AWS.

Post reply on HN