Alle Artikel mit dem Schlagwort “cloud native

Kommentare 0

Warum Cloud Native Bewerbern die Zukunft gehört

Mein erster IT-Job bestand vor 21 Jahren darin Daten in eine Access97 Datenbank einzugeben. Diese habe ich dann normalisiert, in einen SQL Server 6.5 überführt und multi-user fähig gemacht. Lange ist es her. Danach habe ich Cisco Administration gelernt, Switching, Routing – Verkabelungen angebracht, von Token Ring auf (Fast-)Ethernet migriert. Damals gab es zudem im Zuge des Y2K Problem den Bedarf bestehenden Systeme zu migrieren, Windows NT 4.0 wurde ausgerollt, das Client-Server Paradigma setze sich durch. Später dann kamen die Erfahrungen mit Sun Server Systemen dazu. Und, natürlich das Aufkommen von den großen Storage Anbietern, NetApp für NFS, EMC für SAN, usw. Noch vor 5 Jahren habe ich ein Projekt zum Aufbau von 1.000qm Rechenzentrum geleitet. Privat habe ich bis 2003 (erster iMac) natürlich auch alle PCs selbst zusammengebaut, Mainboard, CPU, RAM, Festplatten – alles Einzelteile – eigenhändig montiert.

Kurzum, die Generation Hardware – zu der ich mich zähle, hat noch tiefegehende Erfahrung mit Hardware, Verkabelung, Konfiguration und Einrichtung von Systemen.

Im Zuge eines Bewerbungsgesprächs ist mir aufgefallen, dass gerade eine Genration heranwächst, die keinerlei Hardware Bezug mehr hat. Diese, ich nenne sie „Cloud Natives“, wachsen wie selbstverständlich mit privater Hardware auf, die entweder vor Power ihre Spezifikation versteckt (iPad, iPhones und Android Pendants) oder hinreichend Power besitzt, dass es irrelevant ist (PCs und Macs sind ja sozusagen Supercomputer). Bis auf Edge-Cases wie Hardcore Gamer, benötigt man keinen besonderen Rechner mehr. Gleiches gilt für deren berufliche Sozialisation, in den Universitäten und Fachhochschulen wird die Cloud Nutzung gepredigt und entsprechend nutzen sie Cloud Ressourcen oder APIs. Für sie fühlt sich das ganz natürlich an. Die Schere im Kopf, den man bei der Transition von der alten in die neue Welt oftmals noch hat, besitzen sie nicht. Sie sind es gewohnt Autoscaling zu nutzen, sie denken wie selbstverständlich in CI-/CD-Pipelines. Betriebssysteme werden auch nicht gepatched, nein, man baut ein neues Image und läßt dieses rollend in die Produktion aus.

In Summe führt das dazu, dass die Bewerber (die man heute auch sucht) sich nativ in beispielsweise AWS bewegen. Im Umkehrschluss, wenn man sie fragt, ob sie in der Lage sind, auch mal eine einfache statische Route zu setzen, sind sie ein wenig verschämt und sagen, dass sowas bislang nicht notwendig war. Wenn ein Loadbalancer gebraucht wird, dann nimmt man halt den Elastic Load Balancing Service.

Ich finde es unterm Strich spannend und beeindruckend zugleich, da ich glaube, dass diese Generation Probleme aus einer Ganzen anderen Ebene und Sichtweise heraus angeht. Sie sind es gewohnt Applikationen Stateless zu bauen. Speicher zum Beispiel ist unendlich da, daher kann auch von vornherein mit Big Data geplant werden.

Zum Schluss bleibt für die alte Schule, falls sie Angst hat unbedeutend zu werden, der Rettungsanker a la Cobol. Auch heute sind Cobol Spezialisten trotz End-of-Sale der Plattformen stark nachgefragt. Gleiches gilt in Zukunft wohl auch für gute Storage-Admins oder Network-Engineers.

Kommentare 0

Warum benötigt man ein Service Mesh bei einem Cloud Deployment

Im Cloudcast #298 wurde Linkerd vorgestellt. Linkerd (gesprochen linker-dee) ist ein Service Proxy, der dazu dient die Kommunikation zwischen lose gekoppelten System oder Microservices zu orchestrieren. Früher nannte man sowas manchmal auch ESB (Enterprise Service Bus).
Der Unterschied zu den ehemaligen SOA (Service Oriented Architecture) Ansätzen der Nuller Jahre, wo man in der Regeln versucht hat statische Systeme miteinander zu koppeln folgt der Ansatz des Service Mesh der Annahme moderner Cloud Paradigmen wonach die Services unstet sind. Das bedeutet sind sind in Teilen verfügbar, werde teilweise aufskaliert („Autoscale“), oder abgebaut bei weniger Last. Im Idealfall orchestriert sich das System selbst, sei es nun gesteuert durch entsprechende Container-Manager wir Kubernetes oder Docker Swarm oder durch andere Mechanismen.
Das Konzept eines Service Mesh dient nun dazu entsprechende Inter-Service-Requests zu gewährleisten und zu steuern.

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. (But there are variations to this idea, as we’ll see.)
The concept of the service mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled by an orchestrator like Kubernetes. Not only is service communication in this world incredibly complex, it’s a pervasive and fundamental part of runtime behavior. Managing it is vital to ensuring end-to-end performance and reliability.

Da setzt linkerd nun an. Aus ehemaligen twitter Produktleuten und hinreichend mit VC Kapital ausgestattet, ist es sicherlich kein komplett neues Konzept.

The service mesh is ultimately not an introduction of new functionality, but rather a shift in where functionality is located. Web applications have always had to manage the complexity of service communication. The origins of the service mesh model can be traced in the evolution of these applications over the past decade and a half.
Consider the typical architecture of a medium-sized web application in the 2000’s: the three-tiered app. In this model, application logic, web serving logic, and storage logic are each a separate layer. The communication between layers, while complex, is limited in scope—there are only two hops, after all. There is no “mesh”, but there is communication logic between hops, handled within the code of each layer.


Inter-Service Kommunikation, load-balancing, latency-assurance, all diese Features können durch ein Service Mesh unterstützt werden. Die Plugin Architektur von linkerd finde ich am reizvollsten, da hierdurch sogar einfache Protokollumsetzungen möglich sind.
linkerd ist seit neuem auch Teil der CNCF.