Hacker News Reader

> There's nothing that prevents you from redeploying your service in microsecond, just as you hit "Save" button in vscode.

I knew someone would find some merit to my PHP + SSHFS setup someday

> and supporting of miriads languages

It might have better chances with some common language runtime, than declaring One True Language. No matter what language you pick or invent, it's gonna be hated by many. Intermediate representations? Sure, but much less so.

But you are absolutely right that clouds need a fundamentally different runtime, built on different ideas and principles - not virtual machines running containers pretending to be functions, all completely separate from resource declarations (which are in turn all individual nuanced messes).

That tight, opinionated integration of hardware and software sounds a lot like 'mainframe'.

Lisp machines strike back? ;)

> Lisp machines strike back? ;)

Ah well, you beat me to it: https://news.ycombinator.com/item?id=36489625

That’s what I was reading here, everything old is new and opinionated again.

> Cloud will be easy with consistent approach.

> Cloud will be easy with opinionated tooling.

> Cloud will be easy with opinionated approach to configuration.

This is really true. AND in no time at all, it will turn from "easy" into "steady, reliable" and then FOMO-derived cognitive dissonance will set in for either engineers, developers, sales team, or users, or some set of those. You'll get people inviting you back to FOMO-squirrel-duct-tape-emergencies-cloud.

At that point I'm convinced you have to find a way to act like you are FOMO+ while keeping easy-cloud well-maintained, if you wish to keep the squirrel cloud difficulties at bay. If you are part of a team then I wish you the best of luck.

this.

the problem is people, not tech.

the solution is taste and discipline, same as its always been.

There’s a good chance this is realised within 5 years, built on WebAssembly.

While it’s not on the metal performance like native compilation, it’s close. I wouldn’t be surprised to see CPU instructions for WASM to get to native performance, if it got popular enough as a runtime.

"Cloud" is just "datacenter" with special mark-up for the pointy haired boss.

Adopting a PHB-friendly name won't make the problems go away.

> There's nothing that prevents you from redeploying your service in microsecond, just as you hit "Save" button in vscode.

Yeah, we had that 20 years ago with PHP. It had its downsides too, let me tell you.

What would you replace Linux with?

You don't really need any OS to run, say, BEAM VM (just an example). Language runtime could be an OS of its own, as long as it has all the necessary primitives so you can have your concurrency, messaging and persistence in a distributed fashion. All you need is a thin HAL (or a hypervisor, e.g. consider https://data-room-software.org/erlangonxen/ - just a first result I've found searching for running BEAM on bare metal) that's just enough to support the hardware.

You don’t need it to run, but running is not operating a service. Observability and debugability of unikernels is abysmal. I need Linux not for BEAM, node or Python; I need it for strace.

I thought we're talking about true serverless. I don't believe Lambda lets you use strace?

And Erlang/BEAM that I've used as an example has its own tracing and debugging facilities. (I don't think it has proper multi-tenancy though so it's not like someone can just use it for cloud as it is, but I've just picked it as a closest example to what I think serverless should look like.)

Or you're talking about this from node/server admin perspective? Then, yeah, sure, but unless you're a cloud engineer it's not your business - that's Amazon/Google/Microsoft's problems.

In my dream technology world, we’d be able to compile our applications into microkernels that we could deploy on cloud machines. Less layers between applications and the hardware, less “moving parts” that can break, etc.

> You don't really need any OS to run, say, BEAM VM (just an example).

Yes, you do. BEAM will not handle your CPU interrupts or manage your physical memory pages or your USB devices. (The 99 percent of an OS's job.)

That's hypervisor's (or some theoretical HAL's) job. While those can also be called an OS - I meant, there's no need for a full-fledged one, like Linux kernel.

Reading that I am confused: isn't hardware abstraction what the Linux kernel does? It only becomes a general purpose OS with all the distribution specific stuff.

It does, and it does a lot more than just working with hardware.

I'm sort of oversimplifying it (and probably forgetting a piece or two), but all that's needed is MMU, some minimal network subsystem with device drivers for network cards, and some very tiny VFS - just enough to handle the initrd-like thingy (the rest would be networked storage handled at the application level). E.g. if all we're going to ever run is a single VM that has its own ideas of processes and signals, we may not really need any full-fledged process scheduling or IPC, just the bits to support kernel's own threads.

A "hypervisor (or some theoretical HAL)" is literally what an OS is.

You'd build language-specific unikernels, like MirageOS. No point carting a whole operating system around to run one process as one user.

WASM? BEAM? JVM? Anything?

"Linux" is huge overkill for a cloud abstraction.

Cloud applications don't need 99% of all device drivers and the desired ones need to be tuned for cloud anyways. Cloud applications need a persistent store but not necessarily a filesystem. Cloud applications don't want to think about process scheduling they want to assume they have the CPU and memory they need. etc.

Actually by Linux I mean the whole POSIX-"compatible" operating system.

Linux itself might be fine as a HAL.

But at this point there might be better alternatives.

Have you tried AWS CDK in watch and hotswap mode? It’ll quickly replace all Lambdas with new versions upon save. Not a few ms, but a few seconds.

this is the LambdaUpdateCode api, and it’s definitely fast enough for a good dev workflow.

it even lets you pass the zip data as the post body when less than 50mb. otherwise it points to a zip in s3 or a container uri.

Isn't the described vision a little bit like Heroku, which famously had some issues?