Yeah, say all you want about AWS pricing, but damn if Amazon doesn't go out of their way to support things for a very long time.
I once complained on Twitter that I was having trouble with an EKS issue, and the product manager for EKS reached out to me directly, put me in contact with one of their engineers, and then they discovered an issue and rolled out a fix for it that day.
In a separate incident, I couldn't get GCP to read the verification data for a domain from their webmaster tools so I was unable to use the domain with GCP Cloud Run. I mentioned this on Twitter, and the product manager reached out to lecture me about how I shouldn't be using Cloud Run with domain mapping because that's in "preview". He then pointed me to another method to point a domain at cloud run, which it turned out was also in preview. All of this was because Google Webmaster Tools validated the domain but GCP wasn't able to get that information. I ended up cancelling the GCP project and just using AWS (as I should have from the start).
It's embedded deeply in Google's culture that they not only don't provide support, but they'll insult and gaslight the people asking for it.
I will say though that companies which take support seriously do monitor all sorts of channels as well.
Very much this. At my company we have many other means of support readily available, but some people instinctively reach for Twitter for peer support. Being active on Twitter means our support team can help even those people who don't think to use our official channels, which is good for the customer and good for our image.
I think that parent post was just implying that AWS cares about it's image and will provide support even if you don't go down the correct channels.
Google doesn't give a shit regardless of the method of request.
They even go into your cloud architecture and tell you where you fucked up.
And yes, they have made their money back off me in the 10 years since (average $100-200 a month).
[0]: https://vertis.io/2013/12/16/unauthorised-litecoin-mining/ [1]: https://news.ycombinator.com/item?id=6911908
And yes,it's bad practice putting the keys in code to begin with, and I knew better.
Won't save some of it if you're sleeping, but can definitely reduce the time someone has to run up bills.
Also to the users of their open source software, as many people who used Tensorflow 1.x can attest to.
This feels like the crux of the difference between Google and Microsoft/Amazon.
Google product culture seems to assume they built everything correctly, so if there's an issue, you're questioning their competency.
Microsoft/Amazon product culture seems to start with "weird things will constantly go wrong", so support is viewed as an opportunity to figure out how things can be made better, based on real world experience.
For most Google products, what seems to be missing is a link between customer support and SRE. I.e. "We're Google, we can't do customer support at our scale. SRE is a superior way of keeping services reliable."
Fair... but SRE doesn't handle "the real world is messy, and here's a situation a product manager never thought of."
Out of the big three, Google Drive had an insanely good run as unlimited. (Even non-enterprise business plans with caps in theory were unlimited in practice until this year.)
- Former ACD customer who got burned.
I assume this means they look at your photos and other data.
You can "compress" anything, if one of the modes of your compressor is simply to store the data "as is", but generally speaking encrypted data is indistinguishable from a random bit stream and cannot be compressed.
If you think about it, one of the ways that compressors and attacks on encryption work is by looking for structure in the data. If you still have that after encryption, you don't have a good algorithm.
Due to the pigeonhole principle, to be able to make some inputs shorter you have to make some inputs longer. The way compression works is by making more likely inputs shorter, while making unlikely inputs longer. But for encrypted data, if your encryption method is good (that is, not ECB mode), all possible values are equally likely (unless you known the secret key).
Mostly it's photos, pdfs, word documents, executables, videos, etc.
Aside from that there are mathematical tools you can use to detect whether a binary blob is compressed/encrypted or not, like entropy calculation.
That gives me an idea. Might be fun to write a tool that will encrypt a file but make it look like a valid .zip file that just unpacks to meaningless noise. There's gotta be something like that already out there... Although you could recursively unpack/evaluate and eventually you should get to the point where it's non-random data. If you never do, then it's encrypted.
There are some academic papers (I think one by Ross Anderson) which state that steganography relies on there being some randomness in the data you are hiding the message inside. So, to make the bandwidth available for for steganographic data hiding as large as possible, those needing to conceal data need incentives for innocents to publish files constructed using as large as possible quantities of random bits. It looks like Stable Diffusion is providing this incentive!
I used to use Amazon stuff but it has really become such insane spyware. There is no data collection/analytics that goes too far for Amazon. It's really appalling, no less so that they use their near monopoly on using Kindles to deeply mine for data on exactly what people are reading, how long on each page, etc. Really gross.
If I had to lose one bit of data or port one platform due to Google's !@#$%^&, it would more than pay my lifetime personal Google expenses many times over, as well as of the lifetime expenses of my current employer.
Former employer bubbled up to millions of dollars, and it was still worth it. Former employer got screwed over by Google to a greater tune, despite having a dedicated engineering support team at Google.
The math starts to work out differently for some of the PaaS providers, where costs are several times higher than AWS, and my time is cheaper despite the (rather impressive) time savings. However, having a reliable cloud provider pays for itself many times over.
I've lost had serious unexpected expenses literally every time I've been in any business setting which did business with Google. That's quite a few times. Literally the only time I'll do business with Google is:
- Free tier, quick one-off hack
- Legacy
- Literally no other options
Even the legacy, I'm working to port away since it's cheaper to do on my timeline than Google's.
>I've had customers get their cloud accounts shut down for a literal three cent billing error
I once just stopped paying an AWS bill on a small website I abandoned (few USD/month), came back to check after a long while and I was surprised to find out how long does it take for AWS to actually shut you down.
Also on AWS, on two different occasions I screwed up and got a high ticket bill:
* Got a lot of data out of Glacier and bill spiked to a couple thousand $$$ (this one'e explicitly mentioned several times in their docs but my mind just didn't register it).
* Forgot to turn off some expensive spot instances and left them running for ~2 days (where it should've been minutes). Again, some thousand $$$.
Both times I opened tickets, told them it was an honest mistake and they just wrote them off, :O.
I reached out to our account rep at AWS and asked if we could delay our bills for three months. They laughed and said that if we didn't pay our bill for three months their system would just send us a bunch of emails, but that they wouldn't even start the process of closing the account until at least three months had passed- and even then they'd delay it further for us.
We got a new funding round and paid all of our bills, but we would not have been able to make payroll if AWS wasn't so lenient about it. That was 2020, so almost three years ago, and that company is still regularly featured at AWS talks and product announcements.