Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

441–450 of 670 posts

Re: The Serverless Revolution Has Stalled

#441

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…

> When put like that, it’s amazing that we didn’t come up with this idea earlier.

It's called time-sharing and it existed in the 1960's. [1]

[1] https://en.wikipedia.org/wiki/Time-sharing

The difference between time-sharing and serverless is that the former solved the issue of expensive personal computing, until cheap personal computers took over that market. The latter solves perceived expensive computing on the "server" side.

But what does it serverless solve exactly? It doesn't solve a technical problem, rather addresses concerns on the business side. Serverless solves a cost problem.

First, computing needs aren't linear, they fluctuate. And so, there's a problem of under- and over-utilization vs availability of resources. Serverless approaches computing power like tapwater: you're essentially paying for the CPU time you end up using.

Second, elasticity. Instead of having staff struggle - losing time - with the fine intricacies of autobalancers, sharding and what not; you outsource that entirely to a cloud provider. Just like a tap, if you need more power, you just turn the tap open a bit more.

Finally, serverless services abstract any and all low level concepts away. Developers just throw functions in an abstraction. The actual processing is entirely black box. No need to worry about the inner details of the box.

Sounds like a good deal, right?

> Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server.

Well... no. Outsourcing all of that to a third party cloud computing vendor doesn't dismiss you from your responsibility. All it does is shift accountability to the cloud provider who agreed to take you on as their customer. Securing your factory still very much includes deploying a secure digital solution to manage your machinery and process lines.

Plenty of industries wouldn't even remotely consider outsourcing critical parts of their operations, and this would include digital infrastructure. And this is regardless of the maturity of serverless technology. Risk management is a vast field in that regard.

Then there's legal compliance. There are plenty of industry specific regulations that simply don't even allow data to be processed by third party cloud services unless stringent conditions are adhered to. Medicine, banking and insurance come to mind.

Finally, when it comes to business critical processes, businesses aren't interested in upgrading to the latest technology for the sake of it being cutting edge. They want a solution that solves their problem and keeps solving that problem for many years to come. Without having to re-invest year after year in upgrades, migrations and changes because API's and services keep shifting.

Does that mean that there isn't a market for serverless computing? Of course there is. Serverless computing is a JIT solution. It's an excellent solution for businesses in a particular stage of their growth. And it closes the gap for plenty of fields where there really is a good match. I just feel that "maintaining your own server is completely nuts" is a bit overconfident here;

Re: The Serverless Revolution Has Stalled

#442

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 disagree. Every AWS Lambda function I've ever written can be ran as a regular node/python process. The lambda-specific part is miniscule. If I wanted to run these on Azure or Google only the most inconsequential parts of the function would need to be changed.

In my experience, having started and abandoned side projects in both aws lambda and google app engine, half your project becomes:

* Well, obviously we use a hosted database

* And obviously, AWS provides our logging and all our analytics.

* Obviously when people call our lambda functions, they do so either through an AWS-specific API, or one constrained to a very limited set of forms.

* Of course, we can't blindly let everything access everything, so naturally we have IAM roles and permissions for every lambda function.

* Well, the cloud provider will look after secrets and things like that for us, no need for us to worry about database passwords.

* Naturally, with all these functions and IAM roles to look after, and we need tagging for billing. We should define it all with CloudFormation scripting.

* Well, the nosql database the they provide comes with their specific library. And as it shards things like this, and doesn't let you index things like that, you've got to structure your data this specific way if you want to avoid performance problems.

* You don't want your function to take 200ms+ to respond, your users will notice how slow it is. So no installing things with apt-get or pip for you, let me get you a guide on how to repackage those into the vendor-specific bundle format.

* You want to test your functions locally, with access to an interactive debugger? You're living in the past, modern developers deploy to a beta environment and debug exclusively with print statements.

* And so on.

In this case, a lot of the 'complexity' one hoped to eliminate has just been moved into XML files and weird console GUIs.

Re: The Serverless Revolution Has Stalled

#443

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 disagree. Every AWS Lambda function I've ever written can be ran as a regular node/python process. The lambda-specific part is miniscule. If I wanted to run these on Azure or Google only the most inconsequential parts of the function would need to be changed.

> Every AWS Lambda function I've ever written can be ran as a regular node/python process. The lambda-specific part is miniscule.

Of the actual function code, sure.

Of course, if you aren't manually configuring everything and are doing IaC, that isn't generic. And if you are supporting the Lambda with any other AWS serverless services, the code interfacing with them is pretty AWS specific.

Re: The Serverless Revolution Has Stalled

#444
post #246
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.

This doesn’t automatically scale down to zero though which to me is a key differentiator of true serverless.

Re: The Serverless Revolution Has Stalled

#445
Serverless conceptually was too tightly bound to the function as a service model. As we peel that back what we're finding is serverless really means "not my server". Someone else manages that piece of infrastructure, it can be anything, a VM, a database, etc. But in this case it feels like serverless is falling squarely into the PaaS category, building a better Heroku. Google Cloud Run is one prime example. DigitalOcean App Platform is another. I think this is likely the primary way software gets run in the cloud in the future BUT with one huge caveat, its not clear its going to be the way forward for large scale development itself.

Cloud lacks what mobile lacked before the iPhone, a development model. When we finally figure that out, it'll become obvious that table stakes here is an actual full end to end experience with one language and a set of primitives to help scale development for the cloud. That's not FaaS. Its something entirely new. The language will be popular, maybe Go, the focus will be on cloud APIs. Everything else will be become a client. The web era is over, thats not what the cloud is about. Cloud is all about APIs.

Re: The Serverless Revolution Has Stalled

#446
I'd agree with the part of maintaining your own server. like personal one. I promised myself like 5 years ago I'll never be my own (and family and friends..) sysadmin ever again. ... but serverless needless mean tiny programs in nodejs. serverless is basically a super category for what we used to call PaaS simply saying the granularity of what you deploy can be smaller. it doesn't mean it has to be smaller. as far as I am concerned it can also be way bigger than what heroku represents. This is what composability on infrastructure means. It means you have the same interface to deploy a single line of JS... and a service that is itself composed of a couple of monoliths each with its own data backend. The "form of the program" should be dominated by the problem it solves not its deployment target. That is the thing we are trying to achieve at platform.sh where I run product. A uniform interface to a composable infrastructure. We are not quite yet there... this is not a trivial problem. And I don't think that "just ship your machine" Docker style solves this. To be really composable you need both finer grain and higher abstractions. What I mean is that at every level you compose you need to be able to define dependencies (my function requires this version of nodejs and this system lib) my already composed monolith that includes a dependency on MySql and Redis) is a dependency of this static site builder.. at each layer the semantics are very close. But not the same. Just shipping a container eludes these issues and basically reproduces the model of "good old servers" in a way this is contrary to what true serverless has to offer. Which is absolutely not caring at all about the runtime. And caring only about the design of your system such as that it espouses best the form of your problem.

Re: The Serverless Revolution Has Stalled

#447

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…

[deleted]

Re: The Serverless Revolution Has Stalled

#448

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 nuts to run servers. If an application is operating at any scale such that there is a nonstop stream of requests, then it will be cheaper, faster, and more energy-efficient to run a hot server. This follows from thermodynamics. No matter how good the cloud vendor's serverless is, it's always going to be less efficient than a server, unless it doesn't do any setup and teardown (i.e. no longer serverless).

It is nuts to run one server. Then you're wasting money with a server/VM. That's what serverless is ideal for: stuff no one uses. That's a real niche. Who's going to use that? Not profitable companies.

Often I think for most cases where you reach for serverless, you should reconsider the choice of a client-server architecture. An AWS Lambda isn't a server anymore; it's not "listening" to anything. Why can't the "client" do whatever the Lambda/RPC is doing?

Maybe what you want is just a convenient way to upload code and have it "just work" without thinking about system administration. The types of problems where you don't care about the OS is once again a niche. You probably don't even need new software for these kinds of things. You can just use SaaS products like Wordpress, Shopify, etc.

Serverless won't be profitable because the people who need it don't make money.

Re: The Serverless Revolution Has Stalled

#449

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…

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

I don't agree, serverless code in itself tends to be portable. It's the surrounding services that lock you in.

Re: The Serverless Revolution Has Stalled

#450
post #252

Earlier quoted context omitted.

> Instead, you can write a function that takes parameters from elsewhere and call your business logic there. This is what I tried to do initially after experiencing the dev pain for only a few minutes. But unfortunately this doesn't work very well in anything but the most trivial case because as soon as your lambda has a 3rd party package dependency you need to install that dependency somehow. For example, let's say…

Unless I’be misunderstood, every knock against serverless above has actually been a knock against the complexity of having tiny, de-coupled cloud native services and how difficult it can be to mock... to which the answer is often “don’t mock, start by using real services” and then when that is less reliable or you need unit tests, then mock the data you expect. In the case of SNS, mock a message with the correct SNS…

Well sure, but then your development (and test) environment is tied to live services and you now you have two problems. It really, really sucks when an unrelated service goes down during an existing incident and you never mocked.
Post reply on HN