What does “serverless” mean to you? So many companies are using it | Hacker News Reader

What does “serverless” mean to you? So many companies are using it

8 pointswhispersnow19 comments

with their own definition and interpretation that almost feel like a mkt buzz word and I am totally confused...

You need two things to run a piece of code:

1) Code and execution environment 2) Compute infrastructure to run (1) on

Serverless, to me, means that (2) is abstracted away from you. You submit (1) to the serverless service (AWS Lambda for example) and the service figures out how to run it. Serverless does not mean there are not any servers. It is just something you do not need to ideally worry about. Abstractions are leaky though, and they can leak in very mysterious ways the higher up the abstraction tree you go.

This is super clear! TY!

I like this description. It is similar to the concept of "no-code" where the code is definitely there, but it is abstracted away to the point that the user theoretically doesn't ever notice it.

Good observation. Code is also a Jenga tower of abstractions from High level language (Python) -> Low level language (Assembly) -> CPU microcode. No code is just yet another layer on top. The higher up you go, the more difficult it can be to debug issues, and the more locked in you will be in the infrastructure. I like to stay somewhere in the middle. Not too low such that I am wasting a bunch of time with implementation details, but not too high where I don't understand enough about the technology to fix issues. The industry, as an aggregate, is steadily and relentlessly moving up the abstraction tower.

A builder may use bricks to build a house - yet he may still be interested in the brick's composition & the brick making method.

These days, he may even use a brick robot to automate bricklaying, and still be interested in the mortar used.

Same for software ?

That is an interesting comparison. I think it highlights that engineers may need to constrain the design a few levels of abstraction lower than where they typically operate at any given time. I think performance constraints is a key motivating factor for when we need to peel back the layers of abstraction and tweak something under the hood(s).

I think another analogy is like building a skyscraper. The construction worker needs to worry about the floor below him and the floor he is working on. Everything below him is an implementation detail from his perspective.

If N is the cutting edge level of abstraction, N+1 is what research is doing, N-1 is where I like to operate at while I wait for N to stabilize.

Take a stack of AWS services for example. AWS comprehend medical is an abstraction built on a bunch of NLP building blocks. AWS health lake is an abstraction on top of AWS comprehend medical. At this point I don't care about the NLP underlying AWS comprehend but I don't want to use AWS health lake until it has a chance to stabilize and another abstraction is built on top of it.

This also reminds me of something C programmers have all witnessed at least once: inline assembly.

Outside of bare metal programming, pretty much anything done with inline assembly can already have been done with straight-up C. BUT by using inline assembly, the coder has (nearly) direct control over what the compiler spits out.

And the reason I say "nearly," before someone corrects me, is that there are multiple ways to express the same operations in assembly.

For example, ADD AX,BX can be compiled as C303h or D801h... the end result is exactly the same, but the binary code is not at all the same. Incidentally, this is one of a few methods forensic agents heuristically determine what compiler was used for a given malware sample.

It's abstraction all the way down. Even at the Assembly Language level.

And it definitely need a fair amount of coding background to be able to work with the no-code platforms to debug it!

In addition to serverless meaning that you don’t have to worry about the compute layer, I take it to mean also:

• I don’t need to manage the infrastructure for each of the services I depend on • My compute and other services are billed based on usage, not for being switched on • Everything scales up as needed, and just as important, down to zero

There is always a "Server" somewhere. Serverless just abstracts it for you so you don't have a physical server to ssh into, maintain it etc. It also gives you flexibility in terms of running it only when you need to execute certain tasks/functions (e.g. AWS Lambda)

Can I understand that serverless means a cloud infrastructure?

I think of it as the server instrumentation being obfuscated away. I don't really like the name because it seems misleading, but the offerings themselves can be really handy.

Serverless to me just means I don't have to worry about managing a server (as in hardware, OS, updates, etc, etc.) I just have to manage an app/container.

A virtual machine that's spun-up for long enough to run your program and then disposed of.

Then what's the difference between a "serverless" vs VMs like docker?

VMs and Docker are just convenient ways to capture the "execution environment" as I referenced in my previous comment.

"Serverless" comes packaged and optimized for this mode of operation. Everyone expects the VMs to be short-lived. I'm sure it's all a remarkably boring VM service underneath.

To me, it means you deploy a function or service without needing to configure what it runs on.

means no handling servers, even having to run containers is not really serverless.

Reply on news.ycombinator.com