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.
We are still early with the cloud
161–170 of 202 posts
Re: We are still early with the cloud
#162I 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.…
Re: We are still early with the cloud
#163Earlier 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.
Give me CI/CD pipelines deploying containers to a k8s cluster during the day.
Re: We are still early with the cloud
#164Earlier 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).
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> 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 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
#166Earlier 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…
Re: We are still early with the cloud
#167So 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
#168First, > 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.
Re: We are still early with the cloud
#169Earlier 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?
Re: We are still early with the cloud
#170Earlier 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.