Interview mit Bernd Rederlechner

Public Cloud: „Jedes System ist angreifbarer, sobald es eine Adresse im Internet besitzt. Was soll es helfen, dass es in eigenen Räumen steht und ich meine Admins kenne?“

Katharina Degenmann

Während die Public Cloud in der Vergangenheit eher als Angriffsfläche für Hacker angesehen wurde, gewinnt sie aktuell zunehmend an Aufwind. Wir sprachen mit Bernd Rederlechner, Lead Architects of PU DIgital Solutionsbei T-Systems, über die Vorzüge der Public Cloud, wie hoch das Sicherheitsrisiko tatsächlich ist und wie Automatisierung dabei helfen kann, unabhängig zu bleiben.

Wer Bernd Rederlechner einmal live erleben möchte, der hat auf der diesjährigen DevOps Conference in München Gelegenheit dazu. In seiner Session Strategy or Suicide – Migration of a Big Data Architecture to Public Cloud wird es darum gehen, welche Vorteile es hat, Big-Data-Architekturen in die Public Cloud zu migrieren und wie die Migration am besten gelingt.

JAXenter: Dein Talk auf der DevOpsCon 2019 beschäftigt sich mit dem Weg von Big-Data-Architekturen in die Public Cloud und den strategische Problemen dabei. Als ein Hemmschuh wird oftmals die Sicherheit genannt. Ist die Angriffsfläche in der Public Cloud wirklich größer?

Bernd Rederlechner: Die Frage rangiert bei mir persönlich unter dem Begriff „Cloud-Paranoia“. Jedes System ist doch angreifbarer, sobald es eine Adresse im Internet besitzt. Und da soll es helfen, dass es in eigenen Räumen steht und ich meine Admins kenne? Studien zeigen z.B., dass immer noch ein Viertel aller Angriffe „von innen“ kommen oder zumindest Hilfe haben. Ich denke, jeder muss heute bei Sicherheitsmaßnahmen nachlegen – ob in der Cloud oder nicht. In der Public Cloud stehen die meisten Basismechanismen für Verschlüsselung, für Abwehr und für Monitoring auf Knopfdruck zur Verfügung. Im Eigenbau dagegen ist es gar nicht so einfach, solche Mechanismen schnell mal selbst richtig aufzusetzen. Es scheitert oft schon an fehlenden Spezialisten. Auch die Verantwortung von Entwicklern wächst: statt Sicherheit auf Infrastruktur abzuschieben, gehört sie ins Software-Design. Ein Wechsel in die Cloud ist da eine gute Gelegenheit, diese Hausaufgabe gleich mit zu erledigen.

Außerdem gilt es, einen Cloud-Provider zu wählen, dem ich auch in kritischen technischen oder politischen Situationen wirklich vertraue. Ich persönlich finde es da wichtig, auf das eigene Bauchgefühl zu hören und nicht einfach der Herde nachzulaufen.

JAXenter: Was siehst Du bei einer Migration von Big-Data-Architekturen in die Public Cloud als größten Nutzen?

Bernd Rederlechner: Wie der Name schon sagt: es geht bei Big-Data darum, große Datenmengen zu handhaben. Das bedeutet generell, dass man auch viele Ressourcen zum Auswerten bzw. zum Speichern von Daten benötigt. Die Public Cloud hat den großen Vorteil, dass ich mir bei Bedarf zusätzlichen Kapazitäten dazu holen bzw. kurzfristig wieder freigeben kann. Ich habe selbst gerade ein Projekt mit Lastwagen begleitet. Da macht es schon etwas aus, dass es ein Sonntags-Fahrverbot gibt. Montags fahren dann aber viele zur gleichen Zeit los, und ich brauche dann wirklich viel Rechenleistung. Ressourcen-intensive Systeme mit Varianzen im Datenverkehr über den Tag oder über die Woche profitieren also vom dynamischen Verbrauchsmodell der Public Clouds, insbesondere wenn man mit automatischen Skalierungsmechanismen arbeitet.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Sogenannte Streaming-Architekturen verarbeiten große Datenmengen quasi „im Vorbeiflug“. Je nach Anwendungsfall werden dabei nicht immer viele Daten gespeichert. Es geht dann eher darum, schnell und verlässlich Reaktionen auszulösen. Im Kern basieren solche System auf hochverfügbaren und skalierbaren Messaging-Infrastrukturen. Ein professionelles Messaging-Backbone selber aufzubauen, ist kein Spaß – auch nicht als Eigenbau in einer Public Cloud. Ein Streaming-Dienst als fertiger PaaS-Service dagegen vermeidet in dieser Hinsicht eine Menge Überraschungen und Kopfschmerzen.

Sobald es ans Aufbewahren großer Datenmengen geht, treten die Kosten für persistente Speicherung in den Vordergrund. In der Public Cloud gibt es sehr günstige Speichervarianten für große Datenmengen. Leider gilt, dass die Speicher umso langsamer werden, je günstiger sie sind. Architekturen, die das berücksichtigen, laufen sehr günstig in einer Public Cloud. Wir nennen das „Architekturen mit Daten-Ökonomie“. Im eigenen Rechenzentrum habe ich meist nur Festplatten und Backups zur Verfügung (zumindest als kommerziell interessante Varianten). Architekten haben deshalb wohl früher eher selten eine mehrstufige Daten-Ökonomie in ihre Architekturen eingebaut. Das bedeutet aber leider, dass eine einfache Re-Installation solcher Altsysteme in der Public Cloud – ohne Modernisierung – der Architektur kaum Vorteil bringt.

JAXenter: Kann und sollte ich Plattformdienste nutzen oder sollte man Vendor Lock-in vermeiden? Bzw. gibt es eine klare Exit- bzw. Fallback-Strategie und wenn ja, wie sieht diese aus?

Bernd Rederlechner: Für mich gilt das “Langweiliges as a Service“-Prinzip: „Baue eigene Services dort, wo Kunden bzw. Endnutzer des Systems hierdurch einen deutlichen Vorteil spüren oder einen echten Unterschied zur Konkurrenz wahrnehmen! Nutze gemanagte PaaS-Services überall dort, wo du das gleiche, langweilige Zeug machst wie alle anderen!“ Damit begebe ich mich sehenden Auges in die Hände dieses gefährlichen „Vendor Lock-In“ Monsters, also dem Problem, dass ich nicht einfach das Produkt später wechseln kann. Ernsthaft, wenn man sich Investitionen in moderne Unternehmenslandschaften anschaut, scheint die Furcht vor Vendor Lock-In ohnehin nicht für alle Anbieter und IT-Produkte zu gelten…und übrigens: Hat schon jemand ohne viel Aufwand durch einfaches Umschalten ein Produkt ausgewechselt?

Gute Architekturen haben sich schon immer dadurch ausgezeichnet, dass sie eine IT Lösung über definierte Schnittstellen in kleinere, entkoppelte Einheiten aufspalten. Wenn man dabei domain-getrieben, also fachlich, und nicht Technologie-fokusiert vorgeht, begrenzen diese Schnittstellen wie Schotten in einem Schiff die notwendigen Änderungen beim Wechsel eines Plattform-Services. Eine streng fachliche Modellierung einer Dienstleistung limitiert quasi die unterliegende Technologie-Abhängigkeit. Ich zeige das an einem Beispiel in meinem Talk. Bei einem Wechsel muss man zwar die Schnittstelle neu implementieren, aber in den meisten Fällen nicht unkontrolliert „überall im System herumschrauben“. Wechseln geht, aber nicht so kostenfrei wie vielleicht erträumt.

Man darf am Ende beim Schutzbedarf vor Vendor Lock-In nicht übertreiben. Es ist ohnehin eine Illusion zu glauben, dass man Vendor-Lock-Ins vorhersehen kann. Wer hätte gedacht, dass Spectre und Meltdown uns klar machen, dass die Nutzung von Intel-Prozessoren ein klassisches Vendor Lock-In ist?

JAXenter: Inwieweit kann Automatisierung dabei helfen, Cloud-unabhängig zu bleiben?

Bernd Rederlechner: Interessante Frage. Sie zeigt, dass der Zusammenhang anscheinend nicht so offensichtlich ist, wie ich dachte. In der Vergangenheit bestand Automatisierung hauptsächlich in kleinen Hilfs-Skripten, die das Leben des Administrators einfacher gemacht haben. In einer DevOps-Welt liegt die Messlatte viel höher: Auf Knopfdruck lassen Automatisierungen ganze Systemumgebungen entstehen oder sterben – und zwar absolut zuverlässig, weil sonst die gesamt Continuous Delivery Pipeline stillsteht. Wir reden also über komplexere Software – und daher sollte auch die Automatisierung ein wenig Architektur haben. Aus dem Domain Driven Design haben Architekten gelernt, dass ein Anti-Korruption-Layer ein gutes Mittel ist. Damit entkoppele ich mich von Systemaspekten, die ich nicht direkt kontrollieren kann. Mehr Tipps und Details würden hier zu weit führen – auch dafür gibt es ja meinen Vortrag.

Für mich bedeutet Cloud-Unabhängigkeit nicht, dass ich ohne Nachdenken auf Knopfdruck die Cloud wechseln kann. Auch das hat noch nie funktioniert. Aber eine Anti-Korruptionsschicht als eine Art Sollbruchstelle in meiner Automatisierung hilft mir, mit überschaubarem Aufwand bei Bedarf eine weitere Cloud anbinden und nutzen zu können.

JAXenter: Am Ende hängt es ja aber meistens doch am Geld. Welchen Tipp kannst du Entwicklern geben, um ihre Manager von den Vorteilen der Cloud zu überzeugen?

Bernd Rederlechner: Inzwischen reicht es, deinem Manager zu sagen, dass Firma xyz (am besten ein Konkurrent) eine Public Cloud-First Strategie hat – aber Spaß beiseite! Meiner Erfahrung nach schwingt bei Cloud-Diskussionen immer eine emotionale Komponente mit: sei es die Verlustangst, weil ich meine IT nicht mehr besitze oder der böse Hacker, dem ich auf der Cloud jetzt schutzlos ausgeliefert bin. Evangelisieren wirkt da kaum.

Wenn man nicht durch Worte überzeugen kann, dann besser durch Fakten. Das kann eine einfache Kostenrechnung sein, die zeigt, dass meine Referenztestumgebung in der Cloud viel günstiger wird, weil ich sie abends und am Wochenende ausschalte. Das kann eine testweise Installation meiner Anwendung auf einer Public Cloud sein, die ihren Ressourcenverbrauch mittels automatischer Skalierung an die jeweiligen Bedürfnisse anpasst. Es funktioniert auch jede Art von Verbesserung an einer Business-Applikation, bei der ich im eigenen Rechenzentrum erst mal lange auf die Lieferung der Infrastruktur oder sogar auf eine strategische Initiative warten müsste. Managerinnen ziehen meistens schnell mit, wenn eine Geschäftsverbesserung sofort und ohne allzu hohe Extrakosten möglich ist.

JAXenter: Wie schätzt Du den Einsatz von Cloud Services im Hinblick auf die Branche ein? Ist die Cloud der einzige Weg oder bleiben hybride Systeme noch lange Zeit die Realität in den Unternehmen?

Bernd Rederlechner: Ich glaube tatsächlich, dass sich in den nächsten zehn Jahren nur noch große Konzerne oder spezielle Sicherheitsbereiche eine hybride Infrastruktur überhaupt noch leisten. Überall dort, wo die Infrastruktur direkt oder indirekt von meinem Geschäft bezahlt werden muss, schmälert eine selbstbetriebene Landschaft meinen Gewinn stärker als eine Landschaft in der Public Cloud.

An dem Punkt kommt normalerweise der Aufschrei der IT-Verantwortlichen in Unternehmen (oder auch von einigen meiner Kollegen). Ich kann das aber begründen: Ich beziehe mich dabei nämlich nicht auf den offensichtlichen Kostenvergleich Invest- vs. Mietkosten in der Public Cloud. Mir geht es um die versteckten Kosten und Nachteile durch „Warten bis ich eine Komponente nutzen kann“ beim Bau eines Systems. Digitale Lösungen benötigen viele moderne Software-Frameworks, die redundant, robust und schnell laufen müssen. Nicht die reine Installation der Software lässt mich warten, die Herstellung einer Plattform mit vergleichbar hohen betrieblichen Qualitätsstandards wie in einer Public Cloud dauert. Fehlt die Qualität, verzögert ungeplante Arbeit den Lieferfortschritt. Gerade digitale Geschäftsmodelle rechnen sich häufig aber nur dann, wenn man erster am Markt ist oder zumindest ziemlich schnell hinter dem Spitzenreiter folgt. Warum also das Geschäft riskieren und auf einen Service auf Knopfdruck verzichten – nur damit ich einen Server in meinem eigenen Rechnerraum streicheln kann? Ganz zu schweigen von der Frage, was komplizierter ist: die Pflege eines Hybriden oder die pragmatische Migration der „Reste“ in eine Public Cloud und die Handhabung einer einzigen Cloud.

JAXenter: Vielen Dank für das Interview!

Bernd Rederlechner is one of the Lead Architects of PU DIgital Solutions, the Digital Transformation Unit of T-Systems. He has been responsible for small innovation projects as well as large-scale programs as chief architect and gathered a lot of experience in balancing interests of the silos Dev, Ops, Test and product management. This solid foundation helps him to make Cloud and DevOps a successful reality for medium to large-scale organisations. The goal is to deliver new business ideas fast and efficient – in cooperation with external customers and also with collegues within Deutsche Telekom.
Geschrieben von
Katharina Degenmann
Katharina Degenmann
Katharina Degenmann hat Politikwissenschaft und Philosophie studiert. Seit Februar 2018 arbeitet sie als Redakteurin bei der Software & Support Media GmbH und ist nebenbei als freie Journalistin tätig.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: