Live data from Hacker News

We are still early with the cloud

erikbern.com

111–120 of 202 posts

Re: We are still early with the cloud

#111

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.

It’s even worse than that really because it only takes a small slip into some of the cloud-native services and that adversarial relationship is entirely unavoidable and unportable and you are stuck with it. Which is exactly what is demanded by the providers to get the best cost-benefit relationship in the short term. Of course the human race is entirely cursed by short-term thinking.

The true cost of all technology is only apparent when you get the exit fee invoice.

Re: We are still early with the cloud

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

Re: We are still early with the cloud

#113
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.

It's kind of weird that it's not just a built in toggle button to the system but GCP has the primitives to let you suspend the system when a threshold is met.

https://cloud.google.com/billing/docs/how-to/notify#cap_disa...

Re: We are still early with the cloud

#114
post #87
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…

> After this discussion decided Ill never ever want to work with ppl with such attitude.

This is a problem I constantly come across when trying to hire people coming from Netflix, Google, Facebook, Amazon and similar companies that have this "I'm the smartest vibe".

At one point in time, it was a good indicator of skill that they were coming from one of those places, that we could trust their technical knowledge as long as they left the place willingly and weren't fired from the place.

But some years ago it started to change and now we're seeing previously work experience at those places as something negative, as hires from those places tend to want to upend everything to something their previous company used to do, even though it wouldn't make any sense for the their new workplace to do.

And then constantly "scale" becomes an argument when the product they're building haven't even found a market fit yet. They're always jumping into this theoretical possible limits that we're nowhere near of hitting but want to solve everything upfront.

It's exhausting both for management and the rest of the team to have to deal with, so best just to avoid that class of developers as a whole.

Re: We are still early with the cloud

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

Interesting to hear people who use OpenFaas. Seems you are happy with it? Any big problems?

Re: We are still early with the cloud

#116
post #112

Earlier quoted context omitted.

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.

It's kind of weird that it's not just a built in toggle button to the system but GCP has the primitives to let you suspend the system when a threshold is met. https://cloud.google.com/billing/docs/how-to/notify#cap_disa...

Shame it doesn't actually protect you, this startup [1] had a spending limit and they racked up charges so fast even Google's own billing system couldn't keep up.

In typical Google fashion it's luck of the draw if you get saved or lose your home [2]

[1] https://blog.tomilkieway.com/72k-1/

[2] https://news.ycombinator.com/item?id=25378899

Re: We are still early with the cloud

#117
post #66

Developing on a cloud VM is all fun and games until the connection drops. Will it some day be possible to have a reliable connection everywhere all the time? I donno.

Without internet connection, most modern development grinds to a halt pretty quickly in any case. Github won't work. All those dependencies your build needs will no longer download. That issue tracker that tells you what you need to do is no longer reachable, and forget about copy pasting from Stackoverflow. Etc. There are things you can still do offline of course. But it gets inconvenient pretty quickly. There's not…

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 explains a lot about why most software doesn't well in environments like that, people simply believe conditions like that don't exists so why should the server allow connections that take longer than 3 seconds? "Probably they're spamming us so let's drop the connection instead".

If you have the right setup, all of the issues you're saying are easily worked around (even the "copy paste from Stack Overflow" issue, although I'm not sure if that's a joke or not).

Re: We are still early with the cloud

#118

Earlier quoted context omitted.

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…

Interesting to hear people who use OpenFaas. Seems you are happy with it? Any big problems?

I like it for many reasons, but especially the helpful community, founder and everything just works. We use it with Istio at the moment. We switched from Cockroach (did not like the license and we had a few perf issues) to Yugabyte en Scylla recently for micro service and Monolith scaling to use with openfaas and it is really scaling to anything we need. Of course different situations have different needs, but this works very well for us.

Re: We are still early with the cloud

#119
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.

That has been true for as long as I have been programming. But:

Similar statements have been made about high level programming languages. Nowadays most devs don’t understand how the CPU works, but write on the top of a tower of abstractions and nobody bats an eye. Many of those abstractions are quite complex!

I can imagine that the same could apply to certain kinds of network activities. Look at how ppl use http as a magical secure and robust inter process communication channel with no understanding of how it works at all.

Lambda is a half a baby step in this direction.

Another problem is tollbooths. The phone system uses a lot of bandwidth simply to charge the customer money. My phone company charges me overseas rates if I make a phone call outside the country, even if both endpoints are using WiFi, not the cellular network! I’m afraid of the same with fine-grained and abstract distributed computing, but perhaps the magical hand wave abstractions I posit above can help.

This tollbooth nightmare btw is the dream of the web3 bros.

Re: We are still early with the cloud

#120

Earlier quoted context omitted.

Quoted post unavailable.

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…

> The great thing about Linux as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it.

The great thing about x86 instruction set as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. Only a handful of programmers develop at a layer below the x86 instruction set, or even at that level for that matter.

We have to get our heads out of that mire.

Post reply on HN