The best answer is of course not to at all. Burst into the cloud, static workloads in your own DC.
This is terrible advice for all but the largest of organizations. Running your own hardware is AWFUL. Get ready to dedicate an entire team to network engineering, fixing broken hard disks, patching operating systems, screwing around with RAID controllers, upgrading switches, planning power and cooling, and endless vendor negotiation -- with ISPs, hardware manufacturers, datacenter operators, etc. Oh, and did I mentio…
Effectively using AWS Reserved Instances
41–50 of 123 posts
Re: Effectively using AWS Reserved Instances
#42The notion that the break even point is 70% is ignoring some really important stuff. If you reserve workload x on hardware y for n years, you're effectively strapping yourself into a sure-to-be-obsolete and more expensive platform which you'll have to then move off of at an arbitrary point n years in the future. If you don't move, you wind up paying a premium to be stuck with the obsolete / more expensive platform ju…
Re: Effectively using AWS Reserved Instances
#43> To automate this, we built an ETL process in SQL and Python that detects when we fall outside this band and automatically prepares a purchase for us to approve. @Stripe: Will this (or parts of it) be open sourced?
They published the code in a gist. It doesn't have a license, but since the python code is only 61 lines, would be trivial to rewrite yourself from their example. https://gist.github.com/lopopolo-stripe/e00b4bfa0839c125ed7a...
Re: Effectively using AWS Reserved Instances
#44Google Cloud's pricing approach seems much more sane than each company having to spend all this effort juggling reserved instances.
Visibility in terms of outcomes means savings, or rather, variability means cost.
Ultimately, you're going to bear the cost if you cannot provide visibility because Google is not likely ever going to do it as well as you can for your own business.
Ultimately, if you knew exactly what you needed over the next few years, the cost would be significantly cheaper as there's no need to have slack or wasted capacity. Google effectively forgoes this option entirely and assumes at least some minimum volatility, which means more cost.
I think it would be nice to have Google's offer, but then also a longer term 'lock in' low price option as well, as frankly, this fits a lot of businesses. Most of the economy is not as dynamic as Valley startups.
Re: Effectively using AWS Reserved Instances
#45Despite being a strong advocate for AWS, this is where I will say Google completely outshines Amazon. Google's approach to pricing is, "do it as efficiently and quickly as possible, and we'll make sure that's the cheapest option". AWS's approach is more, "help us do capacity planning and we'll let you get a price break for it.". Google applies bulk discounts after the fact, AWS makes you ask for them ahead of time.
Using GCC still feels like comparing an early android to a modern iOS. I guess they have to sell it cheap when the features and quality is not there.
For example: when AWS encounters non-catastrophic issues with their hypervisor, you are on the hook for moving the instances away (meaning stop-start, or termination and relaunch for instance store). Depending on the instance type, this can cause service disruption.
GCP will transparently migrate the VM while it is running for you. You never see it, you customers don't either.
Same for networking: if you use their "premium" network, you can have anycast IPs to the closest POP, which will route traffic on Google's Network, not the open internet. AWS does not have anything close to this, the closest is multi-region VPC peering, without the fancy routing.
AWS offers more features though, which could be important if you require them.
Re: Effectively using AWS Reserved Instances
#46Earlier quoted context omitted.
This is terrible advice for all but the largest of organizations. Running your own hardware is AWFUL. Get ready to dedicate an entire team to network engineering, fixing broken hard disks, patching operating systems, screwing around with RAID controllers, upgrading switches, planning power and cooling, and endless vendor negotiation -- with ISPs, hardware manufacturers, datacenter operators, etc. Oh, and did I mentio…
Having run a small hosting company for about 17 years now, I am laughing at this post... You greatly overstated the difficulty and understate the massive cost savings.
Re: Effectively using AWS Reserved Instances
#47Earlier quoted context omitted.
This is terrible advice for all but the largest of organizations. Running your own hardware is AWFUL. Get ready to dedicate an entire team to network engineering, fixing broken hard disks, patching operating systems, screwing around with RAID controllers, upgrading switches, planning power and cooling, and endless vendor negotiation -- with ISPs, hardware manufacturers, datacenter operators, etc. Oh, and did I mentio…
Having run a small hosting company for about 17 years now, I am laughing at this post... You greatly overstated the difficulty and understate the massive cost savings.
Re: Effectively using AWS Reserved Instances
#48Earlier quoted context omitted.
To be fair, AWS gives you bigger discounts for RI than GCP's sustained use. That makes sense; someone gotta pay for the risk. This said, GCPs committed use discounts still seem to be a better deal than convertible RIs. Looking at the run-of-the-mill 64GB RAM standard instance: AWS 1yr all upfront: $0.458 GCP commited use: $0.47878 AWS 1yr no upfront: $0.491 GCP sustained use: $0.532 AWS 1yr no upfront convertible: $0…
The customer takes all the risk. Reserving instances is a bad deal, that should be assimilated to gambling.
There is a certain amount of clarity or volatility in a system. Volatility will entail cost that will effectively be passed onto the buyer one way or another.
Google can be smart about it and try to do some predictions, but ultimately, the customer should in many cases know much more about what their usage patterns will be. This information reduces volatility and therefore cost ... passed on to the buyer.
If you say "I want to rent 10 cars for a month" vs. "I want the ability to rent from 2 to 20 cars for a month, not sure about what" - what is the intrinsic cost going to be for the provider? Even with demand smoothing over a large client base ... the increased volatility is cost.
I don't think this is related to gambling.
In many ways this is really similar to financial planning and I think the language of this article will make way more sense to financial types than technical types. I might even go so far as saying this is really a problem for financial ops, and not devops.
Re: Effectively using AWS Reserved Instances
#49Earlier quoted context omitted.
What are you talking about? I have so many questions - who is uncle Bob in this scenario, an AWS employee? Who's uncle is he and why is that important? And what makes his flash drive fancy? AWS has several encryption products you can easily look up, such as KMS. No, the employees don't have the keys. [1] [1] https://aws.amazon.com/kms/faqs/
Uncle Bob is AWS employee. How is the application residing on AWS decrypt private data if it does not have access to the master(private) key?
Re: Effectively using AWS Reserved Instances
#50I thought that payment processors are using their own hardware. How is AWS protecting their own customers' privacy? - can uncle Bob insert his fancy flash drive, copy my data, and sell it? Before you say it is encrypted - where does the encryption happen and doesn't AWS employees have access to the keys too?
AWS has different options for different companies/data. They even have options for US government data that are certified by DSS I believe, and they have options if you need PCI, HIPAA, and other types of compliance. See: https://aws.amazon.com/compliance/hipaa-compliance/ https://aws.amazon.com/compliance/pci-dss-level-1-faqs/