Nur weil Google, Amazon oder Facebook laufen, wie sie laufen, heißt das noch lange nicht, dass Sie es auch tun sollten. Hier sind vier "Best Practices" jener Hyperskalierer, die Sie gerne ignorieren dürfen. [...]
Vor Jahren kämpfte Google mit dem Pitching seiner Cloud-Angebote. Im Jahr 2017 schlug ich vor, dass das Unternehmen Mainstream-Unternehmen dabei unterstützen sollte, „wie Google zu laufen“, aber in einem Gespräch mit einem leitenden Google-Cloud-Produktmanager deutete er an, dass das Unternehmen diesen Ansatz scheut. Die Bedenken? Dass Mainstream-Unternehmen die Bedürfnisse von Google vielleicht nicht teilen oder dass Google sie vielleicht einfach nur einschüchtern würde.
Für die Normalsterblichen, die die IT in solchen Mainstream-Unternehmen betreiben (also: fast alle), haben Sie keine Angst. Es hat sich gezeigt, dass es viele Dinge gibt, die Google möglicherweise tut, die für Ihre eigenen IT-Bedürfnisse keinen Sinn machen.
Fragen Sie einfach Colm MacCárthaigh, AWS-Ingenieur und einer der Entwickler des Apache-HTTP-Servers, der nach „Beispielen für technische Dinge“ fragte, „die nicht für jeden Sinn machen, nur weil Amazon, Google, Microsoft oder Facebook sie tun“. Die Antworten – exzessive Verfügbarkeitsgarantien, Site Reliability Engineering, Microservices und Monorepos unter den Highlights – sind lehrreich.
Exzessive Verfügbarkeitsgarantien
„Fünf oder fünf-plus Neuner Verfügbarkeitsgarantien“, sagt Pete Ehlke. „Abgesehen von der Gesundheitsversorgung und den Notrufzentralen fällt mir nichts ein, was sich nicht in der FAANG-Skala [Facebook, Amazon, Apple, Netflix und Google] bewegen würde und tatsächlich fünf Neuner benötigt. Und der ROI funktioniert so gut wie nie“.
Ich erinnere mich noch gut an diesen Fall aus der Vielzahl der Startups, für die ich gearbeitet habe, sowie aus meiner Zeit bei Adobe (deren Service-Level-Zusagen in der Regel nicht bei fünf Neunern liegen, sondern wohl höher als nötig sind). Kommen Sie zurecht, wenn das Multiplayer-Spiel scheitert? Ja. Wie sieht es mit Office 365 für ein paar Minuten oder sogar Stunden aus? Ja und ja.
Site Reliability Engineering
SRE (das in mehreren Antworten an MacCárthaigh so genannt wurde) wurde 2003 von Google gegründet, um dem Ingenieurwesen einen operativen Schwerpunkt zu geben. Einige wenige Kernprinzipien leiten SRE:
- Risiken annehmen
- Nutzung von Service-Level-Zielen (SLOs)
- Mühen beseitigen
- Überwachung verteilter Systeme
- Automatisierung nutzen und Einfachheit fördern
Oder, wie Ben Traynor, der die SRE-Praxis von Google entwickelt hat, es beschreibt:
SRE ist im Grunde genommen eine Arbeitsweise, die in der Vergangenheit von einem Betriebsteam ausgeführt wurde. Dabei werden jedoch Ingenieure mit Software-Know-how eingesetzt, und es wird davon ausgegangen, dass diese Ingenieure sowohl prädisponiert sind als auch die Fähigkeit haben, menschliche Arbeit durch Automatisierung zu ersetzen. Im Allgemeinen ist ein SRE-Team für Verfügbarkeit, Latenzzeit, Leistung, Effizienz, Änderungsmanagement, Überwachung, Notfallreaktion und Kapazitätsplanung verantwortlich.
SRE-Teams verbringen einen großen Teil ihrer Zeit mit der Automatisierung, wobei das letztendliche Ziel darin besteht, ihre Arbeit zu automatisieren. Sie verbringen viel Zeit mit dem „Betrieb/Bereitschaftsdienst und der Entwicklung von Systemen und Software, die zur Erhöhung der Zuverlässigkeit und Leistung des Standorts beitragen“, meint Silvia Pressard.
Das klingt wichtig, und dies umso mehr, wenn man „Zuverlässigkeit des Standorts“ mit „geschäftlicher Verfügbarkeit“ gleichsetzt. Aber müssen die meisten Unternehmen ihre Entwickler wirklich zu Betriebsexperten machen? SRE mag bei Google oder Amazon kritisch sein, aber für die meisten Unternehmen ist es wohl eine schwere Aufgabe, die Entwickler mit einer zu hohen operativen Belastung zu beauftragen, als dass sie diese erfolgreich bewältigen könnten.
Architektur für Microservices
Wie der Kommentator „Buzzy“ es sagt: „Definitiv Mikroservices. Die Zahl von insgesamt 20 Mitarbeitern, die ich von diesem Felsvorsprung herunterreden musste….“ Er ist auch nicht der Einzige, der Mikrodienstleistungen als eine unnötige Komplikation für die meisten Unternehmen bezeichnet. Viele der Antworten auf MacCárthaigh’s Tweet erwähnten Mikrodienstleistungen.
Martin Fowler argumentierte: „Obwohl [Mikrodienste] eine nützliche Architektur darstellen – viele, ja die meisten Situationen würden mit einem Monolithen besser funktionieren“. Moment mal, was? Sind Monolithen nicht ein böses Relikt aus der Vergangenheit? Natürlich ist das nicht so einfach. Wie ich bereits geschrieben habe,
Das große Versprechen von Mikrodienstleistungen ist Freiheit. Die Freiheit, eine Anwendung in verschiedene Dienste zu zerlegen, die unabhängig voneinander eingesetzt werden können. Die Freiheit, diese disparaten Dienste mit verschiedenen Teams unter Verwendung ihrer bevorzugten Programmiersprache, Tools, Datenbank usw. aufzubauen. Kurz gesagt, die Freiheit für Entwicklerteams, Dinge mit einem Minimum an Bürokratie zu erledigen.
Doch für viele Anwendungen ist diese Freiheit mit unnötigen Kosten verbunden, wie Fowler betont:
- Verbreitung: Verteilte Systeme sind schwieriger zu programmieren, da Remote-Aufrufe langsam sind und immer das Risiko eines Fehlschlags bergen.
- Letztendliche Einheitlichkeit: Die Aufrechterhaltung einer starken Konsistenz ist für ein verteiltes System extrem schwierig, was bedeutet, dass jeder mit der letztendlichen Konsistenz zurechtkommen muss.
- Betriebskomplexität: Sie brauchen ein ausgereiftes Betriebsteam, um viele Dienste zu verwalten, die regelmäßig umverteilt werden.
Dieser letzte Punkt wird von Sam Newman besonders hervorgehoben: „Für ein kleines Team kann eine Mikrodienst-Architektur schwer zu rechtfertigen sein, da allein für den Einsatz und die Verwaltung der Mikrodienste selbst Arbeit erforderlich ist.“
Das soll nicht heißen, dass ein Mikro-Dienstleistungsansatz immer falsch ist. Nein, es ist einfach ein Hinweis darauf, dass wir nicht zu einem komplizierteren (aber skalierbaren) Ansatz übergehen sollten, nur weil die Hyperskalierer ihn verwenden (im Allgemeinen, weil die Skalierung so kritisch ist).
Ein Monorepo sie zu knechten
Ob Mikrodienste oder Monolithen, Sie sollten Ihren Code wahrscheinlich nicht in einem „Monorepo“ speichern. Dies war eine gängige Antwort auf MacCárthaighs Bitte. Monorepos speichern den gesamten Code eines Unternehmens in einem einzigen Versionskontrollsystem (VCS), um die (vermeintlichen) Vorteile zu nutzen, die sich aus der Verringerung der Code-Duplizierung und der besseren Zusammenarbeit zwischen den Teams ergeben.
Das ist die Theorie.
Die Praxis sieht jedoch ganz anders aus. „Es wird schnell unvernünftig, wenn ein einzelner Entwickler das gesamte Repository auf seinem Rechner hat oder es mit Tools wie grep durchsucht“, so Matt Klein, ein Ingenieur, der einige der ausgeklügeltsten Systeme bei Amazon, Twitter und jetzt Lyft gebaut hat. „Wenn man bedenkt, dass ein Entwickler jeweils nur auf kleine Teile der Codebasis zugreift, gibt es dann einen wirklichen Unterschied zwischen dem Auschecken eines Teils des Baums über ein VCS oder dem Auschecken mehrerer Repositories? Es gibt keinen Unterschied.“
Klein fährt fort:
Was die Zusammenarbeit und die gemeinsame Nutzung von Code betrifft, so sind die Entwickler in der Größenordnung Unterabschnitten des Codes durch Tools höherer Ebenen ausgesetzt. Ob der Code in einem Monorepo oder Polyrepo vorliegt, ist irrelevant; das Problem, das gelöst wird, ist dasselbe, und die Wirksamkeit von Zusammenarbeit und Code-Sharing hat alles mit der Ingenieurskultur und nichts mit der Codespeicherung zu tun.
Seien Sie Sie selbst
Natürlich können einige Unternehmen von der Verfügbarkeit von Monorepos oder Five-Nines oder von Mikrodienstleistungen oder SRE profitieren. Sie könnten auch davon profitieren, ihre eigenen Rahmenbedingungen zu schaffen, ihre eigene Infrastruktur aufzubauen oder von den anderen Dingen, die von Kommentatoren über MacCárthaigh verhöhnt werden. Der Punkt ist, dass nur weil Google, Facebook, Amazon oder ein anderer Hyperskalierer es tut, heißt das noch lange nicht, dass man es auch tun sollte. Im Zweifelsfall sollte man zweifeln. Beginnen Sie mit den individuellen Bedürfnissen Ihres Unternehmens und finden Sie den richtigen Ansatz für die Erstellung und Verwaltung von Software, je nachdem, wer Sie sind und nicht, wer Sie gerne wären.
*Matt Asay schreibt unter anderem für InfoWorld.com.
Be the first to comment