Live data from Hacker News

We are still early with the cloud

erikbern.com

41–50 of 202 posts

Re: We are still early with the cloud

#41

Interestingly, at Google the typical developer workflow (google3) is very cloud native. Most devs write code in VS code in the browser. Many (most?) devs don't have a physical desktop any more, just a cloud VM. The code lives in a network mounted filesystem containing a repository. The repository is hosted remotely (everyone can see edits you make to any file nearly immediately). Builds are done remotely with a share…

Having heard complaints of Google developers, the problem with this is the limitation of Chromium and the browser more generally. Browsers are utterly terrible at letting users script their own shortcut etc.

Re: We are still early with the cloud

#42
post #16

> I'm excited for a world where a normal software developer doesn't need to know about... I'm not excited for this. There's a quote I cannot find that I miss greatly, but maybe a Whitehead quote or some such about Civilization being measured by that which it doesn't have to think about, that which it takes for granted. It's always struck me as powerful, but giving ourselves the ability to forget & un-learn does not t…

I think you're right that the same old fundamentals & tools will still dominate, but I think this 'new world' can arrive by just making those old fundamentals more powerful and useful. Erik's example of Spotify has within it the story of an ever more powerful and reliable internet network making first music streaming possible, then video streaming. The (mobile and wired) internet network is getting so fast these days…

Spotify is an interesting example to bring up, & somewhat a sore one for me. Because their Spotify Apps API was in effect an attempt to make Spotify a music cloud. It was, in my view, raringly successful, a great system that thousands of people built intensely good and new music experiences on, embedded within the Spotify desktop app. It turned the desktop client into a cloud-run system for rapid music app deployment, all inside the Spotify walled-garden.

Then Spotify killed it. A decision which continues to baffle me, and which, like Signals recent decision to abandon SMS, speaks mainly of a desperation to completely own the experience. https://developer.spotify.com/community/news/2014/03/24/clos...

So Spotify is now an example of a dead end, a former cloud, a mere product to me. They've taken great works from the past & about, and they've built one product, and they're going to spend decades moving around where the buttons are and trying to tweak how and when they can ring the cash register & deposit some money into Spotify, Inc. They're from the cloud (sort of), but they've wound back 90% of their ambition to be or contribute to clouds.

Spotify (& many others) can build what they build because of a conflux of factors. Simply having gobs more hard drive, cpu, network throughput, and (most important of all) new online consumers are the core hard & fast requirement that enabled Spotify to become Spotify. But that's only semi-related to what I think is really at the heart of this conversation: the cloud. Yes the team was good about scaling out & aggressively deploying new technologies, devops & core tech, and that helped them go. But it's confusing & unhelpful as a case study. Fact is: switches were just getting better, cpus were just getting better, and Spotify could almost certainly have happened in a fairly legacy way, with fairly legacy ideas, & there'd been streaming before, albeit executing & attracting/keeping necessary talent would have had worse odds on legacy ideas.

Yes: from a consumer perspective, Spotify leverages the internet to on-demand deliver content. It's an example of most of the computing happening in a far off neo-mainframe. That's absolutely something we associate with the cloud. I absolutely see that as core to Erik's story here.

But the characteristic seems somewhat uninteresting to me in isolation. I do think more scale out abstractions & ideas have a huge place, a huge future, but also, they keep running into the "then all developers are just consumers of shit they really have no idea of or power over" problem that means there's no real social environment surrounding these advances.

Something that seemed real to me from these threads: the comment griping about never managing firewall rules by hand rings true. And we are developing control planes aka controllers aka operators, are building more intent-based autonomic systems, reasonably well, that do our lifting for us. There's a host of good new "edge" (not edgy edge edge, just like, lots of data centers edge) tech that's also like- yeah- cloud it up more. Think less about computers/resources/clusters, just push code. These are all in the heart of cloud, of making available various grid computing/utility computing notions that have circled around for a long time, of making us think less specifics. And I think that's indeed true & powerful. But it keeps running into the asocial problem above, that there's no social environment, most of the secret-sauce is retained, locked inside the neo-mainframe.

CloudFlare and Deno seemingly are some of the only two who seem to realize the Tim O'Reilly adage that I hear no-where near enough this decade: "Create more value than you capture." Or else your dream is going to some day die as your dream, with yes maybe good marks, but no real lasting success. If cloud computing is to be a future of real note, it has to be a shared one. That's been an exceedingly brutal gauntlet that few technological/cloudogical would-be's have proven their advance through.

Re: We are still early with the cloud

#43

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 become less risk averse the more established they are - they are economically incentivised towards that.

The silver lining for me is that there is always room for disruptors in this scenario.

Re: We are still early with the cloud

#45
post #2

I am not a cloud expert but so much of this rings true, esp the following quote: “Why is Bob in the ops team sending the engineers a bunch of shell commands they need to run to update their dev environment to support the latest Frobnicator version? For the third time this month?” I just couldn’t stop laughing.

Because devs will not update their Frobnicator for seventeen years, choosing to solve leetcode instead. Eventually the Frobnicator that the devs are using will be so security vulnerable the fact that the source code exists in the package repository is itself a CVE. Because you're a dev, when this happens it's a funny story, but for Bob it's seventeen meetings and having to listen to Franz, the director of development chew out the entire team as if they're utterly incompetent. This means Bob just disables your access to the rest of the systems unless you have a correct Frobnicator, and doesn't care whether he blocks you or not - because you would be complaining to your director either way.

Re: We are still early with the cloud

#46

Interestingly, at Google the typical developer workflow (google3) is very cloud native. Most devs write code in VS code in the browser. Many (most?) devs don't have a physical desktop any more, just a cloud VM. The code lives in a network mounted filesystem containing a repository. The repository is hosted remotely (everyone can see edits you make to any file nearly immediately). Builds are done remotely with a share…

Having heard complaints of Google developers, the problem with this is the limitation of Chromium and the browser more generally. Browsers are utterly terrible at letting users script their own shortcut etc.

It's perfectly possible and in fact quite pleasant to work with intellij inside google. At least for JVM languages.

Disclaimer: I work for google

Re: We are still early with the cloud

#47

Interestingly, at Google the typical developer workflow (google3) is very cloud native. Most devs write code in VS code in the browser. Many (most?) devs don't have a physical desktop any more, just a cloud VM. The code lives in a network mounted filesystem containing a repository. The repository is hosted remotely (everyone can see edits you make to any file nearly immediately). Builds are done remotely with a share…

Having heard complaints of Google developers, the problem with this is the limitation of Chromium and the browser more generally. Browsers are utterly terrible at letting users script their own shortcut etc.

The problem is that developers have no idea how to run systems at a scale larger than their local Mac and iPhone.

Re: We are still early with the cloud

#48
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,…

Good replies by others here. "crazy and destructive" that you have no idea about how computers work today, or how computers are still computers. Your ignorance about things like Sun workstations as it relates to literally everything today, I mean you have no idea about modern computing lol

Re: We are still early with the cloud

#49

Saying that Spotify is "producer-friendly" must be couched in the context of the times. 100% of $0 is still $0, and at the time most people were just pirating music so you weren't making anything off of recordings. If Spotify wanted to give you literally fractions of a cent instead of $0, you were going to take that. I wouldn't say it was ever really friendly to producers...mostly to consumers and, in order to be fri…

Spotify pays up to 70% of their revenue to copyright holders.

So, your beef should be with them, not Spotify. Which you should already be aware of if you truly are a music producer.

However, it costs you nothing to bash Spotify. It may cost you your career to bash the actual greedy leeches who control the money flows in music.

Re: We are still early with the cloud

#50
post #26

Earlier quoted context omitted.

"It's crazy and destructive that we are still using the unix paradigm in the cloud." # ssh user@rsync.net "test -f fileThatExists" #echo $? 0 ... from my cold, dead hands ...

Quoted post unavailable.

Okay, tell me how you do it much better in k8s
Post reply on HN