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

31–40 of 202 posts

Re: We are still early with the cloud

#31

Post by nstart »

_gabe_ wrote: post #24
thundergolfer wrote: post #10

Earlier quoted context omitted.

But the cloud can and will be a fundamental part of the new developer tools. Since reading the blog post's mention of Repl.it I went and downloaded their new Iphone app and used https://modal.com to spin up 30-40 containers from a script doing sentiment analysis on ~30k movie reviews: https://twitter.com/jonobelotti_IO/status/158291976221638656... This cost me about 5 cents. Developer environments and workflows built…

> Since reading the blog post's mention of Repl.it I went and downloaded their new Iphone app and used Modal.com to spin up 30-40 containers from a script doing sentiment analysis on ~30k movie reviews: IPhone processors run billions of cycles every second and are capable of running billions of instructions every second. I'm amazed that we've gone from "Run doom on my toaster", to "I can spin up 30-40(!) containers t…

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, and redis instance and code anywhere you go without thinking of setting up an environment. Don’t even think of how to connect to your db. The tool knows you want your service to connect to it and knows not to let anyone else connect except for exceptional case debugging. And once you are done with your v0.0.1, you press deploy, wizard your way through, and it’s out on the internet without you having to think about it further. (And for bonus points, everything including the platform config is quietly getting committed to a git repo in the background so you get all the advantages of IAC by default in the event you need it). And you don’t think about scaling or deployment resources or anything like that. It just happens and you go on about your business (hopefully with some thought given to billing). And when you want to connect a service to another one you don’t think of concepts of ip blocks or auth or certificates. Service A communicates with the world and service B. The dev experience is that you call service B from service A and all the auth and TLS and ip addressing and name spacing is handled in the background. The dev experience is you call service B and that’s it. And that deploys 1:1 to production as well.

Even the above scenario feels somewhat uncreative like it only imagines a few steps up from what we have instead of a paradigm shift. But basically it’s not about shifting to different platforms like iOS or remote dev machines. It’s about an experience of development that is tied in deeply with the environment you ship to and in a way that completely frees you of thinking of low level concepts which all happen in the background.

Re: We are still early with the cloud

#32

Post by deckard1 »

_gabe_ wrote: post #24
thundergolfer wrote: post #10

Earlier quoted context omitted.

But the cloud can and will be a fundamental part of the new developer tools. Since reading the blog post's mention of Repl.it I went and downloaded their new Iphone app and used https://modal.com to spin up 30-40 containers from a script doing sentiment analysis on ~30k movie reviews: https://twitter.com/jonobelotti_IO/status/158291976221638656... This cost me about 5 cents. Developer environments and workflows built…

> Since reading the blog post's mention of Repl.it I went and downloaded their new Iphone app and used Modal.com to spin up 30-40 containers from a script doing sentiment analysis on ~30k movie reviews: IPhone processors run billions of cycles every second and are capable of running billions of instructions every second. I'm amazed that we've gone from "Run doom on my toaster", to "I can spin up 30-40(!) containers t…

> Doom was written for the IBM PC. This PC had a clock speed of 4.77MHz and 64Kb of RAM.

well, not that PC. Doom required a 386 and 4MB of RAM. But you really wanted a 486 or Pentium to run it smoothly. Catacomb 3D, a real early id Software 3D game, actually would run on an 8088 XT.

Also noteworthy, Doom was created on a NeXT computer, which was also a bit ahead of PC at the time. So there was a power differential applied to what they were creating.

Re: We are still early with the cloud

#33

Post by [deleted] »

m463 wrote: post #25
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,…

I completely understand what you're saying. I'm sort of reminded of how the US government is the worst (except for all the rest), when having an absolute ruler should be so MUCH more efficient. Problems would be fixed by fiat. Or maybe, why does lisp persist with its horrible user-unfriendly syntax? :) I guess we will just have to invent it. (and you should do your part by reminding people with examples of old system…

[deleted]

Re: We are still early with the cloud

#34

Post by mgraczyk »

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 shared object cache. Tests typically run in the cloud (forge).

Facebook has similar infrastructure, although more pieces run locally (builds were mostly done on your VM circa 2020)

For my personal projects, I try to do most development on a cloud instance of some kind, collocated with the rest of the infrastructure.

Re: We are still early with the cloud

#35

Post by morby »

nstart wrote: post #31
_gabe_ wrote: post #24

Earlier quoted context omitted.

> Since reading the blog post's mention of Repl.it I went and downloaded their new Iphone app and used Modal.com to spin up 30-40 containers from a script doing sentiment analysis on ~30k movie reviews: IPhone processors run billions of cycles every second and are capable of running billions of instructions every second. I'm amazed that we've gone from "Run doom on my toaster", to "I can spin up 30-40(!) containers t…

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…

But this forces architectures that may be problematic for certain use cases. Cookie cutter solutions will always end up getting bogged down with more and more options. And options for options.

Re: We are still early with the cloud

#36

Post by GMoromisato »

100% agree.

https://replit.com is making progress on this. They've moved (almost) all dev tools to the cloud so you can just edit and run in the cloud.

My own project, GridWhale, goes one step further and provides a single, integrated cloud platform for development. Rather than writing separate programs for frontend and backend, you write a single program and the platform remotes the UI as appropriate. Here's a demo: https://gridwhale.medium.com/the-gridwhale-gui-system-55c449...

Re: We are still early with the cloud

#37

Post by jb_gericke »

We're seeing the drive to Internal Development Platforms and Platform Engineering teams who are charged with eliminating developer toil and creating golden paths (ironically coined by Spotify engineering)/paved roads to production as a response to the complexity inherent to modern apps and the modern app SDLC.

Not so much an abstraction over public cloud as it is an opinionated consolidation of DevOps, SRE and cloud engineering.

Re: We are still early with the cloud

#38

Post by deathanatos »

First,

> I never ever again want to think about IP rules. I want to tell the cloud to connect service A and B!

Dear God this 1000 times. My eyes bleed from IP-riddled firewalls foisted upon my soul by security teams.

If I could also never NAT again, that'd be nice.

> Why do I need to SSH into a CI runner to debug some test failure that I can't repro locally?

Hey I can answer that one. Because an infra team was tasked with "make CI faster" and couldn't get traction getting the people responsible for the tests to write better tests (and often, just hit a brick wall getting higher ups to understand: "CI is slow" does not mean the CI system is slow. CI's overhead is negligible), and instead did the only thing generally available: threw money at the problem.

Now CI has a node that puts your local machine to shame (and in most startups, it's also running Linux, vs. macOS on the laptop) (hide the bill), and is racing those threads much harder.

I've seen people go "odd, this failure doesn't reproduce for me locally" and then reproduced it, locally, often by guessing it is a race, and then just repeated the race enough times to elicit it.

Also, sometimes CI systems do dumb things. Like Github Actions has stdin as a pipe, I think? It wreaks havoc with some tools, like `rg`, as they think they're in a `foo | rg` type setup and change their behavior. (When the test is really just doing `rg …` alone.)

Also, dev laptops have a lot of mutated state, and CI will generally start clean.

Those last two are typically hard failures (not flakes) but they can be tough to debug.

> Do we need IP addresses, CIDR blocks, and NATs, or can we focus on which services have access to what resources?

We need IP addresses, but there's not really a need for devs to see them. Nobody understands PTR records though. CIDR can mostly die, and no, NAT could disappear forever in Cloud 2.0, and good riddance.

Let me throw SRV records in there so that port numbers can also die.

Because it's bothering me: that graph is AWS services, not EC2 services.

Re: We are still early with the cloud

#39

Post by emptybits »

rektide wrote: 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…

> There's a quote I cannot find that I miss greatly ...

This is probably it: "Civilization advances by extending the number of important operations which we can perform without thinking of them." - Alfred North Whitehead

(And I agree that depth is rewarding and civilization allowing us to forget things isn't always tempting!)

Re: We are still early with the cloud

#40

Post by verisimilitudes »

rsync wrote: post #26
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,…

"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 ...

No post body was provided.
Post reply on HN