Vor unserem Team liegt ein spannendes Wochenende: Wir tragen die Früchte unserer vielmonatigen Arbeit an die Web-Öffentlichkeit.

Nach langer Schreibpause gibt es deshalb auch mal wieder ein kurzes Blogposting von mir. Die letzten Monate waren 24/7 meinem Baby sevenload gewidmet, da blieb nicht viel Luft zum Schreiben.

Nachdem wir in 2007 schon diverse B2B-Projekte (z.B. sportsfreunde.de, BMW-web.tv) umgesetzt haben, wird nun endlich auch unser eigenes Portal auf den aktuellen technologischen Stand (sevenload Platforms) gebracht.

Nun sitzen wir hier, und blicken einer langen Nacht ins Auge. 36 Stunden ohne Schlaf, davon liegen noch knapp 22 vor mir. Und ich freu mich drauf!

So ein Relaunch ist eine komplexe Operation, gerade wenn man ihn in dem Umfang durchführt, wie wir es nun tun. Durch Änderungen in der dahinterliegenden Datenstruktur und Systemarchitektur müssen innerhalb weniger Nachtstunden Millionen und Abermillionen von Datensätzen und Dateien angepasst, umgewandelt und restrukturiert werden. Dabei muss jede Systemkomponente und damit jedes Teammitglied Hand in Hand arbeiten, und es müssen zahlreiche Phasen und Checks durchlaufen werden.

Manche Dinge kann man parallelisieren, manche hängen voneinander ab. Manche Prozesse laufen reibungslos ab, andere werfen unvorhergesehene Probleme auf. Deshalb herrscht bis zum Schluss Anspannung und Aufregung. Wir fühlen uns hier wie im Space Operations Center - alle Entwickler reden und fragen quer durch den Raum, denn effektiver ist eine solche Nacht nicht durchführbar. Alle 30 Minuten ruft jemand Dinge wie “Datenport Core abgeschlossen“, “Reindizierung der Tables ist glatt durchgelaufen” oder “File-Merging komplett“.

Wenn man dann auf die Uhr schaut, wurde der Zeitplan mal mehr und mal weniger genau eingehalten, aber im Großen und Ganzen pendelt er sich immer wieder ein. Aktionen wie unsere Workshop Weeks haben das Team für solche Situationen zusammengeschweißt.

Es liegt noch viel vor uns, und ich werde gerade wieder dringend gebraucht. Was man anfängt, muss man auch zu Ende bringen. Bei Ibo und im sevenload Blog gibt es weitere und regelmäßig aktualisierte Relaunch-News. Drückt uns die Daumen!

Aufmerksame Beobachter wissen längst, dass sevenload auch im B2B-Bereich sehr aktiv ist. Basis dieser äußerst erfolgreichen Geschäftsfeld-Expansion ist unsere Technologie-Plattform “sevenload Platforms”.

Vor einigen Monaten habe ich einige Details über unsere Systemarchitektur veröffentlicht. Diese sehr aufwändige und komplexe Struktur ist auf die Entwicklung und den Betrieb großer (Web-)Plattformen ausgelegt und gibt uns ein mächtiges Instrument in die Hand, um solche Plattformen extrem schnell und qualitativ umsetzen und bereitstellen zu können.

Disclaimer: Mein Blog soll hier wirklich nicht zur Marketing-Schleuder werden, aber ich liebe dieses Teil einfach :)

Die Plattform lässt sich grundsätzlich in 4 Teilbereiche aufsplitten:

• The Platform
  Plattform-Basisfunktionen (Administration, Internationalisierung und Lokalisierung, Skalierung, Tracking, Ad-Technologie, Security)
• Social Networking
  Allgemeine interaktive Community-Funktionen (Profile, Gruppen, Kontakte, Foren, Messaging, Chats, Kommentare, Bewertungen)
• Media Publishing
  Veröffentlichung und Verwaltung von Multimedia-Inhalten (Audio, Videos, Livestreaming, Bilder, Dokumente, Alben, Playlists, Widgets)
• Interoperability
  Plattform-übergreifende Komponenten und Schnittstellen (APIs, Mobile, MMS, TV, MP4/iTunes/iPod, Single Sign On)

Im Fokus all dieser Funktionen steht auch immer eine gute Performance, Lastbeständigkeit, Erweiterbarkeit und die Eignung für den Massenmarkt (it does scale).

In den letzten Monaten haben ich und mein Team aus Workaholics eine Reihe großer Whitelabel-Plattformen entwickelt. Zwei davon sind bereits online:

Den ganzen Beitrag lesen

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:

Den ganzen Beitrag lesen

Zufällig fiel mir ein älterer Artikel in die Hände, den ich Mitte letzten Jahres für das PHP Magazin geschrieben habe.

Thema:

Der Begriff „Web 2.0“ fasst zusammen, was moderne Web-Plattformen leisten müssen: Große Mengen an Daten und Informationen sollen innerhalb von Millisekunden miteinander verknüpft, weiterverwendet und ausgetauscht werden. Die Anforderungen an die Entwicklung moderner Web-Applikationen sind gewaltig – und mit PHP zu meistern. Die deutsche Bild- und Videoplattform sevenload macht vor, wie Web 2.0 mit PHP funktioniert.

Es geht also um einen kurzen Ein- und Überblick in die Welt der Entwickler großer Plattformen, angereichert mit ein paar Praxistricks.

Der Artikel wurde kurz darauf auch nocheinmal in der Visual-X veröffentlicht, da konnte man also auch über ihn stolpern.

In Absprache mit dem PHP Magazin darf ich den Artikel hier auch als PDF zum Download anbieten. Daumen hoch für die Top-Redaktion und den Software & Support Verlag!

Das Prinzip der Service Orientated Architecture (SOA) findet sich heutzutage in jeder wirklich skalierbaren und guten Webapplikation wieder. Auch sevenload setzt auf SOA. Bevor ich jedoch davon erzählen kann, möchte ich zunächst die SOA-Basics erklären.

Im Allgemeinen geht es dabei darum, einzelne Funktionen der Software so gründlich es geht voneinander abzukapseln und in unabhängige Services (Komponenten) zu verpacken. Diese kommunizieren dann über eine klar definierte Schnittstelle (API) untereinander und ermöglichen so eine sehr saubere und parallele Entwicklung.

Das ist ein bißchen wie bei großen Lego-Sets aus früheren Zeiten: Erst baute man den Dino-Kopf, dann den Dino-Rumpf, dann hat man beides zusammengesteckt. Das Gute daran war: Ich konnte den Kopf bauen, mein Sandkastenfreund gleichzeitig den Rumpf. Wir mussten uns nur auf die Verbindungsteile einigen.

Zurück zum Code: Lediglich die Schnittstelle (Input & Output) eines Service muss also geregelt und definiert sein – wie Vorgänge intern abgewickelt werden, ist dem Entwickler der einzelnen Komponente selbst überlassen.

Den ganzen Beitrag lesen