Video: Kubernetes: Eine Einführung (November 2024)
Die Unternehmens-Software-Landschaft ist mit lebhaften Technologien übersät. Wir haben über viele von ihnen geschrieben, sei es Blockchain, Low Code-Entwicklung oder andere aufkommende Trends, die unsere Arbeitsweise verändern. Ein neues Schlagwort, von dem Sie vielleicht noch nie gehört haben, ist "microservices".
Das ist so gewollt. Microservices sind eine andere Art, Software auf der Basis von miteinander verwobenen modularen Komponenten zu entwickeln, als die traditionelle Idee eines "Monolithen" - einer Anwendung, die aus einem immer größer werdenden Berg von Code besteht. Auf Microservices basierende Apps unterscheiden sich nicht von der Seite der Benutzeroberfläche (User Interface, UI), unabhängig davon, ob es sich um eine komplexe Rechenzentrums-App oder eine Web- oder Mobil-App handelt, die auf einer skalierbaren Cloud-Infrastruktur gehostet wird.
Der Grund, warum sich Unternehmen für Microservices interessieren sollten, ist, dass die Architektur im Hintergrund dazu beiträgt, dass Ihre Entwicklungs- und IT-Teams schneller arbeiten und innovieren, die Infrastruktur verwalten und die Kosten und die Komplexität beim Hinzufügen neuer Features und Funktionen zu einer App reduzieren. Al Hilwa, Programmdirektor für Anwendungsentwicklungssoftware-Forschung bei IDC, erklärte, wie er einem Manager Mikrodienstleistungen anbieten würde, wobei er sowohl die kulturellen als auch die technischen Herausforderungen im Blick hatte.
"Beim Aufbau neuer Systeme ist es wahrscheinlich entscheidend zu erkennen, dass ein einzelner Mikroservice von einem kleinen Team erstellt werden sollte", sagte Hilwa. "Zweitens ist eine Toleranz gegenüber Vielfalt in Programmiersprachen und Entwickler-Workflows oft mit der Unabhängigkeit einer gesamten Microservices-Kultur verbunden. Die Hauptaufgabe eines Exec besteht darin, Software schrittweise in kleinen Teams zu erstellen, wobei jedes Modul ein zusammenhängendes Modul mit einem veröffentlichten Modul bildet Der Vorteil ist, dass die unabhängigen Module viel schneller entwickelt werden können, solange die veröffentlichten APIs auf organisierte Weise verwaltet werden."
Was sind eigentlich Microservices?
Hilwa verfasste 2015 einen IDC-Bericht mit dem Titel "Die Entstehung von Mikrodiensten als neuer architektonischer Ansatz für die Entwicklung neuer Softwaresysteme". In dem Bericht definiert er Microservices als eine granulare Softwarearchitektur, in der App-Komponenten unabhängig voneinander entworfen und weiterentwickelt werden, um API-definierte Interoperabilitätsanforderungen zu erfüllen (dh in die App als Ganzes eingebunden). Microservices existieren jedoch nicht im luftleeren Raum. Eine neue Architektur erfordert eine starke organisatorische Unterstützung und eine Veränderung der IT-Kultur.
Microservices werden auch nicht von einer bestimmten Technologie definiert, sondern als Weiterentwicklung des langjährigen Konzepts der serviceorientierten Architektur (SOA), ergänzt durch die Einführung von Containern und die zunehmende Automatisierung durch Entwicklungsansätze wie Continuous Delivery (CD) und Continuous Integration (CI).
"Unternehmen, die heute Microservices einsetzen, sind in der Regel von dem Wunsch nach einer schnelleren Service-Entwicklung motiviert", sagte Hilwa. "In den meisten Fällen setzen Microservices daher die CI / CD-Automatisierung in hohem Maße ein. Allerdings kann die tatsächliche Bereitstellungsgeschwindigkeit zwischen den Diensten unterschiedlich sein. Ich denke, der Schlüssel liegt darin, einen guten Blick auf die interne Kultur zu werfen und zu sein." sicher, dass Sie bereit sind, eine größere Dezentralisierung und Vielfalt im Technologiestapel zu tolerieren."
Unter "interner Kultur" versteht Hilwa vor allem DevOps, eine Philosophie, die Softwareentwicklung, IT-Betrieb und Qualitätssicherung (QS) in einem einzigen, kollaborativen Workflow vereint. Das DevOps-Software-Startup HashiCorp und seine Gründer sind seit langem Befürworter von Microservices. Unternehmen wie Cisco, DigitalOcean, Mozilla und Stripe zählen zu den Open-Source-Anwendern und Unternehmenskunden des Unternehmens.
Microservices bilden den Kern dafür, wie HashiCorp die Entwicklung der DevOps-Infrastruktur und App-Workflows über seine beliebten Open-Source-Tools und die wachsende Enterprise-Produktsuite hinweg angeht. Armon Dadgar, CTO und Mitbegründer von HashiCorp, hat den Unterschied zwischen Monolithen und Microservices mithilfe einer einfachen Analogie aufgehoben: Amazon und eBay.
"Betrachten Sie Amazon und eBay als einzelne Anwendungen. Aus Sicht der Endbenutzer sehen sie ähnlich aus, aber hinter den Kulissen verfolgten die Unternehmen unterschiedliche Ansätze bei der Erstellung und Architektur ihrer Anwendungen", sagte Dadgar. "Amazon war von Anfang an ein Bündel von Microservices. Es fungiert als eine einzige App. Wenn Sie jedoch die Suche, den Produktkatalog, den Warenkorb, die Rechnungen und die Bestellabläufe durchführen und diese Funktionen aufteilen, werden die beiden Anwendungen auf unterschiedlichen Plattformen ausgeführt Maschinen."
Die Amazon-Analogie erstreckt sich auch auf die Struktur von Amazon. Dadgar erklärt Technologieansätze wie Microservices als Werkzeuge zur Unterstützung der größeren Prozessbewegung in Richtung DevOps. Jeff Bezos '"Two Pizza Rule" funktioniert so, dass nur zwischen fünf und acht Personen in einem bestimmten Amazon-Team sind. Wenn das Team größer wird, wird es in zwei Teile geteilt.
Die Organisationshierarchie von Amazon beginnt sich dem zuzuordnen, was Dadgar als "Zerlegung der Funktionalität" bezeichnet. Jedes Team ist sowohl auf organisatorischer als auch auf modularer Architekturebene getrennt und kann sich dann freier entwickeln und experimentieren, ohne dass jede Änderung koordiniert werden muss. Dies funktioniert jedoch immer noch als Teil einer einzigen zusammenhängenden App.
"eBay verfolgte einen monolithischen Ansatz. eBay wurde vollständig als lange Code-Anwendung mit 50 Millionen Zeilen aufgebaut", sagte Dadgar. "Der Ansatz von Microservices ist anfangs schmerzhafter, weil die Probleme der Modularität und Interoperabilität nicht in einem Monolithen existieren. Aber die Dinge brechen zusammen, wenn die App zu groß wird. In einem Monolithen gibt es keine Zersetzung.
"Denken Sie an Hunderte oder Tausende von Entwicklern, die an einer einzigen Codebasis zusammenarbeiten und versuchen zu koordinieren. Ein QA-Team, das Funktionen auf einer Seite der Anwendung hinzufügt, könnte auf der anderen Seite zu einem Umbruch führen, da es keine klare Trennung von Rollen und Verantwortlichkeiten gibt Man braucht immer mehr Koordination zwischen den Projektmanagern und einen Qualitätssicherungsprozess, der Wochen dauern kann und die Entwicklung von Engpässen erfordert, egal wie schnell das Team arbeitet. Es sind zu viele Köche in der Küche."
Container und Microservices in einer DevOps-Welt
Die Art und Weise, wie Ihr Unternehmen eine Microservices-Architektur implementiert, entscheidet maßgeblich darüber, ob sich die Investition auszahlt oder nicht. Microservices sind im Vorfeld eine Menge Arbeit, insbesondere bei der API-Integration, die erforderlich ist, um sicherzustellen, dass alle Services miteinander kommunizieren. Hilwa erklärte, dass es noch komplizierter sei, Mikrodienste in ein bestehendes System zu integrieren. Er empfiehlt Unternehmen, nach Möglichkeit neue Systeme zu erstellen, anstatt eine ältere Monolith-App für Microservices neu zu erstellen.
"Traditionelle Systemarchitekturen umfassen normalerweise große, komplexe Datenbanksysteme mit ausgefeilten normalisierten Schemata", so Hilwa. "Das Zerlegen solcher Systeme in kleinere Komponenten mit ihren eigenen unabhängigen Systemen erfordert viel Datenbank-Design-Arbeit und das effektive Umschreiben des größten Teils der Kernanwendungslogik. Dies ist in den meisten Fällen kosten- und zeitintensiv."
Wenn Sie eine Legacy-App neu erstellen, empfiehlt Hilwa, diese schrittweise durchzuführen. Auch wenn Microservices wichtiger als die API-Integration sind, funktionieren sie ohne die dahinter stehende DevOps-Kultur nicht. Dadgar von HashiCorp sagte, dass Microservices in Bezug auf den größeren Dachkonzern von DevOps zu einem Werkzeug werden, um eine größere Prozessverschiebung hin zu einer grundlegenden Änderung der Workflows zu ermöglichen, mit denen wir Apps bereitstellen. Er wies auf das Tao von HashiCorp hin, das als er und Mitbegründer Mitchell Hashimoto das Unternehmen gründeten: einfach, modular und zusammensetzbar.
"DevOps ist in gewisser Hinsicht ein noch überladenerer Begriff als Microservices", sagte Dadgar. "Aber ein Unternehmen besteht aus Menschen mit unterschiedlichen Wissensspezialitäten: Entwicklern, Betreibern, Sicherheitsbeauftragten. Und dann haben Sie einen Prozess, wie Sie diese Menschen organisieren. Dann haben Sie die Werkzeuge, um diesen Prozess zu unterstützen, bei dem Mikrodienstleistungen und Container zum Einsatz kommen Komm herein."
Container, die durch die Open-Source-Explosion von Docker populär geworden sind, sind keineswegs das einzige Tool, mit dem Unternehmen Microservices ermöglichen können. Laut Hilwa von IDC werden Container in modernen Apps als Teil der CI / CD-Workflows und in einigen Fällen während der Bereitstellung in der Produktion verwendet. Aber er sagte, dass Microservices auch virtuelle Maschinen (VMs) nutzen können, ohne Container zu benötigen.
Im Hinblick auf die Entwicklung der Business Clouds sind Docker-Container und Microservices eine leistungsstarke Toolkombination, die von Unternehmen aller Größen und Formen - von Start-ups wie HashiCorp bis hin zu Unternehmensriesen wie Oracle - genutzt wird. Dadgar von HashiCorp sagte, Container seien die bequemen Mittel, mit denen Dev und Ops (und je nach Vereinigung auch verschiedene Teams und Dienste) miteinander kommunizieren.
"Was ist das Artefakt, das wir zwischen den Entwicklern und Betreibern austauschen? Was fließen wir durch und bauen es um uns herum? Container sind eine bequeme Einheit zum Austauschen", sagte Dadgar. "Denken Sie an ein globales Schifffahrtsprodukt für Unternehmen auf der ganzen Welt. Egal, ob es sich um ein Frachtschiff, einen Güterzug oder einen Lastwagen handelt, es fließt dieselbe Einheit durch das gesamte System."
DevOps und Microservices sind noch lange nicht weit verbreitet, aber der Markt wächst nur. Laut IDC-Bericht wird die Microservices-Architektur in den nächsten fünf Jahren in eine Reifephase eintreten. Diese Reife wird vor dem Hintergrund der DevOps-Kultur, die bis 2020 50 Prozent der Unternehmen erreicht, der ständigen Weiterentwicklung der Software-Automatisierungstools und der Dominanz billiger, skalierbarer Cloud-Infrastrukturen wie Amazon Web Services (AWS) und Microsoft Azure eintreten.
Dadgar sagte, dass HashiCorp trotz des geringen Anteils von Unternehmen, die derzeit DevOps und Microservices einsetzen, bereits stark überzeichnet ist. Der erste Umsatz im siebenstelligen Bereich wurde nach nur neun Monaten Unternehmensumsatz erzielt, zusätzlich zu einer Open-Source-Community auf GitHub mit mehreren Millionen monatlich aktiven Benutzern. Microservices sind nur ein Teil der Workflow-App-Tooling-Pipeline von HashiCorp und der größeren DevOps-Infrastruktur-Roadmap. Die Modularität und Interoperabilität, die das Unternehmen entwickelt, hat den rasanten Aufstieg eines der heißesten Software-Startups im Silicon Valley vorangetrieben.
"Als wir vor vier Jahren begannen, gingen wir zu Besprechungen und stellten unsere Vision für die Verwaltung der Infrastruktur auf", sagte Dadgar. "Wir wurden nicht gerade ausgelacht, wir wussten, dass es früh war. Aber jetzt sind unsere Werkzeuge wie Terraform auf dem Weg, Industriestandards zu werden. Was wir sehen werden, ist ein Dominoeffekt des Wettbewerbsdrucks und in der Langfristig wird unsere Rolle darin bestehen, mit CIOs und CTOs zusammenzuarbeiten, um zu verstehen, welche Prozessverschiebung erforderlich ist.
"Denken Sie früher an Toyota", fuhr Dadgar fort. "Sie hatten eine Menge Autohersteller, die Produkte bauten, aber die Kosten waren höher als sie sein sollten. Toyota hat das, was ein Auto ist, nicht neu erfunden. Sie haben den Prozess nur strenger und inkrementeller gemeistert und sind vom Gespött zum Kraftpaket übergegangen und haben das gezwungen." Der Rest der Branche muss dieselben Praktiken anwenden, um wettbewerbsfähig zu bleiben. Derzeit fragen sich Branchenführer, wie sie einen Wettbewerbsvorteil erzielen können, und ihre Antwort lautet, die Praktiken der Googles und Amazonen des Marktes zu übernehmen Punkt, es wird eine kritische Masse treffen."
