4 ms·

I think some mix two on-prem concepts here: 1) true on-prem DC which means HW, HVAC, UPS etc on premises with full HW staff and full network vs 2) old days bare

I think some mix two on-prem concepts here: 1) true on-prem DC which means HW, HVAC, UPS etc on premises with full HW staff and full network vs 2) old days bare metal which means colocation or stock rack offering in provider's DC, who takes care of all HW stuff under contract. I am participating in K8s migration to on-prem HW in customer's owned server room. The scaling flexibility is close to none. Old time HW procurement processes take months. Blades need to go thru HW and NW Engineer's hands for a few weeks, before even K8s workers can be installed there, then apps scaled. This is for a project which has known requirements and performance expectations. Forget any of that if you are just privoting start-up. But for anyone who just wants to "own" the data, the stack and to squeeze the maximum performance, then bare metal dedicated hosting or rack rental should be enough.

vidarh 4y ago
Agree with this. I would not want "true on prem" most places, not least because on-prem cost is driven in no small part by real-estate and electricity prices and salary costs near the colo, and for a lot of companies that means their on-prem won't be able to compete on price with colo or even managed servers with a provider. A lot of manage server offerings also offer requisitioning via API, rent on short term contracts (so still opex like cloud instead of capex). But I also tend to favour hybrid setups these days, and most managed providers also has a cloud offering, which gets you the best of both if you have a decent provisioning setup and an overlay network: The base load on managed servers at whatever commitment period gives you the best prices. The cloud instances provides elasticity. Done well your users/devs can't tell where one ends and the other starts. And because you have a cloud setup tied in, you can go pretty close to the wire on those managed servers - a lot more so than with a purely on-prem/purely colo/rented servers setup, increasing the savings from the managed servers even more. I've had setups like this where we hardly ever needed to spin up any elastic capacity, but where having the capability meant the managed servers often got to 90%+ utilisation because we could let the utilisation rate get that high without issue knowing the system would spin up cloud instances if necessary.

vidarh 4y ago

Agree with this. I would not want "true on prem" most places, not least because on-prem cost is driven in no small part by real-estate and electricity prices and salary costs near the colo, and for a lot of companies that means their on-prem won't be able to compete on price with colo or even managed servers with a provider. A lot of manage server offerings also offer requisitioning via API, rent on short term contracts (so still opex like cloud instead of capex). But I also tend to favour hybrid setups these days, and most managed providers also has a cloud offering, which gets you the best of both if you have a decent provisioning setup and an overlay network: The base load on managed servers at whatever commitment period gives you the best prices. The cloud instances provides elasticity. Done well your users/devs can't tell where one ends and the other starts. And because you have a cloud setup tied in, you can go pretty close to the wire on those managed servers - a lot more so than with a purely on-prem/purely colo/rented servers setup, increasing the savings from the managed servers even more. I've had setups like this where we hardly ever needed to spin up any elastic capacity, but where having the capability meant the managed servers often got to 90%+ utilisation because we could let the utilisation rate get that high without issue knowing the system would spin up cloud instances if necessary.