That said, I look forward to the company (or side project) where "serverless" can save me from also assuming the "devops" role.

Interestingly, as Firebase evolved during our use, nearly all of our external-instance use cases were obsoleted by more powerful native serverless support, esp. around functions.

All of which is the best of both worlds for serverless: an easy escape hatch to custom instances, and an ever-decreasing need for that escape hatch.

* video encoding;

* ETL processes;

* other analytical workloads;

* long-running websocket connections with Twitter/Facebook/etc APIs.

From my perspective, serverless solves the "boring" part of making REST APIs easier to manage, which were already very easy to manage.

How would serverless be applies to, say, a python script that streams Twitter tweets using websockets?

[0] https://aws.amazon.com/sqs/ [1] https://aws.amazon.com/kinesis/

I guess you could argue where to draw the "serverless" line, at functions or containers, but Zeit is calling this container service "serverless" so I think Fargate would fall into the same category. I think it would make sense for Zeit to eventually support long-running containers too (looks like the current max is 30 minutes, I'm not sure how they chose that number)

Either it works with web-hooks that you could lead to a Lambda via API-Gateway.

Or it needs to pull the data, then you could trigger Lambda via CloudWatch intervals.

I think this is the issue/risk with serverless. You either get locked into one of the big 3, or you end up doing all of the ops work to run your own stateful systems. As some of the people above you said, managing and scaling the stateless HTTP components is not the hard/expensive part of the job.

    1) you don’t have to manage infrastructure
    2) you don’t have to think about infrastructure (what size cluster do i need to buy?)
    3) you pay for what you use at a granular level. (GB stored, queries made, function invocations, etc)
    4) scale to zero (when not in use, you don’t pay for much of anything)

But the primary utility of serverless is an attempt at solving Amazon's problem of being commoditized by containers.

Can we please call it "stateless" instead of "serverless"?

The user experience (as an end user using the website) is pretty terrible IMO. It often takes multiple seconds for various areas of the site to load (bound by the network). It's also super Javascript heavy and just doesn't feel good even on a fast desktop workstation.

Authentication is also a nightmare from a UX point of view. Every time I access the site it makes me click through an intermediate auth0 login screen.

I really hope this doesn't become a common trend to run web apps like this. It would make the web nearly unusable.

I'm not a "serverless" hater either. I want technology to move forward to make my life as a developer better. I don't care what tech it is, but right now I just don't get that impression from serverless set ups (both from the developer and end user POV).

The only one that seems like it could even be related is the page loads being slower. But I'd be surprised if the issue were the serverless aspect of the architecture and not just that this software is apparently shoddy overall.

Renders server-side, loads quick, minimal JS.

In the mid-90’s it was common to run httpd via inetd. That lasted until HTTP 1.1 came along. I see people running websites out of Lambda now and just get a sense of deja vu. We realised this start-on-demand style didn’t scale for highly interactive use cases 20+ years ago!

The very list of benefits on ZEIT, mentions 4 things: first two of them are clear over-engineering bloat (plus premature optimization), and second two were actually created only because of serverless. They were (and nothing more was mentioned in section benefits ;) :

* Clusters or federations of clusters * Build nodes or build farms * Container registries and authentication * Container image storage, garbage collection and distributed caching

I don't know why everybody can't see fakeness of argument'you need clusters, farms and hundreds of servers'. You don't. Actually you do only (contrary to your statement), if you're FANG.

Why? Because look at real world HUGE examples. E.G. stackoverflow (and no, your company/startup/whatever, will not reach their level of traffic) can do everything on literally dozen of servers, while they admitted that in some scenarios 1 web server was enough. Source: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...

Our 10x..100x smaller companies would perfectly do on 2..4. There is no need for whole over-engineering.

The ultra funny thing is ZEIT selling 'deployment self-heal' as old known (windows anybody) and ridiculed recipe: it will work after restart. Right. It's better to shut off car engine, go out, go in, and start again. This is XXI engineering :)

[0] https://www.thestreet.com/story/13230576/1/what-are-fang-sto...

They are on the forefront of serverless.

Everything is deployed as immutable infrastructure.