Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Als ich anfing, mich mit dem Thema Software-as-a-Service (SaaS) zu beschäftigen, erwartete ich, dass ich viele bewährte Methoden finden würde. Schließlich war SaaS ja kein neues Konzept. Es gab zahlreiche Beispiele für erfolgreiche SaaS-Unternehmen und es herrschte die allgemeine Meinung, dass sich SaaS bei vielen Unternehmen als bevorzugte Form der Bereitstellung etabliert. Für mich bedeutete das, dass ich hauptsächlich bestehende Muster und Strategien übernehmen und anwenden würde. Überraschenderweise war das nicht der Fall.

Je mehr ich mich in die Lösungen der Kunden vertiefte und die Branche nach Orientierungshilfen durchforstete, desto mehr wurde mir klar, wie wenig Klarheit es darüber gab, was es bedeutet, SaaS-Umgebungen zu entwickeln, aufzubauen und zu betreiben. Ich denke, dass dies zum Teil ein Nebenprodukt der natürlichen Unklarheit ist, die sich aus der Zuordnung einer Technologie zu einem bestimmten Begriff ergibt. Der Mangel an absoluten Werten hat viel Raum für konkurrierende Definitionen und Meinungen darüber geschaffen, wie SaaS aussehen soll. Dies hat dazu geführt, dass Unternehmen mit grundlegend unterschiedlichen Implementierungen und Ansätzen sich als SaaS bezeichnen können. Ich beobachte immer noch eine Reihe von Unternehmen, die sich auf den Weg zu SaaS machen und dabei völlig unterschiedliche Ansichten darüber haben, was es für sie bedeutet, ein SaaS-Bereitstellungsmodell zu nutzen.

Daran ist an sich nichts auszusetzen. Es ist in Ordnung, unterschiedliche Vorstellungen davon zu haben, was SaaS bedeutet. Das wird jedoch zu einem größeren Problem, wenn du mit Kunden arbeiten musst, die dich als SaaS-Experten erwarten. Als Experte kannst du deinen Kunden nicht einfach sagen, dass sie bauen können, was sie wollen. Vagheit ist nicht gut für Teams, die sich darauf verlassen, dass du ihnen bewährte Methoden, Strategien und Muster zeigst. Um meinen Job zu machen, musste ich in der Lage sein, unsere Diskussion mit einem klaren Standpunkt darüber zu beginnen, was es bedeutet, eine SaaS-Architektur und ein SaaS-Geschäft nach bewährten Methoden aufzubauen. Ich musste in der Lage sein, die SaaS-Landschaft so zu definieren, dass die Teams die Kompromisse, Architekturmuster und betrieblichen Überlegungen verstehen, die ihre mandantenfähige Architektur direkt beeinflussen. Um dieses Ziel zu erreichen, musste ich eine klare Taxonomie der SaaS-Prinzipien und -Strategien erstellen, die eine Reihe von Domänen, Arbeitslasten, Kundenprofilen usw. abdecken konnte. In vielerlei Hinsicht ging es dabei auch darum, sich bewusst von einer weit gefassten Vorstellung davon zu lösen, was eine SaaS-Lösung ist, und eine Reihe spezifischer Leitplanken zu definieren, die den Unternehmen helfen können, ihren Weg zu planen.

Es war dieses grundlegende Bedürfnis, das mich auf einen mehrjährigen Weg brachte, um die SaaS-Architektur besser zu definieren. Was mit ein paar Blogbeiträgen begann, wurde von einer Reihe von Whitepapers, Webinaren, Podcasts, Schulungsvideos und Konferenzpräsentationen abgelöst. Im Laufe der Zeit stellte ich fest, dass die von mir vertretenen Konzepte und Grundsätze in immer mehr Bereichen Anwendung fanden. Das brachte mich auf den Gedanken, dass es vielleicht an der Zeit wäre, ein Buch zu schreiben, das alle Schlüsselelemente dieses Leitfadens in einem durchgängigen Erlebnis zusammenfasst.

Ich hoffe, dass ich mit diesem Buch die SaaS-Diskussion präzisieren kann, indem ich einen Rahmen dafür schaffe, wie man über SaaS denkt und wie man diese Konzepte mit realen Konstrukten verbindet. Das Ziel ist es, sicherzustellen, dass wir uns auf die grundlegenden Prinzipien einigen und dann zu zeigen, wie diese Prinzipien in verschiedenen Anwendungsfällen und mit verschiedenen Technologien umgesetzt werden. Indem wir diese Konzepte mit bestimmten Technologien (Kubernetes, Serverless usw.) verknüpfen, kannst du sehen, wie die Nuancen einzelner Technologien einen erheblichen Einfluss auf die Gesamtauslegung deiner mandantenfähigen Architektur haben können.

Auf dem Weg dorthin werde ich eine klare Taxonomie der Kernelemente jeder SaaS-Umgebung erstellen und ein Vokabular für SaaS definieren, das es uns ermöglicht, einen universelleren Ansatz für die Kategorisierung und Beschreibung der beweglichen Teile einer SaaS-Architektur zu verfolgen. Ich werde die gesamte Bandbreite der SaaS-spezifischen Architekturmechanismen betrachten, darunter Tenant Isolation, Onboarding, Tiering, Identität, Metriken, Abrechnung und Datenpartitionierung. Für jeden dieser Bereiche werden wir uns Beispiele ansehen, wie sie in verschiedenen Umgebungen angewendet werden können.

Das Buch wäre auch unvollständig, wenn es nicht die operativen Elemente von SaaS beleuchten würde. Du wirst feststellen, dass die Architektur von SaaS-Umgebungen direkt von den operativen Unternehmenszielen (Agilität, Innovation, Kosteneffizienz) beeinflusst wird. Diesen engen Zusammenhang werden wir im Laufe des Buches untersuchen und die betrieblichen Überlegungen darlegen, die den Aufbau deiner SaaS-Umgebung beeinflussen werden.

Insgesamt sehe ich dieses Buch als einen guten Ausgangspunkt für die Diskussion über SaaS-Architekturen. Es versucht, eine klarere Sicht darauf zu schaffen, wie wir SaaS definieren, und hebt die wichtigsten Prinzipien, Konstrukte und Strategien hervor, die für den Aufbau einer SaaS-Architektur mit bewährten Methoden entscheidend sind.

Eine sich entwickelnde Landschaft

Die ersten mandantenfähigen Lösungen, an denen ich gearbeitet habe, hatten eine sehr einfache Vorstellung davon, was SaaS bedeutet. Diese Umgebungen arbeiteten in der Regel mit einem Modell, bei dem sich die Kunden einen Compute-Cluster teilten und die Daten jedes Kunden in einer separaten Datenbank speicherten. Ich vermute, dass es auch heute noch viele Systeme gibt, die dieses Modell verwenden - vor allem in Umgebungen, in denen Teams ihre eigene SaaS-Infrastruktur hosten und verwalten.

Als die Cloud aufkam, brachte sie eine völlig neue Dimension von Möglichkeiten in das SaaS-Bild. Die Managed Services, die dynamische Skalierung und das Pay-as-you-go-Prinzip der Cloud statteten SaaS-Teams mit Tools und Mechanismen aus, die ihren Bedürfnissen entsprachen. Die Unternehmen konnten alle Vorteile der Cloud nutzen, um das Kosten-, Betriebs- und Agilitätsprofil ihrer SaaS-Umgebungen zu verbessern. In einigen Fällen war die Anziehungskraft der Cloud so groß, dass einige Unternehmen die Cloud mit SaaS gleichsetzten (was sie nicht ist).

Du kannst dir vorstellen, wie das Aufkommen der Cloud einen völlig neuen Bereich für SaaS-Architekten eröffnete. Sie bot den Architekten ein viel größeres Angebot an Tools, Diensten und Betriebsmechanismen, mit denen sie die Entwicklung ihrer mandantenfähigen Umgebungen rationalisieren konnten. Die Cloud ermöglichte es SaaS-Teams, noch mehr betriebliche Komplexität in die Cloud zu verlagern und so die Reibungsverluste und den Overhead zu reduzieren, die mit der Unterstützung und dem Betrieb eines SaaS-Geschäfts verbunden sind. Sie bot auch native Mechanismen, die Skalierbarkeit, Hochverfügbarkeit und Kosten-/Betriebseffizienz förderten.

Diese natürliche Verbindung zwischen SaaS und der Cloud trug wesentlich zur allgemeinen Attraktivität und schnellen Akzeptanz des SaaS-Bereitstellungsmodells bei. Neue SaaS-Unternehmen waren in der Lage, die Stärken der Cloud zu nutzen, um die Entwicklung von SaaS-Angeboten zu beschleunigen und bestehende Bereiche und Marktsegmente zu stören. Cloud-basierte SaaS-Unternehmen konnten sich schneller bewegen, bessere Margen erzielen, neue Märkte erobern und viel schneller innovativ sein. Wie du dir vorstellen kannst, motivierte dies die bestehenden Softwareunternehmen, ihren Weg zu SaaS zu beschleunigen, und einige von ihnen sahen den Wechsel zu SaaS als grundlegend für ihr Überleben an. Es beeinflusste auch das Verhalten der Softwarekunden, die die reibungslose und wertorientierte Natur des SaaS-Modells erwarteten und annahmen.

All diese Aktivitäten haben eine Lawine der SaaS-Einführung ausgelöst. Außerdem entstand ein erheblicher Bedarf an zusätzlichen Erkenntnissen und Anleitungen dazu, wie diese Cloud-Konstrukte in einer mandantenfähigen Architektur angewendet werden können. Das Zusammentreffen dieser Faktoren - der Bedarf an einer viel breiteren und tieferen Architekturanleitung, die allgemeine SaaS-Akzeptanz und der Einfluss der Cloud - hat die Nachfrage nach mehr Klarheit darüber, wie SaaS-Lösungen entwickelt, aufgebaut und betrieben werden, wachsen lassen.

Was bedeutet das nun für dieses Buch? Der wichtigste Punkt ist, dass der Bereich der bewährten Methoden für SaaS weiterhin ein bewegliches Ziel ist. Die rasante Entwicklung von SaaS-Unternehmen und das Aufkommen neuer Technologien führen immer wieder neue Strategien, Mechanismen und Konstrukte ein, die zukünftige Richtlinien beeinflussen können. Es ist davon auszugehen, dass sich die bewährten Methoden und Strategien für SaaS auch in Zukunft an die sich verändernde Technologielandschaft anpassen werden.

Für wen ist dieses Buch gedacht?

Dieses Buch richtet sich an Entwickler, Architekten und Betriebsteams, die SaaS-Lösungen erstellen, migrieren oder optimieren. Vielleicht bist du ganz neu bei SaaS und suchst nach den grundlegenden Konzepten, die dir den Einstieg in SaaS erleichtern, oder du bist bereits in SaaS eingetaucht und überlegst, wie du die hier beschriebenen Prinzipien anwenden kannst, um eine bestehende Lösung zu verbessern. Du wirst feststellen, dass ich in dieser Liste auch den Betrieb mit einbezogen habe. Auch wenn sich ein großer Teil dieses Buches auf die Entwickler und Architekten konzentriert, ist es wichtig, dass auch die Betriebsteams die Kompromisse und Strategien mitgestalten, die die Grundlage für dein SaaS-Erlebnis bilden. Dementsprechend müssen auch die Entwickler und Architekten stärker in das Betriebserlebnis einbezogen werden.

Ich beginne ganz bewusst mit einer Reihe von grundlegenden Konzepten, die sich durch das gesamte Buch ziehen. Selbst wenn du bereits Erfahrung mit SaaS hast, würde ich dir dringend empfehlen, mit diesen grundlegenden Konzepten zu beginnen. Die Ideen, die in der Anfangsphase des Buches entwickelt werden, stellen einige der klassischen Vorstellungen von SaaS in Frage und führen eine Terminologie und Denkweise ein, die jeden Aspekt der Gestaltung und des Aufbaus einer SaaS-Umgebung beeinflusst. Die Beispiele im weiteren Verlauf des Buches veranschaulichen, wie diese Designentscheidungen und Muster umgesetzt und angewendet werden. Wenn du diese Grundlage geschaffen hast und dich an diesen Kernprinzipien orientierst, wird sich das direkt darauf auswirken, wie du die Dekomposition von Microservices, das Bereitstellungsmodell deiner Lösung, das Identitätsmodell und so weiter angehst. Ich will damit sagen, dass du eine enge Verbindung zwischen den Grundprinzipien und den zugrundeliegenden Implementierungsstrategien erkennen wirst, wenn du dich mehr mit den Details der Implementierung beschäftigst. Wenn du dich auf eine Reihe gemeinsamer Leitprinzipien stützt, können du und deine Teams bei der Konzeption, der Entwicklung und dem Betrieb deiner SaaS-Umgebung auf gemeinsame Werte zurückgreifen.

Es gibt auch eine Ebene, auf der diese SaaS-Inhalte für SaaS-Führungskräfte und -Stakeholder von Wert sind. Auch wenn sie weniger an den technischen Details interessiert sind, werden sie sich wahrscheinlich auf die grundlegenden Elemente des Buches stützen, um ihre SaaS-Vision zu verfeinern und zu konkretisieren. Bei der Einführung von SaaS sind kulturelle, metrische und teamdynamische Aspekte zu berücksichtigen, und der Erfolg der SaaS-Strategie deines Unternehmens hängt in hohem Maße davon ab, dass die Führungskräfte in einem gemeinsamen Wertekanon verwurzelt sind. Dies ist oft einer der am meisten übersehenen Aspekte beim Aufbau eines erstklassigen SaaS-Unternehmens. Aus denselben Gründen kannst du dir vorstellen, dass es für Produktverantwortliche und andere, die mit der SaaS-Vision verbunden sind, von großem Nutzen sein wird, wenn sie diese grundlegenden SaaS-Prinzipien kennen.

Ein Fundament - keine Bibel

Die Grundsätze, die ich in diesem Buch behandle, sind das Ergebnis meiner Erfahrungen, die ich bei der Arbeit mit zahlreichen SaaS-Anbietern gemacht habe, die eine Reihe von Bereichen, Zielgruppen und Branchen abdecken. Dieses Buch enthält die Themen, Muster und Anleitungen, die sich aus diesen Projekten ergeben haben. Ich hatte auch das Glück, von Teams und Menschen umgeben zu sein, die mir geholfen haben, diese Vision zu entwickeln.

Es ist jedoch wichtig zu wissen, dass dieses Buch nicht dazu gedacht ist, als De-facto-Bibel für alles, was mit SaaS zu tun hat, zu dienen. Die hier vorgestellten Strategien und Muster für den Aufbau von SaaS-Architekturen sind als Ausgangspunkt gedacht, um mehr Klarheit und Definition in das Universum des mandantenfähigen Designs und der Architektur zu bringen. In vielerlei Hinsicht habe ich mich selbst als Lückenfüller gesehen, der einen Weg gefunden hat, die Natur von SaaS-Lösungen besser zu beschreiben und zu charakterisieren, wohl wissend, dass es alternative Strategien gibt oder in Zukunft geben könnte.

Ich hoffe, dass diese Konzepte dadurch sichtbarer werden und sich mehr Bauherren und Architekten an einer breiteren Diskussion beteiligen, um diese Grundsätze besser zu vermitteln.

Hinweis

Ein Großteil meiner Erfahrung im SaaS-Bereich stammt aus meiner direkten Arbeit und Erfahrung mit dem AWS-Stack von Diensten und Tools. Das bedeutet, dass ich mich, wenn wir uns näher mit den Einzelheiten befassen, natürlich zu den AWS-Tools und -Strategien hingezogen fühle. Die meisten Grundsätze und Strategien sind jedoch nicht nur auf AWS beschränkt. Sie lassen sich in den meisten Umgebungen gut umsetzen. Ich möchte auch darauf hinweisen, dass die Strategien und Prinzipien, die ich behandeln werde, meine eigenen Perspektiven, Meinungen und Ansichten darstellen. Vieles von dem, was wir erforschen werden, ist sicherlich von dem Wissen und den Praktiken beeinflusst, die ich während meiner Zeit bei AWS entwickelt habe. Was schließlich in diesem Buch steht, sollte jedoch nicht als von AWS befürwortete Anleitung betrachtet werden.

Was nicht in diesem Buch steht

SaaS ist ein breit gefächertes Thema, bei dem es viele Themen gibt. Wenn du dir das Inhaltsverzeichnis dieses Buches ansiehst, wirst du sehen, dass ich einen großen Teil des SaaS-Universums abdecke und ein ziemlich breites Spektrum an Design-, Entwicklungs- und Implementierungsperspektiven erforsche - einschließlich Geschäftsthemen. Du wirst sogar ein Beispiel nach dem anderen finden, in dem ich die Verbindung zwischen SaaS-Geschäfts- und Technologiestrategien hervorhebe. Ich mache deutlich, dass Entwickler und Architekten ein großes Interesse daran haben müssen, die SaaS-Geschäftsparameter zu nutzen, um den Fußabdruck ihrer Lösung zu gestalten.

Obwohl diese geschäftlichen Elemente ein zentraler Bestandteil der SaaS-Geschichte sind, wirst du feststellen, dass ich es absichtlich vermieden habe, tiefer auf bestimmte Aspekte des Geschäftsbereichs einzugehen. Es gibt ganze Bücher, die sich mit SaaS-Vertrieb, Marketing, Go-to-Market, Geschäftsmodellierung, Journey Mapping, Metriken usw. beschäftigen. Für mich stehen diese Themen für sich allein und gelten allgemeiner für den SaaS-Bereich. Auch wenn ich mit diesen Bereichen nur wenig zu tun habe, finde ich, dass sie besser als eigenständige Themen behandelt werden sollten. Ich empfehle Unternehmen, sich mit den SaaS-Konzepten vertraut zu machen, wenn sie ein solides SaaS-Geschäft aufbauen wollen; ich werde sie hier aber nicht behandeln.

Es ist auch erwähnenswert, dass dieses Buch nicht versucht, jede Variante von SaaS zu behandeln. Es gibt viele kommerzielle Business-to-Consumer (B2C)-Lösungen, an die die Menschen denken, wenn sie an SaaS denken. Auch wenn sie dem Normalbürger vielleicht am vertrautesten sind, so sind sie doch nach einem für die meisten untypischen Modell aufgebaut. Die meisten SaaS-Anbieter haben nicht vor, Millionen von Nutzern zu unterstützen. In der Regel verwenden B2C-Umgebungen ihre eigenen, einzigartigen Designstrategien, die oft für spezielle Skalierungsanforderungen optimiert sind. Im Gegensatz dazu wird ein Business-to-Business (B2B) SaaS-Unternehmen, das Hunderte bis Tausende von Unternehmen unterstützt, wahrscheinlich einen anderen Ansatz für die Gestaltung und Architektur seiner mandantenfähigen Umgebung wählen. Ich denke, dass der B2C-Bereich interessant ist und dass die Konzepte des B2C-Bereichs viele Überschneidungen mit den Grundprinzipien haben, die ich behandeln werde. Gleichzeitig muss ich aber auch zugeben, dass es Bereiche gibt, in denen B2B- und B2C-Strategien erheblich voneinander abweichen können. Den Mietern eine eigene Infrastruktur zur Verfügung zu stellen, ist zum Beispiel eine völlig legitime Option in einem B2B-Umfeld. In den meisten B2C-Umgebungen ist derselbe Ansatz wahrscheinlich nicht praktikabel.

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Weist auf neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen hin.

Constant width

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

Code-Beispiele verwenden

Die Code-Beispiele aus den Kapiteln 10 und 11 stehen unter https://oreil.ly/saas-ch10-code bzw. https://oreil. ly/saas-ch11-code zum Download bereit. Die Links sind auch in diesen Kapiteln angegeben .

Wenn du eine technische Frage oder ein Problem mit den Codebeispielen hast, sende bitte eine E-Mail an

Dieses Buch soll dir helfen, deine Arbeit zu erledigen. Wenn in diesem Buch Beispielcode angeboten wird, darfst du ihn in deinen Programmen und deiner Dokumentation verwenden. Du musst uns nicht um Erlaubnis fragen, es sei denn, du reproduzierst einen großen Teil des Codes. Wenn du zum Beispiel ein Programm schreibst, das mehrere Teile des Codes aus diesem Buch verwendet, brauchst du keine Erlaubnis. Der Verkauf oder die Verbreitung von Beispielen aus O'Reilly-Büchern erfordert jedoch eine Genehmigung. Die Beantwortung einer Frage mit einem Zitat aus diesem Buch und einem Beispielcode erfordert keine Genehmigung. Wenn du einen großen Teil des Beispielcodes aus diesem Buch in die Dokumentation deines Produkts aufnimmst, ist eine Genehmigung erforderlich .

Wir freuen uns über eine Namensnennung, verlangen sie aber in der Regel nicht. Eine Quellenangabe umfasst normalerweise den Titel, den Autor, den Verlag und die ISBN. Zum Beispiel: "Building Multi-Tenant SaaS Architectures von Tod Golding (O'Reilly). Copyright 2024 Tod Golding, 978-1-098-14064-9."

Wenn du der Meinung bist, dass die Verwendung von Code-Beispielen nicht unter die Fair-Use-Regelung oder die oben genannte Erlaubnis fällt, kannst du uns gerne unter kontaktieren

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 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 erhältst du unter https://oreilly.com.

Wie du uns kontaktierst

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

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/bldg-multitenant-saas aufrufen .

Neuigkeiten und Informationen über unsere Bücher und Kurse findest du unter https://oreilly.com.

Finde uns auf LinkedIn: https://linkedin.com/company/oreilly-media

Schau uns auf YouTube: https://youtube.com/oreillymedia

Danksagungen

Ich hatte das Glück, von vielen Menschen umgeben, beeinflusst, unterstützt und inspiriert zu werden, die direkt und indirekt zur Entstehung dieses Buches beigetragen haben. Der beste Ort, um damit zu beginnen, ist wahrscheinlich der Anfang, wenn man sich meine ersten Tage bei AWS ansieht, als ich als neuer SaaS-Lösungsarchitekt eingestellt wurde, um zu versuchen, eine Vision zu definieren und zu gestalten, was es bedeutet, SaaS-Angebote in der Cloud zu entwickeln. In dieser Zeit hatte ich das Glück, von Matt Yanchyshyn angeleitet zu werden, der mich anspornte, mich einzubringen, schnell zu handeln und Ergebnisse zu liefern. Matt Yanchyshyn hat die Fähigkeit, viel zu fragen, dir Raum zum Handeln zu geben und dich zu inspirieren, groß zu denken. Seine frühe Ermutigung hat mich auf diesen Weg gebracht und ich bin mir nicht sicher, ob ich ohne seine klugen Worte so weit gekommen wäre.

Meine Fähigkeit, in die Tiefe zu gehen und meine SaaS-Kenntnisse weiterzuentwickeln, hängt auch direkt mit den Erfahrungen zusammen, die ich bei der Arbeit mit SaaS-Unternehmen gemacht habe. Dadurch, dass ich mich mit Unternehmen zusammensetzen und ihre SaaS-Lösungen genauer unter die Lupe nehmen konnte, lernte ich ein breites Spektrum an Branchen, Bereichen, Geschäftsszenarien und Anwendungsszenarien kennen. Die Daten, Muster und der Code, die dabei herauskamen, waren und sind unbezahlbar. Ich hatte auch das Glück, von einem großartigen Team von SaaS-Architekten und Business Leads umgeben zu sein, die eine Schlüsselrolle bei der Weiterentwicklung von SaaS spielten und mir dabei halfen, bewährte Methoden, Strategien und Muster immer wieder neu zu bewerten. Es gibt zu viele, um sie hier zu erwähnen, aber ich möchte Craig Wicks, Seth Fox, Emily Tyack und Michael Schmidt für ihre frühe Führung und Zusammenarbeit hervorheben. Auch Adrian De Luca war eine ständige Inspirationsquelle, die mich immer wieder angeleitet und ermutigt hat.

Das Schreiben eines Buches hängt auch stark von einem Team ab, das hinter den Kulissen mitarbeitet und diesen Weg mit dir geht. Das Team bei O'Reilly war in allen Phasen der Entstehung dieses Buches großartig. Im Mittelpunkt meiner täglichen Arbeit bei O'Reilly stand Melissa Potter. Sie half mir bei der Entwicklung des Buches, überprüfte meine ersten Entwürfe, beantwortete Fragen und war immer mit ermutigenden Worten zur Stelle. Louise Corrigan von O'Reilly war ebenfalls von Anfang an dabei. Sie hat mich in den ersten Phasen bei der Gestaltung der Buchstruktur beraten und mich bei wichtigen Entscheidungen unterstützt. Ich möchte mich auch bei den technischen Gutachtern des Buches bedanken: Anubhav Sharma, Russell Miles und Toby Buckley. Danke, dass ihr euch die Zeit genommen und eure Erkenntnisse mit mir geteilt habt. Eure Sichtweisen haben mir geholfen, die Geschichte zu verfeinern und das Buch zu verbessern.

Im Mittelpunkt jeder Reise, die ich unternehme, steht natürlich meine Familie. Auch wenn sie nie ganz verstanden hat, was ich tue, war sie immer an meiner Seite und hat mich auf meinem Weg ermutigt. Meine Frau Janine hat mich bei allem, was ich tue, unterstützt, und dieses Projekt war da keine Ausnahme. Ihre ermutigenden Worte machen es mir immer leichter, weiterzumachen. Dann sind da noch meine Kinder, Chelsea und Ryan. Auch wenn sie jetzt erwachsen sind und ihren eigenen Weg gehen, finden sie immer noch Wege, um meinen Tag zu erhellen und mich daran zu erinnern, wie glücklich ich bin.

Get Aufbau von mandantenfähigen SaaS-Architekturen now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial