Architecting for Scale, 2. Auflage

Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Bei Architecting for Scale geht es um Modernisierung. Es geht darum, deine kritischen Anwendungen so zu entwickeln und zu aktualisieren, dass sie den Anforderungen deiner immer anspruchsvolleren digitalen Kunden gerecht werden. Es geht um Hochverfügbarkeit, es geht darum, deine Anwendungen mit modernen Entwicklungs- und Betriebstechniken zu gestalten, es geht darum, deine Entwicklungsteams so zu organisieren, dass deine Anwendungen - und dein Unternehmen - erfolgreich sind, es geht um die Skalierung für deine größten Tage, es geht um die Nutzung der Ressourcen, die dir in der Cloud zur Verfügung stehen, um diese Herausforderungen zu meistern.

Skalierbarkeit ist viel mehr als nur die Bewältigung eines großen Datenvolumens.

Wer sollte dieses Buch lesen?

Dieses Buch richtet sich an Architekten, Manager und Direktoren, die große Anwendungen und Systeme entwickeln und betreiben, sei es in einer technischen oder in einer betrieblichen Organisation. Wenn du Softwareentwickler, Systemzuverlässigkeitsingenieure oder Betriebsteams leitest oder eine Organisation mit großen Anwendungen und Systemen führst, werden dir die Vorschläge und Anleitungen in diesem Buch helfen, deine Anwendungen reibungsloser und zuverlässiger zu machen.

Wenn deine Anwendung klein angefangen hat und unglaublich gewachsen ist (und jetzt einige der mit diesem Wachstum verbundenen Wachstumsschmerzen erlebt), leidest du vielleicht unter einer geringeren Zuverlässigkeit und Verfügbarkeit. Wenn du mit dem Umgang mit technischen Schulden und den damit verbundenen Anwendungsfehlern kämpfst, bietet dir dieses Buch eine Anleitung, wie du diese technischen Schulden abbauen kannst, damit deine Anwendung leichter mit einem größeren Umfang zurechtkommt.

Warum ich dieses Buch geschrieben habe

Nachdem ich sieben Jahre bei Amazon gearbeitet hatte, wo ich hochskalierte Anwendungen sowohl für den Einzelhandel als auch für Amazon Web Services (AWS) entwickelt hatte, wechselte ich zu New Relic, einem Unternehmen, das sich inmitten eines Hyperwachstums befand. Das Unternehmen spürte, dass es die Systeme und Prozesse brauchte, um hochskalierte Anwendungen zu verwalten, aber es hatte die Prozesse und Disziplinen zur Skalierung seiner Anwendung noch nicht vollständig entwickelt.

Bei New Relic habe ich aus erster Hand erfahren, wie schwer es für ein Unternehmen ist, zu skalieren, und mir wurde klar, dass es viele andere Unternehmen gibt, die tagtäglich mit den gleichen Problemen zu kämpfen haben.

Jetzt reise ich durch die ganze Welt und spreche mit Kunden und Menschen wie dir über die Cloud, über Skalierung, über Verfügbarkeit und über den kritischen Prozess der Entwicklung moderner Anwendungen. Ich halte Vorträge, Podiumsdiskussionen, Kurse und Seminare. Ich führe Einzelgespräche mit technischen Leitern und Führungskräften, um ihnen zu helfen, ihre Ziele zu erreichen und von ihnen zu lernen, was funktioniert und was nicht. Ich schreibe Artikel. Ich gebe Interviews. Ich nehme an Podcasts teil.

Mit diesem Buch möchte ich anderen, die mit wachstumsstarken Anwendungen arbeiten, helfen, Prozesse und bewährte Methoden zu erlernen, die ihnen dabei helfen, die Fallstricke zu vermeiden, die sie bei der Skalierung erwarten.

Egal, ob deine Anwendung jedes Jahr um das Zehnfache oder nur um 10 % wächst, und egal, ob die Anzahl der Nutzer, die Anzahl der Transaktionen, die Menge der gespeicherten Daten oder die Komplexität des Codes zunimmt, dieses Buch kann dir helfen, deine Anwendung so zu entwickeln und zu warten, dass sie dieses Wachstum bewältigen kann und gleichzeitig ein hohes Maß an Verfügbarkeit aufrechterhält.

Ein Wort zum Maßstab heute

Wenn die Anwendungen wachsen, passieren zwei Dinge: Sie werden deutlich komplizierter und sie bewältigen ein deutlich größeres Datenvolumen.

Mehr Komplexität bedeutet mehr Brüchigkeit. Mehr Verkehr bedeutet mehr neuartige und komplexe Mechanismen zur Verwaltung des Verkehrs.

Anwendungsentwickler bauen selten von Anfang an Skalierbarkeit in ihre Anwendungen ein. Wir denken oft, dass wir die Skalierbarkeit eingebaut haben und glauben, dass wir alles Notwendige getan haben, um unsere Anwendung so hoch wie möglich skalieren zu können. Aber meistens finden wir Fehler in unserer Logik und in unseren Anwendungen. Diese Fehler tauchen erst auf, wenn wir anfangen, Skalierungsprobleme zu erkennen, und das erschwert die Skalierung auf größere Datenmengen und größere Datensätze.

Das führt zu noch mehr Komplexität und noch mehr Sprödigkeit.

Letztendlich wird dieser Kreislauf aus Größe, Brüchigkeit, Größe und Komplexität zu einer Todesspirale für eine Anwendung, in der es zu Stromausfällen, Blackouts und anderen Problemen mit der Servicequalität und Verfügbarkeit kommt.

Aber das sind deine Probleme. Deine Kunden interessieren sich nicht für diese Probleme. Sie wollen einfach nur, dass deine Anwendung die Arbeit erledigt, die sie von ihr erwarten. Wenn deine Anwendung nicht funktioniert, langsam oder inkonsistent ist, werden deine Kunden sie einfach aufgeben und sich nach Konkurrenten umsehen, die ihr Geschäft erledigen können.

Wie können wir die Skalierbarkeit unserer Anwendungen verbessern, selbst wenn wir an diese Grenzen stoßen? Es liegt auf der Hand: Je früher wir die Skalierbarkeit im Lebenszyklus einer Anwendung berücksichtigen, desto einfacher ist sie zu skalieren. Dennoch wollen wir unsere Anwendungen nicht über das erforderliche Maß hinaus skalierbar gestalten. Zu jedem Zeitpunkt des Lebenszyklus gibt es viele Techniken, mit denen du die Skalierbarkeit deiner Anwendung verbessern kannst.

Aber bevor du über Techniken zur Skalierung deiner Anwendung nachdenken kannst, musst du deine Anwendungsverfügbarkeit in Form bringen. Nichts anderes ist wichtig, bis du diesen Sprung machst und diese Verbesserungen durchführst. Wenn du diese Änderungen nicht von Anfang an vornimmst, wirst du feststellen, dass du bei der Skalierung deiner Anwendung den Überblick verlierst und zufällige, unerwartete Probleme auftauchen. Diese Probleme führen zu Ausfällen und Datenverlusten und beeinträchtigen deine Fähigkeit, deine Anwendung weiterzuentwickeln und zu verbessern, erheblich. Und wenn der Datenverkehr und die Datenmenge zunehmen, werden diese Probleme noch schlimmer. Bevor du etwas unternimmst, solltest du dein Verfügbarkeits- und Risikomanagement in Ordnung bringen.

Was ist neu in der zweiten Ausgabe?

Während viele der in diesem Buch besprochenen Konzepte größtenteils zeitlos sind, mussten viele (wie z.B. Serverless Computing) aktualisiert werden, um den Veränderungen der Branche in den letzten vier Jahren Rechnung zu tragen.

Außerdem habe ich die letzten Jahre damit verbracht, um die Welt zu reisen und über diese Themen zu sprechen. Ich habe viel aus den Gesprächen mit Kunden und anderen Experten gelernt und vieles von dem, was ich gelernt habe, in diese Ausgabe einfließen lassen.

Außerdem wurde das Buch um ein umfangreiches Update zur Cloud-Nutzung ergänzt.

Schließlich wurde der Inhalt gegenüber der ersten Ausgabe erheblich umstrukturiert und neu geordnet, um die Informationen leichter zugänglich und relevanter zu machen.

Die Nutzung der Cloud

Cloud-basierte Dienste wachsen und expandieren mit extrem hoher Geschwindigkeit. Software as a Service (SaaS) wird zur Norm für die Anwendungsentwicklung, vor allem wegen der Notwendigkeit, diese cloudbasierten Dienste bereitzustellen. SaaS-Anwendungen sind besonders anfällig für Skalierungsprobleme, da sie mandantenfähig sind.

Da sich unsere Welt verändert und wir uns mehr und mehr auf SaaS-Dienste, Cloud-basierte Dienste und hochvolumige Anwendungen konzentrieren, wird die Skalierung immer wichtiger. Ein Ende der Größe und Komplexität, auf die unsere Cloud-Anwendungen anwachsen können, scheint nicht in Sicht zu sein.

Die Mechanismen, die heute zum Stand der Technik gehören, um die Skalierung zu bewältigen, werden morgen nicht mehr als einfache Mieter sein, und die Lösungen für die Skalierungsprobleme von morgen werden die heutigen Lösungen einfach und minimalistisch aussehen lassen. Unsere Branche wird immer komplexere Systeme und Architekturen benötigen, um die Größe von morgen zu bewältigen.

Im Laufe der Zeit werden einige Inhalte in diesem Buch natürlich veraltet sein. Mein Ziel ist es, so viele Inhalte wie möglich zu vermitteln, die den Test der Zeit überstehen.

Dienstleistungen versus Microservices

In der Branche gibt es viele Kontroversen über die Verwendung der Begriffe Service und Microservice. Ich persönlich mag den Begriff Microservice nicht, weil er eine bestimmte Größe eines Dienstes impliziert, was nicht unbedingt eine gesunde Annahme ist. Viele Dienste sind klein, und einige sind wirklich "micro", aber viele sind auch viel größer. Die Bestimmung der geeigneten Größe hängt vom Kontext ab und unterliegt vielen Bedenken und Kriterien,¹ Meiner Meinung nach verzerrt die Verwendung des Begriffs "Microservices" diese Diskussion. Ich bin mir jedoch bewusst, dass der Begriff "Microservice " in der Branche stark an Popularität gewonnen hat.

Es gibt auch Leute, die den Begriff " Service" als Teil des Begriffs " SOA" verwenden und diese Begriffe weiter einordnen, um sich auf eine bestimmte Art von Architektur zu beziehen, die vor einem Jahrzehnt oder mehr beliebt war. Ich finde diese Vergleiche ungenau und verwirrend.

Ich persönlich bevorzuge den Begriff Service, aber ich weiß, dass viele Leute den Begriff Microservice verwenden. Deshalb verwende ich in meinen Gesprächen mit anderen Unternehmen je nach Kontext beide Begriffe. Meiner Meinung nach bedeuten beide Begriffe genau das Gleiche.

Es gibt aber noch eine andere Verwendung des Wortes Service, die es wert ist, diskutiert zu werden. Das ist, wenn du dich auf einen externen Dienst beziehst, z. B. wenn du sagst: "Amazon bietet den Amazon S3 Service an." Diese Verwendung des Wortes " Service" scheint sich von der anderen zu unterscheiden, aber in Wirklichkeit ist es das Gleiche. Ein "Dienst" ist ein Softwaremodul, das eine ganz bestimmte Funktion und die Daten, die diese Funktion unterstützen, bereitstellt. Ob der Dienst von deinen Entwicklern oder von den Ingenieuren bei Amazon geschrieben wird, ist irrelevant. Ich weiß jedoch, dass es manchmal wichtig ist, zwischen diesen beiden Arten von Diensten zu unterscheiden.

Deshalb werde ich diese Begriffe in diesem Buch folgendermaßen verwenden. Je nach Kontext werde ich beide Begriffe synonym verwenden. Du wirst sehen, dass ich in diesem Buch eher das Wort Service verwende. Du solltest davon ausgehen, dass beide Begriffe genau das Gleiche bedeuten. Wenn ich mich auf eine bestimmte Art von Dienstleistung beziehe, die von einem anderen Unternehmen erbracht wird, z. B. einen Cloud-Service, werde ich dies angeben. In diesen Fällen wirst du Begriffe wie "AWS-Service", "Cloud-Service" oder "SaaS-Service" verwenden.

Moderne digitale Kundenerlebnisse

In unserer modernen digitalen Welt sind Softwareanwendungen das Gesicht unserer Marke und unseres Unternehmens. Die Art und Weise, wie unsere Kunden mit uns interagieren, geschieht über unsere Software. Unsere Anwendungen sind nicht nur ein Teil des Kundenerlebnisses. In vielen Fällen sind sie sogar das gesamte Kundenerlebnis. Software ist entscheidend für unseren Erfolg, und moderne Kunden erwarten, dass auch unsere Anwendungen modern sind. Wie unsere Kunden unsere Marken und unser Unternehmen wahrnehmen, hängt stark davon ab, wie sie unsere Software wahrnehmen.

Eine nicht-moderne Anwendung

Ein Beispiel: Mein Sohn hat eine Anwendung auf seinem Smartphone, die er benutzen muss, um einige seiner medizinischen Leistungen zu erhalten. Es ist eine staatliche Anwendung, die von der US-Regierung entwickelt und betrieben wird.

Diese Anwendung funktioniert nicht immer. Wenn du die Anwendung zu einer ungeraden Tageszeit startest, erhältst du eine Fehlermeldung. Die Fehlermeldung lautet: "Diese Anwendung kann nur zwischen 9 und 17 Uhr, Montag bis Freitag, östlicher Zeit, genutzt werden.

Ja, das ist richtig. Es handelt sich um eine mobile Softwareanwendung auf seinem Smartphone, die außer während der Geschäftszeiten an der Ostküste deaktiviert ist.

Kann dein Unternehmen mit einer Anwendung wie dieser arbeiten? Kann es mit dieser Art von Nutzungsbeschränkung arbeiten? Kann jedes kommerzielle Unternehmen seinen Kunden solche Beschränkungen auferlegen und im Geschäft bleiben?

Nein, ich wette, es gibt kein einziges kommerzielles Unternehmen da draußen, das überleben kann und seine Kunden auf diese Weise behandelt. Stattdessen müssen wir unseren Kunden unvergessliche Kundenerlebnisse bieten. Unsere Anwendungen müssen immer dann funktionieren, wenn unsere Kunden sie nutzen wollen. Alles muss zu 100% funktionieren, 24 Stunden am Tag, 7 Tage die Woche. Wenn nicht, enttäuschen wir unsere Kunden, und enttäuschte Kunden gehen weg.

Navigieren in diesem Buch

Bei der Skalierung geht es nicht nur um die Verwaltung des Verkehrsvolumens, sondern auch um das Management von Risiken und Verfügbarkeit. Oft sind all diese Dinge verschiedene Arten, das gleiche Problem zu beschreiben, und sie gehen alle Hand in Hand. Daher müssen wir, wenn wir über Skalierung sprechen wollen, auch Verfügbarkeit, Risikomanagement, Team- und Organisationsprozesse sowie moderne Architekturparadigmen wie Microservices und Cloud Computing berücksichtigen.

Deshalb ist dieses Buch in fünf große Teile gegliedert, die jeweils einen wichtigen Grundsatz der skalierbaren Architektur darstellen. Werfen wir einen Blick auf jeden dieser Teile.

Grundsatz 1. Verfügbarkeit: Die Aufrechterhaltung der Verfügbarkeit in modernen Anwendungen

Moderne Software muss ein hohes Maß an Verfügbarkeit aufweisen. Kunden werden keine Ausfälle tolerieren. Wenn deine Anwendung nicht funktioniert, wenn dein Kunde sie braucht, wird er nicht lange ein Kunde bleiben.

In Teil I wird die Bedeutung der Anwendungsverfügbarkeit für unsere Kunden erörtert und wie sie durch die Skalierung von Anwendungen beeinflusst wird. In diesen Kapiteln geht es darum, die Verfügbarkeit zu verstehen, zu messen und zu verbessern.

Zu den Kapiteln in diesem Teil gehören:

• Kapitel 1, Verstehen, Messen und Verbessern deiner Verfügbarkeit

• Kapitel 2, Zwei Fehler hoch - Raum haben, um sich von Fehlern zu erholen

Grundsatz 2. Moderne Anwendungsarchitektur: Dienste nutzen

Moderne Software erfordert den Einsatz moderner Anwendungsarchitekturen. Moderne Anwendungsarchitekturen erfordern eine Abkehr von monolithischen Anwendungen und eine Umstellung auf servicebasierte Architekturen.

Monolithische Anwendungen sind extrem schwer zu skalieren, sowohl was die Skalierung des Datenverkehrs als auch was die Fähigkeit angeht, die Größe der Organisation zu skalieren, die an der Anwendung arbeitet. Je größer der Monolith ist, desto langsamer lassen sich Änderungen an der Anwendung vornehmen, desto weniger Personen können daran arbeiten und sie effektiv verwalten, und desto größer ist die Wahrscheinlichkeit, dass Verkehrsschwankungen und Wachstum die Verfügbarkeit negativ beeinflussen.

Serviceorientierte Architekturen lösen diese Probleme, indem sie eine größere Flexibilität bei der Skalierung je nach Verkehrsaufkommen bieten. Darüber hinaus bieten sie einen skalierbaren Rahmen, der es größeren Entwicklungsorganisationen ermöglicht, an der Anwendung zu arbeiten, so dass die Anwendungen selbst größer und komplexer werden können.

Zu den Kapiteln in Teil II gehören:

• Kapitel 3, Dienste nutzen

• Kapitel 4, Dienste und Daten

• Kapitel 5, Umgang mit Dienstausfällen

Grundsatz 3. Organisation: Skalierung deiner Organisation für moderne Anwendungen

Du kannst keine moderne Software entwickeln, wenn deine Entwicklungsorganisation keine modernen Prozesse und Verfahren anwendet. Dazu gehören die Verantwortlichkeiten für den Service und die Entwicklungsprozesse.

Es spielt keine Rolle, wie skalierbar deine Anwendung ist. Du kannst deine Anwendung nicht skalieren, wenn deine Entwicklungsorganisation nicht so strukturiert ist, dass sie das unterstützt, oder wenn deine Organisation nicht die richtige Kultur hat, um höhere Verfügbarkeit und größere Skalierbarkeit zu fördern.

Wenn du deine Teams so organisierst, dass sie die Anforderungen an die Skalierbarkeit besser erfüllen, entsteht eine Kultur, die die Skalierungsanforderungen deiner Anwendung unterstützt.

Zu den Kapiteln in Teil III gehören:

• Kapitel 6, Dienstleistungseigentum - STOSA

• Kapitel 7, Dienstleistungsebenen

• Kapitel 8, Dienstleistungsvereinbarungen

Lehrsatz 4. Risiko: Risikomanagement für moderne Anwendungen

Du kannst nicht alle Risiken aus einem System entfernen. Das ist einfach nicht möglich. Alle komplexen Systeme haben ein inhärentes Risiko. Stattdessen müssen wir lernen, mit dem Risiko umzugehen und es als Werkzeug zu nutzen, um die technischen Schulden zu bewerten und Entscheidungen über Anwendungsverbesserungen zu treffen.

Risikoverständnis, Risikomessung und Priorisierung von Aktivitäten auf der Grundlage des gemessenen Risikos sind wichtige Instrumente für den Aufbau hochskalierter, hochverfügbarer Anwendungen.

Zu den Kapiteln in Teil IV gehören:

• Kapitel 9, Risikomanagement bei skalierter Architektur

• Kapitel 10, Spieltage

• Kapitel 11, Bausysteme mit reduziertem Risiko

Grundsatz 5. Die Cloud: Die Nutzung der Cloud

Hohe Verfügbarkeit in einer modernen Anwendung erfordert eine flexible Skalierung. Wir können es uns nicht mehr leisten, überschüssige Infrastrukturkapazitäten zu haben, um den Spitzenbedarf unserer Anwendung zu decken. Stattdessen müssen wir Infrastrukturressourcen dynamisch zuweisen und nach Bedarf nutzen, je nach aktuellem Bedarf.

Dynamische Infrastrukturen und Anwendungen, die dynamische Infrastrukturen unterstützen und optimieren können, sind eine entscheidende architektonische Komponente für den Aufbau hochskalierter, hochverfügbarer Anwendungen.

Dynamische Infrastrukturen sind der wichtigste Vorteil der öffentlichen Cloud. Die Nutzung der Public Cloud ist wichtig, damit deine Anwendung in großem Umfang hochverfügbar bleibt.

Zu den Kapiteln in Teil V gehören:

• Kapitel 12, Erste Schritte Skalierbare Architektur in der Cloud

• Kapitel 13, Fünf Branchentrends, die durch die Cloud verändert wurden

• Kapitel 14, Arten von SaaS und Tenancy

• Kapitel 15, Verteilen deiner Anwendung in der AWS Cloud

• Kapitel 16, Verwaltete Infrastruktur

• Kapitel 17, Zuweisung von Cloud-Ressourcen

• Kapitel 18, Serverless und Funktionen als Service

• Kapitel 19, Edge Computing

• Kapitel 20, Geografische Auswirkungen auf die Nutzung der Cloud

Dies sind die fünf entscheidenden Grundsätze für die Entwicklung von Anwendungen, die den modernen Anforderungen unserer Kunden entsprechen. Diese Grundsätze bilden die Basis von Architecting for Scale.

Online-Ressourcen

Die Website Architecting for Scale(www.architectingforscale.com) bietet zusätzliche Informationen zu diesem Buch, einschließlich Links zu ergänzendem Material. Weitere Informationen über mich findest du auf meiner Website www.leeatchison.com, und du kannst auch meinem Blog unter www.leeatscale.com folgen .

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Tipp

Dieses Element steht für einen Tipp oder eine Anregung.

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

O'Reilly Online Learning

Hinweis

Seit mehr als 40 Jahren bietet O'Reilly Media Schulungen, Wissen und Einblicke in Technologie und Wirtschaft, um Unternehmen zum Erfolg zu verhelfen.

Unser einzigartiges Netzwerk von Experten und Innovatoren teilt sein Wissen und seine Erfahrung durch Bücher, Artikel, Konferenzen und unsere Online-Lernplattform. Die Online-Lernplattform von O'Reilly bietet dir On-Demand-Zugang zu Live-Trainingskursen, ausführlichen Lernpfaden, interaktiven Programmierumgebungen und einer umfangreichen Text- und Videosammlung von O'Reilly und über 200 anderen Verlagen. Weitere Informationen findest du unter http://oreilly.com.

Wie du uns kontaktierst

Bitte richte Kommentare und Fragen zu diesem Buch an den Verlag:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Nord
• Sebastopol, CA 95472
• 800-998-9938 (in den Vereinigten Staaten oder Kanada)
• 707-829-0515 (international oder lokal)
• 707-829-0104 (Fax)

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter https://oreil.ly/architecting-for-scale-2e aufrufen .

Schreib eine E-Mail an [e-mail], um Kommentare oder technische Fragen zu diesem Buch zu stellen.

Weitere Informationen zu unseren Büchern, Kursen, Konferenzen und Neuigkeiten findest du auf unserer Website unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

Folge uns auf Twitter: http://twitter.com/oreillymedia

Schau uns auf YouTube: http://www.youtube.com/oreillymedia

Danksagungen

Es gibt zwar mehr Menschen, die mir geholfen haben, dieses Buch zu schreiben, als ich hier jemals aufzählen könnte, aber ich möchte dennoch einige Personen erwähnen, die mir besonders geholfen haben:

• Ken Gavranovic, das Wort Freund ist nicht ausreichend, um dich zu beschreiben. Vertraue immer auf die Macht der Affen.

• Bjorn Freeman-Benson, der mich in der Anfangsphase der Entwicklung der ersten Ausgabe dieses Buches maßgeblich unterstützt hat und der mir bei New Relic Möglichkeiten eröffnete, die mir halfen, die Erkenntnisse zu gewinnen, die ich für dieses Buch brauchte. Ich bin so froh, dass unsere Freundschaft über die Tage hinaus anhält, an denen wir direkt zusammengearbeitet haben.

• Kevin McGuire, der mir ein Freund und Vertrauter war. Wir haben gemeinsam bei New Relic angefangen, und es war dein Weitblick und deine Vorstellungskraft, die meiner Karriere den nötigen Fokus und die Richtung gegeben haben, die mich heute leitet.

• Abner Germanow, Darren Cunningham, Jay Fry, Bharath Gowda und Robson Grieve, die mir eine Chance gegeben und dafür gekämpft haben, dass ich meine Rolle als Vordenker bei New Relic bekomme. Die Zeit, in der ich mit euch allen zusammengearbeitet habe, war mit Abstand die spaßigste, lohnendste und persönlich erfüllendste Zeit, die ich je erlebt habe. Ich vermisse diese Zeit sehr. Vor allem Abner, ohne dich hätte ich nicht die Karriere, die ich heute habe. Du hast mich in diese neue Rolle hineingeführt und mir geholfen, von einem Ingenieur und Architekten zu einem Strategen, Experten und Vordenker zu werden. Danke, dass du an mich geglaubt und mich auf diesem Weg begleitet hast.

• Jim Gochee, der mich in die Magie von New Relic einführte, sowohl als Produkt als auch als Karriere.

• Lew Cirne, dessen Vision uns New Relic und mir eine Karriere und ein Zuhause gegeben hat. Die Freude und der Enthusiasmus, die man nach einem persönlichen Treffen mit Lew empfindet, sind ansteckend und sehr motivierend. Kein Wunder, dass New Relic so erfolgreich ist.

• Kevin Downs, mein Freund und Wolkenkumpel. Grüß die Maus von mir. Ach ja, und übrigens: Container sind die Regel.

• Brandon SanGiovanni, mein Freund. Von MLB über Marvel bis hin zu Mickey - du hast viele der Herausforderungen, die ich in diesem Buch bespreche, aus erster Hand erfahren und du lebst noch und lächelst! Ich danke dir für deine Unterstützung, dein Wissen und vor allem für deine Freundschaft.

• Abbas Haider Ali, den ich sehr schätze. Wir sind beide Vordenker in der Branche, und es ist toll, jemanden zu haben, an dem man seine Ideen abprallen lassen kann und von dem man Vorschläge bekommt. Dein Beitrag zu den ersten Entwürfen dieses Buches hat es wesentlich besser gemacht. Ich danke euch!

• Kurt Kufeld, der mir als Mentor zur Seite stand und mir geholfen hat, mich in die seltsame, chaotische, herausfordernde, anstrengende und letztendlich sehr lohnende Welt namens Amazon einzufügen.

• Greg Hart, Scott Green, Patrick Franklin, Suresh Kumar, Colin Bodell und Andy Jassy, die mir Möglichkeiten bei Amazon und AWS eröffnet haben, die ich mir nie hätte vorstellen können.

• Brian Anderson, mein ursprünglicher Redakteur, und Kathleen Carr, meine derzeitige Redakteurin bei O'Reilly. Gemeinsam sind sie dafür verantwortlich, dass dieses Buch und viele andere Projekte bei O'Reilly Media zustande kommen. Brian hat die erste Ausgabe dieses Buches möglich gemacht. Kathleen hat mich dazu ermutigt und befähigt, die stark erweiterte zweite Auflage zu erstellen, zusammen mit mehreren Kursen, Schulungen und Wissensveranstaltungen.

• Amelia Blevins von O'Reilly, die wesentliche redaktionelle Vorschläge für das Format, das Layout und den Inhalt dieser erweiterten zweiten Auflage des Buches gemacht hat. Diese Vorschläge haben die Qualität und Lesbarkeit des Buches erheblich verbessert. Wenn dir die neue Struktur dieser zweiten Auflage gefällt, hast du das Amelia zu verdanken.

Allen, die mich nach der Lektüre der ersten Ausgabe dieses Buches mit Lob, Ermutigung und Vorschlägen angesprochen haben, danke ich dafür, dass sie mir geholfen haben, mich zu motivieren und mir Ideen für die Verbesserungen zu geben, die in diese zweite Ausgabe eingeflossen sind.

Meiner Familie und vor allem meiner Frau Beth, die mein ständiges Licht ist und mich durch unser gemeinsames Leben führt. Meine Tage sind heller, und mein Weg ist klarer, weil sie bei mir ist.

All diesen Menschen und allen anderen, die ich nicht erwähnt habe, möchte ich von Herzen danken.

Ich kann nicht enden, ohne auch die Felligen zu erwähnen: Issie, der schnarchende Spaniel, und Abbey, der fröhliche Corgi. Und schließlich Budha, das verrückte Kätzchen, das mehr als seinen Anteil an Tippfehlern zu diesem Buch beigetragen hat.

¹ In "Aufteilung in Dienste" gehe ich ausführlicher auf die Dimensionierung von Diensten ein .