Microservices im Vergleich zu Monolithic Arch.

Okay, ich glaube, wir sind live. Da steht, wir sind hier drüben. Es sollte nicht wie beim letzten Mal passieren. Wir dachten, wir wären live, aber wir waren aus irgendeinem Grund nicht live auf YouTube. So oder so. Also hallo und willkommen bei Momentum Office Hours. Mein Name ist Yash und ich werde von meinen Mitbegründern Harsh, Jay und Koushik begleitet. Um das Thema der Woche zu besprechen.

was eine monolithische Architektur im Vergleich zu einer Microservices-Architektur ist. Ich hoffe, ich habe das richtig gesagt. Unser Ziel ist es, Ihnen umsetzbare Erkenntnisse und praktische Strategien zu bieten, die Sie auf Ihre eigenen Produkte anwenden können. Während der gesamten Sitzung empfehlen wir Ihnen, Fragen zu stellen und Ihre Gedanken mitzuteilen. Dies ist eine fantastische Gelegenheit, voneinander zu lernen, neue Erkenntnisse zu gewinnen und auch Ihre SaaS-Initiativen voranzutreiben. Lassen Sie uns also loslegen. Jay, Harsh, Koushik, wie laufen die Dinge?

Läuft super. Genau in der Mitte der Woche, ich beende gerade die Besprechungen und plane die nächsten. Fahren Sie mit dem Flow fort und dann haben wir den Podcast-Zeitplan. Ich bin ziemlich beschäftigt damit. Wenn wir dann zu den Bürozeiten kommen, ist das ein interessantes Thema. Um ganz ehrlich zu sein, kleiner Technikfreak aus meiner Sicht. Und es ist interessant. Ich habe einige Fragen von meiner Seite, aber ich möchte, dass andere anfangen.

Es versteht sich von selbst, dass heute keiner von uns dreien dieses Thema genug versteht, um etwas sagen zu können. Also, ich werde in diesem Fall die Führung übernehmen müssen. Also, fangen wir mit dem Grundlegenden an. Was ist die grundlegende und einzige Frage, für die wir qualifiziert sind, was ist monolithische Architektur und was ist dann Microservices-Architektur? Zum Beispiel, warum müssen wir reden

Warum ist das so einfach? Also kann ich nicht einfach eine einfache Architektur haben? Ja, also wenn Sie Architektur als einfache Architektur kennen, ist es eine monolithische Architektur. Architektur ist also eine monolithische Architektur. Also hast du einfach das Einfache als Wort genommen und es dann kompliziert gemacht. Ich nicht. Richtig.

Wir können also sagen, wenn Sie ein Produkt bauen möchten, haben wir viele Anwendungen. Es gibt also verschiedene Arten von Komponenten, Modulen. Wenn wir all diese Dinge in einem Produkt kombinieren, dann bauen wir ein Produkt. In der Monolithik sind all diese Komponenten, Funktionen und Module miteinander verbunden. Und wir können sagen, dass sie sich alle auf nur einem Server befinden. Das können wir also in einem Modul sagen.

all diese Module oder Komponenten sind kombiniert und es gibt eine große modulare Komponente und alles ist, Sie wissen schon, nur ein Server, das wird als monolithisch bezeichnet, wenn sie miteinander verbunden sind, während in monolithischen, wo in Microservices all diese Komponenten unabhängig voneinander sind und sie sehr unterschiedlich miteinander arbeiten und wenn sie miteinander kommunizieren wollen

wir können sagen, dass es eine API oder GLSK gibt, richtig, also kommunizieren sie miteinander, also können wir sagen, ich gebe ein Beispiel, Sie können eine Antwort bekommen, wir können sagen, wir können ein Beispiel nehmen, wir haben Amazon, Amazon, richtig, die Amazon-E-Commerce-Website, auf der sie eine Suche haben, sie haben eine Liste aller Produkte, richtig, wir haben eine Suche, bei der Sie suchen können wie F140 pro

Also, all diese Dinge sind kleine Kernkomponenten und wo sind all diese Komponenten

Wenn ich also vernetzt sage, was bedeutet dann vernetzt? Auf diese Weise haben all diese Dinge dieselbe Codebasis. Sie haben dasselbe Text-Tag. Sie haben ein Repositorium für all diese Dinge. Und wenn all das miteinander verbunden ist, dann ist das eine der monosynchronen Architekturen.

Ja, wenn ich es richtig verstehe, in Bezug auf das Beispiel, das Sie mit der E-Commerce-Plattform genannt haben, heißt das, dass sie, wenn sie eine Microservices-Architektur als Beispiel haben, die Zahlungsabwicklungsdienste einfach unabhängig voneinander optimieren oder skalieren können, ohne etwas an den Produktkatalogdiensten oder einem anderen Modul an sich zu ändern? Ja, CCL ist also einer der Vorteile, oder? Mit der Skalierbarkeit, oder?

Ja, also sage ich dir, also sage ich dir, Amazon-Inventarverwaltung, Rechnungsverwaltung, Produktmanagement, kann die Benachrichtigung richtig sagen, wo ist meine Bestellung für dieses Ding. Hier sind die kleinen Module. Bedenken Sie jetzt einfach, dass ich meine Angebotsseite verbessern möchte. Sie können die Inventarseite richtig sagen, auf der Amazon alle Produkte speichert. Wenn ich nun optimieren will, also du kannst sagen, richtig skalieren, wenn ich das Ding richtig skalieren will,

Also dafür, wenn all diese Komponenten miteinander verbunden sind, oder? Also, wenn ich skaliere, kannst du sagen, dass ich ein paar Kleinigkeiten habe, oder? Und dann ich, das ist mein großes Problem, oder? Und all diese Dinge werden automatisch zu den letzten. Es gibt eine ganze Anforderung nur für das Inventar, das kannst du sagen. Ich will nicht für mein, du kannst sagen, das, du weißt schon, Management skalieren oder nicht, sie sind völlig in Ordnung. Also

In der Monologie gibt es also einen Nachteil. Wenn Sie ein Modul skalieren möchten, oder wir können sagen, die eine Funktion, kann das nicht monologisch ablaufen. Wenn wir verkleinern, wird die gesamte Anwendung zu einer Skala. Das ist also einer der Vorteile, wir können sagen, derselbe Vorteil, den wir beim Microservice haben. Nun, so sage ich es Ihnen, also in der Monologie sind das alles

Im Microservice, was wir tun können, teilen wir diese Komponenten oder Module in die verschiedenen auf, wir können sagen, die Kategorie, in der sie unterschiedliche Textraten haben, sie haben unterschiedliche Server in der Datenbank, sie haben verschiedene Server, sie haben verschiedene Server, jetzt, wenn du willst, kannst du alles kaufen, richtig und danach gibt es eine Rechnungsverwaltung, Buchungsverwaltung, also gibt es eine andere Serverdatenbank

und dann können wir sagen, dass es eine Benachrichtigung gibt, dass es einen anderen Server oder eine andere Datenbank gibt. Nun, wenn ich weiß, dass es, sagen wir mal, Black Friday gibt, wo sie viel Traffic auf meiner eigenen Angebotsseite haben, oder? Aber meine Güte, du kannst sehen, dass der Versand und die Benachrichtigungsdienste im High-End-Bereich einwandfrei funktionieren. Wenn ich skalieren möchte, muss ich nur meine Inventarverwaltungsdatenbank oder meinen Server im großen Maßstab erweitern. Also von diesem Weg aus können wir

Ich kann sagen, dass wir das können, wenn wir ein hohes Ziel haben, dann ist unser Service skalierbar, aber wir müssen unsere verschiedenen Module nicht für verschiedene Dienstleistungen wie die Rechnung skalieren, sonst können wir sagen, dass es keine Sicherheit gibt. Also hier ist eine Analogie und sag mir, ob das eine gute Art ist, darüber nachzudenken. Also als Beispiel: Alle Menschen, alle Menschen oder alle Tiere sind monolithische Architekturen

wenn sie wachsen, skalieren sie mit der gleichen Geschwindigkeit. Wie auch immer, wenn du an Dr. Reed Richards denkst, der wie eine der Figuren in Die Fantastischen Vier ist, der wie der elastische Mann ist. Wenn er also den Bösewicht erwischen wollte, könnte er seine Arme wirklich wachsen lassen, er könnte seine Arme, Beine oder seinen Hals wachsen lassen, je nachdem, welchen Bösewicht er fangen wollte.

Also sind das Microservices? so. Eine sehr schlechte Analogie, aber ist das für einfache Leute wie uns, die keine Techniker sind, eine gute Vorstellung, dass ich in der Lage sein werde, einen bestimmten Teil meiner Anwendung bei Bedarf unverhältnismäßig mit anderen zu skalieren? Ja, richtig. Ja, also das Beispiel wird sein, wir können sagen, nicht 100%, aber 50%, es ist so, als ob das Beispiel, das du gesagt hast, da ist ein Frauenkörper,

Warum muss eine App also verschiedene Teile von sich selbst skalieren?

in etwa in einem anderen Verhältnis, oder? Wenn ich zum Beispiel etwa 1000 Benutzer habe, die fünf Funktionen meiner Anwendung nutzen, warum, meine ich, wenn aus diesen 1000 Benutzern 10.000 Benutzer werden, verwenden sie dann nicht alle meine Apps, also meine gesamte App muss auf das 10-fache skaliert werden, warum sollte eine unverhältnismäßige Skalierung erforderlich sein? Ja, also sage ich dir,

Lass uns über die FIFA-Weltmeisterschaft sprechen. Das ist globaler.

Sie streamen das Fußballspiel live. Es gibt also zwei Komponenten. Erstens steht J &K für die Liste der Spiele. Aktuelle oder wir können sagen, bevorstehende Spiele. Denken Sie jetzt an den Traffic, den wir in der Liste der Spiele bekommen. Hier kannst du sagen, wie die aktuellen Ergebnisse sind, was die kommenden Spiele sind. Und der Traffic, den wir im Live-Streaming bekommen.

Beide sind sehr unterschiedlich. Nun, ich kann sagen, jetzt gibt es vor allem diejenigen hier, die live sind, sie schauen sich den Live-Stream eines Fußballspiels an. 20 Millionen Menschen schauen zu. 20 Millionen Menschen schauen den Live-Stream auf der 25x. Also kommen diese Leute nicht

Wir können die Auflistungsseite sagen, auf der sie einfach den Verlauf oder kommende Bilder aufrufen können, oder? Wir brauchen das also nicht Wir brauchen jetzt nicht Wir können sagen, dass es denselben Verkehr gibt. Es gibt einen anderen Verkehr, oder? Jetzt können wir sagen, dass das jetzt einer sein sollte. Deshalb brauchen wir das, oder? Also denke ich nur über unsere Geschichte nach

Es ist in zwei Dinge unterteilt, die Auflistung und das Live-Streaming. Auch wenn auf der Listing-Seite nur sehr wenig Traffic herrscht, ich ihn aber nicht posten kann, muss ich meinen Server oder eine gewisse Kapazität erhöhen. Also muss ich X Betrag für diesen Service bezahlen. Überlegen Sie sich nun, ob ich diesen Service in zwei Komponenten unterteile, eine ist die Auflistung und die andere ist der Service.

Wenn ich die Anforderungen für das Listing und das Streaming beibehalte, ist das anders. In diesem Fall ist die Belastung also sehr gering, denn selbst wenn der Traffic zunimmt, muss ich nur meine Skalierbarkeit auf dem Streaming-Server erhöhen, nicht auf dem Listing-Server. Ich kann also sagen, dass die Leistung des Streaming-Servers gering ist. Das Streaming wird hoch sein, aber insgesamt ist es geringer als wenn ich nur einen Server habe.

die beide in einem Setup haben. Das sind also auch die Unterschiede. Nun, je nach Anwendungsfall, wenn ich einen Livestream habe, was ist dann die beste Technologie, die ich verwenden kann? Der untere Schreibtisch ist das Beste an der Software und er eignet sich gut für den Livestream. Wenn wir über die Auflistung sprechen.

Wir können also sagen, dass Python oder Django gut für die Auflistung sind. Aber wenn ich eine Microservice-Architektur habe, bei der die beiden Modi unterschiedlich sind, kann ich unterschiedlichen Texttext verwenden, eine andere Datenbank. Aber wenn es nur einen Server gibt, dann muss ich das reparieren, entweder muss ich mehr Text verwenden oder Python. Also je nach Festplattengehäuse oder Ausstattung, wenn ich meinen Texttext oder meine Datenbank ändern will, dann geht das nur mit Microflash.

Also hier ist noch ein Like, also wenn ich bedenke, dass ich Maschinenbauingenieur bin, versuche ich, in diesem Bereich Analogien zu finden, um es ein bisschen besser zu verstehen. Das ist also auch wie eine klassische Herausforderung mit Montagelinien, oder? Nehmen wir als Beispiel an, es gibt eine Montagelinie für die Montage eines iPhones, wenn das Aufsetzen der Kamera zwei Minuten dauert, das Aufsetzen des Chips aber fünf Minuten, was würdest du dann wollen

ist, du willst zwei Stationen haben, die den Chip einsetzen und eine Station, die die Kamera einsteckt und dann leitet das nur den Verkehr um. Also gewissermaßen und dann können Sie im Grunde sicherstellen, dass es keine Engpässe gibt und dass Sie das auch nicht müssen, Sie können eine Komponente ziemlich unabhängig von der anderen Komponente skalieren, und zwar zu Zeiten, in denen Spitzenverkehr herrscht oder zu Zeiten

in sehr kurzer Zeit wird eine große Anzahl von Leuten mitmachen, das wirst du immer noch schaffen können. Die nächste Frage, die ich habe und die ich von Ihnen verstehen möchte, lautet: Ich gehe davon aus, dass die meisten Leute, wenn sie anfangen, ihr Produkt zu bauen, damit beginnen, es monolithisch zu bauen, weil es einfach ist. An welchem Punkt denken Sie darüber nach, welche Kennzahl eintreten muss, welches Ereignis eintreten muss, das den Übergang von monolithischen zu Microservices auslösen sollte?

Architektur.

dass ich unsere Plattform benutze. Und jetzt können wir sagen, dass meine CPU zu der Zeit quasi war, wir können sagen, dass es nur zwei GB RAM gibt, richtig, zwei RAM. Sie werden von 1000 Benutzern verwaltet. Wenn das Produkt erst einmal wächst, stimmt, der Klassiker wird, wie gesagt, von 1000 bis wir sagen können, dass das Kontinuum nur aus Benutzern besteht, richtig, sie nutzen die Plattform bereits. Also dafür, wenn ich will

Wenn ich will, dass mein Produkt stabil läuft, muss ich meinen Server erhöhen. Es wird 4 Jobs geben. Jetzt wird der Verkehr wieder hoch sein und ich muss 4 auf 6 erhöhen. Es gibt eine horizontale Skalierung nach rechts. 2 bis 4, 4 bis 6, 6 bis 8. Es wird sehr hohe Kosten haben. Sobald du es weißt

Das ist natürlich mein gewisses Limit. Ich kann diesen Kurs nicht überschreiten. Das ist also eine Art von Problem. Das ist also ein Kurs. Jetzt muss ich den Kurs so aufteilen, dass er kürzer wird, denn wenn das Produkt erst einmal richtig läuft, ist es unwahrscheinlich, dass wir 10 Module haben und alle diese 10 Module den gleichen Traffic haben, alle haben dieselben Benutzer. Es gibt ein paar von zwei Dingen.

sehr wichtig für das Produkt. Die meisten Benutzer nutzen das ja, ein Teil des Dienstes, dann haben wir für den Service, den wir sind, hohe Kosten. Also auf diese Weise, wenn wir von den Hauptkomponenten weggehen. Auf diese Weise können wir die Modalität auf zwei oder drei Dienste aufteilen. Und was die Umwelt angeht, müssen wir herausfinden, welcher Dienst sich am besten von der Modalität lösen lässt.

ob es meistens so ist oder nicht. Also zuerst die Skalierbarkeit. Sobald wir wissen, dass es ein hohes Niveau gibt, können wir loslegen. Die zweite Sache ist die Flexibilität. Wenn wir nun ein Modell starten, müssen wir uns für einen Texttyp entscheiden, wie den Node.js oder Python. Jetzt kommt ein neues Feature. Wir haben den Vorschlag geändert.

dass wir mehrere Benutzer zulassen. Jetzt wissen wir, wenn du das implementieren willst, dann ist das ein Text-Tag, das ist das Beste dafür. Ich kann nicht dasselbe Text-Tag verwenden, da sie nicht gut in der Lage sind, diese Art von Verkehr zu bewältigen. Wenn wir das wissen, wenn wir über diese Art von Ressourcen verfügen, dieses Text-Tag für die Datenbank kennen, ist es das Beste für diesen Fall.

wir müssen von einer Kante zur anderen Seite gehen. An zweiter Stelle steht also die Flexibilität. Drittens ist die Wartbarkeit. Wir können sagen, dass wir ungefähr 10 Leute in meinem Team haben. Jeder ist in einem Modul. Nun, wenn man welche einsetzen will

neue Änderungen in der Produktion. Zur gleichen Zeit unterscheidet auch das Team 2 dort alle Änderungen an der Produktion. Also, jetzt werden die beiden Mitglieder die verschiedenen Dinge in der Produktion einsetzen. Wenn wir einen Server haben, müssen wir überprüfen, ob sich dies auf einen der beiden Änderungen auswirkt oder nicht. Also, wenn wir wissen, ob das so ist, behalten Sie es bei

Wenn die Kosten für die Wartung sehr hoch sind, können wir sagen, dass unser Produkt nicht kaputt ist, weil wir warten müssen. Dann müssen wir viele Denkversuche machen. Es wird zu viel Zeit in Anspruch nehmen. In dieser Zeit wissen wir, dass es an der Zeit ist, von Logik zu Microservice überzugehen. Dann teilen wir die Antwort damit auf. Dann, damit jedes Modul oder alles seinen Kern auf seiner Website einsetzen kann oder ich mir überlegen muss, wie ich das machen kann.

Jetzt, wo die meisten Produkte richtig fließen, können wir sagen, wenn es nur wenige Änderungen gibt, wenn verschiedene Produkte richtig sind, dann können wir sagen, dass die gesamte Anwendung kaputt ist. Jetzt können wir

wie das geneigte oder was auch immer das richtige Produkt ist. Die Hauptsache ist, dass du dich anmeldest und einloggst, du machst es immer richtig. Selbst wenn etwas passiert ist, aber der Benutzer kann sich anmelden, wenn es ein monolithisches Recht gibt und wenn Sie das sagen können, weil sich das Zahlungsmodul geändert hat oder die Effizienz beeinträchtigt ist. Jetzt geht es zu meinen Recherchen, richtig, denn meine Autorisierung, mein Anmeldemodul ist ebenfalls ausgefallen.

Jetzt ist es wichtig, bei der Anmeldung den Lead zu bekommen, auch wenn meine Bewerbung nicht verfügbar ist. Bei JTM müssen wir unsere App so aufteilen, dass wir sagen können, dass das Autorisierungsmodul für die Anwendung unterschiedlich ist. Selbst wenn wir etwas bereitstellen, funktionieren beide Module unserer Anwendung einwandfrei. Damit wir die Führung übernehmen können. Also gibt es vier Dinge, die wir hauptsächlich sagen können wie

Das ist eine von uns müssen entscheiden, welche Eigenschaften für uns wichtig sind und dafür müssen wir und wann wir erreichen, wenn wir wissen, dass dies ein sehr wichtiges Merkmal für uns ist, zu diesem Zeitpunkt müssen wir von monolithisch zu makro-saturnisch übergehen. Heißt das also, ist es möglich, eine Gruppe zu haben, die monoplethisch ist, eine Mischung aus beiden? Ist das überhaupt

habe einen monolithischen und einen Microservice. Ich denke, eine Mischung aus beiden ist per Definition Microservices. Sobald Sie eine Komponente haben, die aus dem Monolithen herausfällt, wird sie zu einem Dualith oder gehört per Definition zu Microservices, denke ich. Auch das ist eine Vermutung.

Ich habe meine Autorisierungsmodule von der Anwendung getrennt. Sie können also sagen, dass ich jetzt die Microsoft-Architektur habe, in der die Autorisierung die Microsoft-Architektur hat, aber meine Anwendung immer noch monolithisch ist. In meiner Anwendung gibt es also immer noch so viele Komponenten, dass sie miteinander verbunden sind. Ja. Eines möchte ich noch hinzufügen: Harsh, den du in Bezug auf ein Beispiel dort erwähnt hast, weißt du, dass bestimmte grundlegende

wie Anmelden und Einloggen werden hier sein. Diese Dinge sollten nicht ausfallen, wenn wir bestimmte Funktionen bereitstellen. Bedeutet das also, dass selbst die Integration einer Microservices-Architektur in das Produkt die Ausfallzeiten bei der Implementierung neuer Bereitstellungen reduzieren würde? Nehmen wir zum Beispiel an, ein Produkt hat 11 Module, von denen nur ein oder zwei Module neu aktualisiert werden. Sie wissen also, dass die Bereitstellung dieser Module keine Auswirkungen auf andere Module haben würde. Dann lass uns auch die

Ausfallzeiten, die aufgrund der neuen Bereitstellung auftreten und dadurch ebenfalls reduziert werden. Ja, wir können also irgendwie Auswirkungen haben, aber es hat keine großen Auswirkungen, da der richtige Zeitpunkt für die Bereitstellung nicht so sehr von den Microservices abhängt. Wenn wir das Deployment mit dem anderen durchführen, gibt es andere, wir können sagen, die Methoden wie die blau-grüne Architektur oder allgemein haben wir einige automatisiert, wenn wir diese verwenden.

das einzige Tool für den Einsatz, dann haben wir schon die Nullausfallzeit. Sie können sagen, wenn ich eine monolithische Architektur habe und etwas auf Produkten einsetzen möchte, gibt es nur wenige Änderungen, da bei der Monosil-Architektur alle Anwendungen erneut bereitgestellt werden, nicht nur kleine Änderungen. Wir können also sagen, dass es zwei Minuten dauern wird, die gesamte Anwendung bereitzustellen, auch wenn es nur wenige Änderungen gibt. Aber in

Wir können also sagen, dass der Zeitpunkt der Bereitstellung durch die Verwendung des Mikrodienstes reduziert werden kann.

was du erwähnt hast, es wird auf Microservices umgestellt, oder? Nehmen wir an, sie erreichen aus Teamsicht zwischen 25 und 50 Personen im Entwicklungsteam. Und jetzt wollen sie zur Microservices-Architektur übergehen. Wie wirkt sich die Anpassung an diese Microservice-Architektur auf die Teamorganisation und die Gesamtproduktivität aus?

Ja, wir können also sagen, auch wenn selbst in monolithischen Systemen die Dinge durch die Verwendung der Module geteilt werden. Richtig. Für das Team ist es also irgendwie schwierig, weil wir sagen können, dass die Genauigkeit unterschiedlich ist. Richtig. Aber wenn wir erst einmal entschieden haben, dass das Monolithikum genau ist, dann ist es für das Team schwierig, die neue Sprache und andere Dinge zu lernen, wenn die Übung geändert wird, richtig.

Ja, und trotzdem, selbst wenn wir von Microsoft wechseln, müssen wir so viele andere Dienste nutzen, oder? Genau wie derzeit, wenn es monolithische gibt, richtig, wenn sie die Daten von einem Modul zu einem anderen Modul senden wollen, richtig, es gibt einen einfachen Funktionsaufruf. Richtig? Sobald wir den Microservice aufgeteilt haben, richtig, danach gibt es zwei verschiedene Komponenten. Wenn es zwei Sprechanlagen gäbe, wären sie jeweils

Dann haben sie eine API direkt, wenn sie die Daten übertragen können. Also muss das Team diese API erstellen. Auf diese Weise kann man sagen, dass das Team lernen muss, aber das Team muss sich weiterentwickeln, so viele Änderungen vornehmen, um vom monolithischen zum Makro-Architekten zu werden. Und wie lange dauert es in der Regel, von einer monolithischen zur Microservice-Architektur überzugehen? Und wer mag das in einem Team?

das hat Full-Stack-Ingenieure, Frontend-Ingenieure, DevOps-Mitarbeiter, Produktmanager und Projektmanager. Ich gehe davon aus, dass Produkt- und Projektmanager das nicht wissen. Aber wer macht diese Aktivität? Wir können also sagen, wenn wir einmal gesagt haben, richtig, jetzt wollen wir von Microsoft wechseln, oder? Wir können also sagen, dass die Architektur zuerst eine ist, wir können die Architektur erstellen. Sehen Sie, wir berechnen die Dienstleistungen.

es kann mehr sein und es ist nicht so, dass es Dienste gibt, weniger mehr 10 Dienste, weniger konvertiert alle Dienste in eins, einmal. Richtig? Nun, was sind die, wir können sagen, weniger wirkungsvollen Dienste, oder? Denn wenn du umziehen willst, oder? Dann ist es auch ein Typ, wir können sagen, wir testen, oder?

der Übergang von der Microsoft-Architektur nach rechts. Also dieser spezielle Dienst, die Architektur, der wir folgen, ist richtig oder nicht. Weil es bei Microservices auch bei Microsoft verschiedene Dienste gibt. Ob es einen Server gibt oder wir können sagen, dass der Server elektrisch ist oder nicht. Ob Sie Lambda für den NK-Anruf verwenden müssen oder nicht. Wir wissen es also nicht. Also, was wir können

Was wir befolgen, ist die Liste der wichtigsten Dienstleistungen in unserem Produkt. Wir müssen diesen Service identifizieren und danach, wie wir diesen Architekten verschieben können, diesen Service von unserer Haupt-Codebasis entfernen und einmal wollen wir nach rechts gehen und dann müssen wir in Zukunft sehen, welches Tag-Tag wir verwenden wollen, welche Datenbank wir verwenden wollen, weil es bisher möglich war, dass wir eine Relationsdatenbank verwenden.

Aber jetzt, wegen so vieler Änderungen, ist es gut, von MySQL auf NoSQL umzusteigen. Diese Art von Entscheidung muss also getroffen werden, wenn wir von Microservices übergehen. Klingt nach einer langen und kollaborativen Übung, die uns nicht dazu bringen wird, neue Funktionen zu entwickeln.

Aber eine Sache, die ich sehr spannend fand, ich meine, ich fand es sehr interessant, basierend auf dem, was Ash erwähnt hat, dass jedes Modul auf dem effizientesten Tech-Stack dafür basiert, man nimmt das und implementiert es. Aber das würde es auch nicht bringen, das ist ein großer Teil des Kontos, es gibt eine Ebene der Komplexität, die sich daraus ergibt. Hätte nicht jeder Tech-Stack seine eigenen Möglichkeiten, damit umzugehen? Zum Beispiel wird das Debuggen sehr unterschiedlich sein.

von einer Textspur zu einer anderen Textspur. Wie gehen Sie also mit diesem Komplexitätsgrad um, wenn es darum geht? Also, der beste Weg ist, den besten einzustellen. Stellen Sie Leute ein, die das schon einmal gemacht haben. Ich denke, das ist eine Art, darüber nachzudenken.

Ja, und außerdem hat jeder Sprachauszug immer seine eigenen Eingabeaufforderungen. Deshalb ist es unwahrscheinlich, dass wir, wenn wir entscheiden, dass wir es verteilen wollen und sagen, ich möchte dieses Modul auf Mykologie umstellen. Es muss also einen Grund geben. Es gibt also einige Probleme, mit denen ich konfrontiert bin. Deshalb möchte ich umziehen.

Mein Chat funktioniert nicht einwandfrei. Das ist ein Problem. Wie repariere ich das? Was ist die beste Technologie, mit der ich das beheben kann? Dann, nachdem ich mich entschieden habe, Python, Node, diese sind alle verfügbar. Was ist das Beste, was ich entscheiden kann? Nach unserem Willen, auch nachdem wir die Sprache unterschrieben haben, ist das Gleiche, was Sie auch für die Datenbank beachten müssen. Wenn die Datenbank korrekt ist,

für meinen Anwendungsfall. Auf diese Weise können wir entscheiden, welche Technologie oder welche Datenbank perfekt für meine Microservices ist. Also ich denke, denke, denke, Koushik, wieder ein sehr ungenaues, vielleicht muss ich darüber nachdenken, ist, es ist so, es ist wie, wie viele Messer sollte man in der Küche haben, oder? Das hängt von der Größe der Küche ab. Also wenn ich koche für

wahrscheinlich sind ein oder zwei Messer okay. Aber wenn ich für etwa 150 Leute koche, dann brauche ich sechs verschiedene Messer. Also, sagen wir ein Messer, das zum Schneiden von Gemüse verwendet wird, ein anderes, das zum Schneiden von Fleisch verwendet wird, ein anderes, das speziell zum Schneiden von Fisch verwendet wird und solche Sachen. Also, wahrscheinlich sind diese sicher und wenn Sie also eine Küche betreiben, die 150 Personen bedient, und wenn Sie zwei Messer haben, dann wissen Sie, dass Sie in Schwierigkeiten geraten werden.

Der Schnitt wird nicht schnell genug sein, wird nicht fein genug sein, wird nicht gut genug sein und ich denke, es erhöht die Komplexität auf jeden Fall, weil es einige Messer geben wird, weißt du, an dem Abend ist niemand ins Restaurant gegangen und hat Fisch bestellt, also das Messer liegt einfach da auf der Küchentheke, aber das ist okay, weil es einen Abend geben wird, an dem alle reinkommen und Fisch bestellen werden und ich denke, was ist das interessant hier

Ich denke, das war ein großartiges Gespräch. Vielen Dank, Harsh, dass Sie gekommen sind und über monolithische Architektur und Microservices-Architektur gesprochen haben. Das war ein gutes Gespräch und vielen Dank an alle, die mitgemacht haben, während die Sitzung live war. Wenn Ihnen das Gespräch, das wir geführt haben, gefallen hat und Sie mehr sehen möchten, lassen Sie es uns wissen. Wir machen das jeden Mittwoch abends.

Und wenn Sie ein bestimmtes Thema haben, das wir behandeln sollen, wissen Sie, Koushik ist unser Designleiter, Jay ist unser Wachstumschef, Harsh ist unser technischer Leiter. Während des gesamten Produktlebenszyklus würden wir uns freuen, ein Gespräch zu führen und darüber zu sprechen. Und Sie können sich uns anschließen, in den Kommentaren Fragen stellen und solche Dinge. Nun, danke euch allen fürs Mitmachen. Und bis zum nächsten Mal, bis bald. Tschüss. Tschüss. Tschüss.

‍

‍