Idee, Motivation und Hintergrund
Jeder spricht über "Mutlicloud" und will "jeden Workload an jeder Location" betreiben. Wir sprechen nicht nur darüber - wir tun es auch! Im letzten Blog Post zum Thema Cloud Native App Journey "Interact" sind wir auf dieses Thema eingegangen.
Dieser Blog Post geht direkt auf das Thema "Interact" und die Umsetzung über ServiceMesh, ServiceDiscovery und "Multi Cloud|Plattform"-Connectivity ein
Aber erst einmal der Reihe nach:
Sicherlich ist es sinnvoll einen Workload dort zu platzieren, wo er "am besten" aufgehoben ist. Wenn wir "die Cloud" mit einen "Hotel" vergleichen ist der heutige Standard oftmals Kubernetes. Kubernetes ist das Betriebssystem für Applikationen in der Cloud und ermöglicht state-of-the Art Betrieb von Applikationen und die Abbildung deren Life-Cycle.
Aber nicht alle Applikationen sind per-se containerisiert oder gar Microservices. Des weiteren stellen sich viele, grundsätzliche Fragen. Denn die zentrale, bzw. Herausforderung ist, dass alle Applikationen - vor allem die modernen - mit anderen Applikationen kommunizieren müssen - über diverse Plattformen hinweg.
Welche wesentlichen Fragen stellen sich:
Wie verbindet man die einzelnen Plattformen (Clouds, Datacenter, VMs, Container, etc.) in der Realität?
Welche Herausforderungen gibt es hinsichtlich des Netzwerkes?
Wie implementiert man Security mit echtem Zero-Trust-Networking und Verschlüsselung?
Wie Automatisiert man die Vernetzung und Entlastet Dev und Ops?
Wie finden sich die Applikationen bzw. die einzelnen Komponenten, wenn diese verteilt betrieben werden (Stichwort: ServiceDiscovery)
An dieser Stelle landet man bei den Themen: Service Mesh & Service Discovery
Global galaktische Herausforderung
Cloud. Container. Kubernetes. Microservices. Lift and Shift. Re-Factor, Re-Architect. Cloud Native App Journey. Das ist alles toll und es sind Technologien, welche uns viel wertvolles bringen können - sofern wir sie richtig einsetzen.
Es ist aber kompletter Unsinn, wenn wir den Leuten für jede neue Technologie sagen, Ihr müsst Eurer Zeug umbauen - oder sogar komplett neu bauen. Das vernichtet Synergie. Alles muss mit Sinn, Verstand und einer gehörigen Portion Pragmatismus geschehen.
Und das sagen wir als Technologen.
Fangen wir einmal ganz weit vorne an - worum geht es in der heutigen IT?
Entwicklung von Monolithen hin zu “Cloud Native Applikationen”
Wie hat alles angefangen?
Mit einzelnen, physikalischen Servern
Darauf folgten Virtuelle Maschinen (und darauf dynamische VMs - z.B. mit OpenNebula, Terraform, AWS EC2, usw.)
Und darauf dann die noch kleineren, kurzlebigen Container
Und daraus bestehen die ganzen Flotten von Microservices
Welche Herausforderungen sind entstanden?
Wie migriert man von einem Monolithen hin zu Microservices?
Wie sichert man die Kommunikation zwischen den Services ab?
Wie geht man mit Stateful Applikationen um?
Dazu kommen die Organisatorischen Herausforderungen wie das Gesetz von Conway ( https://de.wikipedia.org/wiki/Gesetz_von_Conway )
Etwas technischer an Hand eines simplen Beispiels dargestellt:
Die (internen) Funktionsaufrufe innerhalb eines Monolithen wandern nun als Remote Procedure Call (RPC) über ein Netzwerk:
Und Netzwerke sind ja bekanntlich super sicher und stabil - vor allem in der Cloud und zwischen Datacentern. NICHT.
Dazu kommen Herausforderungen wie “Multi Plattform” - oder “Multi Cloud”
Die Services eines Kubernetes Clusters sollen mit Bare-Metal Servern, VMs, Containern oder Serverless Functions / Cloud Services kommunizieren können.
Wie verbindet man all diese unterschiedlichen Plattformen untereinander?
Ohne Vendor Lock-In?
Ohne massiven Overhead und Komplexität im Betrieb?
Mit Security / Zero-Trust?
Die wesentlichen, technischen Herausforderungen:
Service Discovery - wie finden sich die Services?
Sicherheit welcher Service darf mit welchem sprechen (über sicheres mTLS)?
Routing - Wie wird zu den einzelnen Services geroutet?
Damit haben wir schon die wesentlichen Grundlagen und Features eines Service Mesh grob umrissen.
Im Detail werden wir diese Punkte und Fragestellungen in den folgenden Blog Posts klären.
Commentaires