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 mention, throw elasticity out the window -- all of this has to be planned in advance, and purchased, and installed, months ahead of when it will be operable. So forget the ease and convenience of just spinning up more capacity.
Also, there's a massive distraction of having to focus management attention on this non-value-adding part of the business, all so that you can shave down some cost, rather than investing in growing revenue.
Having been in this position firsthand, don't do this. If netflix can run 1/3 of Internet traffic off of AWS, I guarantee they're much larger than you, and it should say something, that they'd rather outsource this part of their business than dealing with all this crap.
Focus on software and product/market fit. It's just a much, much, much better use of expensive technical people, that will be done on day 1, without any risk, hassle, or complexity, than trying to replicate something someone else already does for you, much better and at competitive costs, than trying to reinvent all of this yourself.
To be honest, I don't even want to deal with EC2 anymore; I'd rather just use a PaaS.
Don't start a conversation with an opening generalization like that if you want something constructive. Especially when the rest of your post is clearly based on the single anecdote of your experience.
>Running your own hardware is AWFUL.
Maybe for you. Not for any sysadmin with even just a couple of years of experience.
>patching operating systems
We're talking about instances, none of that sysadmin stuff goes away if you're on AWS. If you don't have patching management for operating systems on AWS then your instances are screwed. AWS instances don't eliminate the need for sysadmin work.
The only real difference is the hardware management. And if you read my post you would have seen that I said using aws for the on-demand flexibility is okay. All of the static workloads are what belongs down in your datacenter.
Netflix doesn't run 1/3 of the Internet traffic off of AWS, only a tiny subset because of the aforementioned shitty economics. The real workhorses are in custom netflix servers at peering points. Netflix would be bankrupt if they used AWS for video. Do some research before spreading free marketing propaganda.
This forum tends to only think in terms of explosive growth of traffic, which <0.1% of companies actually have to deal with. AWS flexibility is needed by very few successful B2C companies, but it's supported by the cargo-culting of orders of magnitude more developers ("jedberg said this worked for reddit, we need this because we're like reddit").
Also, your whole argument about non 'value-add' is bogus. That's the same excuse that management uses to outsource all development. Everything has a cost and provides some value to the company.
[1] https://openconnect.netflix.com/en/ [2] https://media.netflix.com/en/company-blog/how-netflix-works-... [3] https://medium.com/netflix-techblog/high-quality-video-encod...
That didn't even take into account the "free" multi-region capability you get from Amazon. Splitting our physical servers into a second region with enough capacity to failover would have nearly doubled our costs.
Once you’re spending a few million dollars a year on cloud (arguably even less in some cases), it behooves you to explore hosting yourself. Cloud provider margins are substantial for a reason.
Also, what kind of workloads are you running that don't require databases? The biggest expense in any distributed system is moving data. If you have a datacenter with all the data, you've to move that data to the cloud and back for every bursted request. Whatever you might save in running your own DC will be lost to bandwidth charges.
And on the topic of running your own datacenter, it's unlikely you can run it as efficiently as AWS. What you might save in not paying AWS's profit margin you will probably spend in not being able to be as efficient as they are.
>What you might save in not paying AWS's profit margin you will probably spend in not being able to be as efficient as they are.
This isn't how I've seen the numbers work out for the huge chunk of workloads that require mostly static instances (a.k.a haven't been modernized into a serverless code base). You are right about Amazon having an efficiency edge, but you are wrong about that benefit being to the customer's bottom line instead of theirs.
We are nowhere near the real commoditized pricing of massive scale compute. Even with the inefficiency of smaller datacenters, you can easily best AWS prices.
Where did you get the impression that you have to move all of the data into the cloud for every bursted request? That's a lazy strawman architecture to attack.
Auto-monitoring included[2]. Unmetered bandwidth, too[3].
[1] https://www.ovh.com/world/dedicated-servers/infra/
[2] https://www.ovh.com/world/dedicated-servers/monitoring.xml
[3] https://www.ovh.com/world/dedicated-servers/bandwidth-upgrad...
“Saving money” by running your own servers is penny wise, pound foolish. You’ll never, ever compete with AWS for features or cost.
(And “you” means almost everybody reading this...)
I call shennanigans on this as a made-up statistic. You may be able to convince that percentage of people of that, but they may well not be aware of what's possible with commodity hardware.
> there is zero value add in running your own data center.
Sure there is. Money and maximum (I/O) performance.
> “Saving money” by running your own servers is penny wise, pound foolish. You’ll never, ever compete with AWS for features or cost.
You may be right about (software) features, but certainly not about cost. It's not "saving money" with quotes. It's actually saving money. You just have to hire someone that happens to know how to save money.
AWS will never, ever compete with you for hardware features or cost.
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.
Thanks jedberg. You've definitely captured how we feel about it.
I will say that while our sustained use discount (SUD) works as you describe, our committed use discounts (CUD) are more similar to the AWS Flexible RIs. For some customers, even if it's obviously cheaper to use on-demand and just get the SUD benefit, they prefer the predictable "let me be sure I pay X" model.
As a note, even though CUDs and Flexible RIs are similar, I prefer ours (obviously). It's just a pile of cores and RAM in a region that you sign up to. That is easy enough to do in arrears that no ETL is necessary, and like you imagine: we want to automate this, too. We also don't play games with upfront payment or not, but most enterprises don't care.
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.564
Either way, there is way more $$$ consulting for AWS than for GCP because of the expertise required to optimize costs.
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.
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 just to avoid the cost of migration.
RIs are a lock in.
Also bear in mind that the savings you get from RIs will generally outweigh the reduction in price of the instance.
Second, the underlying financial principle is that with visibility comes lower volatility comes lower cost - that's some very basic financial logic that's at play here.
Yes, of course the contract implies a degree of vendor lock-in, but this is inherent in the nature underlying operational costs.
"RIs are a lock in." - of course. And if you don't want to be locked in, then you're going to have to pay a lot more: AWS, GCC it doesn't matter, it's the same financial reality everywhere.
AWS has several encryption products you can easily look up, such as KMS. No, the employees don't have the keys. [1]
How is the application residing on AWS decrypt private data if it does not have access to the master(private) key?
@Stripe: Will this (or parts of it) be open sourced?
https://gist.github.com/lopopolo-stripe/e00b4bfa0839c125ed7a...
1. Once you buy a reserved instance, you're locked in to that type and price for the duration, even though newer types at lower prices may get introduced (as they almost definitely would over 1-3 yrs).
2. If you're from outside the US, you might not be able to resell your reserved instance. So you're stuck with an old instance type at an inflated cost.
In contrast, Google Cloud just gives you a price equivalent to a reserved instance price (or better), based on hours of usage, without asking for an upfront commitment.
We aren’t a huge account (less than 30k/month) so I thought this was a nice gesture on Amazon’s part.
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.
> 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.
We hear you. That's why we offer Committed Use Discounts [1]. Are you saying that a 3-year commitment to a specific price (or lower, as we do price cuts) is insufficient though? (I want to understand)
[1] https://cloud.google.com/compute/docs/instances/signing-up-c...
Disclosure: I head engineering/devOps at Engineer.ai - one of our products Cloudops.ai allows our customers to save up to 15% of their AWS bill without making RI purchases, as well as get discounted prices and additional flexibility (custom lock-in periods) for RIs they do wish to purchase. Feel free to reach out for information - my email address is in my about section.
I am aware that AWS and GCP are the go-to options for this audience, and that Oracle isn’t particularly favored for the Java lawsuit (among other things). If you are able to set these grievances aside, the OCI pricing team has done something unique: they have created a means by which you can effectively buy credits from Oracle and use them for whatever service (current or future) you need. It is called the Universal Credits Model (UCM) [1].
If you anticipate usage above a certain threshold, tier-based discounts are available at the time of purchase. It’s like a store gift card; buy whatever you want. This takes away some of the stress of capacity planning and instance-type selection. Additionally, you can adopt new services and avail lower prices in the future.
With UCM, customers:
1. Sign one single contract that provides unlimited access to all current and future Oracle PaaS and IaaS services (Compute, DB, Block Storage, Blob Storage, Network, etc.) spanning both Oracle Cloud and Oracle Cloud at Customer. 2. Gain on-demand access to all services plus the benefit of the lower cost of pre-paid services. Depending on the projected spend, customers can negotiate discounts. 3. Possess the flexibility to upgrade, expand or move services across datacenters based on their requirements. 4. Have the freedom to switch PaaS or IaaS services they are using without having to notify Oracle. 5. Can adopt new services when they GA.
Please send any questions my way, and I will get answers to you.
(1) https://www.oracle.com/cloud/bring-your-own-license/faq/univ...
Method one: You write a SQL query and some Python. You put a sticky note on your computer "Remember to run that biweekly."
Method two: You pull up your shop's documentation for how to add the (BIG_NUMBER)th entry into the data processing pipeline. This gets you automatic scheduling, retries, monitoring, audit trails, alerts to the right people in case of breakage, etc etc. You write a SQL query and some Python. You plug it into the existing infrastructure.
Would recommend using CloudHealth or other tool vs. using custom ETL. I tried do it myself on my tools, but got worse results than using dedicated tool.
However, dedicated tool need input from development. Sometimes it's worth to buy non-convertible RIs for bigger instance. Sometimes convertible RIs are easier. I just found that convertible RIs with some upfront are incredible tricky to calculate amortisation.