4 ms·
Cloud is difficult because it stiched together from fragments of old applications and approaches. Cloud will be easy with consistent approach. One or very few
by vbezhenar 3y ago
Cloud is difficult because it stiched together from fragments of old applications and approaches.
Cloud will be easy with consistent approach. One or very few languages for everything, from configuring resources, to configuring policies and writing code.
Cloud will be easy with opinionated tooling. No Dockerfile and supporting of miriads languages. Just file with dependencies and folder with source code.
Cloud will be easy with opinionated approach to configuration. No need to support PASSWORD env, PASSWORD_FILE env, some secret access service. Only one secure and simple way.
Basically rebuild cloud from the ground up. Remove Linux from equation, we don't need it. Remove filesystem from equation. You have a source code which executex somewhere. You can declare that your service needs database and it'll get it. You can declare that your service needs to access another service and you'll be able to use API to access another service, without thinking about URLS, auth tokens and all this nonsense. Just RPC.
Lambdas are good idea, but very convoluted. Lots of abstractions over abstractions. Terraform which calls AWS API.
Things could be so much simpler and faster. There's nothing that prevents you from redeploying your service in microsecond, just as you hit "Save" button in vscode.
- drdaeman 3y ago> 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).
- afandian 3y agoThat tight, opinionated integration of hardware and software sounds a lot like 'mainframe'.
- drdaeman 3y agoLisp machines strike back? ;)
- lelanthran 3y ago> Lisp machines strike back? ;) Ah well, you beat me to it: https://news.ycombinator.com/item?id=36489625 https://news.ycombinator.com/item?id=36489625
- stingraycharles 3y agoThat’s what I was reading here, everything old is new and opinionated again.
- phito 3y agoWhat would you replace Linux with?
- drdaeman 3y agoYou 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/ 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.
- baq 3y agoYou 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.
- drdaeman 3y agoI 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.
- FridgeSeal 3y agoIn 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.
- otabdeveloper4 3y ago
- themodelplumber 3y ago> 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.
- nathants 3y agothis. the problem is people, not tech. the solution is taste and discipline, same as its always been.
- ojkelly 3y agoThere’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.
- skinny85 3y agoIsn't the described vision a little bit like Heroku, which famously had some issues?
- otabdeveloper4 3y ago"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.
- fathyb 3y ago> 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
- moltar 3y agoHave 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.
- nathants 3y agothis 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.