Was ist Service-Virtualisierung?

In der besten aller möglichen Welten arbeiten Softwareentwicklungs-, Test- und Betriebsteams immer perfekt synchron zusammen und bringen qualitativ hochwertige Produkte termingerecht, unter Einhaltung des Budgets und völlig fehlerfrei auf den Markt. Aber in unserer Welt wird das eher nicht passieren. Schon die Herausforderung, immer komplexere Anwendungen zu erstellen, die in der Regel aus mehreren voneinander abhängigen Komponenten bestehen, sorgt dafür, dass jeder Lebenszyklus der Softwareentwicklung eine oft holprige Strecke zurücklegen muss.

Dennoch können wir zumindest nach dem Ideal streben und neue DevOps-Teams und agile Workflows  können den Prozess beschleunigen und dazu beitragen, Produktionsabläufe so reibungslos wie möglich zu gestalten, indem sie die Kommunikation verbessern, mehrere Softwarekomponenten gleichzeitig erstellen und regelmäßige automatische Tests durchführen. Es gibt jedoch ein Problem, das selbst das beste DevOps-Team blockieren kann, und das ist das Warten auf abhängige Komponenten. Einfache Unit-Tests können an Codebits oder einzelnen Systemkomponenten getrennt durchgeführt werden, aber ein zuverlässiges Testen von Code und Systemintegration kann sich als unmöglich erweisen, wenn in Ihrer Testumgebung wichtige Abhängigkeiten fehlen. Und hier kann Service-Virtualisierung die Dinge dramatisch beschleunigen.

Mit der Service-Virtualisierung können Ihre DevOps-Teams virtuelle Services anstelle von Produktions-Services verwenden, was regelmäßige und umfassende Tests auch dann ermöglicht, wenn noch wichtige Komponenten in Ihrer Systemarchitektur fehlen. Durch die Simulation des Verhaltens wesentlicher Komponenten, die in einer endgültigen Produktionsumgebung vorhanden sein werden, ermöglicht die Service-Virtualisierung, Integrationstests an komplexen Anwendungen viel früher im Entwicklungsprozess durchzuführen, wodurch die wesentlichen Engpässe beseitigt werden, die andernfalls Produktion und Markteinführung einer zu testenden Anwendung (AUT) verzögern würden. Für die Entwicklung der meisten Unternehmensanwendungen, die auf einer gemischten Reihe von Systemkomponenten beruhen, die harmonisch zusammenarbeiten, „füllt die Service-Virtualisierung die Lücken“ fehlender Systemkomponenten. Sie simuliert deren Reaktionen und zeigt, wie die verschiedenen Komponenten zusammenwirken. Das ist besonders nützlich bei der Entwicklung komplexer Cloud-, API- und SOA-basierter Systeme sowie an jedem Punkt eines Produktionszyklus, an dem wichtige Hard- und Softwarekomponenten für Testzwecke nicht ohne weiteres verfügbar sind.

Immer mehr Unternehmen nutzen Service-Virtualisierung, um die Produktivität zu steigern, die Testkosten zu senken und qualitativ hochwertigere Software in kürzerer Zeit bereitzustellen. Neben der Emulation wichtiger Softwareanwendungen, Services von Drittanbietern und sogar ganzer Backend-Systeme können die virtuellen Assets auch verlässlich von Ihrem gesamten Produktionsteam gemeinsam genutzt werden, was eine effizientere parallele Entwicklungspraxis erleichtert. Durch die schnelle und einfache Beseitigung von Abhängigkeitseinschränkungen durch Virtualisierung kann sich Ihr Unternehmen einen Wettbewerbsvorteil gegenüber anderen verschaffen, die noch im Bereich der linearen Entwicklung verharren.

Virtualisieren Sie Ihre Services mit ServiceV Pro

Warum empfiehlt es sich, Service-Virtualisierung einzusetzen?

Bisher mussten Testteams warten, bis nahezu fertige Anwendungen bereitgestellt werden konnten, bevor sie mit den eigentlichen Funktions-, Integrations- und Performance-Tests beginnen konnten. Unterschiedliche Projektteams stellen womöglich verschiedene Komponenten eines Systems oder einer Anwendung einzeln her und bauen sie dann zu einem einzigen funktionierenden Produkt zusammen, bevor sie es den Testern ermöglichen, sich damit auseinanderzusetzen. Es ist logisch, es ist linear und es ist langsam. 

Der Schwerpunkt auf dem Testen einer nahezu fertigen Softwareanwendung mit all ihren Komponenten – die bereits schön hinter einer funktionalen Benutzeroberfläche integriert sind – wird natürlich auch weiterhin ein wesentlicher Schritt in jedem Entwicklungszyklus sein. In diesen Tagen schneller (und kontinuierlicher) Entwicklungszyklen ist es jedoch oft nicht mehr sinnvoll, so lange mit dem Testen zu warten, um festzustellen, wie verschiedene Softwarekomponenten miteinander kommunizieren. Tests müssen von Anfang an neben der Entwicklung durchgeführt werden, und dies gilt insbesondere für die Produktion heterogener Systeme, die mehrere Schichten von voneinander abhängigen Komponenten, Drittanbieteranwendungen und APIs umfassen. Tatsache ist, dass zu dem Zeitpunkt, an dem eine moderne Anwendung eine prüfbare Benutzeroberfläche hat, dies in der Regel nur das Sahnehäubchen auf einem sehr komplexen, mehrschichtigen Kuchen ist.

Wenn wir für einen Moment mit dieser köstlichen Metapher fortfahren, könnten wir sagen, dass der Einsatz von Service-Virtualisierung es möglich macht, den allgemeinen Geschmack unseres Kuchens viel früher im Prozess zu testen, nämlich während wir dem Teig noch Zutaten hinzufügen und selbst dann, wenn dem Teig wichtige Komponenten wie Eier oder vielleicht auch Mehl noch fehlen. Mit unserem vollständigen Kuchenrezept in der Hand, in dem genau steht, welche Zutaten wir benötigen, können unsere virtuellen Zutaten vorübergehend für alle tatsächlich fehlenden Zutaten einstehen, während wir fortfahren. So kann unsere agile App-Bäckerei leicht alle ungewöhnlichen Geschmackskombinationen erkennen, die wir versehentlich Schritt für Schritt in den Kuchenteig einführen, bevor er jemals in den Ofen geht und lange bevor er eingefroren wird.

Mit anderen Worten: Service-Virtualisierung ist ideal für jene testgestützten Entwicklungsteams (TDD), die ihren Produktionsplan beschleunigen wollen, indem sie ihre Fehlersuche auf die API-Schicht konzentrieren, wo größere Probleme im Allgemeinen oft zuerst in die Systemschnittstellen eingeführt werden, anstatt warten zu müssen, bis sie eine vollständigere, produktionsreife App testen können. Mit Hilfe der Service-Virtualisierung können Entwickler Integrationen früher überprüfen, als es andernfalls möglich wäre. Und wenn man bedenkt, dass die Benutzererfahrung einer Anwendung vollständig von der Summe ihrer Bestandteile abhängt, ist es sinnvoll, sicherzustellen, dass diese Komponenten gut funktionieren, während sie erstellt werden, anstatt auf eine fertige Anwendung zu warten. Service-Virtualisierung kann zu jedem Zeitpunkt in der Entwicklung einer Anwendung nützlich sein, von der Unterstützung bei kleinen manuellen Unit-Tests bis hin zur Durchführung automatisierter Performance-Tests eines integrierten Systems. 

Wenn Ihr Unternehmen nicht über ausreichende Ressourcen verfügt, um seinen Entwicklern und Testern alle für ein Produktionssystem erforderlichen Komponenten zur Verfügung zu stellen, kann die Nutzung virtueller Services während des gesamten Entwicklungszyklus viel Zeit und Geld sparen. Jedes Softwareentwicklungsteam kann von der Service-Virtualisierung profitieren, insbesondere wenn es sich nicht anbietet, wiederholt mit abhängigen Komponenten von Drittanbietern wie Salesforce, Oracle oder PayPal zu testen. Durch die Virtualisierung des Verhaltens eines CRM-, ERP- oder Zahlungs-Gateways in Ihrer Systemarchitektur – mit simulierten Daten- und Softwarereaktionen – können Ihre Entwicklungstätigkeiten ungehindert voranschreiten und Sie können beliebig oft Tests durchführen, um den Weg für reibungslose Benutzerakzeptanztests zu ebnen, sobald die tatsächlichen Komponenten von Drittanbietern bereitgestellt sind.

Mocking im Vergleich zu Service-Virtualisierung

Wenn Softwareentwickler, Tester und Systemadministratoren zum ersten Mal von Service-Virtualisierung hören, können sie diese mit Server Virtualisierung oder virtuellen Maschinen verwechseln. Aber Service-Virtualisierung emuliert nicht den Server selbst in all seiner Komplexität, sondern emuliert einen zentralen Punkt, an dem ein Server mit Ihrer Anwendung interagieren könnte. Die Service-Virtualisierung simuliert nur besonderes Verhalten von Software, die mit Ihrer Anwendung getestet werden muss, um zu sehen, ob dieses Verhalten das Ergebnis von Interaktionen mit Großrechnern, Datenbanken, Cloud-Servern, mobilen Geräten, Zahlungs-Gateways, ESPs, CRMs, ERPs und so weiter ist. Da das Ziel einfach darin besteht, die Entwicklung zu beschleunigen, besteht keine Notwendigkeit, Funktionen, API-Aufrufe oder Services zu virtualisieren, die Sie für Ihre Testumgebung nicht benötigen.

Service-Virtualisierung wird ebenfalls häufig mit Mocking und der Erstellung von Simulations-Stubs verwechselt, aber sie’ sind nicht dasselbe (und stellen, was das betrifft, auch keine Spötter und Stümpfe dar). Mocks und Stubs sind vorgetäuschte Softwarekomponenten, die von Entwicklern verwendet werden, um reale Softwarekomponenten zu Testzwecken nachzuahmen, was zunächst einmal sehr nach Service-Virtualisierung klingt. Einer der größten Unterschiede zwischen Mocking-Services und virtuellen Services besteht jedoch darin, dass Mocking-Funktionen in der Regel sehr kontextspezifisch sind, da sie eine bestimmte Verhaltensreaktion simulieren, um einen bestimmten Entwicklungsbedarf zu einem bestimmten Zeitpunkt zu erfüllen (d.h. eine fehlende Abhängigkeit einzubringen, um ihre Abwesenheit zu umgehen, oder ihre Anwesenheit aushilfsweise zu testen, womöglich getrennt vom Rest der zu testenden Anwendung). Virtuelle Dienste hingegen können während des gesamten Produktionszyklus eingesetzt werden und liefern jederzeit – für alle Entwicklungsabsichten und Testzwecke – das gleiche Verhalten und die gleiche Funktionalität für jeden Entwickler oder Tester, der sie nutzen möchte. Sobald sie als Teil einer projektweiten Testumgebung erstellt wurden und verfügbar sind, ersparen virtuelle Komponenten den einzelnen Entwicklern das Schreiben und Umschreiben eigener Mocks und Stubs, was allen Beteiligten Zeit und Mühe spart.

Ein weiterer wichtiger Unterschied besteht darin, dass mit Mocking einzelne Klassen simuliert werden können, während mit der Service-Virtualisierung das Verhalten von Backend-Services ganzer Netzwerke simuliert werden kann. Und soweit es Anwendungen betrifft, so sind die Reaktionen der virtuellen Services so gut wie die der realen. Aber wenn man Mocks verwendet, wird ihre Haltbarkeit durch ihre Glaubwürdigkeit begrenzt. So kann zum Beispiel die Verwendung des Verhaltens eines simulierten Zahlungsverkehrs-Gateways durch den Versuch einer anderen Funktion, das gleiche Zahlungs-Gateway-Mock zu verwenden, ungültig gemacht werden. Aus der Sicht des Tests bedeutet dies, dass sich Mocking im Allgemeinen am besten für Unit-Tests eignet, während die Service-Virtualisierung für Integrations- und Performance-Tests besser geeignet ist. Im Idealfall würde ein gut eingespieltes Engineering-Team in seinem Qualitätssicherungsarsenal sowohl Mocking als auch Service-Virtualisierung sinnvoll einsetzen.

Service-Virtualisierung verstehen

Welche Arten von Entwicklungssituationen sind also am besten für eine Service-Virtualisierung geeignet? Und wie genau funktioniert sie?

Da serviceorientierte Architekturen immer häufiger verwendet werden, gibt es keinen Mangel an Softwarekomponenten von Drittanbietern, die sich darüber freuen würden, wenn Sie sie in Ihren neuesten Anwendung verwenden würden. Diese Apps von Drittanbietern können sich um alles kümmern, von der Verwaltung Ihrer Kundendatenbank bis hin zur Durchführung schneller Bonitätsprüfungen, von der Bearbeitung Ihrer E-Mail-Abonnements bis hin zur Verarbeitung des Bestands und der Bestellungen in Ihrem Online-Shop. Die meisten Anwendungen – und sogar einfache Websites – machen heute umfangreichen Gebrauch von Software von Drittanbietern, und diese eigenständigen Services ersparen es Entwicklern, ähnliche native Funktionen intern von Grund auf neu entwickeln zu müssen. Die reibungslose Kommunikation Ihrer Anwendung mit Anwendungen von Drittanbietern kann jedoch viele Probleme mit sich bringen, insbesondere wenn Ihre Anwendung von externen Komponenten abhängig ist, die möglicherweise noch nicht in Ihren Code integriert oder für Testzwecke nicht ohne weiteres verfügbar sind. Ein Beispiel für eine solche Situation, in der sich die Service-Virtualisierung als sehr nützlich erweisen würde, bietet die Entwicklerin Marcia Kaufman von der Beratungsfirma Hurwitz and Associates:

Betrachten Sie beispielsweise das Szenario eines Online-Händlers mit mehreren Lieferanten. Der Einzelhändler hat eine neue mobile Anwendung für Kunden entwickelt.  Diese Anwendung nutzt einen Bonitätsprüfungsservice, der von einem Drittanbieter bereitgestellt wird. Das Team kann ohne diese abhängige Komponente keine Tests durchführen, aber sie steht für Tests nicht zur Verfügung. Ohne Service-Virtualisierung hat das Software-Entwicklungsteam einige schwierige Entscheidungen zu treffen und keine der möglichen Optionen ist zufriedenstellend. Wenn das Entwicklungsteam ohne die notwendigen Tests weitermacht, kann es zu Fehlern kommen, die später wesentlich schwieriger und kostspieliger zu beheben sind. Wenn das Team wartet, bis der Service eines Drittanbieters verfügbar ist, verringert sich die Produktivität der Entwickler und das Team verpasst möglicherweise die vorgegebenen Produktionsfristen. Darüber hinaus kann es, wenn der Drittanbieterservice verfügbar wird, ziemlich teuer werden, die Anwendungsperformance bei hoher Auslastung zu testen, da der Service bei jeder Ausführung Geld kostet.

Durch die bloße Virtualisierung des betreffenden Bonitätsprüfungsservices lässt sich der hypothetische Anwendungsfall von Frau Kaufman relativ leicht lösen. Zumindest ist es leicht nachzuvollziehen. Aber wie geht man vor, um einen derartigen virtuellen Service tatsächlich zu erstellen? Service-Virtualisierungssoftware verwendet typischerweise eine von zwei möglichen Methoden, um virtuelle Komponenten zu erzeugen. 

Die erste besteht darin, mit einer Standard-Servicebeschreibung zu beginnen, welche die Parameter beschreibt, die Ihre Komponenten erfüllen müssen. Anschließend wird mit Ihrer Virtualisierungssoftware entsprechender Code (z. B. XML, .Net oder Java) generiert, um das Verhalten der benötigten Komponenten zu simulieren. Dies erfordert einen gewissen Aufwand beim Einrichten und Optimieren, wie es die meisten automatisierten Testwerkzeuge tun, aber jede fertige virtuelle Komponente muss in der Regel nur einmal erstellt werden, um wiederholt und kontinuierlich in Ihrer Entwicklungs- und Testumgebung verwendet zu werden. 

Die zweite Methode ist potenziell (aber nicht immer) einfacher, da mit Hilfe von Service-Virtualisierungssoftware Traffic-Aufzeichnungen der tatsächlichen Systeminteraktionen und API-Aufrufe zwischen Ihrer Anwendung und den abhängigen Komponenten, die einer Virtualisierung bedürfen, erstellt werden. Durch die Aufzeichnung des realen Systemverkehrs können Service-Virtualisierungstools simulierte “Reaktionen” zwischen Anwendungen, abhängigen Komponenten und sogar den Backend-Servern erzeugen, von denen sie abhängen. Aber wie auch immer Ihre eigene Virtualisierungssoftware solche Austauschvorgänge erlernt und generiert, ist es diese Fähigkeit, zentrale Systemverhalten perfekt zu simulieren, die Service-Virtualisierung zu einem so unglaublichen Werkzeug macht.

Die Zukunft der Service-Virtualisierung

Der Hauptgrund für den Einsatz von Service-Virtualisierung ist natürlich, Zeit und Geld zu sparen, da Entwicklungsfehler frühzeitig in der Produktion erkannt werden und die Notwendigkeit umgangen wird, ein teures Testlabor aufzubauen. Beliebte Softwareanwendungen für die Service-Virtualisierung können auf üblicher, erschwinglicher Hardware ausgeführt werden, und die von Ihnen eingerichteten virtuellen Testumgebungen können im Laufe der Zeit leicht modifiziert und recycelt werden, um verschiedenen Anforderungen gerecht zu werden. Ob Ihr Unternehmen jedoch in eine Service-Virtualisierungslösung investieren sollte oder nicht, hängt von Ihrer eigenen Kosten-Nutzen-Analyse ab. Aber wenn Qualitätssicherung ein wichtiger Bestandteil Ihres Geschäftsmodells und des Lebenszyklus Ihrer Softwareentwicklung ist, sollten Sie ernsthaft darüber nachdenken. Die Virtualisierung Ihrer API selbst kann auch ein enormer Kostenvorteil sein.

In dieser immer schneller werdenden Ära webbasierter Dienste und mobiler Anwendungen, in der die persönliche Wahrnehmung Ihres Angebots von Seiten der Endbenutzer mehr als alles andere zählen kann, ist es wichtig, dass Entwickler, Tester, Systemadministratoren und kaufmännische Akteure ein gemeinsames Verständnis der Bedeutung von Softwarequalität haben. Ebenso wichtig ist es aber, dass Teams so schnell und zielführend wie möglich zusammenarbeiten können. Da verschiedene agile Workflow-Methoden zur Norm werden, wird der geschickte Einsatz eines Tools wie Service-Virtualisierung – das Teams ermutigt, sich an parallelen Entwicklungsaufgaben zu beteiligen, und darauf „brennt“, Tests ab dem Tag Eins durchzuführen – ein entscheidender Faktor sein, um ein Produktionsteam von der ebenso dynamischen Konkurrenz abzuheben. Von nun an können Teams, die virtuelle Services am besten nutzen, die Oberhand gewinnen.

Autor: John Paul Mueller

Weitere Ressourcen