A decade ago everyone knew that shared hosting was for hobby sites and stuff that didn't really matter.
Maybe some more people will learn that lesson.
If you do the math like “we have 1000 cores and 2048Gb of RAM and 10Tb of RAID’ed SSD” and then plug that in to the GCP calculator... it’s going to be at minimum 1.5-2x your bare metal cost.
That’s not even including bandwidth which is pretty much free at bare metal hosts unless you’re doing a lot of egress.
The calculus changes when you realize that you’re over-provisioned on the bare metal side for a variety of reasons: high availability, “what if”, future growth that’s more medium term than short, etc.
Then you scale back the numbers you’re plugging into the calculator and things are still expensive but now within reason.
Couple that with things like global anycast region aware load balancer, firewalls (an in-line 10GigE highly available firewall costs a lot of money), ability to spin up hundreds of cores in 5 seconds and the value proposition becomes clearer.
It still depends on your work load, but there’s a lot more to consider than just straight up monthly cost.
I use GCE for DNS, Storage, CDN (for fronting storage backed files), dynamic workloads that can run on preemptible instances, and scalable instances to serve published static content, but I use dedicated servers for databases, elasticsearch, redis, and application servers fronting those things.
We keep looking at GCP waiting for the pricing to make sense and still trying to figure out how people run low latency Postgres on there. :)
(I work on GCE)
> It is just as easy to automate [..]
It's really not. As someone who's done provisioning automation at 2 companies, this is hard. Hardware is difficult, every new generation of hardware introduces new challenges in the provisioning and the more hardware configurations you need to support (and different vendors, all kinds of PCI plug-in cards etc), the more likely things go wrong. It takes a full team to build, maintain and debug this. It takes a couple of hours to build a GUI that calls the GCP API's to provision an instance for you, assuming you even need to do this instead of just using the Cloud Console directly. Sure, you pay for it, but now you have 4-10 engineers freed up to do something that provides actual value to your business.
> [..] if you plan well [..]
If. But that's really hard. Capacity planning and forecasting is complicated and the smaller a player you are, the harder it'll be for you to get a decent vendor contract with significant discounts and to be able to adjust and get to hardware quickly outside of your regularly forecasted buy-cycle. On the other hand, it's not your issue in the cloud. You request the resources and as long as you have the quotas, you'll get it (with rare exception).
> [..] and more secure [..]
I severly doubt that. In most cases, though you can host your stuff in certified DC's you'll still be in a colocation facility. Most cloud providers have their own buildings or rent complete buildings at a time. No one else but them has access to those grounds. Aside from that, take a look at what Google for example does on GCP to ensure that their code and only their code can boot systems, how they control, sign and verify every step of the boot process[0]. I've yet to see anyone do that and I doubt most companies that do bare metal have even thought of this or have the knowledge to even execute on this.
[0]: https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-...
Aside from all of this, cloud isn't competing with just providing you compute. VM's (GCE, EC2) is just the onboarding ramp. The value is in all the other managed services they offer that you no longer need to build, maintain, scale and debug (global storage and caching primitives, really clever shit like Spanner or Amazon RDS/Aurora, massively scalable pub/sub and load balancing tiers, autoscaling, the ability to spawn your whole infrastructure or your service on a new continent to serve local customers in a matter of minutes etc). If all you're using cloud providers for is as a compute provisioning layer, then you're doing it wrong.
Yes, but you will hit all the same problems with different hardware generations, different configs with different limitations, etc. If anything GCE and AWS have more complex offerings than most bare metal hosts. And you have all the same maintenance issues as you run stuff over time and hardware and software updates get released.
> Capacity planning and forecasting is complicated
AWS and GCE certainly don't make it easier. And if you can't capacity plan accurately on cloud and take advantage of spot pricing and auto-scaling then you will be paying 10X price, which describes most smaller players.
> I severly doubt that [bare metal is more secure]
I am saying that shared hosting is fundamentally insecure. No matter what else you do, if you let untrusted people run code on the same server that is a huge risk that assumes many, many layers of hardware and software are bug free.
> cloud isn't competing with just providing you compute
I agree on this. But not all of those services work as well as advertised either.
I haven't hit any issues with hardware generations. At worst what I've had to do is blacklist a GCP zone b/c it misses an instance type I need. In most cases I don't need to care and images that can boot are provided and maintained by the respective cloud provider, so you can build on top of that. I don't need to source or test components together, or spend hours figuring out why this piece of hardware isn't working well with that one. Or why this storage is slower than the other disk with the same specs from a different vendor. I don't need to lift a finger or deal with any hardware diversity issues, I just do an HTTP POST and less than a minute later I have an GCE instance available to me. Though in most cases I don't even do that, I just instruct GKE to schedule containers for me. I also don't need to worry about any hardware renew cycles, deal with failing hardware, racking and expansion of my DCs and what not.
The reason GCP and AWS have more complex offerings is b/c they can afford to provide it. Due to their scale they can shoulder the complexity of letting you chose from a vast array of different hardware configurations, which usually also results in better utilisation for them. Most people can't, which is why bare metal host options are much more constrained. And as a consequence why a lot of resources are wasted b/c it's especially hard to find someone supporting small instance types for just bare metal.
> AWS and GCE certainly don't make it easier.
To me they do. I don't need to deal with the hardware. I don't need to plan buying cycles, account for production cycles and chip releases by manufacturers and factor in how that's going to affect supply, or how an earthquake in Taiwan will make it prohibitively expensive for me to get the disk type I normally want to. I still need to do capacity planning, but I can tolerate much bigger fluctuations in those, and people's usage patterns, in the cloud than I can on bare metal. Unless I want to have hundreds of machines sitting idle, just in case I might need them.
But the best thing is, if I get it wrong in the cloud, I can correct, in a matter of minutes if I want to. Too big instance types? OK, I'll spin up smaller ones, redeploy and tah-dah my bill goes down. Sure you could do that on bare metal, assuming you can even get to a right/small enough instance type, but it's far from this easy in most cases.
> And if you can't capacity plan accurately on cloud and take advantage of spot pricing and auto-scaling then you will be paying 10X price, which describes most smaller players.
But then we're back down to trying to use the cloud just for compute, which is not what you should be doing and not where the value of a cloud offering comes from.
> I am saying that shared hosting is fundamentally insecure.
Though that's definetly true security isn't black or white, it's not secure vs. insecure. Something that you might consider an unacceptable risk (theoretical or practical) might be entirely fine for someone else. There are definetly cases in which this would be of major concern, but for most people it really isn't. Aside from that, as both hardware designs are changing and software mitigations are deployed we're able to achieve stronger and stronger isolation. Eventually, for all intents and purposes, this will be solved.
> if you let untrusted people run code on the same server that is a huge risk that assumes many, many layers of hardware and software are bug free.
This sitll holds true even if you only let your people run code on the same instance (unless you're also only running a single process/app per server?). It becomes a bit more problematic but there's also a lot more research in this area going on than a few years back. We're discovering issues, sure, but we're also getting better and better at mitigating them.
> But not all of those services work as well as advertised either.
True. Every cloud provider could do better. But then, I'd like to see anyone attempt and succeed at what AWS, Google and Microsoft (or smaller shops like Digital Ocean, Rackspace) etc are doing, at their scale and with a staggeringly diverse portfolio of services and high SLAs. All taken care of for you, so you can actually assemble their primitives into useful things for your business, instead of needing to spend months and multiple teams to build the building blocks in the first place (and then also the cost of continued development and maintenance of these capabilities, and of course adding more and more of these capabilities yourself as your organisation's needs evolve).