Containers won the battle, but will lose the war to serverless

I'm baffled that anybody with any experience of software development could think that something like FaaS will solve logic duplication issues; the hypothetical "118 systems doing pretty much exactly the same thing" exist because of organisational failures, and the same thing will continue to happen regardless of how that logic is implemented.

That is exactly the situation with kubernetes and containers, and it is nice indeed, as I can easily switch between providers. In fact, my company got free digital ocean credits and was able to seamlessly host a cluster on DO for free to enhance testing. This is the ultimate.

What scares me about serverless is the complete lock-in with the vendor. It’s the same reason google app engine just couldn’t be a game changer. You need that balance between customization and commoditization that serverless I think fails on, unless some protocol like docker comes in to save it.

Things will be going great and then there's the oddly weird 2 second delay. I guess it is bringing up a new server or container to run the lambda in.

Whereas with your own (or well, Amazon's) machines you can scale up before hitting the limits and not need long pauses.

Maybe one day they'll fix that.

I know it's written in an irritating style, but I feel like this kind of scaled application deployment strategy is basically the future, and you'd be very very naive to dismiss it as just some marketing hype.

The ability to deploy arbitrary micro-services to a cluster is basically all this is, under the hood, and that's something that intrinsically beneficial.

Sure, you may argue, the difference between deploying code to a cluster, and deploying a container to a cluster may seem immaterial, largely, but ultimately its hard to argue that it's better to choose the container in most cases, if you can delegate the work of 'configure and manage the container and container infrastructure' to someone else.

There's no question it'll slowly start eating the container world in my opinion; the barrier to entry is low, and ultimately (with something like openwhisk) you can use a container if you do need to package say, a specific version of opencv for some specific purpose.

Can anyone suggest why this is a bad approach?

It doesn't sound like a bad approach to me, and a lot of people are taking a lot of interest in it.

The problem is the people who are pitching "microservices as a service", as though you might be able to delegate some parts of your service out as a microservice to other people, like you can run a 'lpad service' and there will be the new 'microservice app store' and people will all flock to use it, and a few people who write the early 'good functions' will Get Rich Quick.

...and every time any single one person screws up their service, or has a tizzy and shuts it down, dozens of applications will fail.

What a disaster waiting to happen; its ridiculous, and all the noise about it is just people looking for funding (or just clueless, I have no idea).

...but, that doesn't change the fundamental value proposition of serverless: auto-scaling without devops.

(Also:

> And we’re seeing the exact same pattern with serverless. Yes, other companies could challenge Amazon’s dominance. But they probably won’t, because they don’t believe it’s for real. And by the time they do, it’ll be too late.

Yep. That's spot on as well)

The one exception, of course, being how everybody seems to have come together around containers. So now everybody’s excited about containers, but the battle’s shifted up. So you’ve won the battle, but lost the war."

The interviewee here manages to make a Santayana mistake without realizing it; eventually, just as containers standardized, serverless functions will standardize, and cloud vendors will either conform or marginalize their offerings in response.

The future, in my opinion is offerings like AWS fargate. The developer writes logic that is containerized, and the auto scaling, scheduling, etc is handled in a seamless fashion by the provider, removing the burden of ops from the developer. In many ways, this is a connection-oriented Faas, and that is where the future likely lies, due to its wide applicability

1. Can I run a standard Rails or Django app on "serverless"?

2. If I'm running on Heroku and don't directly manage servers, does that count as "serverless"?

But anyway I think that eventually the real 'serverless' will be peer-to-peer systems like Ethereum smart contracts, IPFS, dat, etc.