Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We are still early with the cloud

erikbern.com

Post reply on HN
Print view View original

91–100 of 202 posts

Re: We are still early with the cloud

#91

Post by codetrotter »

fhd2 wrote: post #43
JayStavis wrote: post #23

Maybe there is a name for this phenomenon, but it feels like when we add so much productivity via layers of abstraction, even more person-effort gets allocated to the higher levels of abstraction. Because 1. that's where people are most productive / happy / compensated / recognized / safe 2. businesses can confidently project return on investment How many engineers get to work on a part of the stack that has some roo…

Probably not the name you're looking for, but I typically talk about this stuff in terms of local and global maxima. Low-risk optimisation efforts typically get trapped on some local maximum over time, while bold efforts get closer to the global one - the minority that doesn't fail, that is. Applies to build vs buy decisions and business in general quite nicely. From what I've seen, businesses and projects usually be…

> businesses and projects usually become less risk averse the more established they are - they are economically incentivised towards that.

You mean the other way around, right? Businesses and projects usually become more risk averse the more established they are.

Re: We are still early with the cloud

#92

Post by rtpg »

gwm83 wrote: post #50
verisimilitudes wrote: post #40

Earlier quoted context omitted.

Quoted post unavailable.

Okay, tell me how you do it much better in k8s

you could easily imagine some Python-esque shell language (xonsh?) and have that be:

print(os.path.exists("ssh://user@rsync.net:fileThatExists"))

A boolean, a still (relatively) terse line of code. And when you end up wanting to do something even a bit more complicated it'll be a smooth gradient of difficulty.

As with every discussion around shells, though, the amazing terseness of scripts is great, but every form of programmatic behavior beyond "do this then that" and "do string interpolation here" is a massive pain in the butt. The biggest advantage is that stuff like pipes are a very good DSL.

Re: We are still early with the cloud

#93

Post by abofh »

tluyben2 wrote: post #72
gwm83 wrote: post #60

Earlier quoted context omitted.

Well AWS has been quite clever, using both Xen originally and also now KVM VMs, but everything else is based on that yeah. But that's gotten really complex over the years. They now use a container execution environment called firecracker or something that is open sourced and might be totally separate from their virtualized environment - or at least on top of it where they do let you just run little jams. Cloud isn't…

Think the point is that as I am writing software, I don’t care about any of that. I expected an opinionated environment when I first heard the word cloud 2 or so decades ago; I wanted to put my code in cvs (git now) and that’s it; I don’t want to think of anything outside that. Especially security or scaling. I ran 1000s of physical Linux servers over the decades using chroots when it was not fashionable to have cont…

No post body was provided.

Re: We are still early with the cloud

#94

Post by fragmede »

pojzon wrote: post #87
asim wrote: post #69

Everything Google is doing comes to the world 10 years later. Being inside Google is like seeing the future. They had all these technologies long ago, now it's just a case of timing and turning them into products. I've learned that sometimes the world just isn't ready for these advancements. The journey Google went on internally, everyone else has to go on for themselves. That said. I think we're still super early in…

After talking to manager at Google during an interview and him explaining to me that almost all tools at Google are home baked because most if not all services are so huge you wont be able to use opensource solutions for that. Then I reminded myself about VictoriaMetrics that in benchmark outclassed Google Cloud Metrics by an order of magnitude. Ppl at Google think they are the smartest (and often are) but in some ca…

Mind linking the VictoriaMetrics benchmark? I found a couple of medium.com articles but not the benchmark itself but it sounds like a good read.

Re: We are still early with the cloud

#96

Post by johnchristopher »

rtpg wrote: post #92
gwm83 wrote: post #50

Earlier quoted context omitted.

Okay, tell me how you do it much better in k8s

you could easily imagine some Python-esque shell language (xonsh?) and have that be: print(os.path.exists("ssh://user@rsync.net:fileThatExists")) A boolean, a still (relatively) terse line of code. And when you end up wanting to do something even a bit more complicated it'll be a smooth gradient of difficulty. As with every discussion around shells, though, the amazing terseness of scripts is great, but every form of…

> you could easily imagine some Python-esque shell language (xonsh?) and have that be:

> print(os.path.exists("ssh://user@rsync.net:fileThatExists"))

That's just invoking the whole jungle when all you want is a banana.

Re: We are still early with the cloud

#97

Post by rtpg »

johnchristopher wrote: post #96
rtpg wrote: post #92

Earlier quoted context omitted.

you could easily imagine some Python-esque shell language (xonsh?) and have that be: print(os.path.exists("ssh://user@rsync.net:fileThatExists")) A boolean, a still (relatively) terse line of code. And when you end up wanting to do something even a bit more complicated it'll be a smooth gradient of difficulty. As with every discussion around shells, though, the amazing terseness of scripts is great, but every form of…

> you could easily imagine some Python-esque shell language (xonsh?) and have that be: > print(os.path.exists("ssh://user@rsync.net:fileThatExists")) That's just invoking the whole jungle when all you want is a banana.

What do you think happens when you invoke a shell? It's not some magical primitive, it also does string parsing and all the other stuff that a scripting language requires. SSH also has to parse the line!

I did say Python-esque (I do get that Python in particular has a lot of stuff in its prelude). Really if you want to be super pedantic then the most "banana"-y isn't a line in your shell but some C library calls on both sides of the system.

Re: We are still early with the cloud

#98

Post by nstart »

everfrustrated wrote: post #77
nstart wrote: post #31

Earlier quoted context omitted.

I think related to the article, this would fall under the lift and shift concept the author described. What the author really wants is a transformative experience around developing in a way that is cloud native. So don’t apt install packages on your alternative iPhone which has a Linux container option built into the OS. Instead, tap a few buttons to say you are developing a webapp with a node backend, Postgres db, a…

This exactly is what Platform Engineering teams do. Every business is unique and there isn't a universal generalisable useful solution here which is also simple. Hence why Platform teams exist.

I hear you. I’ve been lucky to work on dev experience in a platform team so I do agree that this is a platform teams job. I wonder though as our stacks mature and things normalize, if there’s a chance to do some thinking and organize systems from first principles to create a platform that suits the vast majority of app development. If a team outgrows it, maybe that’s a call for a platform team.

I’m trying to imagine though what a platform team might look like in a world like that. A lot of dev ops teams today work around cloud configs and terraform for example instead of bash scripts and hardware. Maybe platform teams of the future think of plugins and modules for these imagined systems instead of building on top of a lot of low level stuff.

Re: We are still early with the cloud

#99

Post by otabdeveloper4 »

gumby wrote: post #7

It's crazy and destructive that we are still using the unix paradigm in the cloud. In the 70s we have transparent network fileststems, and by the 80s I had a more advanced cloud-native environment at PARC than is available today.* The Lispms were not quite as cloud native as that, but still you could have the impression that you just sat down at a terminal and had immediate window into an underlying "cloud" reality,…

"Treating remote resources truly abstractly" doesn't work in practice. Too many points of failure in our systems, and you really, really don't want to paper them over with abstraction if you want to build a fault-tolerant system.

Re: We are still early with the cloud

#100

Post by bakugo »

verisimilitudes wrote: post #76
throwawaylinux wrote: post #74

Earlier quoted context omitted.

That is far, far more than transferring a byte of data. It's not the future though of course, this was well established in the 80s, it just so happens that it's a decent model for managing remote machines that outlasted over-engineered distributed designs like Plan9, VMS, MOSIX, etc. It's much more meaningful and useful than "something simple" "running little functions floating in the void" which just sounds like som…

That is far, far more than transferring a byte of data. Educate me. It's much more meaningful and useful than "something simple" "running little functions floating in the void" which just sounds like some vapid marketing pitch. That was a quick response to what I thought would be better than administrating a UNIX system on an Amazon machine. Don't be an ass. I've no experience with the real distributed computing syst…

> No, that's the vapid marketing pitch. The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage.

You sound like someone who wants some sort of magical fantasy abstraction level where errors never happen and you can just write code without ever caring about said errors or really anything that happens at a lower level or outside of your code. Sorry, but that doesn't exist and never will. Code runs on computers, it doesn't run in a "void".

Post reply on HN