Hacker News Reader

Comment by yshrestha | Hacker News Reader

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.

View on HN

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!

This is super clear! TY!

Reply on news.ycombinator.com