Hacker News Reader

Comment by userbinator | Hacker News Reader

The first trait of "serverless" is that there is still a server, and it has nothing to do with P2P networks. This must be one of the worst marketing-isms I've come across, and I've heard some really awkward conversations due to it. In the very brief contact I had with "serverless" systems, I remember the phrase "serverless server" mentioned several times. A more appropriate name would probably be "managed microservices".

View on HN

Three years of BigQuery... zero discussion about nodes, memory, disk arrays, vacuuming... None of it.

We still worry about costs, forecasting, latency, monitoring, availability, access controls, auditing, and resource utilization. So, I don't think "opsless" is applicable in the least.

But we don't worry about servers or nodes. We don't worry about zones or regions (we do worry about legal jurisdictions, but that's non-technical concern).

I don't worry about the server and there is no server are two very different statements. Serverless is a terrible name for it.

If I don't have to talk about servers, there's no difference in optics to saying serverless.

When I go to a Jimmy John's, I'm never served by Jimmy John. So what?

It's great marketing, albeit not what every person imagines, when encountering the term.

1st time you get a $60k AWS Lambda bill from developers leveraging lambda you end up having a talk with finance and a huge incentive to setup a server(s) for the developers to run jobs on

* edit was working on vault and for some reason typed that word instead of lambda

Instead of setting up servers I'd improve my cost monitoring and make the developers responsible for the costs they generate (with great power comes great responsibility). Both of that should have happened before they got permissions to use scalable infrastructure anyway.

I always go to Function as a Service. But i understand the struggle.

To be pedantic, the way I see it, it is not really a Function that is a Service here, rather a Function execution environment. The Function is actually yours.

EDIT: markup (not a frequent poster here :) )

Of course there are servers and networks and disk, etc. Serverless means you don't manage a server and the abstraction is not based around a server. The term "Managed Microservice" does not make any sense since microservices don't have the same lifecycle as managed functions.

It's just PaaS. We already had a term.

Some will say that PaaS did have knobs for amount of servers/instances/dynos/whatever but that's a minor detail and the innovation is called autoscaling. No need for an entirely new buzzword. But naming is both hard and exciting so we have "serverless".

PaaSes typically run persistent processes like big monolithic apps. "Serverless" is more like auto-scaled CGI-as-a-service.

What's the difference? PaaS platforms can accept code from a single function (lambda) all the way up to an entire container (knative/cloud run). The scale of code deployed doesn't really change the definition of a platform.

I've seen PaaS more frequently affiliated with services sold to me where the service is bound to a persisted compute resource, and you're always billed for it. There is a always a cpu core running the platform somewhere.

Whereas serverless/Lambda/container service can take the billed cpu to zero when you deem fit. There are still cpus managing and administering, but you have the option to take your utilization that you get billed for to zero, where in the PaaS that I've been sold to, I didn't have that option. YMMV, of course.

Those who don't "get" cloud likely haven't seen one big use case where the costs of cloud services are pretty immaterial: very large organizations with human-dominated change processes. The win here with cloud is the policies and contracts are embedded into the API and access configurations. The speed-up isn't from elastic services, it is eliminating the layers of humans standing between you and the service you want delivered.

If you work in such an organization where you send in a change ticket with the exact Unix commands you want run, and it takes a week for the sysadmins to get around to processing the ticket, the cloud seems lightning-fast by comparison. Then all the scaffolding to set up CI/CD, CMDB, configuration management, secrets store, elastic services, etc. either on-prem or in the cloud doesn't seem nearly so tedious any longer.

The aptly misnamed serverless architecture means you're using hosted services, where most "serverless" technologies can be placed somewhere between server hosting and static web hosting.

E.g. server hosting, container hosting, database hosting, app hosting, function hosting, web hosting.

I think opsless would be a better term, but probably has shitty marketing potential.

Even that’s not really true. You still have to wire it all together and figure out how to manage latency.

Agreed. You still have to forecast costs, audit use, manage access, deal with availability issues, etc.

A good serverless platform lets you focus on those issues instead of OS patches and hardware upgrades.

Opsless is pretty good. Function as a service (FaaS) is what my preference is. It seems every time something about serverless comes up on the forum, there's the inevitable "but there are servers" comment.

In the FaaS (also my preferred term) world the “ops” responsibilities include cost management. Fargate, Lambda etc can get very expensive very quickly if you don’t have a guy on top of this.

Is it really event function as a service? It's not like you can just remote a function to Lambda at least (unless there's some framework that does that on top). It's really just a managed container with a fixed entry point and built-in instrumentation.

I don't like FaaS much more because of the ambiguity of the word "function". In most servers I've worked on, you start by definition the single function that determines where to route the request. What it really is, is managed services, but that has its conflicting definitions.

To add to the confusion, in Azure a Function App (the deployable thing) an contain multiple Functions (the invocable things).

Microservice as a service is clearest to me.

> I think opsless would be a better term

Considering that 'serverless' actually needs a more experienced and expensive ops team, no, it really wouldn't.

While I agree that opsless isn't a fitting name, how do you come to the conclusion that a serverless architecture requires more ops resources than a traditional one?

From my experiences the opposite is the case: The amount of time spent on operating a serverless architecture is much smaller than having to care about the underlying servers as well.

A pretty good example are all the nasty OS-related security vulnerabilities. Instead of patching hundreds of servers, like in the old days, with serverless applications you don't need to do anything. Even better: Your provider (at least if it's one of the major ones) has probably already patched these vulnerabilities, before they get published.

Some people use "Zero Ops", which might be better than opsless. I've heard a conversation once where "opsless" was mentioned, and the other person thought it was "hopeless".

When serverless functions access resources in a VPC, the Network Ops, router, and configuration skills get put to the test.

Stateless sums it up but gives away the downside.

BigQuery is pretty stateful and, I would argue, one of the better "serverless" offerings out there.

"Modern FastCGI"?

"The Eternal Mainframe" http://www.winestockwebdesign.com/Essays/Eternal_Mainframe.h...

Wasn't FastCGI actually running a persistent connection, just like an HTTP connection but with a custom protocol for no good reason?

"Auto-scaled-CGI-as-a-service"

Name itself is important. It is faster and more efiecient than cgi

Yes, it was a local only binary connection. The key difference from regular CGI was not needing to start a new process for every request, so it could be used with languages with long VM startup time.

Yeah, that makes it Not CGI, so it's more like binary HTTP. I guess you could say, a precursor of HTTP/2 :)

application serverless?

Reply on news.ycombinator.com