The true costs of hosting in the cloud [LWN.net]

The true costs of hosting in the cloud

Posted Feb 28, 2018 19:42 UTC (Wed) by admalledd (subscriber, #95347)
Parent article: The true costs of hosting in the cloud

Reasons mentioned in the article are exactly why for small/medium sized platforms the approach my current employer takes is perhaps the best-of-both. Granted, it requires you to plan for it from the start, but tooling for the cloud itself requires different concepts anyways when moving from bare hardware (or even VMs).

Here, we have a few rows of racks in a co-location DC. These support all our 24/7 "base load", then if we have any large spike that cannot be processed within the DC it is shipped to our cloud environments where they scale out to a few thousand within a few minutes. Of course the "magic" to do this is platform/application specific, but they *do* exist for most anything in one form or another.

At least for our estimations, the staffing cost of cloud-vs-dc was near-to-nothing different for our size, and we only need one/two who specialize in pure hardware, the rest of OPS don't need to particularly care between. As mentioned it is really only when we start hitting that wall of "Intricate high-speed inter-node networking at $SIZE" that we then move excess burst to the cloud.

By no means is this a perfect answer, but from what little I have seen of others and talked to, it is an attractive solution if it can be made to fit.

(Disclaimer: I have not yet had a chance to follow any of the links for further details, so if this hybrid concept was already mentioned I apologize.)

to post comments

hybrid setups are interesting

Posted Feb 28, 2018 20:02 UTC (Wed) by anarcat (subscriber, #66354) [Link]

[snipped description of a hybrid cloud/colo setup] (Disclaimer: I have not yet had a chance to follow any of the links for further details, so if this hybrid concept was already mentioned I apologize.)

It has not, thanks for bringing this up. It's definitely something that was brought up in other talks at Kubecon, but it's something lots of people are still struggling with. In other articles about Kubecon, I mentioned how Kubernetes is one way to standardize those applications and allow cross-cloud migrations, or at least make those possible. I think it's why large cloud providers like Google, Amazon and Microsoft are embracing it: it provides an on-ramp to their services. And I think having the possibility to have hybrid infrastructures like what you are proposing is probably the best, as it resolves the main problem with colocation, which is when the plain fails and you run out of capacity or you have catastrophic outages. The possibility of rebuilding in the cloud is an amazing fallback.

That said, one big problem with the cloud is when you start using custom extensions like Amazon's serverless stuff or Google's large datasets. Those are "heavy" in that they are a "gravity center" that pull services towards them and make it hard to find the "escape velocity" to leave the service again when you need to. You become dependent on those APIs or large datasets that cannot be abstracted away. So that's also something to be careful about when considering the cloud.