Acht Distributed-Computing-Irrtümer der PHP-Entwickler
Kommentare

Matthew Setter hat in Anlehnung an die acht Irrtümer bei der Entwicklung von Distributed-Computing
-Applikationen eine neue Liste verbreiteter Missverständnisse im PHP-Umfeld erstellt. Die acht Punkte

Matthew Setter hat in Anlehnung an die acht Irrtümer bei der Entwicklung von Distributed-Computing
-Applikationen eine neue Liste verbreiteter Missverständnisse im PHP-Umfeld erstellt. Die acht Punkte haben einige Überschneidungen mit der alten Liste von Peter Deutsch aus dem Jahre 1997, da PHP-Apps in der Regel ebenfalls Distributed-Lösungen sind. Setter erläutert:

1. Das Netzwerk ist zuverlässig

Auch in Zeiten von Cloud-Computing, wo das Risiko auf viele Server oder noch besser, wie bei Xeround auf mehrere Cloud-Anbieter aufgeteilt wird, kann es nie eine 100-Prozent-Garantie geben, dass Zugriff auf alle Services gewährt ist. Was mache ich, wenn mein Provider plötzlich eine DDoS-Attacke erfährt und seine Infrastruktur zusammenbricht? Bin ich auf einen solchen Fall vorbereitet?

2. Latenz ist Null

Egal, wie schnell unsere Systeme werden: Die Lichtgeschwindigkeit wird immer 300.000 Kilometer pro Sekunde betragen und somit wird ein transatlantisches Datenpaket immer mindestens 30 Millisekunden unterwegs sein. Damit müssen wir arbeiten, auch wenn wir dies über Dienste wie Amazon S3 reduzieren können, bei denen wir Mirrors in der Nähe unserer Anwender einrichten können. Dennoch muss ich bei meinen Anwendungen stets die Latenzen mit einkalkulieren, sofern sie relevant sind.

3. Bandbreite ist unendlich

Die Verfügbarkeit drahtloser Internet-Anbindungen steigt stetig, doch wächst auch der Bedarf: 8,49 Prozent der globalen Website-Aufrufe kommen von Smartphones und Tablets. Diesen neuen Anwendern müssen die bisherigen Server Daten anliefern, und es ist mit immer mehr Traffic zu rechnen. Weiß ich als Entwickler, wie viel Traffic mein Server stemmen kann?

4. Das Netzwerk ist sicher

Der Traffic von Schadsoftware ist in den letzten Quartalen stark angestiegen. Im Finanzsektor hat man 30 Mal so viele Pakete mit Schadsoftware gezählt wie noch ein Quartal zuvor. Es waren 19,1 Terabyte Daten in 14 Milliarden Paketen im vierten Quartal 2011. Weitere Zahlen findet Ihr hier.

Mit Sicherheit auf PHP-Servern beschäftigen sich einige Blogs. Darunter Chris Shifletts Blog, Essential PHP Security, und das PHP Security Consortium.

5. Die Topologie wird sich nicht verändern

Topologische Veränderungen können täglich geschehen. Ist ein Server nicht mehr erreichbar, fallen Datenbankzugriffe aus und unser Service ist offline. Einfache Anwendungen sind davon selten betroffen, doch wenn unsere App wächst und wir uns auf mehrere Server verteilen müssen, dann wird auch unsere Abhängigkeit von der wandelbaren Topologie größer. Unser Deployment muss sich diesem Risikofaktor anpassen.

6. Es gibt einen Administrator

Man darf sich nicht darauf verlassen, dass jeder Service Provider immer mit einem Administrator dienen kann, der im Falle eines Ausfalls oder eines Hacker-Angriffs genau weiß, was zu tun ist. Und wenn wir nicht zufrieden sind mit einem Anbieter, macht uns ein Vendor Lock-in eventuell das Leben schwer, wenn wir mit unserer Anwendung umziehen wollen.

7. Die Transportkosten sind Null

Ein Umzug der Daten kostet Zeit und Geld. Wenn unsere komplette Infrastruktur in einem einzelnen Server-Rack vorliegt, das von Haus zu Haus transportiert werden soll, dann sind die Kosten zwar sehr gering, doch verursacht die Downtime Verluste. Diese können wir uns ersparen, wenn wir unsere Daten weltweit spiegeln lassen, doch zieht das wieder hohe Betriebskosten nach sich. Also haben wir die Wahl zwischen hohen Kosten oder langen Ausfällen. Wie finden wir die Balance?

8. Das Netzwerk ist homogen

PHP-Entwickler sind aufgrund ihrer bunten Service-Landschaft von dieser falschen Annahme teilweise verschont. Unterschiedliche Datenbank-Typen und Server-Betriebssysteme sowie die Kommunikation mit Web-Services in XML oder JSON sind uns bekannt. Da sich diese oft ändern können, sind Entwurfsmuster wie das der Abstrakten Fabrik empfehlenswert, um leichter auf Änderungen reagieren zu können.

Fazit

Matthew Setter sieht für PHP-Entwickler gute Chancen, auf die Fallstricke des Distributed Computings reagieren zu können, da viel Informationen und Ressourcen dazu im Netz bereitliegen. Dennoch sollte sich jeder Entwickler fragen, welche der acht Punkte er bislang unbedacht ließ.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -