Mein letzter Artikel im PHP Magazin ist knapp 1 Jahr her, nun habe ich erneut einen für das Heft geschrieben. Titel: “Scale me up!”.

Der Artikel richtet sich insbesondere an junge Startups und allgemein Projekte, die sich in naher Zukunft einem starkem Wachstum ausgesetzt sehen. Dabei geht es sowohl um konzeptionelle Themen und praxisnahe technische Kniffe als auch um den Aspekt des Entwicklungs- und Teammanagements für kleine Projekte.

Aus der Einleitung:

Wachsende PHP-Projekte stehen vor vielen Herauforderungen: Es gilt Fallstricke in Systemarchitektur und Konzept zu vermeiden und der ansteigenden Last Herr zu werden. Code-Kapselung, Datenbankskalierung und Caching sind unverzichtbare Aspekte dieses Prozesses, doch auch das Thema Teammanagement rückt bei wachsenden Projekten schnell in den Vordergrund. Dieser Artikel soll Einsteig, Inspiration und Hilfestellung für all jene sein, die sich mit wachsenden Projekten im Umbruch und Aufbruch befinden.

Er ist jedoch primär für Einsteiger gedacht und kann jedes der angesprochenen Themen allenfalls anreißen. Der Artikel soll ganz vorallem Anlass zum Denken, zur Recherche und zur Eigenumsetzung geben.

Ich werde ihn in einigen Monaten außerdem wieder online in einer PDF-Version veröffentlichen, möchte jedoch jeden am Artikel interessierten Leser darum bitten, schon vorab die Druckausgabe des PHP Magazins zu kaufen und damit das Magazin zu unterstützen.

Dass die Ausgabe des Magazins heute am 14. November und damit ausgerechnet an meinem Geburtstag erscheint, freut mich natürlich umso mehr :).

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