, 3 min read

Various Quotes from Kristian Köhntopp

Below posts from Kristian Köhntopp specifically talk about cloud, costs, and performance. I collected these quotations as "proof" that cloud is not always a cheaper solution compared to on-prem. Kristian Köhntopp worked as system- and database-administrator, security engineer, scalability engineer at NetUse, Web.de, MySQL (now Oracle), SysEleven, Booking.com, and other companies. Also compare Dropbox leaving AWS and saving $75 million over two years.

1. Power consumption. A large factor for a data center is power consumption. Power consumption in turn is dependant on utilization of the CPUs.

From Data Centers and Energy, Oct-2019:

Finally, computer power usage is not linear: Power management on a data center CPU turns cores on and off as needed, and thus, a CPU uses already circa 50% power at 10% utilisation. From a cost and from an environmental perspective it is best to utilise any CPU to the fullest. Some older measurements of mine on this.

Picture of referenced measurement is "Watts used by number of threads busy", y-axis is Watts, x-axis is number of threads:

In the same post:

(...) everything before the Last Mile is already fiber, and fiber lines allow extremely fast networking at relatively low energy.

From Rechenzentren und ihren Stromverbrauch regulieren, Nov-2020:

Watched over a period of five years, energy costs make half of the costs of computers -- for a hyperscaler this is such a high cost factor, that for economic reason they try to optimize the energy intake in their data centers.

2. Cloud costs. It is obvious that cloud is not by itself cheaper than on-prem. Quite the contrary. From 940.000 User in Baden-Württemberg, Jan-2021:

Why not cloud? Because cloud is incredible expensive. In my cost calculations the costs for cloud deployments per month are roughly equal or more expensive than cost calculations for bare metal in ones own datacenter per year, including power consumption, networking, space, etc.

This can all be optimized, but in the end it is always the same: cloud is roughly an order of magniture more expensive than doing it all oneself.

Said differently, one can unscrupulously overprovision the bare metal solution and still be lower than AWS prices.

From Software Defined Silicon, Sep-2021:

Hyperscalers are interested in ever growing CPUs with ever growing number of cores, and ever growing density in their datacenter. Hyperscaler have CPU utilization and "return-per-core" as their KPI and want custom silicon to cover virtualization, networking, or special tensorflow CPUs.

Ordinary customers do not see it this way: for a small company, you can possibly stuff the entire server requirements in one 64C/128T single socket configuration with 2-4 TB RAM. Problem with that: explosion radius in case of failure.

3. Networking in cloud. Below guidelines for SQL indicate that specially tailored on-prem data centers do better with database loads. From SQL Engineering Guidelines, Apr-2022:

We do not store code in the database.

  • We do not use views.
  • We do not use stored procedures or stored functions.
  • We do not use triggers.
  • We do not use UDFs (“user defined functions”, .so files that are loaded into the server proper and can be called as SQL-functions)
  • We do not run code in the database, because it makes applications very hard to update atomically in a rollout.

Further

Currently, we have on-prem databases with a memory saturated setup, and they expose query latencies for single primary key lookups in memory of 0.15ms. This will not hold in the cloud, in virtual environments, and also not in setups that put ProxySQL in-between.

4. Change in behaviour. On innovations in larger organizations, Der Testing-in-Production-Blues, Dec-2020:

Organizations learn this way. Such setbacks are important, because now one has shared experiences and learned from crisis, how colleagues react and which colleagues had helpful advice before the crisis, to which one should have heard earlier on. Organizations do not jump, they move forward linearly, the best one can hope for is to direct or accelerate their gliding. "Jump innovations" is not what can be observed in larger structured groups or administrations.