top of page
  • Tim Hartlieb

Fastly - "nur" ein CDN-Anbieter oder Enabler für das Web 4.0 ?

Aktualisiert: 18. Aug. 2020


 

Visa/Mastercard und AWS/Azure in Einem, von den Zielkunden „geliebt“ und eine für „tot“ erklärte Industrie disruptiert – ist das alles überhaupt möglich? Um dieser Frage nachzugehen, werfen wir in der heutigen Unternehmensanalyse einen etwas genaueren Blick auf Fastly.


Aufgrund der technischen Eigenheiten des Edge-Computing ist die heutige Analyse etwas länger und technischer. Allerdings kann man ohne das entsprechende Hintergrundwissen Fastly´s einzigartige Positionierung meiner Ansicht nach nicht ausreichend nachvollziehen.


 

1) Der Unternehmenshintergrund – Worum geht es überhaupt?


Fastly wurde 2011 von Artur Bergmann, Simon Wistow, Sean Leach und Tyler McMullen in San Francisco gegründet. Die Gründungsidee entstand dabei aus einem Problem, das die Gründer – allen voran Bergmann – zunehmend verärgerte. Denn während Bergmann als CTO für Wikia – einem populären Web-Hosting-Service – arbeitete, wurde er immer unzufriedener mit den damals vorhandenen Content Delivery Networks (CDN). Ihn störten wiederum nicht nur die langen Ladezeiten, sondern vor allem auch die Tatsache, dass die damals existierenden CDNs zu umständlich zu konfigurieren waren und kaum individualisiert werden konnten.


Bergmann träumte stattdessen von einem frictionless Hosting-Service, der – ganz nach dem Motto „von Entwicklern für Entwickler“ individuell konfigurierbar, besser skalierbar und viel leistungsfähiger war. Aus diesem Grund verabschiedete er sich von Wikia und begann, ein völlig neues Server-Netzwerk from ground up und nach seinen Vorstellungen zu entwickeln.


2017 konnten bereits über 100 mio. USD an Umsatz sowie namhafte Kunden wie beispielsweise Pinterest oder Stripe ausgewiesen werden. Nachdem insgesamt 219 mio. USD an Venture-Capital eingesammelt worden waren, erfolgte im Mai 2019 bei einer Bewertung von knapp 2,2 mrd. USD schließlich das IPO an der NASDAQ.


 

2) Das Produkt – Was verkauft das Unternehmen?


Gestartet ist Fastly also als Anbieter eines Content Delivery Network, heute ist das Unternehmen allerdings weitaus mehr als „nur“ ein CDN-Anbieter. Um das zu erkennen, müssen wir einen genaueren Blick auf den Werdegang von Fastly und die spezifischen Produkt- und Brancheneigenheiten werfen. Zunächst einmal stellt sich daher die Frage, was überhaupt ein CDN ist.


Vereinfacht gesagt ist ein CDN ist ein Server-Netzwerk, das bei Endnutzern ein reibungsfreies und schnelles Laden von Web-Anwendungen sicherstellen soll. CDNs übernehmen damit also das Hosting für Content-Ersteller. Herkömmliche Hosting-Dienste stoßen allerdings aufgrund verschiedenster Entwicklungen im Zuge der Digitalisierung immer häufiger an gewisse „Grenzen“ und genügen immer weniger den Kunden- und Entwickleranforderungen.


Des Weiteren unterscheiden sich verschiedene Web-Anwendungen zum Teil erheblich im Hinblick auf das beanspruchte Übertragungsvolumen/-raten und Reaktions-/Latenzzeiten, was sich wiederum nicht nur auf das letztendliche Kundenerlebnis, sondern vor allem auch auf den operativen Betrieb beim Content-Ersteller auswirkt. Letztere wollen dem Endkunden nicht nur eine möglichst schnell-ladende und reibungsfreie Anwendung zur Verfügung stellen. Vielmehr müssen sie auch die Kosten für die Datenübertragung sowie sicherheitsrelevante Aspekte in der Datenübertragung im Hinterkopf behalten.

Ziel eines „modernen“ CDN ist es daher einerseits, sowohl die Latenzzeiten zwischen den einzelnen User-Aktivitäten als auch die absoluten Round-Trip-Zeiten wesentlich zu verkürzen. Auf der anderen Seite sollten die Anfragen auf die sog. Origin Server (egal ob Cloud- oder On-premise-Infrastruktur) reduziert werden, da dies nennenswerte Kostenvorteile für den Service-Provider mit sich bringt.


Ein CDN fungiert damit als ein Zwischenspeicher, der deutlich „näher“ am Kunden ist. Dieser Benefit lässt sich sehr anschaulich mit den beiden Grafiken unterhalb darstellen [1]: Während die Daten im oberen Bild immer die „ganze Strecke“ zurücklegen müssen, wird entsprechend dem unteren Beispiel quasi die „halbe Strecke“ eingespart.



Nun sollte aber noch erwähnt werden, dass die Vorteile von CDNs zwar schon bei „einfachen“ Websites greifen, allerdings haben deren Vorteile bei der Bereitstellung von dynamischen Inhalten – also zum Beispiel Streaming oder Gaming – einen noch viel größeren Einfluss. Grundsätzlich stellen CDNs damit also Web-Inhalte über weltweit verteilte Cache-Server bereit. In diesem Zusammenhang müssen außerdem noch drei Ausdrücke differenziert werden:


  1. Internet Exchange Points: Darunter versteht man größere, weltweit verteilte Internetknotenpunkte

  2. Edge Server: Darunter versteht man einen Server, der so nah wie möglich an möglichst viele Endkunden positioniert ist

  3. Point of Present (PoP), auch Edge Locations genannt: Darunter versteht man einen Standort, an dem (meist) mehrere Edge Server angesiedelt sind. Diese sind meistens in großen Städten oder/und in der Nähe eines Internet-Exchange-Points


Der bequeme, da naheliegendste Weg, für die „alten“ CDN-Anbieter war es nun, eine immer größere Zahl an PoPs an strategisch relevanten Orten zu errichten um damit eine immer größere Zahl an Kunden bedienen zu können. Was anfangs als relativ plausible Strategie erschien, sollte sich zum größten Handicap der Legacy-Anbieter entwickeln – aber dazu gleich noch mehr.


Nun machen wir einen kleinen Sprung und betrachten kurz das konkrete Produktangebot von Fastly. Die nachfolgende Abbildung gibt uns hier einen Überblick über die entsprechenden Leistungen: [2]



Content delivery and image optimization: Damit nutzt Fastly seine leistungsfähigen PoPs für klassische CDN-Dienste. Eine Besonderheit ist, dass Fastly hier von Anfang an auf SSDs für das Caching von Inhalten gesetzt hat, was wiederum deutlich kürzere Abrufzeiten ermöglichte.


Video & Streaming: Hier nutzt Fastly sein CDN für Videoanwendungen und Live-Streaming-Anwendungen. Fastly gibt in diesem Zusammenhang eine äußerst hohe Cache Hit Ratio von 97% an, was die Ladezeiten von Videos reduziert und die Belastung der Origin Server deutlich senkt.


Cloud Security: Wie viele CDNs hat auch Fastly seine CDN-Fähigkeiten um einige Sicherheits-Features ergänzt. Cloudfare bietet in diesem Bereich allerdings schon ein etwas umfassenderes Angebot und ist damit vor allem auch ein direkter Konkurrent von Zscaler. Letzteres bietet über eine konkrete Ausprägung eines Edge-Networks einen next-generation VPN-Dienst an. Zu Edge-Networks gleich noch mehr.


Load-Balancing: Hier bietet Fastly gezielte autoscale Routing-Möglichkeiten für die Bereitstellung von Content.


Managed CDN: Für Unternehmen mit speziellen Sicherheitsanforderungen / Datenschutzanforderungen können Fastly´s Programmatic Capabilities auf das firmeneigene Netzwerk ausgeweitet werden.


Werden diese fünf Produktkategorien ALLEIN betrachtet, unterscheidet sich das Leistungsangebot von Fastly nicht allzu stark von den Wettbewerbsangeboten. Diese Angleichung hat zu einer starken Commodization innerhalb der CDN-Branche geführt. Damit ist das Phänomen gemeint, dass zwischen verschiedenen Anbietern keine wesentliche Differenzierung mehr existiert, was letztendlich zu einer Margen-Erosion führt.


Nun zeichnet die zwei CDN-Neulinge (Fastly und Cloudfare) aber eine Besonderheit aus: Denn beide haben ihre PoPs und damit ihr CDN im Unterschied zu den Legacy-Anbietern von Grund auf so konzipiert, dass sie – und auch die Entwickler – die Art und Weise der Inhaltszustellung konfigurieren können. Damit werden die Netzwerke „intelligent“.


Diese „Besonderheit“ wollen Fastly (und auch Cloudfare) mit ihren Edge-Computing-Ansätzen weiter ausbauen. Beim Edge-Computing geht es vereinfacht gesagt darum, Rechenprozesse über eine dezentrale Datenverarbeitung an den Rand eines Netzwerks zu verlagern – aber auch dazu gleich noch mehr.


Zunächst noch einmal ein Blick in die Vergangenheit: CDN-Dienste waren ursprünglich dafür konzipiert, um eine große Anzahl an (damals noch fast ausschließlich) statischen Dateien zu cachen (also zwischenzuspeichern) und diese zu den am nächsten „gelegenen“ Internetnutzern zu verteilen.


Dabei musste keinerlei (innere) Logik angewendet werden im Hinblick auf Fragestellungen, die die Art und Weise der letztendlichen Content-Verteilung betreffen. Folglich wurden die gesamten PoPs der traditionellen CDNs ohne „programmability“ errichtet. Stark vereinfacht kann man sich die „alten“ CDNs daher als "dumme Telefonleitung" vorstellen, die nur eine EINZIGE Handlung ausführen – und zwar die Content-Übermittlung in einer Richtung, also vom Origin Server über die PoPs an den Endnutzer.


Die „next-generation“ programmable-CDNs bieten nun alle Funktionalitäten, die auch die Legacy-CDN abbilden können – „nur“ wird eben das gesamte CDN viel intelligenter und schneller. Auf diese Weise können völlig neue Features angeboten werden:

  • Real-time-Eingriffsmöglichkeiten in das gesamte Netzwerk

  • Context-aware-Routing: Ermöglicht ein Traffic-Routing nach bestimmten Vorgaben bzw. in Abhängigkeit der Content-Art

  • Traffic-Skalierbarkeit der „konventionellen“ CDN-Features, also beispielsweise bei Peak-Demand

  • Eine infrastrukturspezifische Verteilung: Ermöglicht das Routing von Inhalten nach bestimmten Kriterien auf eine bestimmte Infrastruktur (Cloud, Hybrid, On-Premise)


Fastly kündigte nun im April 2017 mit Compute@Edge die erste Edge Cloud Platform an. Diese ist allerdings noch nicht fertig entwickelt und wird in den nächsten 6-12 Monaten in einer beta-Testphase in den Markt eingeführt. Cloudfare war etwas schneller und ging mit seiner Edge Cloud Platform (genannt Cloudfare Workers) bereits 2018 live.


Eine Edge Cloud Platform – auch vereinzelt als Edge Network bezeichnet – ist ein globales Netzwerk, das auf der Grundlage des innerhalb stattfindenden Traffics zusätzliche Funktionalitäten anbieten kann. Die Edge-Server fungieren dabei als „Pforten“ in das Netzwerk. Um diese Funktionalitäten zu erreichen, integrieren Fastly (und auch Cloudfare) weitreichende Programmatic Capabilities in die Edge-Server. Damit wird eine entscheidende Besonderheit im Rahmen der next-generation-CDNs deutlich:


Die Einzigartigkeit im Leistungsangebot von Fastly (und Cloudfare) resultiert aus der Kombination von Edge-Computing UND Edge-Networks.


Zwar sind die Möglichkeiten des Edge Computing an sich schon sehr interessant, aber die wirkliche „Phantasie“ entsteht aus der Kombination von EDGE COMPUTING und EDGE NETWORK. Denn Fastly und Cloudfare haben nicht nur ihre eigenen globalen Rechennetzwerke aufgebaut – vielmehr haben sie die GESAMTE Netzwerk-Architektur dieser von Grund auf so konzipiert, dass sie nun durch die inhärente Flexibilität in völlig neue Bereiche „vordringen“ können.


Diese neuen Anwendungsmöglichkeiten gehen weit über das lokale Content-Caching und einige, integrierte Sicherheitsfunktionalitäten hinaus. Dies liegt aber nicht nur daran, dass in den letzten Jahren durch das Streaming von dynamischen Inhalten die Anforderungen an das Caching und die damit verbundene Content-Bereitstellung stiegen. Vielmehr gibt es eine Vielzahl an treibenden Kräften, die zu einer zunehmenden Verlagerung von Computing-Anwendungen aus den zentralisierten Data-Centers bzw. zentralisierten Cloud-Infrastrukturen in die „Nähe“ der Endnutzer führen.


Ein erster, starker Treiber ist das Aufkommen von vielen dynamischen, zum Teil sehr rechnungsintensiven Web-Inhalten, die zudem eine äußerst geringe Rückmeldungs- bzw. Latenzzeit erfordern. Dazu gehörigen insbesondere das Streaming, VR/AR-Anwendungen, Mapping, Authentification und Gaming.


Für einen reibungsfreien Ablauf solcher Anwendungen müssen verschiedenste – individuell zu konfigurierende – Echtzeit-Entscheidungen getroffen werden. Durch Edge-Computing erhalten die CDN die notwendige, „innere“ Logik, mit der Entwickler diese Entscheidungen passgenau modellieren können. Dank den entsprechenden Programmatic Capabilities kann das Edge-Network dann „selbstständig“ mit Lastspitzen/Übertragungsengpässen umgehen.


Ein mindestens genauso relevanter Treiber ist 5G. Durch den neuen Netzwerkstandard nehmen die Übertragungsraten sowie das Datenvolumen stark zu. Dadurch werden die ohnehin „rückständigen“ und inflexiblen CDN-Architekturen vor nochmals größere „Traffic-Herausforderungen“ gestellt.


Zudem werden die Kosten für die Datenübertragung weiter zunehmen, wodurch bei Content-Erstellern ein noch größerer Anreiz zur Nutzung von möglichst effektiven und „kurzen“ Übertragungswegen entsteht. Denn je weniger Rechenprozesse in den Origin Servern bzw. in der zentralisierten On-Premise-/Cloud-Infrastruktur ausgeführt werden müssen, desto geringer sind die Kosten für die Datenübertragung bzw. die Skalierung der entsprechenden Rechenkapazitäten. Hier muss außerdem noch bedacht werden, dass die Kosten bei peak-demand erheblich ansteigen können – Edge Computing bietet hier wiederum erhebliche Flexibilisierungspotentiale.


Dazu kommt der größte Treiber, der aktuell allerdings noch in den Kinderschuhen steckt: Das Internet of Things. Das Hauptmerkmal dieses Trends ist, dass immer größere Datenmengen durch eine zunehmende Zahl an vergleichsweise „dummen“ Endgeräten (also am Rand des Netzwerks) generiert werden. Da die ursprünglichen CDNs „nur“ dafür konzipiert waren, Content von den Origin-Servern zu den Endnutzern zu transferieren, können sie keine Inhalte in anderen „Richtungen“ innerhalb des Netzwerks übertragen.


Des Weiteren besitzen diese CDNs keinerlei „Rechen-Power“ in Endnutzernähe. Durch die Kombination von Edge Networks und Edge Computing können dann NICHT NUR verschiedenste Daten durch IoT-Geräte dezentral aufgesammelt werden. Vielmehr müssen diese Daten auch nicht mehr in ein zentrales Rechenzentrum zur Auswertung/Rückmeldung übertragen werden. Stattdessen können die Daten direkt in unmittelbarer Nähe des Endgerätes analysiert werden, wodurch das Edge-Network über die Edge-Server mit den verschiedensten IoT-Geräten harmonisch interagieren kann.


Davon abgesehen ist noch eine andere Besonderheit des Edge-Computing von Fastly erwähnenswert. Dabei geht es um den sog. serverless-Ansatz. Mit diesem Ansatz können Entwickler ihre Anwendungen/Services in der Cloud ausführen, ohne sich selbst um Bereitstellung, Skalierung und Management von Servern kümmern zu müssen. Dazu kommt, dass Fastly hier nicht mehr DURCHGEHEND Server mit dem Code der Kunden rechnen lässt.


Allerdings ist das Wort SERVERLESS eigentlich etwas irreführend – denn nach wie vor führt ein Server den Code aus. Der wichtige Unterschied ist aber, dass die Server erst dann „aktiv“ werden, wenn eine entsprechende Anfrage eingeht und nicht mehr kontinuierlich eine Art „Warteschlange“ mit den nächsten Rechenaufgaben vorhalten. Wenn nun also ein PoP von Fastly einen Rechenauftrag erhält, starten der/die Server einen neuen, eigenständigen Rechenprozess.


In der Vergangenheit war es nun so, dass dieser, sog. Cold-Start eine nennenswerte Latenz im Bereich von 100 Millisekunden bis teilweise sogar einigen wenigen Sekunden bedeutete. Dazu kommt, dass jeder Cold-Start mit einem vergleichsweisen hohen Aufwand/Kosten verbunden war/ist.


Wenn die Latenzzeit mehr als 100-200 Millisekunden beträgt, wird sie vom Endnutzer wahrgenommen. Fastly nennt für Compute@Edge eine Cold-Start-Zeit von nur 35 MIKRO-Sekunden, was ca. 100mal schneller als derzeit existierende Konkurrenzdienste ist. Aus dieser äußerst geringen Cold-Start-Zeit sowie einem angekündigtem Runtime-Footprint von nur wenigen Kilobytes ergeben sich deutlich geringere CapEx zum Betreiben der PoPs. Eine geringe „Kalt-Start-Zeit“ ist insbesondere auch für synchronous use cases (also Anwendungen, bei denen am „anderen Ende“ ein Mensch sitzt) entscheidend.


Aus diesem, überlegenen serverless-Model resultieren zwei Vorteile, die weit über reduzierte Latenz- und Round-Trip-Zeiten hinausgehen: Zum einen benötigen die einzelnen PoPs nun deutlich weniger (da viel leistungsstärkere) Server – d. h. weniger ist jetzt mehr. Zudem sind jetzt überhaupt deutlich weniger PoPs für ein ausreichendes Netzwerk erforderlich. Für Fastly bedeutet dies geringere Anfangs- und Betriebskosten.


Zum anderen kann damit die Robustheit gegenüber Cybersecurity-Hacking stark erhöht werden. Dies liegt daran, dass jeder Prozess nun „isoliert“ abläuft. Im „alten“ System wurden die sog. Computing-Container gleichzeitig mit unterschiedlichen Arbeitsaufträgen (von verschiedenen Anbietern) „befüllt“ was die Verwundbarkeit zum Hacking deutlich erhöht.


Grundsätzlich kann man sich die Kombination aus Edge-Computing und Edge-Network also als einen Art dezentralen Mini-Cloud-Service vorstellen, der mit den nahe-gelegensten Endpunkten interagiert. Innerhalb dieses Mini-Cloud-Services kann nun das weltweit verteilte Server-Netzwerk – quasi als Multi-Tandem – flexibel „zusammenarbeiten“. Das Gesamtsystem ist damit wertvoller als die Summe der Einzelteile.


 

3) Der Markt – An wen will das Unternehmen verkaufen?


Wie bereits eingangs erwähnt, gab es die CDNs bereits lange bevor Bergmann Fastly gegründet hatte. Der aktuelle Marktführer heißt Akamai und ist einigen vielleicht aus den Zeiten der Dotcom-Blase noch ein Begriff. Interessant ist jedenfalls die Aussage des Marktführers zur generellen Bedeutung von CDNs, denn laut Akamai wird bereits heute „nearly half of the world's Internet traffic“ über CDNs bereitgestellt.


Dazu passt ein Bericht von Cisco aus dem Jahr 2017. Während darin der CDN-Traffic für das Jahr 2017 noch auf „nur“ 56% beziffert wurde, prognostiziert man bereits für das Jahr 2022 einen CDN-Anteil von 72% (!). [3] [4]


Darüber hinaus wurde erst vor kurzem ein interessanter Artikel von TechHQ mit einer noch interessanteren Aussage von Gartner veröffentlicht. Darin heißt es wörtlich [5]:

"Today, 90% of all data is created and processed inside traditional centralized data centers or clouds. That is beginning to change. According to Gartner, by 2025, 75% of data is going to be processed at the Edge."


Die Newcomer setzten nun von Anfang an auf eine Netzwerk-Architektur, im Zuge derer die Entwickler eine deutlich größere Kontrolle über ihre eigenen Anwendungen/Inhalte haben. Dazu kommen die vorhin beschriebenen Use-Cases und Benefits, welche in den nächsten Jahren durch die genannten Trends zunehmend an Bedeutung gewinnen werden.


Nun stellt sich natürlich die Frage, warum die „alten“ CDN-Anbieter nicht einfach ihr umfangreiches Netzwerk leveragen und die gleichen – oder sogar überlegene – Flexibilitäts-/Programmierfunktionen bereitstellen. Immerhin verfügt Akamai über rund 216.000 PoPs weltweit, Fastly gerade einmal über 72! Diese Frage lässt sich relativ „leicht“ beantworten, denn die alte Architektur mit den unzähligen Standorten – welche früher den eigentlichen Wettbewerbsvorteil darstellten – verwandeln sich allmählich in einen Wettbewerbsnachteil.


Die bisher führenden CDN-Anbieter haben nun versucht, Wettbewerber über eine größere Dichte an Serverstandorten und ein möglichst gleichwertiges Angebot an CDN-Service-Add-ons auf Distanz zu halten. Dabei wurden allerdings die Anforderungen der eigentlichen Zielkunden (den Entwicklern) sowie die sich verändernden Leistungsparameter im Zusammenhang mit dem Web 4.0 zunehmend außer Acht gelassen. Dieses Phänomen passt wiederum 1zu1 zur Trajectory bei einer Sustaining Innovation, die von Christensen im Zusammenhang mit dem Innovators Dilemma hervorragend herausgearbeitet wurde – aber dazu eventuell an anderer Stelle mehr.


Zur besseren Verdeutlichung eine Analogie aus dem Automobilsektor: Über die Jahre haben OEMs ihre Fertigungsstraßen kontinuierlich auf die Produktion von hohen ICE-PKW-Stückzahlen optimiert. Dabei wurden immer mehr (eigentlich) wichtige Wertschöpfungskompetenzen ausgelagert. Lange Zeit konnten durch die eingesparten Kosten sowie die erzielten Skaleneffekte nennenswerte Überschüsse erzielt werden.


Aufgrund eines Technologiewechsels bzw. einer Veränderung in den erwarteten Leistungsparameter kommt es nun zum gleichen Phänomen: Die Produktionsanlagen/-prozesse, die für ICE-PKWs kontinuierlich optimiert wurden und wichtige Wettbewerbsvorteile darstellten, verwandeln sich nun allmählich in einen "Klotz am Bein" – denn die heutigen Fertigungskapazitäten können nicht "einfach" auf die Produktion von Elektrofahrzeugen umgestellt werden. Dass viele wichtige Kompetenzen outgesourct wurden, macht die Sache nicht besser. Oder was genau ist ein Netzwerk aus Produktionsanlagen für ICE-PKWs in 10 Jahren noch wert? Es winken Stranded-Assets und Abschreibungen en masse.


Akamai (und viele andere CDN-Anbieter) sind also in ihrem PoP-System mit veralteter Server-Architektur „gefangen“. Apropos „veraltete Architektur“: Fastly´s überlegene Netzwerk-Architektur wurde – wie fast immer bei disruptiven Innovationen – erst durch einen sog. Enabler, also einen Technologiesprung, ermöglicht. Dieser Enabler war im Fall der PoPs bzw. der CDNs die Einführung von programmierbaren Switches im Jahr 2013 (u. a. durch Arista). Aber dazu noch mehr im Kapitel zur Unternehmens-DNA.


Neben Fastly gibt es noch einen weiteren „CDN-Newcomer“ – und zwar Cloudfare. Gleich vorweg – Cloudfare gefällt mir persönlich ebenfalls sehr gut und kommt für mich grundsätzlich auch für ein Investment in Frage. Aufgrund einiger Punkte habe ich mich aber vorerst „nur“ zu einer Beteiligung an Fastly entschlossen.


Cloudfare zeichnet sich auch durch einen starken Developer-Focus aus und bietet mit seinem Workers-Plattform bereits heute erste Edge-Computing-Funktionalitäten an. Ähnlich wie Fastly bietet Cloudfare gegenüber den Legacy-Anbietern ein „leistungsfähigeres“, konfigurierbares und flexibles CDN an. Davon abgesehen gibt es in meinen Augen drei nennenswerte Unterschiede zwischen beiden Unternehmen:


  1. Kunden und go-to-market: Fastly konzentriert sich ausschließlich auf große Unternehmen und Digitalpioniere. Cloudfare´s Zielkunden sind überwiegend SMEs. Zu Fastly´s Kunden noch mehr im Abschnitt zum Product-Market-Fit.

  2. Pricing-Model: Fastly verwendet ein usage-based-pricing-Modell. Cloudfare verwendet dagegen einheitliche Abrechnungstarife. Je mehr Content daher über Fastly´s Edge-Network bereitgestellt wird, desto größer fallen die entsprechenden Umsätze aus.

  3. Security vs. Performance: Cloudfare integriert in seine „intelligenten“ CDN-Capabilities vermehrt Cybersecurity-Features und nimmt dadurch bei trade-off-Entscheidungen Abstriche bei der Performance in Kauf. Fastly legt DERZEIT stattdessen einen klaren Fokus auf Performance und Leistungsfähigkeit. Dazu noch mehr im sechsten Abschnitt (Unternehmens-DNA).


Der Platzhirsch ist aktuell dagegen (noch immer) Akamai mit seinen rund 216.000 PoPs weltweit. Wie allerdings zuvor beschrieben, wird Akamai mit seiner „veralteten“ System-Architektur vor immer größere Herausforderungen gestellt werden (Stichwort: Wartung und Umrüstung).


Wie wir gleich noch sehen werden, entscheiden sich Digitalpioniere schon heute für Fastly und nicht für Akamai. Zwar besitzt Akamai bereits heute eine eigene Edge-Computing-Produkt – die sog. Intelligent Edge Platform, diese bietet aber nur ein paar erweiterte Sicherheitsfunktionalitäten.


Erwähnenswert ist allerdings noch, dass Akamai NOCH über eine wirklich beeindruckende Kundenliste verfügt. Dazu gehören unter anderem 46 der 50 führenden, Online-Einzelhändler der USA/Kanada sowie 47 der 50 führenden Television Networks der USA. Folglich besteht für Fastly (und Cloudfare) aber ein entsprechend großes Abwerbungspotential.


An dieser Stelle will ich kurz noch auf eine Besonderheit bei der Produkteinführung im B2B-Bereich eingehen: Dort ist es in der Regel so, dass Digital-First-Unternehmen als erstes bestimmte „B2B-Tools“ testen und dann ggf. übernehmen. Die Old Economy wartet bei entsprechenden Neuerungen in der Regel erst das Feedback der Technologieführer ab. Erprobt sich dann ein neues System/Produkt, wird dieses mit einer gewissen Zeitverzögerung übernommen.


Neben Cloudfare und Akamai stellen auch noch die klassischen Cloud-Verkäufer einen ernst zunehmenden Wettbewerber dar. Denn grundsätzlich besteht natürlich das Risiko, dass sie versuchen könnten, den Serverless-Edge-Computing-Markt ähnlich zu dominieren, wie sie heute den Origin-Server-Markt dominieren.


Wie allerdings die Grafik (Stand Januar 2020) unterhalb zu den Cold-Start-Zeiten darstellt, ist selbst das „schnellste“ Konkurrenzangebot von Amazon aktuell noch immer über 100 mal langsamer als Fastly´s Compute@Edge [6]. Dazu passt allerdings, dass insbesondere die Lösungen von Microsoft und Amazon eher für asychronous Workloads konzipiert wurden. Hier fallen größere Latenzzeiten nicht so stark ins Gewicht. Bei Cloudfare beträgt die Cold-Start-Zeit nach den im Juli vorgestellten Neuerungen nun 5ms.



Dazu kommt ein weiterer, wichtiger Faktor: Um Abhängigkeiten zu vermeiden, setzen immer mehr Unternehmen auf eine Multi-Cloud-Strategie. Da im Digitalzeitalter der virtuelle Kundenkontakt immer erfolgskritischer ist, liegt die Vermutung nahe, dass Unternehmen für diese Kundeninteraktion besonders auf die Verwendung von unabhängigen, best-of-breed-Diensten achten.


 

4) Das Geschäftsmodell – Wie verkauft das Unternehmen?


Wie bereits zuvor erwähnt, setzt Fastly im Unterschied zu Cloudfare auf eine dynamische Preisstruktur. Je mehr Daten also über Fastly´s Netzwerk bereitgestellt und verarbeitet werden, desto höher fallen somit die Umsätze aus.

Neben einem leichten Onboarding durch eine kostenlose Testphase profitiert Fastly noch von einer weiteren Besonderheit. Diese hat wiederum mit dem Umstand zu tun, dass sich Fastly vornehmlich auf große Unternehmen konzentriert. Davon profitiert das operative Geschäft auf zwei Arten:


  1. Aus der geringere Kundenzahl ergeben sich geringere Ausgaben für Sales&Marketing

  2. Aus der geringeren Kundenzahl ergibt sich eine effizientere Nutzung der Hardware in den einzelnen PoPs, denn weniger Kunden bedeuten weniger getrennt zu cachende Inhalte.


Darüber hinaus gibt es noch eine anderen Unterschied im Go-To-Market-Ansatz zwischen Fastly und Cloudfare. Letzteres versucht seine Workers-Plattform einer möglichst großen Zahl an Entwicklern zugänglich zu machen. Dafür wird auf eine möglichst hohe Kompatibilität mit möglichst vielen Programmiersprachen geachtet. Fastly geht dagegen davon aus, dass größere (Digital-)Unternehmen über Entwickler verfügen, die ausschließlich für die Programmierung der CDNs bzw. Edge-Networks zuständig sind. In diesem Fall ist ein extensives „Programmiersprachen-Angebot“ nicht mehr so wichtig.


 

5) Der Product-Market-Fit – Gibt es Hinweise dafür, dass Kunden vom Produkt wirklich überzeugt sind?


Nachdem wir uns jetzt einen guten Blick über das Marktumfeld von Fastly verschafft haben, stellt sich natürlich die Frage, ob die ganzen Bemühungen von Fastly überhaupt ein nennenswertes Interesse bei den Zielkunden auslöst. Zunächst einmal kann Fastly bereits heute einen wirklich beeindruckenden Kundenstamm vorweisen. Auf der Grafik unterhalb erkennen wir einige der führenden Digitalunternehmen [7]. Dazu gibt es schon länger Indizien dafür, dass Amazon seit März/April Fastly´s Dienste sowohl für seine Homepage als auch für seine IMDb-Website dem eigenen Cloudfront vorzieht [8].



Des Weiteren ist das Kundenwachstum sehr beeindruckend. So konnte allein zum letzten Quartal die stärkste Zunahme an Kunden (von 1837 im Q1-2020 auf 1951 im Q2-2020) seit dem IPO verzeichnet werden. Die Zahl der sog. Enterprise Customers (also Kunden, die mehr als 100.000 USD für Fastly´s Dienste ausgeben) stieg wiederum auf 304.


Ebenfalls beeindruckend sind auch die Dollar-Based Net Expansion Rate sowie die Annual Revenue Retention Rate. Wie wir in der nächsten Grafik sehen, erreichte insbesondere die Expansion Rate im vergangenen Quartal mit 138% einen wirklich starken Wert [9]. Das heißt, selbst wenn keine neuen Kunden mehr gewonnen worden wären, hätte Fastly einen Umsatzanstieg von 38% erzielt! An dieser Stelle können wir uns noch einmal kurz an das Pricing-Modell und die massiven Tailwinds in Erinnerung rufen. Von einer Churn-Rate von unter 1% können zudem die meisten Unternehmen nur träumen!



Als weiteres Indiz für einen hervorragenden Product-Market-Fit können wir noch einen Blick auf die sog. Sales-Efficiency werfen. Hier liegt folgende Annahme zu Grunde: Wenn ein Unternehmen ein wirklich attraktives Produkt verkauft, sollten nicht allzu viele Marketing-Anstrengungen erforderlich sein, um neue Kunden zu gewinnen.


Dazu betrachten wir den sog. Gross Margin Adjusted CAC (Customer Acquisition Costs) Payback. Hierfür teilen wir die S&M-Ausgaben aus einem Quartal durch den neu hinzugefügten ARR (annual recurring revenue), wobei letzterer mit der Gross Profit Marge multipliziert wird. Anschließend nehmen wir das Ganze mal 12, wodurch wir die Zahl der Monate erhalten, die zur „Tilgung“ der CAC anfällt. Im Allgemeinen geht man hier davon aus, dass eine Payback-Zeit von unter 12 Monate sehr gut ist.


Während nun diese Payback-Period bei Cloudfare 25 Monate beträgt, braucht Fastly im Vergleich nur 8 Monate! Übrigens, besser ist nur noch Zoom, denn dessen Payback beträgt sogar nur 3 Monate.


Als letztes sind auch noch die Rückmeldungen aus einer von Fastly durchgeführten Umfrage sehr aufschlussreich. Darin wurden Unternehmen befragt, warum sie sich für das Testprogramm von Compute@edge angemeldet hatten. Bemerkenswert ist hier, dass fast zwei Drittel genau wissen, wofür sie die neue Technologie verwenden wollen. [10]



 

6) Die „DNA“ des Unternehmens – Wer und was treibt das Unternehmen an?


Zunächst einmal stellt sich die Frage, wie Fastly den „eingestaubten“ CDN-Markt so „überraschen“ und ein derart überlegenes PoP-Netz aufbauen konnte: Die Antwort lautet First-Principle-Thinking. Dieser Ausdruck wurde insbesondere von Elon Musk geprägt und meint das Vorgehen, bei dem zur Lösung eines Problems die Ausgangssituation in die grundlegendsten Bestandteile heruntergebrochen wird, um anschließend durch neuartiges Kombinieren eine wirklich gute – wenn auch vorerst aufwendigere – Lösung zu erhalten. Woran zeigt sich nun diese Denkweise bei Fastly?


Zum einen begann Fastly sich als Startup eine eigene Routing-Infrastruktur aufzubauen – und das in einem Markt, der eigentlich schon dessen Gründungszeit als „commoditized“ galt. Die Gründer wollten allerdings die zunehmenden Trade-off-Entscheidungen zwischen Leistung vs. Kontrolle nicht länger akzeptieren. Als dann ab 2013 (u. a. von Arista Networks) Switches erhältlich waren, auf denen eigene Software aufgespielt werden konnte, entwickelte man einen eigenen Distributed-Routing-Agent (genannt Silverton), der ausschließlich für das Traffic-Routing in den eigenen PoPs konzipiert wurde.


Als nächstes widmete sich Fastly einer anderen, grundlegenden Frage: Sind viele, „kleine“ PoPs oder wenige, dafür sehr leistungsfähige PoPs besser? Während die Legacy-Anbieter den Ansatz eines immer „dichteren“ PoP-Netzwerks wählten, erkannte man bei Fastly, dass „weniger mehr ist“. Dass viele, kleine PoPs nicht (immer) besser sind, hat vor allem damit zu tun, dass die Menge der Inhalte, die in kleinen PoPs gecacht werden kann, sehr begrenzt ist. Infolgedessen werden Inhalte oft zu den Origin-Servern zurückgesendet, was wiederum in erheblichen Verzögerungen und höheren Kosten resultiert. Aus diesem Grund entschied man sich bei Fastly für den Aufbau von wenigen, dafür viel leistungsstärkeren PoPs mit großem Speicherpotential.


Mit einer weiteren Trade-off-Entscheidung sah sich das Fastly-Team dann bei der Entwicklung ihrer Serverless-Edge-Computing-Technologie konfrontiert: Hier musste man sich bei den bisher verwendeten Ansätzen entweder für Sicherheit oder für Performance entscheiden. Um diesen Konflikt aufzulösen, setzt man bei Fastly alles daran, die langen Cold-Start-Zeiten so weit wie möglich zu reduzieren. Während Cloudfare hier Standard-Tools verwendete, entwickelte Fastly selbst Compiler und Runtime in Lucet (auf Basis von WebAssembly) um die maximale Performance zu erreichen. Der Vorteil von Cloudfare´s Ansatz (und dessen “Standard”-V8-Compiler) ist dagegen, dass damit ein schnellerer Markt-Rollout mit einer größeren Zahl an Programmiersprachen erzielt werden konnte.


Zusammenfassend kann man das Vorgehen von Fastly also wie folgt umschreiben: Das Unternehmen versucht immer, aus der Sicht eines ENTWICKLERS die leistungsfähigste, kosteneffizienteste und flexibelste Lösung zu entwickeln. Dafür wird oft ein „Umweg“ über einen deutlich komplexeren und aufwendigeren Ansatz in Kauf genommen. Der Grund dafür ist, dass nur so sichergestellt werden kann, dass die bestmögliche Konfigurierbarkeit und Programmierbarkeit angeboten werden kann.


Eng mit diesem Vorgehen verknüpft ist ein hohes Maß an Product-Evangelism. Vereinfacht gesagt ist damit gemeint, dass Entwickler, die von den Vorzügen von Fastly´s Angebot begeistert sind, innerhalb ihrer Community wirkungsvolles Word-of-Mouth-Marketing betreiben und Fastly so bei der Neukunden-Akquise unterstützen. Dazu passt, dass insbesondere Bergmann ein hohes Ansehen in der „Szene“ genießt.


Das Ziel von Fastly ist dabei wiederum genau auf diese „Szene“ zugeschnitten:

Our mission is to fuel the next modern digital experience by providing developers with a programmable and reliable edge cloud platform that they adopt as their own.


Was das Management-Team betrifft, wechselte Arthur Bergmann im Februar diesen Jahres von seinem langjährigen Posten als CEO in die Rolle des Chief Architect. Ich sehe das als äußerst positiv, da er sich so besser auf die technische (Weiter-)Entwicklung von Fastly´s Edge-Network-Funktionalitäten konzentrieren kann. Seinen Posten übernahm Joshua Bixby, der ebenfalls seit 2013 bei Fastly ist. Bixby gründete zuvor bereits ein Content-Management-Software-Unternehmen sowie ein Unternehmen zur Web Application Acceleration – nicht gerade ein Branchenfremder also. Darüber hinaus sind auch zwei andere Gründer in wichtigen Positionen vertreten: Tyler McMullen ist CTO und Sean Leach übernimmt neben seiner Rolle als Chief Product Architect oftmals auch die technische Kommunikation von Produktneuerungen auf dem Fastly-Blog.


 

7) Überblick über einige Kennzahlen – Stimmen die wichtigsten Zahlen?


Bevor wir zum Fazit kommen, werfen wir noch einen kurzen Blick auf die wichtigsten Kennzahlen. Zum einen kam es bei Fastly im letzten Quartal zu einer nennenswerten Beschleunigung des Umsatzwachstums auf über 60%. Für das nächste Quartal wurde vom Management ein Umsatz von rund 75 mio. USD in Aussicht gestellt. Dies entspricht zwar „nur“ ein yoy-Wachstum von 51%, allerdings erwarte ich mit einen ähnlichen Beat der Erwartungen wie in diesem Quartal. Infolgedessen würde das yoy-Wachstum wieder ziemlich genau 60% betragen. [11]



Da die entscheidende „Kundenschaft“ für Fastly die Enterprise Customers sind, wollen wir uns dazu auch noch eine Grafik ansehen [12]. Darin sehen wir zum einen, wie die durchschnittlichen Ausgaben stetig – auf mittlerweile 716.000 USD – ansteigen. Aufgrund der Pricing-Struktur wissen wir, dass Fastly also immer dann profitiert, wenn seine Kunden einen steigenden Traffic auf ihren Web-Inhalten erzielen. Und genau solche Win-Win-Geschäftsbeziehungen sind meiner Ansicht langfristig besonders attraktiv. Zum anderen muss hier noch erwähnt werden, dass Fastly diese Steigerungen erzielen konnte, obwohl viele Kunden aus eher stark betroffenen Industriezweigen stammen und zu diesem Anstieg folglich wohl eher weniger beigetragen haben!



Abschließend hier noch ein Blick auf einen für viele Investoren „bedrohlichen“ Sachverhalt: Fastly ist noch nicht profitabel und wird es aller Voraussicht nach in den nächsten Quartalen auch nicht sein. Im letzten Quartal betrug das GAAP net loss beispielsweise 15 mio. USD. Demgegenüber steht allerdings nicht nur (Stand 30 Juni) ein Cashbestand (Cash and Cash Equivalents) von 384 mio. USD. Vielmehr erkennen wir aus der nächsten Grafik, dass sich die Verluste in den letzten 5 Quartalen stabilisiert haben [13]. Zudem wurde im vergangenen Quartal erstmal ein positives adjusted-EBITDA ausgewiesen.



 

8) Die Investment-Thesis: Warum investiere ich?


Fastly (und Cloudfare) haben die nächste Generation der Content-Delivery-Networks erschaffen, die sog. Edge Networks. Dazu kombinierten sie Edge Computing mit umfangreichen Programmatic Capabilities.


Zum einen wird der Traffic in den neuen Netzwerken auf diese Weise konfigurierbar und „intelligent“ sowie sicher(er) und schnell(er). Zum anderen können dadurch nicht nur Rechenprozesse in unmittelbarer Kundennähe ausgeführt werden. Vielmehr kann Fastly durch die Kombination aus Edge Networks und Edge Computing eigenständig Rechenprozesse durchführen und auf Basis des stattfindenden Traffics neue Services/Produkte entwickeln. Besonders naheliegend sind Cybersecurity-Features – was wiederum der Strategie von Cloudfare entspricht. Fastly ist allerdings kein Unternehmen der leichten und bequemen "Wege“.


Die Legacy-Anbieter konnten und können Entwicklern mit ihren veralteten CDN-Architekturen keine vergleichbaren Funktionalitäten bieten. Mittels des first-principle-thinking hat Fastly von Grund auf eine komplett überarbeitete System-Architektur entwickelt, welche bisher vor allem führende digital-first Unternehmen überzeugt hat. In den nächsten Jahren sollte Fastly´s Leistungsangebot angesichts der nachfolgenden Herausforderungen/Trends immer mehr Unternehmen überzeugen:


  1. Zunehmende Zahl an dynamischen Webinhalten

  2. Zunehmende Anforderungen an Content-Delivery vor allem hinsichtlich Latenzzeiten und real-time-responsiveness

  3. Steigende Kosten für Cloud-/Rechenkapazitäten

  4. Steigende Datenübertragungsraten durch 5G

  5. Stark wachsende Zahl an Daten-erzeugenden Endgeräten durch IoT

  6. Höhere Sicherheitsanforderungen an Computing-Prozesse


In Anbetracht des erarbeiteten Entwicklungsvorsprungs und dem starken Management-Team sehe ich Fastly als hervorragend positioniert, um für die zukünftigen Internet-Anwendungen der führende Schienennetz-Betreiber“ zu werden. Dabei vereint Fastly die infrastrukturspezifische Bedeutung von AWS/Azure mit den attraktiven Unit-Economics bzw. der Skalierbarkeit von Visa/Mastercard.


Das größte Risiko sehe ich einem starken Commitment seitens Microsoft, Amazon oder Google, diesen Bereich für sich gewinnen zu wollen – denn ausreichende finanzielle Mittel wären dort vorhanden. Allerdings würde ich bei entsprechenden Entwicklungen trotzdem erst einmal abwarten, ob Unternehmen gewillt wären, sich von einem Cloud-agnostischen Anbieter wieder vermehrt in die Arme der „großen“ Monopolisten zu begeben. Und ohnehin lässt sich der Wettbewerbsvorsprung von Fastly mittlerweile nicht mehr einfach so von heute auf morgen einholen. Nichtsdestotrotz sollte man das Wettbewerbsumfeld sowie die Entwicklung der Margen bzw. des Wachstums von Fastly genau im Auge behalten.


PS: Newsletter-Abonnenten haben als Ergänzung noch meine Einschätzung zur aktuellen Bewertung sowie eine Erläuterung zu meinem Nachkauf-Vorgehen erhalten.



Spark Invest - Innovation erkennen, Disruption verstehen und besser investieren


THE END.


 

Disclosure

Der Autor ist zum Zeitpunkt der Veröffentlichung long zum vorgestellten Unternehmen positioniert.


Disclaimer

Sämtliche, geschilderten Inhalte stellen weder Kaufs- noch Verkaufsempfehlungen für Finanzinstrumente (Aktien, Anleihen, Derivate, ETFs, etc.) dar.

Die Inhalte dienen lediglich der Allgemeininformation, spiegeln ausschließlich die persönliche Meinung des Verfassers wieder und stellen keine Anlageberatung dar.

Jedes Investment, dass auf im Blog enthaltenen Informationen basiert oder über im Blog angesprochenen Finanzinstrumenten erfolgt, ist mit Chancen und Risiken - bis hin zum Totalverlust - verbunden.


Der Verfasser kann insbesondere nicht einschätzen, inwiefern angesprochene Finanzinstrumente den Anlagezielen, der Risikobereitschaft und der Verlusttragfähigkeit des Lesers entsprechen.

Wer auf Basis von Informationen aus diesem Blog etwaige Anlageentscheidungen trifft, trifft diese ausschließlich auf eigene Verantwortung und eigene Gefahr.


Der Verfasser übernimmt außerdem keinerlei Gewähr für die Aktualität, Richtigkeit oder Vollständigkeit der Inhalte. Und der Verfasser haftet somit auch nicht für Verluste, die aus Anlageentscheidungen resultieren, die auf im Blog geschilderten Informationen basieren.


 

[1]


[2]


[3]


[4]


[5]


[6]


[7]


[8]


[9]


[10]


[11]


[12]


[13]

2.015 Ansichten

Aktuelle Beiträge

Alle ansehen
bottom of page