Phil Calçado lernte ich bereits vor einiger Zeit auf einem Event in Berlin kennen und hatte daher hohe Erwartungen an seinen Vortrag APIs: The Problems with Eating your Own Dog food. Ich sollte nicht enttäuscht werden. Nachdem die Frage: "Was ist Soundcloud?" und die damit verbundenen Anforderungen an Performanz geklärt waren, wurde dargestellt wie sich die Soundcloud Architektur über die Zeit entwickelt hat.
Während dieser Evolution wurde zeitweise das Rendern der Webseite auf den Browser verlagert, was zu ungefähr 159 API-Anfragen pro Seitenanfrage führte. Nicht nur dem Publikum machte diese Zahl Angst sondern auch der Soundcloud Crew, jedoch war man zuversichtlich dass durch zusätzliche Server diese Last zu schaffen sei. Schnell lernte man, dass nach dem Zusammenbruch des HAProxy weitere Komponenten (memcached/Rails/MySQL) der Masse an Anfragen nicht gewachsen waren. Wie bei Twitter wurde hier die Erfahrung gemacht, dass serverseitiges Rendern von Webseiten weiterhin zentral für die zeitnahe Auslieferung von Webinhalten ist.
Interessante Erfahrungen vermittelte der Vortrag über das Design von Mirco Services, welche auch in anderen Talks des Modern Web Architecture-Tracks ein dominantes Thema waren. So führte der initiale Schnitt in kleinere Services dazu, dass pro Benutzeranfrage deutlich mehr Zeit in die HTTP-Verarbeitung geflossen ist. Auch wenn damit die Datenbank entlastet werden konnte, war dies keine befriedigende Situation. Als zentrales Problem stelle sich die fehlende Parallelisierbarkeit von Rails heraus, da fachlich mögliche, parallele Anfragen nicht umgesetzt werden konnten. Da Rails, zum Leid Calçados, weiterhin eine zentrale Technologie im Soundcloud System darstellt, wurde das Problem über die Verwendung von nebenläufigem IO umschifft.
Beispielhaft wurde dies anhand der nebenläufigen Beschaffung von Trackinformationen verdeutlicht, dies wird in der Ruby Anwendung aufgerufen und über Scala Klassen umgesetzt. Über Scala Futures erfolgt die Kommunikation zwischen beiden Komponenten. So können die Vorteile von Scala im Bezug auf nebenläufige Programmierung genutzt werden, ohne das Rails-Programmiermodell zu sabotieren. Auch dieses Anwendungsbeispiel zeigt wie praktische polyglotte Programmierung funktionieren kann.
Abschließend zeigte Calçado, dass über nebenläufige Anfragen hinaus die Reduktion des Netzwerkverkehrs eine zentrale Rolle spielt. Verbesserungen in dieser Richtung konnten durch spezifische APIs für Anwendungsgruppen wie Mobile, Web oder Partner realisiert werden. Weitere Verbesserungen erhofft man sich durch eine weitere Untergliederung in Experience based APIs.
Alles in Allem zeigt der Vortrag, dass das Design von Services kein Selbstläufer ist sondern neben den offensichtlichen Vorteilen auch Herausforderungen schafft, in deren Bewältigung auch Rückschläge eingerechnet werden müssen.