Problemfall SOA

Wichtigstes Merkmal des Lösungsansatzes auf Netzwerkebene ist, dass er einen zusätzlichen Kontrollmechanismus einführt. Im Falle von Cisco ist das der virtuelle Softswitch »Nexus 1000V«, der sämtliche VMs anbindet und Regeln für die Kommunikation durchsetzt. Laut Comconsult behalten dabei die VMs ihre ACLs und VLAN-Zuordnung auch, wenn sie zwischen verschiedenen Servern umziehen. Konkurrent Brocade löst »das Problem anders, kommt aber zu einem ähnlichen Ergebnis.«, so die Berater. Den großen Vorteil dieser Methode sehen sie darin, Lastverteilung, Desaster-Recovery und Wartung gerade auch bei einer großen Anzahl von VMs zu unterstützen.

Jedoch setzt dieses Vorgehen den im Alltag seltenen Fall voraus, dass Applikationen eins zu eins auf VMs umziehen. Gerade Ansätze wie SOA und SOAP (Service-Oriented-Architecture / Simple-Object-Access-Protocol), RPC (Remote-Procedure-Call) oder DotNet führen dazu, dass aus Daten oder Lastgründen verteilte Architekturen entstehen. Dabei kommen Änderungen wie beispielsweise kombinierte und wieder getrennte Knoten in einem SOA-Ansatz vor, die sich auch auf Netzwerkebene widerspiegeln müssten. Außerdem bringen diese Architekturen meist auch noch ihre eigenen Sicherheitselemente auf Applikationsebene mit, auf die zu verzichten es wenig Sinn macht. Dies hat jedoch zur Konsequenz, dass die Sicherheit auf der Netzwerk- und der Anwendungsebene gepflegt werden muss. Mehr Aufwand, Kosten und zusätzliche Fehlerquellen bei der Konfiguration sind die Folge.