Vor einer Woche sprach ich auf einem Node.JS-Treffen und versprach vielen, eine Aufzeichnung der Aufführung zu veröffentlichen. Später stellte ich fest, dass ich in einer geregelten halben Stunde einige interessante Fakten nicht berücksichtigen konnte. Ja, und ich selbst lese lieber als zu sehen und zuzuhören. Deshalb habe ich beschlossen, meine Präsentation im Format eines Artikels zu veröffentlichen. Das Video befindet sich jedoch auch am Ende des Beitrags im Abschnitt "Links".
Ich habe beschlossen, Ihnen von einem wunden Punkt zu erzählen - dem Leben in einem Monolithen. Es gibt bereits Hunderte von Artikeln darüber auf dem Hub, Tausende von Kopien sind in den Kommentaren gebrochen, die Wahrheit ist seit langem in Kontroversen gestorben, aber ... Tatsache ist, dass wir in OneTwoTrip eine sehr spezifische Erfahrung haben, im Gegensatz zu vielen Menschen, die über bestimmte Architekturmuster in schreiben Vakuum:
- Erstens ist unser Monolith bereits 9 Jahre alt.
- Zweitens verbrachte er sein ganzes Leben unter hoher Last (jetzt sind es 23 Millionen Anfragen pro Stunde).
- Und in NaN schreiben wir unseren Monolithen auf Node.JS, der sich in den letzten 9 Jahren bis zur Unkenntlichkeit verändert hat. Ja, wir haben 2010 angefangen, auf dem Knoten zu schreiben. Wir singen ein Lied zur Raserei der Tapferen!
Wir haben also viel Spezifität und echte Erfahrung. Interessant? Lass uns gehen!
Haftungsausschlusszeiten
Diese Präsentation spiegelt nur die private Meinung des Autors wider. Es kann mit der Position von OneTwoTrip übereinstimmen oder nicht. So viel Glück. Ich arbeite als technischer Experte in einem der Unternehmensteams und gebe nicht vor, objektiv zu sein oder eine andere Meinung als meine eigene zu äußern.
Haftungsausschluss Zwei
Dieser Artikel beschreibt historische Ereignisse, und im Moment ist alles völlig falsch, seien Sie also nicht beunruhigt.
0. Wie ist es passiert?
Der Abfragetrend des Wortes "Microservice" in Google:
Alles ist sehr einfach - vor neun Jahren wusste niemand etwas über Microservices. Also haben wir wie alle anderen angefangen zu schreiben - in einem Monolithen.
1. Schmerzen im Monolithen
Hier werde ich die Problemsituationen beschreiben, die wir in diesen 9 Jahren hatten. Einige von ihnen wurden gelöst, andere durch Hacks umgangen, andere verloren einfach an Relevanz. Aber die Erinnerung an sie, wie Kampfnarben, wird mich niemals verlassen.
1.1 Aktualisieren verbundener Komponenten
Dies ist der Fall, wenn Synergie böse ist. Da jede Komponente mehrere hundert Mal wiederverwendet wurde und es möglich war, sie schief zu verwenden, ging sie nicht verloren. Jede Aktion kann völlig unvorhersehbare Auswirkungen haben, und nicht alle werden von Einheiten und Integrationstests verfolgt. Erinnerst du dich an die Geschichte über Mops, einen Ventilator und einen Ballon? Wenn nicht, googeln Sie es. Sie ist die beste Illustration des Codes im Monolithen.
1.2 Migration zu neuen Technologien
Möchten Sie Express? Linter? Ein weiterer Rahmen für Tests oder Moks? Validator aktualisieren oder zumindest lodash? Node.js aktualisieren? Es tut mir leid. Dazu müssen Sie Tausende von Codezeilen bearbeiten.
Viele sprechen über den Vorteil des Monolithen, dass jede Revision ein atomares Commit ist . Diese Leute schweigen über eine Sache - diese Überarbeitung wird niemals durchgeführt werden .
Kennen Sie den alten Witz über semantische Versionierung?
die wahre Semantik der semantischen Versionierung:
major = eine bahnbrechende Veränderung
geringfügig = eine geringfügige Änderung
Patch = eine kleine Veränderung
Stellen Sie sich nun vor, dass mit ziemlicher Sicherheit jede kleine Änderung in Ihrem Code auftaucht. Nein, es ist möglich, damit zu leben, und wir haben regelmäßig Kraft gesammelt und sind migriert, aber es war wirklich sehr schwierig. Sehr.
1.3 Veröffentlichungen
Hier muss ich zu einigen Besonderheiten unseres Produktes sagen. Wir haben eine große Anzahl externer Integrationen und verschiedene Zweige der Geschäftslogik, die ziemlich selten separat auftauchen. Ich beneide die Produkte wirklich, die tatsächlich alle Zweige ihres Codes in 10 Minuten in der Produktion ausführen, aber das ist hier nicht der Fall. Durch Versuch und Irrtum haben wir für uns einen optimalen Veröffentlichungszyklus gefunden, der die Anzahl der Fehler, die Endbenutzer erreichen, minimiert:
- Die Veröffentlichung läuft und die Integrationstests dauern einen halben Tag
- dann steht es einen Tag lang unter sorgfältiger Aufsicht auf der Bühne (für 10% der Benutzer)
- dann liegt ein weiterer Tag in der Produktion unter noch sorgfältigerer Aufsicht.
- Und erst danach geben wir ihm grünes Licht im Meister.
Da wir unsere Kollegen lieben und freitags nicht veröffentlichen, bedeutet dies letztendlich, dass die Veröffentlichung etwa 1,5 bis 2 Mal pro Woche an den Master geht. Dies führt dazu, dass das Release 60 oder mehr Aufgaben haben kann. Ein solcher Betrag führt zu Zusammenführungskonflikten, plötzlichen Synergieeffekten, einer vollständigen QS-Arbeitsbelastung bei der Protokollanalyse und anderen Problemen. Im Allgemeinen war es für uns sehr schwierig, einen Monolithen freizugeben.
1.4 Nur viel Code
Es scheint, dass die Menge an Code nicht von grundlegender Bedeutung sein sollte. Aber ... nicht wirklich. In der realen Welt ist es:
- Höhere Eintrittsschwelle
- Riesige Build-Artefakte für jede Aufgabe
- Lange CI-Prozesse, einschließlich Integrationstests, Komponententests und sogar Code-Flusen
- Langsame IDE-Arbeit (zu Beginn der Entwicklung von Jetbrains haben wir sie mehr als einmal mit unseren Protokollen geschockt)
- Anspruchsvolle kontextbezogene Suche (nicht vergessen, wir haben keine statische Eingabe)
- Schwierigkeiten beim Finden und Entfernen von nicht verwendetem Code
1.5 Fehlende Codebesitzer
Sehr oft entstehen Aufgaben mit einem unverständlichen Verantwortungsbereich - zum Beispiel in verwandten Bibliotheken. Und der ursprüngliche Entwickler könnte bereits zu einem anderen Team wechseln oder sogar das Unternehmen verlassen. Der einzige Weg, um in diesem Fall verantwortlich zu sein, ist administrative Willkür - eine Person zu nehmen und zu ernennen. Das ist nicht immer angenehm für den Entwickler und denjenigen, der es tut.
1.6 Debugging-Schwierigkeit
Fließt die Erinnerung? Erhöhter CPU-Verbrauch? Wollten Sie Flammengraphen erstellen? Es tut mir leid. In einem Monolithen passieren so viele Dinge gleichzeitig, dass es wahnsinnig schwierig wird, ein Problem zu lokalisieren. Es ist beispielsweise fast unrealistisch zu verstehen, welche der 60 Aufgaben bei der Einführung in die Produktion einen erhöhten Ressourcenverbrauch verursacht (obwohl dies in Test- und Staging-Umgebungen nicht lokal reproduziert wird).
1.7 Ein Stapel
Einerseits ist es gut, wenn alle Entwickler dieselbe Sprache „sprechen“. Im Fall von JS stellt sich heraus, dass sich selbst Backend mit Frontend-Entwicklern verstehen. Aber ...
- Es gibt keine Silberkugel, und für einige Aufgaben möchten Sie manchmal etwas anderes verwenden. Aber wir haben einen Monolithen, und wir können nirgendwo andere Entwickler festhalten.
- Wir können nicht einfach ein gutes Team auf die Empfehlung setzen, die uns auf Anraten von Freunden zugekommen ist - wir können es nirgendwo sagen.
- Im Laufe der Zeit ruhen wir uns auf der Tatsache aus, dass der Markt einfach nicht genug Entwickler auf dem richtigen Stack hat.
1.8 Viele Teams mit unterschiedlichen Vorstellungen von Glück
Wenn Sie zwei Entwickler haben, haben Sie bereits zwei unterschiedliche Vorstellungen darüber, welches das beste Framework ist, welche Standards eingehalten werden sollten, Bibliotheken verwenden usw.
Wenn Sie zehn Teams haben, von denen jedes mehrere Entwickler hat, ist dies nur eine Katastrophe.
Und es gibt nur zwei Möglichkeiten, dies zu lösen - entweder „demokratisch“ (jeder tut, was er will) oder totalitär (Standards werden von oben auferlegt). Im ersten Fall leiden Qualität und Standardisierung, im zweiten Fall Menschen, die ihre Vorstellung von Glück nicht verwirklichen dürfen.
2. Die Vorteile des Monolithen
Natürlich gibt es einige Vorteile des Monolithen, die für verschiedene Stapel, Produkte und Teams unterschiedlich sein können. Natürlich gibt es viel mehr als drei, aber ich werde nicht für alles Mögliche verantwortlich sein, sondern nur für diejenigen, die für uns relevant waren.
2.1 Einfache Bereitstellung
Wenn Sie einen Dienst haben, ist das Aufrufen und Testen viel einfacher als ein Dutzend Dienste. Dieses Plus ist zwar nur in der Anfangsphase relevant. Sie können beispielsweise die Testumgebung erhöhen und alle Dienste außer den daraus entwickelten verwenden. Oder aus Containern. Oder was auch immer.
2.2 Kein Datenübertragungsaufwand
Ein zweifelhaftes Plus, wenn Sie keine Hochlast haben. Aber wir haben genau einen solchen Fall - daher sind die Transportkosten zwischen Microservices für uns spürbar. Egal wie Sie dies schnell versuchen, speichern und übertragen Sie alles schneller als alles andere im RAM - dies ist offensichtlich.
2.2 Eine Baugruppe
Wenn Sie irgendwann in der Geschichte ein Rollback durchführen müssen, ist es wirklich einfach, dies mit einem Monolithen zu tun - nehmen Sie es und rollen Sie es zurück. Bei Microservices müssen kompatible Versionen von Diensten ausgewählt werden, die zu einem bestimmten Zeitpunkt miteinander verwendet wurden, was nicht immer einfach sein kann. Dies wird zwar auch mit Hilfe der Infrastruktur gelöst.
3. Imaginäre Vorteile eines Monolithen
Hier habe ich all die Dinge genommen, die normalerweise als Pluspunkte gelten, aber aus meiner Sicht sind sie es nicht.
3.1 Code - Dies ist die Dokumentation
Habe oft diese Meinung gehört. Aber normalerweise folgen unerfahrene Entwickler, die keine Dateien in Zehntausenden von Codezeilen gesehen haben, die von Leuten geschrieben wurden, die vor Jahren gegangen sind. Aus irgendeinem Grund wird dieser Artikel meistens zugunsten der Monolith-Unterstützer hinzugefügt - sie sagen, wir brauchen keine Dokumentation, wir haben keinen Transport oder keine API - alles ist im Code enthalten, es ist einfach und klar. Ich werde mit dieser Aussage nicht streiten, sondern nur sagen, dass ich nicht daran glaube.
3.2 Es gibt keine unterschiedlichen Versionen von Bibliotheken, Diensten und APIs. Es gibt keine unterschiedlichen Repositorys.
Ja Aber nein. Denn auf den zweiten Blick verstehen Sie, dass der Service nicht im luftleeren Raum existiert. Und unter einer Vielzahl anderer Codes und Produkte, in die es integriert wird - angefangen bei Bibliotheken von Drittanbietern über Server-Softwareversionen bis hin zu externen Integrationen, einer IDE-Version, CI-Tools usw. Und sobald Sie verstehen, wie viele verschiedene versionierte Dinge Ihr Service indirekt enthält, wird sofort klar, dass dieses Plus nur Demagogie ist.
3.3 einfachere Überwachung
Einfacher. Weil Sie ungefähr ein Dashboard haben, anstatt ein paar Dutzend. Dies ist jedoch komplizierter und manchmal sogar unmöglich, da Sie Ihre Diagramme nicht in verschiedene Teile des Codes zerlegen können und nur die durchschnittliche Temperatur im Krankenhaus haben. Im Allgemeinen habe ich bereits im Abschnitt alles über die Komplexität des Debuggens gesagt. Ich möchte nur klarstellen, dass dieselbe Komplexität für die Überwachung gilt.
3.4 Es ist einfacher, gemeinsame Standards einzuhalten
Ja Aber, wie ich bereits in dem Absatz über viele Teams mit der Idee des Glücks geschrieben habe, werden die Standards entweder totalitär auferlegt oder fast bis zum Fehlen geschwächt.
3.5 Geringere Wahrscheinlichkeit einer Codeduplizierung
Die seltsame Meinung ist, dass der Code im Monolithen nicht dupliziert wird. Aber traf ihn ziemlich oft. In meiner Praxis stellt sich heraus, dass die Vervielfältigung von Code ausschließlich von der Entwicklungskultur im Unternehmen abhängt. Wenn dies der Fall ist, wird der allgemeine Code allen Arten von Bibliotheken, Modulen und Mikrodiensten zugewiesen. Wenn es nicht vorhanden ist, wird der Monolith zwanzig Mal kopiert und eingefügt.
4. Vorteile von Microservices
Jetzt schreibe ich darüber, was wir nach der Migration erhalten haben. Auch dies sind echte Schlussfolgerungen aus einer realen Situation.
4.1 Sie können eine heterogene Infrastruktur erstellen
Jetzt können wir Code auf einen Stapel schreiben, der für die Lösung eines bestimmten Problems optimal ist. Und es ist vernünftig, gute Entwickler zu verwenden, die zu uns gekommen sind. Hier ist zum Beispiel eine Beispielliste der Technologien, über die wir derzeit verfügen:
4.2 Sie können viele häufige Veröffentlichungen vornehmen
Jetzt können wir viele kleine unabhängige Veröffentlichungen machen, die einfacher, schneller und nicht schmerzhaft sind. Früher hatten wir nur ein Team, jetzt sind es bereits 18. Es hätte eine Pause gegeben, wenn alle im Monolithen geblieben wären. Oder die Leute, die dafür verantwortlich sind ...
4.3 Einfachere unabhängige Tests
Wir haben die Zeit für Integrationstests verkürzt, die jetzt nur das testen, was sich wirklich geändert hat, und gleichzeitig haben wir keine Angst vor den Auswirkungen plötzlicher Synergien. Natürlich musste ich anfangen, um den Rechen herumzulaufen - zum Beispiel zu lernen, wie man abwärtskompatible APIs erstellt -, aber im Laufe der Zeit beruhigte sich alles.
4.4 Einfachere Implementierung und Test neuer Funktionen
Jetzt sind wir offen für Experimente. Alle Frameworks, Stacks, Bibliotheken - Sie können alles ausprobieren und bei Erfolg weitermachen.
4.5 Sie können alles aktualisieren
Sie können die Version der Engine, Bibliotheken, aber alles aktualisieren! Als Teil eines kleinen Dienstes ist das Auffinden und Beheben aller wichtigen Änderungen eine Frage von Minuten. Und nicht Wochen wie vorher.
4.6 Und Sie können nicht aktualisieren
Seltsamerweise ist dies eines der coolsten Features von Microservices. Wenn Sie einen stabilen Arbeitscode haben, können Sie ihn einfach einfrieren und vergessen. Und Sie müssen es beispielsweise nie aktualisieren, um den Produktcode auf einer neuen Engine auszuführen. Das Produkt selbst arbeitet mit einem neuen Motor, und der Microservice lebt so weiter, wie er gelebt hat. Fliegen mit Schnitzel können endlich separat gefressen werden.
5 Nachteile von Microservices
Natürlich war eine Fliege in der Salbe nicht vollständig, und eine perfekte Lösung, um nur zu sitzen und bezahlt zu werden, funktionierte nicht. Was ist uns begegnet:
5.1 Benötigen Sie einen Bus für den Datenaustausch und die Löschprotokollierung.
Die Interaktion von Diensten über HTTP ist ein klassisches und im Allgemeinen sogar ein funktionierendes Modell, vorausgesetzt, es gibt Protokollierungs- und Ausgleichsebenen zwischen ihnen. Es ist jedoch besser, einen deutlicheren Reifen zu haben. Darüber hinaus sollten Sie darüber nachdenken, wie Sie Protokolle untereinander sammeln und kombinieren können. Andernfalls haben Sie nur Brei in der Hand.
5.2 Verfolgen Sie, was Entwickler tun.
Im Allgemeinen sollte dies immer getan werden, aber in Microservices haben Entwickler offensichtlich mehr Freiheit, was manchmal zu Dingen führen kann, von denen Stephen King Gänsehaut bekommen würde. Auch wenn es äußerlich so aussieht, als ob der Dienst funktioniert - vergessen Sie nicht, dass es eine Person geben sollte, die überwacht, was sich in ihm befindet.
5.3 Sie benötigen ein gutes DevOps-Team, um alles zu verwalten.
Fast jeder Entwickler kann einen Monolithen auf die eine oder andere Weise bereitstellen und seine Releases hochladen (zum Beispiel über FTP oder SSH, das habe ich gesehen). Bei Microservices gibt es jedoch alle Arten von zentralisierten Diensten zum Sammeln von Protokollen, Metriken, Dashboards, Köchen zum Verwalten von Konfigurationen, Volt, Jenkins und anderen guten Dingen, ohne die Sie im Allgemeinen leben können - aber es ist schlecht und unverständlich, warum. Um Microservices verwalten zu können, benötigen Sie ein gutes DevOps-Team.
5.4 Sie können versuchen, einen Hype zu fangen und sich in den Fuß zu schießen.
Vielleicht ist dies das Hauptnegativ der Architektur und ihrer Gefahr. Sehr oft folgen Menschen blind Trends und beginnen, Architektur und Technologie einzuführen, ohne sie zu verstehen. Danach fällt alles in dem daraus resultierenden Chaos und sie schreiben einen Artikel über den Habr, "wie wir zum Beispiel von Microservices zu einem Monolithen gewechselt sind". Bewegen Sie sich im Allgemeinen nur, wenn Sie wissen, warum Sie dies tun und welche Probleme Sie lösen werden. Und welche bekommst du?
6 Khaki im Monolithen
Einige der Hacks, mit denen wir in einem Monolithen leben konnten, sind etwas besser und etwas länger.
6.1 Flusen
Die Einführung eines Liners in einen Monolithen ist keine so einfache Aufgabe, wie es auf den ersten Blick scheint. Natürlich können Sie strenge Regeln festlegen, eine Konfiguration hinzufügen und ... Nichts wird sich ändern, jeder schaltet nur den Linter aus, da die Hälfte des Codes rot wird.
Um das Flusen schrittweise einzuführen, haben wir ein einfaches Add-On für eslint geschrieben - slowlint , mit dem Sie eine einfache Sache tun können - eine Liste vorübergehend ignorierter Dateien. Ergebend:
- Jeder falsche Code wird in der IDE hervorgehoben
- Neue Dateien werden gemäß den Flusenregeln erstellt, andernfalls werden sie von CI nicht übersehen
- Alte regieren allmählich und gehen von Ausnahmen weg
Im Laufe des Jahres war es möglich, etwa die Hälfte des Monolith-Codes in einen einzigen Stil zu bringen, dh fast alle aktiv hinzugefügten Codes.
6.2 Verbesserungen des Unit-Tests
Einmal wurden bei uns drei Minuten lang Unit-Tests durchgeführt. Die Entwickler wollten nicht so lange warten, daher wurde alles nur in CI auf dem Server überprüft. Nach einiger Zeit stellte der Entwickler fest, dass die Tests fielen, verfluchten, eine Filiale eröffneten und zum Code zurückkehrten ... Im Allgemeinen litt er. Was haben wir damit gemacht:
- Für den Anfang haben wir begonnen, Tests mit mehreren Threads durchzuführen. Yandex hat eine Variante von Multithread-Mokka, aber bei uns ist sie nicht gestartet, deshalb haben sie selbst einen einfachen Wrapper geschrieben. Die Tests wurden eineinhalb Mal schneller durchgeführt.
- Dann sind wir von 0,12 auf den 8. Knoten übergegangen (ja, der Prozess selbst zeichnet auf einen separaten Bericht). So seltsam es auch scheinen mag, es gab keinen grundlegenden Produktivitätsgewinn in der Produktion, aber die Tests wurden 20% schneller durchgeführt.
- Und dann haben wir uns hingesetzt, um die Tests zu debuggen und sie individuell zu optimieren. Was die größte Geschwindigkeitssteigerung ergab.
Im Allgemeinen werden derzeit Unit-Tests im Vorbereitungshaken ausgeführt und dauern 10 Sekunden. Dies ist sehr komfortabel und ermöglicht es Ihnen, sie ohne Unterbrechung der Produktion auszuführen.
6.3 Erleichterung des Artefaktgewichts
Das Monolith-Artefakt nahm schließlich 400 Megabyte ein. In Anbetracht der Tatsache, dass es für jedes Commit erstellt wird, stellte sich heraus, dass das Gesamtvolumen ziemlich groß war. Das Durchfallmodul , eine Abzweigung des modclean- Moduls, hat uns dabei geholfen. Wir haben Unit-Tests aus dem Artefakt entfernt und es von verschiedenen Abfällen wie Readme-Dateien, Tests in Paketen usw. befreit. Die Zunahme betrug ungefähr 30% des Gewichts!
6.4 Abhängigkeits-Caching
Früher dauerte die Installation von Abhängigkeiten mit npm so lange, dass Sie nicht nur Kaffee trinken, sondern beispielsweise auch Pizza backen konnten. Deshalb haben wir zuerst das npm-Cache- Modul verwendet, das gegabelt und ein wenig fertig war. Sie konnten Abhängigkeiten auf einem freigegebenen Netzlaufwerk speichern, von dem alle anderen Builds sie dann übernehmen würden.
Dann haben wir über die Reproduzierbarkeit von Baugruppen nachgedacht. Wenn Sie einen Monolithen haben, ist die Veränderung der transitiven Abhängigkeiten Gottes Geißel. , , - . npm-shrinkwrap. , — .
Und dann erschienen schließlich die npm ci und der ausgezeichnete Befehl npm ci der nur geringfügig npm ci lief als die Installation von Abhängigkeiten aus dem Dateicache. Daher haben wir nur damit begonnen und das Speichern von Abhängigkeitsassemblys gestoppt. An diesem Tag brachte ich mehrere Kisten Donuts zur Arbeit.
6.5 Verteilung der Reihenfolge der Veröffentlichungen.
Und dies ist eher ein administrativer Hack, kein technischer. Anfangs war ich gegen ihn, aber die Zeit zeigte, dass der zweite technische Experte Recht hatte und im Allgemeinen gut gemacht war. Als die Releases nacheinander auf mehrere Teams verteilt wurden, wurde klar, wo genau die Fehler auftraten, und was noch wichtiger ist, jedes Team fühlte sich für die Geschwindigkeit verantwortlich und versuchte, Probleme zu lösen und so schnell wie möglich einzuführen.
6.6 Dead Code löschen
In einem Monolithen ist es sehr beängstigend, den Code zu löschen - Sie wissen nie, wo Sie daran hängen bleiben könnten. Daher bleibt es meistens nur auf der Seite zu liegen. Im Laufe der Jahre. Und selbst toter Code muss unterstützt werden, ganz zu schweigen von der damit verbundenen Verwirrung. Daher haben wir im Laufe der Zeit begonnen, Require-Analysis für eine oberflächliche Suche nach totem Code und Integrationstests sowie den Start im Coverage-Check-Modus für eine tiefere Suche zu verwenden.
7 Monolithenschnitt
Aus irgendeinem Grund denken viele Menschen, dass Sie Ihren Monolithen verlassen, eine Reihe von Mikrodiensten von Grund auf neu schreiben und alles auf einmal starten müssen, um zu Microservices zu wechseln - und es wird Glück geben. Aber dieses Modell ... Hmm ... Es ist mit der Tatsache behaftet, dass Sie nichts tun und einfach viel Zeit und Geld für das Schreiben von Code aufwenden, den Sie wegwerfen müssen.
Ich schlage eine andere Option vor, die mir besser zu funktionieren scheint und die bei uns umgesetzt wurde:
- Wir fangen an, neue Dienste in Microservices zu schreiben. Wir betreiben die Technologie, springen auf den Rechen, wir verstehen, ob wir das überhaupt wollen.
- Wir extrahieren den Code in Module, Bibliotheken oder was auch immer dort verwendet wird.
- Wir unterscheiden Dienstleistungen von einem Monolithen.
- Wir unterscheiden Microservices von Services. Ohne Eile und nacheinander.
8 Und schließlich
Am Ende habe ich beschlossen, das Wichtigste zu verlassen.
Denken Sie daran:
- Sie sind nicht Google
- Sie sind nicht Microsoft
- Du bist nicht Facebook
- Du bist nicht Yandex
- Du bist kein Netflix
- Sie sind nicht OneTwoTrip
Wenn etwas in anderen Unternehmen funktioniert, ist es absolut keine Tatsache, dass es Ihnen zugute kommt. Wenn Sie versuchen, die Erfahrungen anderer Unternehmen blind mit den Worten "es funktioniert für sie" zu kopieren, wird dies höchstwahrscheinlich schlecht enden. Jedes Unternehmen, jedes Produkt und jedes Team ist einzigartig. Was für einige funktioniert, funktioniert für andere nicht. Ich mag es nicht, offensichtliche Dinge zu sagen, aber zu viele Leute beginnen, einen Frachtkult um andere Unternehmen herum aufzubauen, Ansätze blind zu kopieren und sich unter gefälschten Weihnachtsbaumschmuck zu begraben. Tu das nicht. Experimentieren Sie, versuchen Sie, entwickeln Sie die für Sie optimalen Lösungen. Und nur dann wird alles klappen.
Nützliche Links: