Live data from Hacker News

We are still early with the cloud

erikbern.com

161–170 of 202 posts

Re: We are still early with the cloud

#161
post #112

As a developer I have an adversarial relationship with the Cloud even though I use it all the time. The reason for that is money / billing. As soon as a credit card is in the relationship exploration and experimentation is over for me. My local Linux machine may go on fire but it will never send me an invoice no matter what I do.

A cynical view would be the billing is designed to trip you up. As an example, if you use Azure with a Visual Studio subscription which includes credit, once the credit is used all of your services are suspended and no further charges are incurred. As a pay-as-you-go customer this option does not exist. You can set a billing "alert" but that doesn't stop the charges.

Yeah that is quite scary. I'd feel much better if I could put a limit on the billing. Just shut everything down if I go beyond X amount of money.

Re: We are still early with the cloud

#162
post #158
post #129

I started my career in simpler times. Developers would produce a zip and handed it over to an admin guy. Dev and Infra/Ops clearly separated. No CI, sometimes not even a build step. I understand the power and flexibility of the cloud but the critical issue is the dependency on super humans. Consider a FE or mobile app developer. They already greatly struggle just to keep up with development in their field. Next, you…

And you're glossing over the pain points that drove the industry to coin DevOps - those times when the zip didn't contain everything it needed to run in production properly and the admin guy had to call the dev multiple times in the middle of the night because their app didn't start properly on deployment. Or the install/startup procedure wasn't documented properly. Or it changed and the document didn't get updated.…

Never had such issues, you can still do decent coordination in such hand-overs. Honestly the only issue was the inflexibility of the hardware.

Re: We are still early with the cloud

#163
post #162
post #158

Earlier quoted context omitted.

And you're glossing over the pain points that drove the industry to coin DevOps - those times when the zip didn't contain everything it needed to run in production properly and the admin guy had to call the dev multiple times in the middle of the night because their app didn't start properly on deployment. Or the install/startup procedure wasn't documented properly. Or it changed and the document didn't get updated.…

Never had such issues, you can still do decent coordination in such hand-overs. Honestly the only issue was the inflexibility of the hardware.

As a former sysadmin who had part of his career in that paradigm, I never again want to wait until 10:30 PM to run manual production deployments handed to me by a developer and hoping their documentation was correct.

Give me CI/CD pipelines deploying containers to a k8s cluster during the day.

Re: We are still early with the cloud

#164

Earlier quoted context omitted.

There are plenty of locations where internet connections constantly breaks, or the network equipment is just so poor that everyone's connections drop/connect once a day or so. Or that the latency is so high that most servers drops your connection before they even gave you a chance to connect. That's "offline" as well even though I'm not actually offline, my connection is just really slow. But the mindset you have exp…

Most software development simply does not happen in those places for that reason. Basically, it's a supply and demand thing. Software developers require decent connectivity and they'll move to where the connectivity is. Or they'll fix a decent connection (using star link or whatever).

I promise you, software development also happens in unbelievable places like South America, Africa and other low connectivity places.

Edit: just came across this submission https://news.ycombinator.com/item?id=33274186

Seems funny that Stack Overflow would enable offline usage when supposedly no developers have poor connection, they'll simply move to places with amazing networking.

Re: We are still early with the cloud

#165
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…

> Cap'n'Proto dared to dream a little more multi-service, to follow somewhat after E-language, but never materialized 3-plus-way communication.

I still intend to implement this! It just has yet to become the most pressing issue for the projects I'm focused on, since the development model is already supported using proxying which makes 3-party handoff merely an optimization.

Re: We are still early with the cloud

#166
post #151

Earlier quoted context omitted.

Poor analogy. You're welcome to address what I wrote directly if you'd like though.

It's quite an appropriate analogy. We used to write a lot of code in assembly code. I used to write microcode and even modified a CPU. But it's been decades since I last wrote microcode (much less modified an already installed CPU!) and now the instruction sets of MPUs like x86 and ARM are mostly just abstractions over a micromachine that few people think about. And an OS it the same: it used to be quite common to wr…

Are you advocating for more abstraction or less? As in a cloud without all the modern OS layers and cruft.

Re: We are still early with the cloud

#167
I have now interns that are supposed to be coding, some are close to have nice diplomas like "CS engineer" and the like but the sad truth is that they don't understand what's a computer, what's a network, what's a server and what's a client, what's the internet and what's a file.

So the cloud 2.0 is all fine and dandy, not having to care about IPs addresses and NAT and storage space is great, however don't forget that all abstractions leak and at some point I'm not sure you can escape going through "from NAND to Tetris" and having built a LAN with a couple of RaspPi to get shit that works done.

That was my old hat rant :)

Re: We are still early with the cloud

#168
post #103

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…

> Now CI has a node that puts your local machine to shame A nice problem to have, I only know the opposite side. Developer laptop being twice the speed of CI.

I'll admit it depends a bit. We're moving to Github Actions and their runners are … slow. There are custom runners, but they're a PITA to set up. There's a beta for bigger runners, but you have to be blessed by Github to get in right now, apparently.

Re: We are still early with the cloud

#169
post #75

Earlier quoted context omitted.

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

Wait, I remember Google gave up supporting IntelliJ around 2011, leaving only one full-featured IDE, Eclipse, as the only option. Did it change since 2011?

That reversed in ~2016. Because Android Studio was based on IntelliJ and heavily staffed (including Blaze support for development of Google's own Android apps), TPTB decided that they should put their weight behind IntelliJ instead of Eclipse. Official internal support for Eclipse was discontinued and the Eclipse team was disbanded.

Re: We are still early with the cloud

#170
post #43

Earlier quoted context omitted.

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.

Yes, sorry :P
Post reply on HN