Die Architektur einer Webapplikation entscheidet über ihre Skalierbarkeit, Stabilität, Flexibilität und die Geschwindigkeit der Weiterentwicklung. Deshalb haben wir bei sevenload eine serviceorientierte Architektur entwickelt, die perfekt auf unser heutiges und zukünftiges Anforderungsprofil passt.

Vor einigen Wochen habe ich im Hinblick auf das heutige Posting bereits vorab erklärt, was SOA ist. Heute möchte ich einen kleinen Einblick in die Architektur von sevenload geben und aufzeigen, wo, wie und warum wir uns für eine strikt serviceorientierte Lösung entschieden haben.

Im Zentrum dieses Beitrags steht das nachfolgende Strukturdiagramm. Was das allgemein gehaltene Strukturdiagramm nicht zeigt, sind viel viel sevenload-Würze und natürlich unsere Geheimzutaten. Ich muss dazu anmerken, dass diese Architektur auf unsere speziellen Anforderungen zugeschnitten ist und für jede Webapplikation aufs Neue maßgeschneidert werden muss. Please, don’t try this at home.

Folgende Dinge werden daraus ersichtlich:

• sevenload besteht aus 3 Kernkomponenten
  Die SDC-Einheit steht für Storage, Distribution und Conversion und managed damit alles dateispezifische, von der Umwandlung und Kodierung der Medieninhalte, über das Hosting bis hin zur Lastverteilung via eigenem Content Delivery Network (mehr dazu bald).

  Der Core ist Herr über alle Daten und Datenspeicher und somit das Herzstück der Applikation. Er optimiert und cacht hereinkommende Anfragen, lässt sie von den passenden Subservices bearbeiten und bereitet die Ergebnisdaten entsprechend auf.

  Die Site letztendlich ist das individuellste und für den eigentlichen Erfolg wichtigste Element im System - das Benutzer-Interface, die einzelnen Features, die Art und Weise, wie Daten dargestellt und zur Verfügung gestellt werden. Die Seele der Applikation.

• Horizontale Skalierbarkeit
  Jede Einheit (jeder Service) ist horizontal frei skalierbar und kann in den meisten Fällen durch das einfache Hinzufügen weiterer Serversysteme beschleunigt werden.
• Weiterentwicklung und Wartung
  Jede Einheit kann unabhängig von den anderen optimiert und weiterentwickelt werden. Entwickler müssen gegenseitig nicht einmal wissen, wie die anderen Einheiten funktionieren, was sogar gefahrlos Spielraum für fremde Dienstleister oder Kunden lässt, die am Site-Bereich selbst mitarbeiten wollen.

  Das ist die in meinen Augen wichtigste Eigenschaft serviceorientierter Architekturen, denn die zuverlässige Weiterentwicklung und Wartung komplexer Applikationen ist und bleibt die größte Herausforderung in der Branche. SOA hilft eben auch beim Skalieren von Softwareentwicklern.

• SOAP für Remote-Prozeduraufrufe
  Wir nutzen SOAP als Protokoll für die Verbindungsstellen zwischen den einzelnen Services. SOAP kann all unsere Remote-Prozeduraufrufe vollständig abbilden, ist schnell, (relativ) leichtgewichtig und verfügt in jeder populären Programmiersprache über eine ausgereifte Implementierung.
• Caching, Caching, Caching
  Was bei populären Webapplikationen sicherlich am schnellsten wächst, sind Cache-Speicher. Geschicktes Caching ist der effiziente Schlüssel zur schnellen und deutlichen Performancesteigerung. Wir verwenden dabei sehr vielfältige Cache-Speicher; von lokalen und entfernten Dateien über lokalen (Opcode-Cache) und entfernten Speicher (z.B. memcached) bis hin zu eigenen Datenbanken.

  Caching-fähig ist grundsätzlich alles. Während wir in der Site-Einheit z.B. auch sehr gut direkten HTML-Code cachen können, cachen wir im Core Datenbank-Queries und Berechnungen.

• Suchindizes, Semantic Tagging Cluster
  Für jede Aufgabe gibt es das geeignete technische Backend. Suchabfragen werden über Volltext-Suchengines (z.B. auf Lucene-Basis) ausgeführt, und für Queries à la “Ähnliche Bilder & Videos” verwenden wir ein spezielles Tagging-System, mit dem wir gerade erst zu experiementieren anfangen (mehr dazu bald).
• Monitoring & Logging!
  Wichtige Lektion: Alles, wirklich alles kann (und wird irgendwann) schiefgehen und ausfallen. Deshalb: Viel viel protokollieren und beobachten, bei kritischen Dingen Alerts versenden lassen (via IM, E-Mail oder gar SMS) und aus den gesammelten Daten lernen.

  Neben Live-Logging sind auch Unit-Tests und vernünftige Deployment- und Staging-Prozesse bei einer großen Webapplikation unabdingbar. Durch die von SOA geförderte verteilte Entwicklung der einzelnen Services entstehen auch ganz neue, unabsehbare Fehlerquellen. Vertrauen ist gut, Kontrolle ist besser.

So, genug für heute :). Ich hoffe, heute viele grundgelegene Eindrücke über das Design großer Webapplikationen vermittelt zu haben. Der Teufel liegt wie so oft im Detail, und das Know-How für diese Architektur haben wir uns über Jahre (kumuliert aufs Team ein paar Jahrzehnte) erarbeitet. Auf dem Weg vom Konzept bis zur marktreifen Applikation sind viele Hürden zu meistern und Zeilen Code zu schreiben.

Wie oben versprochen, werde ich hier demnächst ein wenig über unser hauseigenes Content Delivery Network sowie den Semantic Tagging Cluster (toller Name, oder?) erzählen. Ich freue mich über viel Feedback und Fragen!