Gemeinsam genutzt, nicht offengelegt: Wie Test-Clouds neu definiert werden

Die Evolution von Geräte-Clouds: Von öffentlich über privat zu gemeinsam genutzt

Als Produktmanager verantwortlich für die Bereitstellung administrativer Funktionen innerhalb des Digital.ai Beim Testen von Plattformen betrachte ich die Infrastruktur aus einer bestimmten Perspektive: dem Gleichgewicht zwischen Verfügbarkeit und Kontrolle. Meine Rolle als Cloud-Administrator ist die zentrale Instanz. Der Administrator teilt Ressourcen zu, verwaltet Benutzerberechtigungen und stellt vor allem sicher, dass die Ressourcen verfügbar sind, wenn die Testteams sie benötigen.

Unsere Branche hat sich im Laufe der Jahre stark verändert. Wir haben uns von der vollständigen Kontrolle über physische Hardware hin zur enormen Flexibilität der Public Cloud entwickelt. Doch keines der beiden Extreme hat das eigentliche Problem gelöst. Heute beschreiten wir einen anderen Weg, der die falsche Dichotomie in Frage stellt, die die Branche viel zu lange akzeptiert hat.

Die Zukunft besteht nicht in der Wahl zwischen „Abriegelung“ und „Öffnung für alle“. Es geht um einen dritten Zustand: Gemeinsame Instanz

Ich möchte Ihnen zeigen, wie wir an diesen Punkt gelangt sind und warum diese Unterscheidung wichtiger ist, als die meisten Anbieter zugeben wollen.

Phase 1: Die Ära des „Hardware-Hugging“ (Inhouse & On-Premise)

Wir alle erinnern uns an das traditionelle Modell: das hauseigene Gerätelabor. USB-Kabel, die sich über die Schreibtische schlängelten. Aufgeblähte Akkus von Mobilgeräten, die alle sechs Monate ausgetauscht werden mussten. Manuelle Betriebssystem-Updates, die ganze Nachmittage in Anspruch nahmen. Und dieses eine iPhone 6, das irgendwie noch funktionierte, als alle anderen längst ausgemustert waren.

Die greifbare Kontrolle hatte etwas Befriedigendes; man konnte buchstäblich hingehen und das Gerät, das Probleme verursachte, in die Hand nehmen. Doch der operative Aufwand war erdrückend.

Für unsere sicherheitsbewussten Kunden, insbesondere im Bank- und Verteidigungssektor, haben wir uns zu formalen On-Premises- und Air-Gapped-Lösungen weiterentwickelt. In diesen Setups ist die Infrastruktur vollständig isoliert, sodass die Daten unter voller Kontrolle bleiben.

Die Geräte haben niemals Kontakt zum öffentlichen Internet. Die Testdaten verlassen das Gebäude niemals.

Warum dies entstanden ist

Banking-Apps, die Finanzdaten verarbeiten. Gesundheits-Apps, die Patientendaten verwalten. Regierungsanwendungen mit vertraulichen Informationen. Diese Anwendungen konnten nicht auf einer Infrastruktur ausgeführt werden, auf der möglicherweise Stunden zuvor Tests eines anderen Unternehmens durchgeführt wurden.

Die Antwort der Branche war einfach: „Diese Geräte gehören Ihnen und nur Ihnen, sie sind in Ihrer Umgebung isoliert. Niemand sonst berührt sie.“

Dies befriedigte reale Bedürfnisse.

• Vollständige Trennung von Geräten und Daten für Anwendungen, die regulierte oder vertrauliche Informationen verarbeiten
• Kundenspezifische Infrastrukturkonfiguration zur Erfüllung interner Sicherheits-, Netzwerk- und Compliance-Anforderungen
• Garantierte Datenresidenz und -souveränität, ohne Abhängigkeit von gemeinsam genutzten öffentlichen Ressourcen
• Air-Gap-Bereitstellungen für Umgebungen, die überhaupt keine Verbindung zum öffentlichen Internet herstellen können

Das dadurch entstandene Problem

Aber Folgendes habe ich bei der Verwaltung dieser Umgebungen beobachtet: Dadurch wurde das Sicherheitsproblem gelöst, aber ein neues geschaffen – das wirtschaftliche.

• Hohe GesamtkostenDie Organisationen wendeten viel Zeit, Ressourcen und Geld für die Instandhaltung der Infrastruktur auf.
• Langsamer Zugriff auf neue GeräteIch habe miterlebt, wie Kunden nach dem Verkaufsstart drei Monate lang auf das iPhone 15 warten mussten, um es testen zu können. Die Anschaffung musste von der Geschäftsleitung genehmigt werden. Die Einkaufsabteilung musste es bestellen. Die IT-Mitarbeiter mussten es konfigurieren und ins Testlabor einbinden. Währenddessen luden die Nutzer bereits ihre App auf das neueste iPhone herunter.

On-Premises bot Unternehmen die benötigte Sicherheit, jedoch zu Kosten, die nicht mit der Geräteabdeckung skalierten, die mit der Marktfragmentierung nicht Schritt halten konnte.

Für wirklich sensible Arbeitslasten gilt dies weiterhin. Abgeschottete und lokale Lösungen werden auch in Zukunft relevant bleiben; sie sind unerlässlich für vertrauliche Daten und rechtlich eingeschränkte Anwendungsfälle. Sie sollten jedoch nicht die Standardlösung für jeden Testbedarf sein.

Phase 2: Die SaaS-Spaltung (Öffentliche Cloud vs. Dedizierte Cloud)

Mit dem Übergang des Marktes zu SaaS spaltete sich dieser in zwei binäre Optionen auf. Keine von beiden erfüllt die Bedürfnisse moderner Cloud-Administratoren in Unternehmen, die ein Gleichgewicht zwischen Sicherheit, Abdeckung und Kosten anstreben.

Option 1: Die öffentliche Cloud

Öffentliche Geräte-Clouds entstanden als erste Lösung für ein Problem, das wirtschaftlich unmöglich zu lösen war: Entwickler konnten es sich nicht leisten, jedes Gerät zu kaufen, das ihre Nutzer besaßen.

Die Geräte werden dynamisch nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ zugeteilt, die Kontrollmöglichkeiten sind begrenzt und sie werden von allen Kunden der Plattform gemeinsam genutzt.

Warum dies entstanden ist

Anfang der 2010er-Jahre explodierte die Fragmentierung des Mobilmarktes. Android brachte vierteljährlich Dutzende neuer Geräte auf den Markt. iOS ergänzte seine Modelle jährlich. Manuelle App-Tests auf physischen Geräten wurden für alle außer den größten Unternehmen wirtschaftlich unmöglich.

Öffentliche Cloud-Dienste boten einen Durchbruch: sofortigen Zugriff auf Hunderte von Geräten ohne Hardwarekauf.

Bezahlen Sie nur, was Sie benutzen. Keine Einrichtung erforderlich. Einfach klicken und testen.

Für Startups und schnelllebige Entwicklungsteams war dies ein Wendepunkt.

Dies befriedigte reale Bedürfnisse.

• Die Notwendigkeit, physische Gerätelabore anzuschaffen und zu warten, entfiel.
• Ermöglichte eine schnelle, bedarfsgerechte Validierung ohne Einrichtung oder Infrastrukturplanung.
• Eine breite Geräteabdeckung wurde auch mit begrenzten Budgets wirtschaftlich zugänglich gemacht.

Die sich ergebenden Einschränkungen

Doch mit der Einführung dieser Plattformen in Unternehmen traten Probleme auf, von denen ich in Kundengesprächen immer wieder hörte:

• Eingeschränkte Kontrolle„Unsere Anwendung benötigt spezielle VPN- und Netzwerkkonfigurationen, um eine Verbindung zu internen Umgebungen herzustellen. Geräte der öffentlichen Cloud basieren auf standardisierten Netzwerkkonfigurationen, die dies nicht unterstützen.“
• Verfügbarkeitsprobleme„Wenn Apple ein neues iPhone auf den Markt bringt, schnellt die Nachfrage sofort in die Höhe. Wir müssen dann während wichtiger Testphasen in Schlangen warten.“
• Compliance-Lücken„Unser Sicherheitsteam hat die Architektur geprüft und abgelehnt. Eine mandantenfähige öffentliche Infrastruktur ist für Anwendungen, die sensible Finanzdaten verarbeiten, nicht akzeptabel.“

Öffentliche Cloud-Dienste haben das mobile Testen demokratisiert, aber sie wurden nicht für die Sicherheits- und Kontrollanforderungen von Unternehmen entwickelt.

Option 2: Die dedizierte Cloud

Um die Sicherheitslücke zu schließen, hat sich die Branche auf dedizierte (private) Cloud-Angebote als Standard festgelegt. Dabei handelt es sich um Single-Tenant-Umgebungen, in denen Geräte ausschließlich einem Kunden zugewiesen sind.

Geräte, die exklusiv für einen einzelnen Kunden reserviert sind und volle Kontrolle bieten, ohne dass die Laborinfrastruktur verwaltet werden muss.

Dies befriedigte reale Bedürfnisse.

• Zugang zu einer privaten, mandantenfähigen Cloud-Umgebung, die exklusiv für Ihre Organisation bestimmt ist.
• Sicherheits- und regulatorische Anforderungen durch vollständige Isolation erfüllen.
• Die volle Kontrolle über Geräte und Konfigurationen behalten, um Testszenarien zu optimieren.
• Reduzierung des operativen Aufwands im Zusammenhang mit Laborwartung, Upgrades und IT-Administration.
• Dies bot den Unternehmen die notwendige Sicherheitslage, brachte aber auch einige der wirtschaftlichen Probleme von On-Premise-Lösungen mit sich.

Die sich ergebenden Einschränkungen

• Die anhaltend hohen Kosten für dedizierte Geräte führen zu einer begrenzten Gerätevielfalt und einer unvollständigen Testabdeckung.
• Eine restriktive Gerätezuweisung, insbesondere während Spitzenzeiten wie Vorabtests oder gerätespezifischem Debugging, verringert die Flexibilität beim Testen und kann zu Verzögerungen bei der Veröffentlichung führen.

Die Diskrepanz: Was Kunden tatsächlich brauchten

Zu diesem Zeitpunkt standen wir vor zwei extremen Optionen:

• ÖffentlicheErschwingliche, leicht zugängliche und vielfältige Geräteabdeckung – jedoch Sicherheitsbedenken und begrenzte Kontrollmöglichkeiten.
• EngagiertSicher, kontrolliert, konform – aber teuer und mit begrenzter Geräteauswahl.

Als ich mich jedoch mit Kunden zusammensetzte und sie nach ihren tatsächlichen Testabläufen fragte, beschrieben sie Anforderungen, die keinem der beiden Extreme entsprachen:

„Unsere CI/CD-Pipeline führt stündlich Funktionstests auf 50 Geräten durch. Diese Tests müssen in unserem privaten Netzwerk mit unserer VPN-Konfiguration schnell ausgeführt werden und die Gerätekonfigurationen müssen für verschiedene Testreihen wiederverwendet werden können. Öffentliche Clouds unterstützen dies nicht, und dedizierte Geräte sind für eine Skalierung zu teuer.“

„Für Produktionstests mit echten Kundendaten verwenden wir spezielle Geräte. Bei der Entwicklung hingegen müssen unsere Teams Fehlerbehebungen lediglich schnell auf einer Vielzahl von Geräten validieren. Sie benötigen keine dedizierten Ressourcen – sie benötigen eine umfassende Testabdeckung.“

Das Muster war eindeutig: Die Kunden brauchten etwas zwischen öffentlich und exklusiv..

Sie brauchten:

• Ökonomische Vorteile gemeinsam genutzter Infrastruktur mit bedarfsgerechtem Zugriff auf Geräte
• Breite Geräte- und Betriebssystemabdeckung, vergleichbar mit öffentlichen Clouds
• Sicherheit und Isolation auf Unternehmensniveau, ohne exklusive Gerätebesitzrechte
• Vollständige Netzwerkkontrolle, einschließlich VPN- und Standort-zu-Standort-Konfigurationen
• Zuverlässige Ausführung umfangreicher Testreihen ohne störende Einrichtungs- oder Abbauarbeiten zwischen den Testläufen.

Die Branche hatte das Problem als eine Ja/Nein-Entscheidung dargestellt. Diese Darstellung war falsch, und genau da haben wir angefangen, etwas anderes zu entwickeln.

Phase 3: Gemeinsam genutzte Geräte in privaten Clouds – Der dritte Weg

Das ist wo Digital.ai Tests hat sich in den letzten Jahren auf Innovation konzentriert. Nicht, weil wir um jeden Preis anders sein wollen, sondern weil wir auf die tatsächlichen Bedürfnisse unserer Kunden gehört und versucht haben, ein echtes Bedürfnis zu lösen.

Was dies bedeutet,

Die Geräte werden dynamisch nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ zugewiesen, bieten aber im Vergleich zu öffentlichen Geräten mehr Kontrolle und Flexibilität. Sie eignen sich für die Durchführung umfangreicher Testreihen, die spezifische Konfigurationen erfordern (z. B. die Verwendung derselben VPN-Konfiguration wie bei dedizierten Geräten) und einen unterbrechungsfreien Betrieb gewährleisten.

Sie erhalten die wirtschaftlichen Vorteile der gemeinsamen Nutzung bei gleichzeitig hoher Sicherheit durch eine private Umgebung.

Warum dies entstanden ist

Drei Kräfte wirkten zusammen, um dieses Modell sowohl möglich als auch notwendig zu machen:

1. Die Cloud-Sicherheitstechnologie ist ausgereift.

Die Architektur privater Clouds hat sich so weit entwickelt, dass wir innerhalb einer Multi-Tenant-Infrastruktur echte Isolation schaffen können. Ihre Geräte, Netzwerkkonfigurationen und Daten bleiben vollständig von denen anderer Kunden getrennt, obwohl die zugrunde liegende Cloud-Infrastruktur gemeinsam genutzt wird.

Dieser Grad an Isolation war im Jahr 2015 nicht zuverlässig erreichbar. Mittlerweile ist er jedoch zum Standard in der Cloud-Architektur von Unternehmen geworden.

2. Der Kostendruck hat sich verstärkt

Die Teams wünschten sich dieselben Sicherheitsgarantien bei gleichzeitig besserer Wirtschaftlichkeit. Die alte Antwort „weil es die Sicherheit erfordert“ war nicht mehr zufriedenstellend.

3. Vielfältige Testanforderungen

Teams haben heutzutage nicht mehr nur eine Art von Tests, sondern mehrere Arbeitslasten mit jeweils unterschiedlichen Anforderungen:

• Hochsichere Produktionstests mit echten Kundendaten (erfordert dedizierte Ressourcen)
• Funktionstests im großen Maßstab mit synthetischen Daten (Skalierung und Abdeckung haben Vorrang vor Exklusivität)
• Umfassende Kompatibilitätstests über Hunderte von Geräte- und Betriebssystemkombinationen hinweg (auf dedizierten Geräten allein wirtschaftlich nicht rentabel)
• Tägliche Validierung von Bugfixes im Entwicklungsprozess (schneller Zugriff und Vielfalt erforderlich, Verfügbarkeit nicht garantiert)

Eine einheitliche Infrastruktur, ob öffentlich oder eigens dafür eingerichtet, spiegelt nicht wider, wie Tests heute tatsächlich ablaufen.

Was dies für Ihre Teststrategie bedeutet

Wenn Sie heute Cloud-Lösungen für Geräte evaluieren, rate ich Ihnen dringend, die Unterscheidung zwischen „öffentlich“ und „privat“ gänzlich zu verwerfen. Sie ist überholt und spiegelt nicht die Realität moderner Testverfahren wider.

Treffen Sie Ihre Entscheidung stattdessen darauf, wie Ihre Teams tatsächlich arbeiten. Um Ihnen dabei zu helfen, die Antworten zu finden, finden Sie hier einige hilfreiche Fragen:

1. Wie hoch ist Ihr tatsächlicher Arbeitslastbedarf?

• Verarbeiten alle Workloads sensible oder regulierte Daten oder nur einige davon?
• Benötigen Sie eine garantierte Geräteverfügbarkeit zu jeder Zeit oder nur während definierter Zeiträume?
• Sind Ihre Tests von persistenten Gerätekonfigurationen abhängig oder benötigen sie bei jeder Ausführung eine saubere Umgebung?

Die meisten Teams stellen bei genauerer Betrachtung fest, dass sie eine Mischung haben.

2. Können Sie die Arbeitslasten anhand der Sicherheitsanforderungen trennen?

• Hohe Sicherheit → Dedizierte SaaS- oder On-Premise-Lösung (Produktionsdaten, regulierte oder eingeschränkte Anwendungen)
• Mittlere Sicherheit → Gemeinsam genutzte Geräte innerhalb einer privaten Instanz (Funktionstests, CI/CD, Kompatibilität)
• Niedrige Sicherheit → Öffentliche oder gemeinsam genutzte Geräte innerhalb einer privaten Instanz (frühe Entwicklungsphase, Validierung nicht sensibler Daten)

Die wichtigste Erkenntnis: Nicht jede Testlast erfordert die höchste Sicherheitsstufe.

Fazit: Evolution, nicht Revolution

Die Entwicklung von öffentlich über privat zu gemeinsam genutzt wurde nicht durch Innovationen der Anbieter um der Innovation willen vorangetrieben. Sie wurde vielmehr durch Kundenbedürfnisse und Marktkräfte bestimmt, die die Branche nicht ignorieren konnte:

Gemeinsam genutzte Geräte innerhalb einer privaten SaaS-Umgebung entstanden, weil Unternehmen einen Ausgleich zwischen wirtschaftlichen Aspekten, die sie nicht ignorieren konnten, Gerätevielfalt, ohne die sie nicht testen konnten, und Sicherheit, die sie sich nicht leisten konnten zu opfern, finden mussten.

At Digital.ai Unsere Tests haben gezeigt, dass die Zukunft der Cloud-Infrastruktur für Geräte nicht in der Wahl eines einzigen Bereitstellungsmodells liegt. Vielmehr geht es darum, Architekturen zu entwickeln, die flexibel genug sind, um unterschiedliche Workloads den passenden Ebenen zuzuordnen – und das alles in einer sicheren, konformen Umgebung, die Cloud-Administratoren auch tatsächlich verwalten können.

Die eigentliche Frage war nie „öffentlich oder privat?“

Die eigentliche Frage lautet: „Wie können wir den Testteams die benötigte Abdeckung bieten, ohne unsere Daten preiszugeben oder unser Budget zu sprengen?“

Das ist die Bedeutung von „Geteilt, nicht enthüllt“. Und das ist die Zukunft, die wir gestalten.