Ich schlage vor, darüber zu sprechen, wann Microservices benötigt werden und wann nicht. Spoiler: Das hängt vom Projekt ab.

Wir, Softwareentwickler, haben einen ziemlich interessanten Beruf. Wir können tagelang sicher codieren und dann einen Artikel über etwas lesen - und er stellt unsere gesamte Arbeit in Frage, weil einige Netflix XYZ davon erzählt haben.

Einfach so, aufgrund der Meinung einer Person oder eines Unternehmens, beginnen Sie an allem zu zweifeln, was Sie seit vielen Jahren tun, auch wenn alles perfekt funktioniert hat.

Sie sind nicht Google (es sei denn, Sie sind Google)

Wenn wir HackerNews und andere Nachrichtenseiten lesen, sehen wir häufig technische Nachrichten von Google, Netflix, Amazon und Facebook, und sie sprechen gerne darüber, wie viele Hunderte oder Tausende von Diensten sie starten. Sie sprechen über die Vorteile, Dinge auf ihre eigene Weise zu tun. Dies ist ein Trend der letzten Jahre.

Aber seien wir ehrlich. Es ist unwahrscheinlich, dass Sie 1000 Entwickler haben, die an einem massiven Projekt mit mehr als 10 Jahren Geschichte arbeiten.

Nur weil Google dies tut, heißt das nicht, dass Sie es auch tun sollten.

Wir arbeiten in einer völlig anderen Galaxie. Google ist mit Problemen konfrontiert, auf die wir wahrscheinlich nie stoßen werden, aber gleichzeitig können wir Dinge tun, die Google nicht kann.

Wie starten die meisten Softwareprojekte?

Viele Projekte beginnen mit einer Person, die die ganze Arbeit erledigt. Es gibt eine Million Beispiele, aber werfen wir einen Blick auf Shopify. Ursprünglich verschlüsselte der Dienst Tobias Lyutke (er basierte auf Ruby on Rails und funktioniert übrigens immer noch auf "Rails").

Denken Sie, Tobias zögerte und dachte sorgfältig über die ideale Architektur für Microservices nach, bevor er die erste Codezeile schrieb?

Hölle nein. Ich war nicht anwesend, als ich die erste Version von Shopify entwickelte, die ursprünglich nur ein Online-Shop für Snowboarden war, aber wenn Tobias wie ich (ein typischer Entwickler) aussieht, sah der Prozess ungefähr so ​​aus:

1. Lernen Sie neue Technologien, während Sie das Originalprodukt schreiben.
2. Schreiben Sie einen eher nicht standardmäßigen (bösen), aber voll funktionsfähigen Code.
3. Sehen Sie, wie alles zusammenarbeitet und freuen Sie sich.
4. Refactor wie "Brennen mit Feuer" und verbessern Sie den Code, wenn ein Problem auftritt.
5. Wiederholen Sie diesen Zyklus, wenn Sie neue Funktionen hinzufügen und in einer Produktionsumgebung starten.

Dies mag wie ein sehr einfacher Zyklus erscheinen, aber ich habe ungefähr 20 Jahre programmiert, um herauszufinden, wie tief er ist.

Als Programmierer werden Sie nicht besser, wenn Sie theoretisch die optimalen Einstellungen durchdenken, bevor Sie die erste Codezeile schreiben. Sie werden besser, indem Sie viel Code mit der absoluten und expliziten Absicht schreiben, fast alles, was Sie schreiben, durch besseren Code zu ersetzen, sobald Sie anfangen, echte Probleme zu haben.

Der ursprüngliche Code, den Sie ersetzt haben, ist keine Zeit- oder Arbeitsverschwendung. Im Laufe der Zeit hilft es Ihnen sehr, Ihr Niveau zu verbessern. Dies ist eine geheime Zutat.

Sprechen Sie über Code-Abstraktionen

Als Entwickler haben wir alle den Satz "TROCKEN: Wiederholen Sie sich nicht" gehört, und insgesamt ist es vernünftig, den Job nicht noch einmal zu machen. Aber oft lohnt es sich.

Es lohnt sich zu wiederholen, wenn Sie versuchen, etwas ohne volles Verständnis zu abstrahieren und eine sogenannte undichte Abstraktion zu erstellen.

Normalerweise mache ich die Arbeit dreimal, bevor ich überhaupt daran denke, Code umzugestalten und Duplikate zu entfernen. Oft ergreife ich erst nach dem 4. oder 5. Mal einige Maßnahmen.

Sie müssen wirklich mehrmals sehen, wie Sie den Code in verschiedenen Situationen duplizieren, bevor klar wird, was genau in Variablen übersetzt und an Stellen entfernt werden soll, an denen dieser Code ursprünglich geschrieben wurde.

Abstraktionsebenen, vom eingebetteten Code bis zu externen Bibliotheken:

1. Inline-Code schreiben.
2. Duplizieren Sie den Code an verschiedenen Stellen.
3. Extrahieren Sie doppelten Code in Funktion usw.
4. Verwenden Sie diese Abstraktionen für eine Weile.
5. Sehen Sie, wie dieser Code mit anderem Code interagiert.
6. Extrahieren Sie allgemeine Funktionen in die interne Bibliothek.
7. Verwenden Sie lange Zeit die interne Bibliothek.
8. Verstehe wirklich, wie alle Teile zusammenkommen.
9. Erstellen Sie eine externe Bibliothek (Open Source usw.), wenn dies sinnvoll ist.

Der Punkt ist, dass Sie keine gute Bibliothek oder ein gutes Framework „erfinden“ können. Fast alle sehr erfolgreichen Tools, die wir heute verwenden, stammen aus realen Projekten. Dort wird unser Lieblingswerkzeug aus realen Fällen des internen Gebrauchs extrahiert.

Rails ist ein gutes Beispiel. DHH (Autor von Rails) wachte eines Tages nicht auf und sagte: „Oh! Es ist Zeit, die Verzeichnisse models /, controller / und views /! Zu erstellen. “

Nein. Er entwickelte Basecamp (das eigentliche Produkt), dann erschienen bestimmte Vorlagen, und diese Vorlagen wurden verallgemeinert und dann aus Basecamp in Rails extrahiert. Dieser Prozess dauert noch heute an und meiner Meinung nach ist dies der einzige Grund, warum Rails so erfolgreich bleibt.

Dies ist ein idealer Sturm von sehr gut geführten (gelesen: nicht theoretisch entwickelten) Abstraktionen, kombiniert mit einer Programmiersprache, mit der Sie attraktiven Code schreiben können. Dies erklärt auch, warum fast alle Frameworks wie „Rails, nur in XYZ“ nicht funktionieren. Sie überspringen die Schlüsselkomponenten der Abstraktionskette und denken, dass sie Rails einfach duplizieren können.

Von Abstraktionen zu Microservices

Microservices sind für mich nur eine weitere Abstraktionsebene. Dies ist nicht unbedingt Schritt 10 in der obigen Liste, da nicht alle Bibliotheken für Microservices ausgelegt sind, aber auf konzeptioneller Ebene scheint dies so zu sein.

Microservices sind nicht der Ausgangspunkt, genauso wie Sie nicht sofort versuchen würden, die perfekte externe Open Source-Bibliothek zu erstellen, bevor Sie mindestens eine Codezeile schreiben. In diesem Moment wissen Sie noch nicht einmal, was Sie entwickeln.

Eine auf Mikroservices basierende Architektur kann aus einem Projekt im Laufe der Zeit werden, wenn Sie auf echte Probleme stoßen.

Vielleicht werden Sie diesen Problemen nie begegnen, und viele davon können unterschiedlich gelöst werden. Schauen Sie sich Basecamp und Shopify an. Sie funktionieren beide gut als monolithische Anwendungen.

Ich glaube nicht, dass jemand sie als klein bezeichnen wird, obwohl sie nicht auf einer Google-Skala funktionieren.

Shopify verdient mit Monolithen monatlich 17 Millionen US-Dollar

Ab Mitte 2018 hat Shopify öffentlich bekannt gegeben, dass mehr als 600.000 Online-Shops auf ihrer Plattform betrieben werden.

Shopify ist eine SaaS-Anwendung mit dem günstigsten Preis von 29 US-Dollar pro Monat, und ich habe das Gefühl, dass viele Unternehmen den Preis von 79 US-Dollar pro Monat wählen. Selbst wenn 600.000 Kunden den günstigsten Tarif für 29 US-Dollar nutzen, bedeutet dies auf jeden Fall ein monatliches Einkommen von 17,4 Millionen US-Dollar nur aus dem SaaS-Geschäftsbereich.

Die Basecamp App ist eine weitere großartige monolithische App. Das Interessante an Basecamp ist, dass es nur etwa 50 Mitarbeiter gibt und nur einige von ihnen Softwareentwickler sind, die am Hauptprodukt arbeiten.

Ich möchte sagen, dass Sie SEHR weit gehen können, ohne das Kaninchenloch von Microservices hinunterzugehen. Erstellen Sie nicht einfach so Microservices.

Wann sollten Microservices eingesetzt werden?

Es hängt alles von Ihrer Entscheidung ab. Dies ist nur eines der Dinge, bei denen Sie "Microservices gegen Monolithen" nicht googeln. Wenn Sie wirklich Microservices benötigen, wissen Sie bereits Bescheid.

Es kann jedoch vorkommen, dass Sie eine Reihe von Entwicklern haben, die am besten für die Arbeit an einzelnen Teilen der Anwendung geeignet sind. Die Anwesenheit von Dutzenden von Teams, die isoliert an verschiedenen Komponenten des Produkts arbeiten, ist einer der vernünftigen Gründe für die Verwendung für Microservices.

Denken Sie daran, dass Sie mit einem oder zwei Microservices beginnen können, wenn Sie ein kleines Team haben, das im Laufe der Zeit langsam wächst. In einer solchen Situation sollten Sie den Monolithen wahrscheinlich nicht sofort in 100 Mikrodienste aufteilen, beginnend mit einem Steinbruch.

Ist das Spiel die Kerze wert?

Erwähnenswert ist auch, dass der Übergang zu Microservices mit eigenen Problemen einhergeht. Sie ändern ein Problem gegen ein anderes, also müssen Sie die Vor- und Nachteile abwägen, ob das Spiel die Kerze speziell für Ihr Projekt wert ist.

Eines der Hauptprobleme ist die Überwachung. Plötzlich erhalten Sie eine Reihe von Diensten, die auf verschiedenen Technologie-Stacks geschrieben und auf mehreren Computern ausgeführt werden können - und Sie benötigen eine Möglichkeit, diese detailliert zu verfolgen.

Dies ist eine schwierige Aufgabe, da wir im Idealfall möchten, dass alle Microservices einen einzigen Überwachungsdienst verwenden.

Sie möchten wahrscheinlich keine eigenen Tools entwickeln, da dies an sich zu einer vollwertigen Arbeit werden kann. Dies ist der Grund für den Erfolg von Unternehmen wie LightStep . Dies ist einer der interessantesten Überwachungsdienste, auf die ich gestoßen bin.

Ihr Produkt konzentriert sich mehr auf Großanwendungen (es ist verständlich, warum), funktioniert aber auch für kleine Projekte. Ich habe kürzlich von ihnen gehört, weil sie am Cloud Field Day 4 vorgestellt wurden .

In jedem Fall ist die Überwachung nur eine von vielen Schwierigkeiten, aber ich habe beschlossen, sie zu erwähnen, weil sie eines der schmerzhaftesten Probleme ist.

Letzte Gedanken

Grundsätzlich habe ich diesen Artikel aus zwei Gründen geschrieben:

Erstens habe ich vor zwei Wochen Cloud Field Day 4 besucht und versehentlich an einem Gruppen-Podcast zu einem verwandten Thema teilgenommen. Es sollte in ein paar Monaten veröffentlicht werden, aber hier wollte ich auf einige Punkte eingehen.

Zweitens bekomme ich als Autor von Online-Kursen viele Fragen zum Erstellen eigener Anwendungen.

Viele Entwickler „frieren“ ein und versuchen, ihre Anwendungen in isolierte Dienste aufzuteilen, noch bevor sie die erste Codezeile geschrieben haben. Es kommt zu dem Punkt, dass sie von Anfang an versuchen, mehrere Datenbanken für Anwendungskomponenten zu verwenden.

Dieser Moment hindert sie daran, vorwärts zu kommen, und als Entwicklungskollege weiß ich, wie schwer es ist, in Unentschlossenheit zu stecken (ich hatte es!).

Übrigens arbeite ich derzeit an einer ziemlich großen SaaS-Anwendung - einer Plattform für das Hosten von benutzerdefinierten Kursen. Im Moment arbeite ich alleine an einem Projekt, und Sie können sicher sein, dass ich gerade den Editor geöffnet und am ersten Tag mit dem Schreiben von Code begonnen habe.

Ich werde das Projekt als vollständig monolithische Anwendung speichern, bis es sinnvoll ist, Microservices zu implementieren, aber mein Instinkt sagt mir, dass ein solcher Moment niemals kommen wird.

Was denkst du darüber? Lass es mich in den Kommentaren wissen.