Genau deshalb ist die Häme so aufschlussreich: Sie richtet sich nicht nur gegen einen sportlich gescheiterten Verein, sondern gegen das, wofür Wolfsburg im deutschen Fußball steht: Kommerz und das Gegenteil von sportlich verdientem Erfolg. Deshalb sei Wolfsburg in den Augen vieler zu Recht abgestiegen [1, 2, 3, 4]. Besonders eindrücklich lässt sich diese Missgunst aber in Kommentaren unter Instagram-Beiträgen erleben [5]:

FUSSBALL HAT GEWONNEN
[3392 likes]

Junge was ein geiler Saisonabschluss, Wolfsburg endlich runter
[1427 likes]

Nie mehr 1. Liga, nie mehr, nie meeeehr! Auf nimmer wiedersehen Wolfsburg.
[425 likes]

VW will sein Tochterunternehmen [7] jetzt mit Abermillionen aus der „Krise“ ziehen [6]. Und ein konsequentes Durchsetzen von 50+1 könnte daran einfach überhaupt nichts ändern. Ein Problem mit 50+1 ist eben, dass es keine unternehmerischen Geldflüsse hinein in die Welt der Vereine untersagt. Und damit nicht genug. 50+1 schafft es nicht einmal zu verhindern, dass Investoren mitbestimmungsfeindliche Strukturen etablieren und einen Verein somit de-facto übernehmen. Dass dem auch wirklich so ist, lässt sich erstaunlich anschaulich am Beispiel von RB „Red Bull“ Leipzig in Erfahrung bringen [8]:

Es gibt nur neun stimmberechtigte Mitglieder, im Vorstand sitzen nur Red Bull Mitarbeiter, keiner der Herren lebt in Leipzig.

Dieser Bericht ist zwar von 2012 und heute mehr als zwölf Jahre alt, trotzdem hat sich bei Red Bull Leipzig wenig getan. Erst im vergangenen Jahr kritisierte das Bundeskartellamt die immer noch in sehr ähnlicher Form vorhandenen Vereinsstrukturen [9].

Wirklich verbessert hat sich das nur quantitativ, nicht etwa strukturell. Red Bull Leipzig hatte zuletzt nicht mehr nur neun, sondern laut Bericht zur Mitgliederversammlung 2026 knapp 1.200 Mitglieder, nur 22 davon mit Stimmberechtigung [10]. Die Namen dieser 22 werden scheinbar absichtlich nicht bekanntgegeben.

Noch verhängnisvoller ist allerdings die Auswahl der Mitglieder, die eine Stimmberechtigung erhalten sollen [11]:

Es ist bei Rasenballsport von Beginn an Vereinsphilosophie, dass nur ausgewählte, für den Klub oder den Red-Bull-Konzern tätige und nützliche Personen abstimmungsberechtigte Mitglieder werden können.

Problematisch ist hier nicht etwa, dass Red Bull derart vorgeht, sondern vielmehr dass die DFL über Jahre zugelassen hat, dass 50+1 formal erfüllt, aber seinem demokratischen Sinn nach ausgehöhlt wird. Dabei scheint das Interesse der Fans dasjenige zu sein, das der DFL am Wenigsten am Herzen liegt.

Wikipedia bescheibt 50+1 wiefolgt [13]:

Die 50+1-Regel wurde vom DFB am 24. Oktober 1998 eingeführt. […] Damit sollte für Lizenzvereine ein Rahmen geschaffen werden, ihre Profifußball-Mannschaften in Kapitalgesellschaften umwandeln zu können und gleichzeitig die Macht von Geldgebern zu begrenzen. […] eine Kapitalgesellschaft [kann] nur eine Lizenz erhalten […], wenn der „Mutterverein“ mindestens „50 Prozent zuzüglich (...) eines weiteren Stimmanteils“ innehat. […] Erlaubt ist hingegen, dass sich die Mehrheit des Kapitals im Eigentum privater Investoren befindet.

50+1 regelt also lediglich die formale Stimmrechtskontrolle, nicht aber die de-facto Kontrolle eines Clubs. Ja, Besitzverhältnisse bei in solcher Stärke kulturell bedeutenden Entitäten gehören reguliert und überwacht. Dass die Fairness in der Kaderbildung von derartigen Regulierungen aber eigentlich kaum bis gar nicht beeinflusst wird, hört man recht selten. Stattdessen wird fast ausschließlich und bis zum Umfallen über 50+1 diskutiert, ohne dass sich Gedanken darüber gemacht werden, ob damit überhaupt das wirklich zugrundeliegende Problem behandelt wird.

Geld schießt keine Tore. Aber Geld kauft fast alles, was die Wahrscheinlichkeit erhöht, dass irgendwann jemand Tore schießt: Kaderbreite, Scouting, Trainerstäbe, Akademien, Datenabteilungen, Geduld und Fehlerkorrektur. Genau deshalb reicht es nicht, nur Besitzverhältnisse zu diskutieren. Die Frage ist, wer im Fußball Macht hat, und ob für die Clubs und die DFL ihre Fans mehr sind als nur die zahlende Kulisse.

Quellen

April 17th, 2025

I will start this blog post by defining what "computing on the edge" refers to. Wikipedia states that

[...] [edge computing] refers to any design that pushes computation physically closer to a user, so as to reduce latency [...] (ref)

However, as I'd like to focus on web apps, I will extend the definition by the understanding of major cloud providers (CP):

Edge computing is typically accomplished by serving requests via scalable, containerized, load-balanced systems.

Running your app on the edge typically requires some sort of containerization. When a user sends a request to your service, major cloud providers spin up the container, wait for the HTTP service (inside the container) to be available and then forward the request to the (now running) container. Here's a (simplified) graphic: (not included in transcript)

The startup time for more complex HTTP services typically ranges from a few hundred milliseconds to a few hundred seconds, depending on the tech-stack used to build the service. Most (all) cloud providers know about this and thus mark the container with a TTL that is renewed on every subsequent request. Because of this, the startup latency is significantly worse for apps with few MAUs and for users that reside in regions with few MAUs, as the TTL will expire more often. As a customer of any CP, you can typically request to always have at least one running container per region. However, this will radically increase your hosting expenses, especially for apps with few MAUs, as CPs usually bill their customers per computing time.

Because the cloud is overpriced, devs should always make sure to confirm that anything that runs in the cloud really needs to stay in the cloud. To augment the cost efficiency of the cloud, CPs usually offer their customers two different billing models:

1. Pay-per-Request/Request-based-billing (PpR)
   Customer pays a fixed amount per request plus a fixed amount per vCPU-second plus a fixed amount per GiB-second.
2. Pay-per-Instance/Instance-based-billing (PpI)
   Customer pays a fixed amount per vCPU-second plus a fixed amount per GiB-second. The fixed amounts are usually lower compared to PpR.

You've probably already looked at Example I. This will be our scenario for showcasing the cost of the cloud. I am using the GCP Expense Calculator for the calculation of costs.

Assumptions:

• 2k requests per user per month
• 1 vCPU
• 300ms computing time per request
• 1.5 GiB memory required
• 1 container can handle up to 100 concurrent requests
• us-central1 (Iowa, Tier 1)
  southamerica-east1 (São Paulo, Tier 2)
• PpI 1 instance per region

Putting the GCP and easy scalability aside, two VPSs on Hetzner Cloud with 2 vCPUs and 4 GiB memory each, running 24h/day will cost $ 9.18/month. That will provide you with >2x better specs compared to PpI 24h/day while being >13x cheaper. Ironically, avoiding CPs like the GCP instantly gets you a >10x cost efficiency improvement.

Larry Page, co-founder of Google:

It's often easier to make something 10 times better than it is to make it 10% better.

Thus, when running on the edge is a requirement, devs should strongly consider choosing VPS providers over major CPs, as the cloud is significantly overpriced and the initial manual effort can be easily paid off long term. Sadly, I feel like many devs have forgotten about what "running on the edge" really means. You absolutely do not have to pay Google, amazon or Microsoft ridiculous amounts of money. For most use cases, a few VPSs for every region will be enough.

Up until here, we have mainly focused on the costs and talked a bit about latency. But now, we will get to the real deal when it comes to edge computing: data(-bases)

To demonstrate why running on the edge is pointless when using a monolithic/single central database, let's take a look at Example II. Alice (A) resides in the US while Bob (B) resides in Russia. A talks to the NA Service (N-S) while B talks to the Asia Service (A-S). Both the A-S and the N-S need to access the central database that is being hosted in Germany. In order to talk to their services, A and B authenticate themselves using a JWT. Because the access shall be revokable at any time, N-S and A-S need to query the DB to validate the given credentials. Now assume that our service is a messaging service and A wants to send B a message. We will observe 2 actions:

1. A sending the message
   (sequence diagram not included in transcript)
2. B pulling new messages
   (sequence diagram not included in transcript)

Now let's make some assumptions:

• database delay $d_{DB} = 100$ ms
• service delay $d_s = 10$ ms
• processing delay $d_p = 0$ ms
  "processing is free"

With these assumptions made, it's obvious to see that RTT(1) = RTT(2), where

RTT(1) $= 2 d_s + 4 d_{DB} = 420$ ms

Thus, sending as well as pulling messages takes 420 ms in this scenario.

This example is a modified version of Example II: We still have A and B in their locations but only provide a single Main Service (M-S) this time. A still wants to send B a message and we still observe the actions 1 & 2 (with N-S and A-S replaced by M-S). However, since the scenery has changed, we need a new set of assumptions:

• database delay $d_{DB} = 10$ ms
• service delay $d_s = 100$ ms
• processing delay $d_p = 10$ ms (unchanged)

Obviously, RTT(1) = RTT(2) still holds, but

RTT(1) $= 2 d_s + 4 d_{DB} = 240$ ms

this time, which is almost 2x faster compared to Example II. As one can clearly see, when using a single central database, the use of edge computing significantly increases the latency for end users. Thus, edge computing should not be employed in such scenarios.

Example IV

But what if we want to have both low-latency database access and low-latency services? Then we need to have the same database in different regions at the same time. The key concept we need to accomplish this, is: replication. We need to replicate our database.

Sadly, this easier said than done. Most data models are difficult to replicate. Take relational databases for example, you will face some real challenges:

• ACID-Compliance
• database migrations/schema changes
• conflict resolution

You will have to give up some guarantees if you want to improve latency. E.g. if you wouldn't give up ACID-compliance, you would have to lock relations simultaneously for all regions, which then would worsen the latency far beyond Example II.

This is why most apps that (successfully) run on the edge employ NoSQL databases, as those are much easier to replicate. Graph databases on the other hand, despite belonging to the NoSQL family, are an exception and hard to replicate.

To round things up, I'd like to share some of the best use cases for the edge:

• Content Delivery Networks (CDNs)
• DDoS Protection
• Global Load Balancing
• TLS Termination

If you came this far, I hope you enjoyed the read :)

April 15th, 2025

Hello to whoever is reading this!

This blog entry is mainly for testing purposes.

Here's a link to Google, try clicking on it!

If you haven't noticed so already, this blog is heavily inspired by handwritten.blog. I've discovered Daniel's blog last week and almost instantly thought about how I could create my own handwritten blog. I don't know if Daniel will ever read this, but if you do, please keep up the work, I am a fan!

And just like Daniel, I will only accept comments that have been written by hand and mailed to blog@lehnert.dev.

But unlike handwritten.blog, this blog is brought to you by Simple Vector Graphics (SVGs) instead of Portable Network Graphics (PNGs). This comes at the disadvantage of bigger file sizes (currently, this blog entry weighs in at 25 MB without optimizations and still 1.8 MB when optimized using Inkscape on default settings). However, I am convinced (and optimistic) to further reduce the size of handwritten SVGs in the future.