Ask HN: Why aren't you using a public cloud?
I'm curious to learn reasons why your company is not use a public cloud platform such as AWS, Azure, GCP, etc.?
For venture-backed startups with an emphasis on growth or large scale enterprises, the convenience of the cloud may outweigh the cost premium. But for small to medium size organizations where server load doesn't fluctuate on a day-to-day basis, I haven't yet been convinced that the cloud offers a good enough value proposition.
If daily backups are enough it can’t be beat.
I know a VOD training service runs serverless with videos on S3 and they're very successful.
You can be successful on AWS, but you're leaving money on the table, and for relatively commodity services it's just a question of time before a competitor realise they can do the same with much better margins and lower prices elsewhere.
If your hosting is a small portion of your costs, that might not matter, so I have certainly run services on AWS too, and do in my current job as well, but it's a very expensive convenience. I've yet to come across any systems I know the internals off that couldn't cut hosting costs by moving off public cloud services.
If you want to avoid infrastructure complexity, I'd go for dedicated hosting most of the time. Most of my past clients have ended up paying for more hours on operations for AWS setups than for dedicated. AWS and similar tends to force a lot of ceremony, some of which is good, but a lot of which is unnecessary on dedicated setups or on premises setups.
But yes, if your costs per unit are that low, I've typically told clients it largely depends on what they're most comfortable with. Some then pick AWS and it's a perfectly good choice.
What I'm seeing though, is that a lot of people pick AWS without first pricing out the options, and then later end up with expensive migrations to get off it.
Oh if that isn’t a perfect description of AWS I don’t know what is. Every time I look at AWS, that’s what I discover.
The difference is minimal these days, but usually my experience is that people spend more on devops for AWS. If you want to spin up a dedicated host at e.g. Hetzner or OVH or Softlayer or wherever, it generally take no more or less effort or technical skills than spinning up an instance at AWS. Many of the hosting providers have API's, just like AWS, only they expose their bare metal instead of hypervisor interfaces.
You don't typically need to know any more about the hardware on those systems than you need to know about the virtualized hardware on AWS.
It's not an order of magnitude, but it's something. Probably not worth the effort, for most, though, and I have no idea if "dedicated box" services can approximate something similar.
But once you go live and start to grow, there is a point where the lambda cost equals the instance price. And with an instance, you can almost always do a lot more than that number. Again, that will work if your requests are predictable enough that you can see this number consistently over a large period, say, every week at least.
- Not cost-efficient at large scale. When you expect and plan to run thousands of nodes at near 100% CPU and memory usage for years at a time, running a machine room can still be less expensive.
- Specialized hardware not available in public clouds, e.g., very low latency networks configured in an optimal topology.
- Lack of control over hardware upgrade schedule. E.g., a cloud probably won’t give you those shiny new GPUs as early as you can shove them in your own servers.
The balance is shifting in many of these areas, and there’s plenty of scientific computing that can use a public cloud now. But I still wouldn’t use it for problems that are both highly CPU-intensive and require low latency networks, especially if I have long-term workloads.
By the way, at one point, in science, there is already such a kind of computing cloud: We call it https://en.wikipedia.org/wiki/Grid_computing
1 - aws is very very very expensive for sustained load.
2 - aws offers highly variable performance characteristics, both cpu and networking. It's a best practice after creating a set of ec2 machines to immediately spend 10 minutes perf testing them and dropping slow ones, either cpu or network.
2a - machines in aws that didn't start slow may become slow, particularly for networking. What you really want for many applications is a dedicated rack with very high speed TOR switches. You do not get this in AWS.
3 - Designing ML applications for variable tradeoffs between cpu and network is extremely ugly. Detecting and dealing with network links that can suddenly become extremely slow is awful.
On the business side, there's this trend to stick everything in to "the cloud" and just trust it's OK because everyone else is doing it.
It seems it's too much effort for people to imagine all the ways this could go wrong. Some of us, though, actually think and care and don't simply believe everything we're told.
What happens when we find out the true extent that our information is being used against us? For a majority of us, it'll be too late because chasing fads and trends and doing what everyone else is doing is too appealing, somehow.
For those of us who are too paranoid to just hand over data, you can't even say we're wrong any more - just look at what Edward Snowden taught us about the extent to which our own government has been flagrantly disregarding the law. Keep in mind that's barely scratching the surface.
Most of my success comes not from selling to IT but the CFO or Board. Once they realize they can eliminate a dozen or so SAN Storage or networking engineers then the cloud doesn’t seem so expensive after all.
Edit: There is no silver bullet. Model your needs, make sure your model is accurate. You might still be wrong if your model doesn’t match reality due to unanticipated deviations.
Cloud is best for handling spike workloads, not day to day.
You can afford to let the servers handling your base load get much closer to capacity when you know you can scale up near instantly instead of having to provision new servers.
This is the biggest reason for me to run services that are prepared to run on public clouds, though it's very rare I've ever needed to make use of it - the kind of spikes that are severe enough and long lasting enough to be worth provisioning cloud instances for tends to be very rare for most people.
Uber is trying to pull the same trick AWS did. I mean, I don't know if AWS was bleeding money at first, but in 2008, they had pretty good prices. Hard to compete with. I tried. But the thing is, especially their bandwidth prices? to this day, they are "okay, if it's 2008" I mean, north of ten cents per gigabyte transfer is kind of a lot.
(even in 2008, their bandwidth prices weren't great. I mean, they weren't bad, but their bandwidth prices were never really a lot below what you could get elsewhere. Their compute prices, on the other hand, were really competitive, if you scored them against the same ram at another Xen based VPS provider.)
This is an absolutely standard hosted infrastructure play. The standard VPS business model is to break into the market with really low prices, get a lot of customers, and then sit on those prices for as long as you can, while your costs fall, making your margins grow. I mean, most companies eventually are forced to lower prices again, so you get this cycle of high growth/no margin and then growing margin/bleeding customers.
(Interestingly, of late, the velocity with which hardware prices fall has decreased pretty dramatically, making this model less viable, or at least making it take longer.)
Amazon took this business model to the next level, in the way that VPS companies could only dream about. People voluntarily lock themselves into services on amazon that aren't particularly standardized, that would be quite difficult to shift onto competitors. This is very good for the amazon bottom line.
Before you know it your giant app is stuck on proprietary infra and core business functionality involves paying a significant tax to keep things operational.
I’m a big fan of hosted open source for this reason. But those hosts too have incentives to sell you proprietary “value add” functionality.
Also, don't particularly trust the likes of Amazon, Google or Microsoft, and don't want to give them any more power.
Financial services industry.
There certainly are legitimate reasons not to move to public cloud, but it shouldn't be an emotional one.
Measure cost (including manpower), SLA's, performance, governance, and compliance. After that it should be simple to stay on-prem, go hybrid, or move full force into public cloud.
I think a more complex problem is that many companies have legacy web applications that probably should be rebuilt cloud-native/serverless. Doing a lift and shift can be cost-effective, but decomposing these applications and rebuilding them in serverless would probably provide significant savings.
In terms of actual hosting costs, I've more than once been prepared to offer clients to move them off AWS and guarantee my fee will simply be a percentage of the savings - I've seen clients cut hosting cost between 50% and 90% on moving from AWS to dedicated hosting, and cut their devops costs at the same time.
For someone doing admin/devops who wants to maximize billable hours, recommending AWS would be better than recommending on-prem - it's all remote, no annoying travel etc., and you're likely to make more money, and at the same time you ironically gets less pressure from managers who have been told cloud will cut their costs.
> Doing a lift and shift can be cost-effective, but decomposing these applications and rebuilding them in serverless would probably provide significant savings.
Even if you rebuild them as "serverless" you'd probably end up saving far more by deploying said "serverless" apps on dedicated hosting providers for the base load.
The funny thing is: those jobs already went years ago outsourced to “smart hands” in the DC. You still need people to plan and operate all this stuff. SAs who make the jump willingly have nothing to fear from cloud.
We did use Office 365 because those people had our CIOs ear and gave various discounts to lock us into the MSFT stack, but in-house development was all deployed to our own hardware. Other platforms we ran as part of IT (databases, ERP, analytics) also all were inhouse.
The number one reason were not running all we could on AWS or Azure could be broken down as follows
1) we didn't have the technical knowledge to make the transition 2) the people who were interested in this at all were the younger kids out of college 3) the company is run by older white males who don't trust the younger kids (FTE) and certainly don't trust the IT contractors 4) there was massive resistance to change, even when our industry is bleeding because of low energy prices and little to no profitability 5) Fundamental misunderstanding or lack of understanding of how to secure out data in the cloud 6) business people saw IT as a barrier to innovation 7) IT was very risk averse and with business people not trusting them, it only reinforced their inability to progress
As for [5], we had numerous conversations with MSFT and AWS about trying to run their cloud on premise. We were convinced that we can protect our data better (even though it's not our company's vote competency) than companies like AWS, who are literally in this exact business.
Yeah for all that and other reasons, I left.
It's been 2 years of grind and umpteen number of powerpoint but I see a sea change and hopefully soon....
Bare metal is only a little more work to set up if you're using orchestration and provisioning tools. We use Chef and Consul/Nomad.
IMHO Amazon and the other big cloud providers are not a good deal if you only need compute, storage, and bandwidth and if you have any in-house IT expertise. They only make sense if you're taking full advantage of all their managed services e.g. S3, Redshift, managed SQL, lambda, etc. If you only need raw compute and bandwidth the smaller providers (DO, Vultr) and bare metal (OVH, Hetzner) are far better deals.
https://www.backblaze.com/blog/petabytes-on-a-budget-how-to-...
https://www.backblaze.com/blog/wp-content/uploads/2009/08/co... (Cost of a Petabyte by service vs DIY)
An "availability zone" is an isolated data center. A "region" is a group of availability zones that are geographically isolated but somewhat close to each other.
For instance, three availability zones (data centers) that are within 100 miles (making up a distance) would make up a region.
Amazon says:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-re...
"Each region is completely independent. Each Availability Zone is isolated, but the Availability Zones in a region are connected through low-latency links".
Backblaze hosts everything in one non redundant data center.
Some of smaller cheaper systems do run in cloud, but nothing more important or big yet. It takes time to gain trust.
It's a very uphill battle.
Example: a RAID1 setup, 2 drives. The drives used were literally made one after the other: the serial numbers were sequential. When 1 drive failed, the other drive failed too, at very nearly the same time.
Take drive out, mirror using ddrescue (took a long time) with retry, there was 32kb of data lost out of 400+GB and we never even really discovered what it was - we figure it was either a corrupt image or a part of the installed OS that was not used (such as a man page or text document).