Am 25. April veranstalteten wir von der Mail.ru Group eine Konferenz über Wolken und Umgebung – . Ein paar Highlights:
- Das Wichtigste — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center und Yandex.Cloud sprachen über die Besonderheiten unseres Cloud-Marktes und ihrer Dienste;
- Kollegen von Bitrix24 erzählten, wie sie ;
- Leroy Merlin, Otkritie, Burger King und Schneider Electric sorgten für Interessantes – welche Aufgaben ihr Unternehmen der IT stellt und welche Technologien, darunter auch Cloud-Technologien, sie für die vielversprechendsten halten.
Alle Videos der mailto:CLOUD-Konferenz können Sie hier ansehen , und hier können Sie lesen, wie die Diskussion um Microservices verlaufen ist. Alexander Deulin, Leiter des Forschungs- und Entwicklungszentrums für Geschäftssysteme von MegaFon, und Sergey Sergeev, Direktor für Informationstechnologie der M.Video-Eldorado-Gruppe, berichteten über ihre erfolgreichen Beispiele für die Beseitigung von Monolithen. Wir haben auch damit verbundene Fragen der IT-Strategie, der Prozesse und sogar der Personalabteilung besprochen.
Diskussionsteilnehmer
- Sergey Sergeev, Konzern-CIO „M.Video-Eldorado“;
- Alexander Deulin, Leiter des Zentrums für Forschung und Entwicklung von Geschäftssystemen MegaFon;
- Moderator – Dmitri Lasarenko, Leiter der PaaS-Abteilung Mail.ru Cloud-Lösungen.
Nach der Rede von Alexander Deulin Zur Diskussion gesellen sich Sergey Sergeev von M.Video-Eldorado und Diskussionsmoderator Dmitry Lazarenko von Mail.ru Cloud Solutions.
Nachfolgend haben wir eine Abschrift der Diskussion für Sie vorbereitet, Sie können sich aber auch das Video ansehen:
Der Übergang zu Microservices ist eine Reaktion auf Marktbedürfnisse
Dmitry:
Haben Sie bereits erfolgreiche Erfahrungen mit der Migration auf Microservices gemacht? Und ganz allgemein: Wo sehen Sie den größten geschäftlichen Nutzen durch den Einsatz von Microservices oder den Übergang von Monolithen zu Microservices?
Sergey:
Wir sind bei der Umstellung auf Microservices schon einiges vorangekommen und nutzen diesen Ansatz seit mehr als drei Jahren. Der erste Bedarf, der den Bedarf an Microservices rechtfertigte, war die endlose Integration verschiedener Front-End-Produkte mit dem Backoffice. Und jedes Mal waren wir gezwungen, zusätzliche Integration und Entwicklung durchzuführen und unsere eigenen Regeln für den Betrieb dieses oder jenes Dienstes zu implementieren.
Irgendwann wurde uns klar, dass wir den Betrieb unserer Systeme und die Ausgabe von Funktionalität beschleunigen mussten. Zu diesem Zeitpunkt gab es bereits Konzepte wie Microservices und einen Microservice-Ansatz auf dem Markt und wir beschlossen, es auszuprobieren. Dies begann im Jahr 2016. Anschließend wurde die Plattform gelegt und die ersten 10 Dienste von einem separaten Team umgesetzt.
Einer der ersten Dienste, der am stärksten ausgelastet war, war der Preisberechnungsdienst. Jedes Mal, wenn Sie zu einem Kanal der M.Video-Eldorado-Unternehmensgruppe gelangen, sei es eine Website oder ein Einzelhandelsgeschäft, dort ein Produkt auswählen, den Preis auf der Website oder im „Warenkorb“ sehen, werden die Kosten automatisch angezeigt von einem Dienst berechnet. Warum ist das notwendig: Zuvor hatte jedes System seine eigenen Prinzipien für die Arbeit mit Werbeaktionen – mit Rabatten und so weiter. Die Preisgestaltung erfolgt über unser Backoffice, die Rabattfunktionalität ist in einem anderen System implementiert. Dies musste zentralisiert und ein einzigartiger, trennbarer Service in Form eines Geschäftsprozesses geschaffen werden, der es uns ermöglichte, dies umzusetzen. So ungefähr haben wir angefangen.
Der Wert der ersten Ergebnisse war sehr groß. Erstens konnten wir trennbare Einheiten schaffen, die es uns ermöglichen, getrennt und aggregiert zu arbeiten. Zweitens haben wir die Betriebskosten im Hinblick auf die Integration mit mehr Systemen gesenkt.
In den letzten drei Jahren haben wir drei Frontline-Systeme hinzugefügt. Es war schwierig, sie mit den gleichen Ressourcen zu unterhalten, die sich das Unternehmen leisten konnte. Daher entstand die Aufgabe, nach neuen Absatzmärkten zu suchen, die in Bezug auf Geschwindigkeit, interne Kosten und Effizienz auf den Markt reagieren.
So messen Sie den Erfolg der Migration auf Microservices
Dmitry:
Wie wird der Erfolg bei der Migration auf Microservices bestimmt? Was war das „Vorher“ in jedem Unternehmen? Welche Messgröße haben Sie verwendet, um den Erfolg des Übergangs zu bestimmen, und wer hat ihn tatsächlich bestimmt?
Sergey:
Erstens wurde es innerhalb der IT als Wegbereiter geboren – zur „Erschließung“ neuer Fähigkeiten. Wir mussten alles schneller und für relativ dasselbe Geld erledigen und auf die Herausforderungen des Marktes reagieren. Der Erfolg drückt sich nun in der Anzahl der von verschiedenen Systemen wiederverwendeten Dienste und der Vereinheitlichung der Prozesse untereinander aus. Jetzt ist es so, aber in diesem Moment war es eine Gelegenheit, eine Plattform zu schaffen und die Hypothese zu bestätigen, dass wir dies tun können, es wird eine Wirkung erzielen und den Geschäftsfall berechnen.
Alexander:
Erfolg ist eher ein inneres Gefühl. Unternehmen wollen immer mehr und die Höhe unseres Auftragsbestands ist ein Beweis für den Erfolg. Mir kommt es so vor.
Sergey:
Ja, ich stimme zu. In drei Jahren haben wir bereits mehr als zweihundert Services und einen Auftragsbestand. Der Bedarf an Ressourcen innerhalb des Teams wächst nur – jährlich um 30 %. Dies geschieht, weil die Menschen das Gefühl hatten: Es ist schneller, es ist anders, es gibt andere Technologien, das alles entwickelt sich.
Microservices werden kommen, aber der Kern wird bleiben
Dmitry:
Es ist wie ein nie endender Prozess, bei dem man in die Entwicklung investiert. Ist der Übergang zu Microservices für Unternehmen bereits abgeschlossen oder nicht?
Sergey:
Es ist sehr einfach zu beantworten. Was denken Sie: Der Austausch von Telefonen ist ein endloser Prozess? Wir selbst kaufen jedes Jahr Telefone. Und hier ist es: Solange Geschwindigkeit und Anpassung an den Markt erforderlich sind, sind einige Änderungen erforderlich. Das bedeutet nicht, dass wir auf Standarddinge verzichten.
Aber wir können nicht alles auf einmal abdecken und wiederholen. Wir verfügen über veraltete Standard-Integrationsdienste, die es schon vorher gab: Unternehmensbusse und so weiter. Aber es gibt einen Rückstand, und es besteht auch Bedarf. Die Zahl mobiler Anwendungen und deren Funktionalität wächst. Gleichzeitig sagt niemand, dass man 30 % mehr Geld bekommt. Das heißt, es gibt immer einerseits Bedürfnisse und andererseits das Streben nach Effizienz.
Dmitry:
Das Leben ist in einem guten Zustand. (lacht)
Alexander:
Im Allgemeinen ja. Wir haben keine revolutionären Ansätze, den Kern aus der Landschaft zu entfernen. Es wird systematisch daran gearbeitet, Systeme so zu zerlegen, dass sie besser mit der Microservice-Architektur übereinstimmen, um den Einfluss der Systeme aufeinander zu verringern.
Aber wir planen, den Kernteil beizubehalten, da es in der Betreiberlandschaft immer einige Plattformen geben wird, die wir kaufen. Auch hier brauchen wir ein gesundes Gleichgewicht: Wir sollten nicht voreilig den Kern herausschneiden. Wir platzieren die Systeme nebeneinander und nun stellt sich heraus, dass wir viele Kernteile bereits im Griff haben. Darüber hinaus entwickeln wir die Funktionalität und erstellen die notwendigen Darstellungen für alle Kanäle, die mit unseren Kommunikationsdiensten arbeiten.
So verkaufen Sie Microservices an Unternehmen
Dmitry:
Mich interessiert auch – für diejenigen, die noch nicht umgestiegen sind, es aber planen: Wie einfach war es, diese Idee an Unternehmen zu verkaufen, und war es ein Abenteuer, ein Investitionsprojekt? Oder war es eine bewusste Strategie: Jetzt gehen wir zu Microservices und das war's, nichts wird uns mehr aufhalten. Wie war es für dich?
Sergey:
Wir haben keinen Ansatz verkauft, sondern einen Geschäftsvorteil. Es gab ein geschäftliches Problem und wir haben versucht, es zu lösen. Zu diesem Zeitpunkt drückte sich dies darin aus, dass verschiedene Kanäle unterschiedliche Prinzipien zur Preisberechnung verwendeten – getrennt für Werbeaktionen, für Werbeaktionen usw. Die Wartung war schwierig, es traten Fehler auf und wir hörten auf Kundenbeschwerden. Das heißt, wir verkauften eine Lösung für ein Problem, kamen aber mit der Tatsache klar, dass wir Geld brauchten, um eine Plattform zu schaffen. Und sie zeigten einen Business Case am Beispiel der ersten Investitionsphase: Wie wir es weiterhin amortisieren und was wir dadurch tun können.
Dmitry:
Hast du die Zeit der ersten Etappe irgendwie aufgezeichnet?
Sergey:
Ja natürlich. Wir haben 6 Monate eingeplant, um den Kern als Plattform zu erstellen und den Piloten zu testen. Während dieser Zeit haben wir versucht, eine Plattform zu schaffen, auf der der Pilot skaten kann. Dann wurde die Hypothese bestätigt, und da sie funktioniert, können wir weitermachen. Sie begannen, das Team zu replizieren und zu stärken – sie verlegten es in eine separate Abteilung, die genau das tut.
Als nächstes folgt die systematische Arbeit basierend auf den Geschäftsanforderungen, Chancen, der Verfügbarkeit von Ressourcen und allem, was derzeit in Arbeit ist.
Dmitry:
OK. Alexander, was sagst du?
Alexander:
Unsere Microservices sind aus dem „Schaum des Meeres“ entstanden – aufgrund der Ressourcenschonung, aufgrund einiger Reste in Form von Serverkapazitäten und der Umverteilung der Kräfte innerhalb des Teams. Zunächst haben wir dieses Projekt nicht an Unternehmen verkauft. Dies war ein Projekt, bei dem wir sowohl recherchiert als auch entsprechend entwickelt haben. Wir sind Anfang 2018 gestartet und haben diese Richtung einfach mit Begeisterung weiterentwickelt. Der Verkauf hat gerade erst begonnen und wir sind dabei.
Dmitry:
Kommt es vor, dass ein Unternehmen Ihnen erlaubt, solche Dinge wie Google zu tun – an einem freien Tag in der Woche? Haben Sie eine solche Richtung?
Alexander:
Parallel zur Forschung beschäftigten wir uns auch mit Geschäftsproblemen, sodass alle unsere Microservices Lösungen für Geschäftsprobleme sind. Nur zu Beginn haben wir Microservices entwickelt, die einen kleinen Teil der Abonnentenbasis abdeckten, und jetzt sind wir in fast allen Flaggschiffprodukten vertreten.
Und die materiellen Auswirkungen sind bereits klar – wir können bereits gezählt werden, die Geschwindigkeit der Produkteinführungen und die Umsatzeinbußen können abgeschätzt werden, wenn wir den alten Weg gegangen wären. Darauf bauen wir den Fall auf.
Microservices: Hype oder Notwendigkeit?
Dmitry:
Zahlen sind Zahlen. Und Einnahmen oder eingespartes Geld sind sehr wichtig. Was ist, wenn Sie auf die andere Seite schauen? Es scheint, dass Microservices ein Trend, ein Hype sind und viele Unternehmen ihn missbrauchen? Wie klar unterscheiden Sie zwischen dem, was Sie in Microservices umsetzen, und dem, was nicht? Wenn Sie jetzt ein Vermächtnis haben, werden Sie dann in 5 Jahren noch ein Vermächtnis haben? Wie alt werden die Informationssysteme sein, die in 5 Jahren bei M.Video-Eldorado und MegaFon funktionieren? Wird es zehn oder fünfzehn Jahre alte Informationssysteme geben oder wird es eine neue Generation sein? Wie sehen Sie das?
Sergey:
Mir scheint, dass es schwierig ist, sehr weit weg zu denken. Wenn wir zurückblicken, wer hätte gedacht, dass sich der Technologiemarkt auf diese Weise entwickeln würde, einschließlich maschinellem Lernen und Benutzeridentifizierung per Gesicht? Aber wenn man sich die kommenden Jahre anschaut, kommt es mir so vor, als ob Kernsysteme, Systeme der Enterprise-ERP-Klasse in Unternehmen – sie funktionieren schon seit geraumer Zeit.
Unsere Unternehmen sind zusammen 25 Jahre alt, wobei klassisches ERP sehr tief in der Systemlandschaft verankert ist. Es ist klar, dass wir einige Teile daraus herausnehmen und versuchen, sie in Microservices zusammenzufassen, aber der Kern wird bleiben. Ich kann mir jetzt nur schwer vorstellen, dass wir dort alle Kernsysteme ersetzen und schnell auf die andere, positive Seite der neuen Systeme wechseln.
Ich bin ein Befürworter der Tatsache, dass alles, was näher am Kunden und Verbraucher ist, dort liegt, wo der größte geschäftliche Nutzen und Wert liegt, wo Anpassungsfähigkeit und Fokus auf Geschwindigkeit, auf Veränderung, auf „ausprobieren, abbrechen, wiederverwenden, etwas anderes machen“ liegen nötig“ – da wird sich die Landschaft verändern. Und verpackte Produkte passen dort nicht so gut hinein. Zumindest sehen wir es nicht. Da sind die einfachsten, einfachsten Lösungen gefragt.
Wir sehen diese Entwicklung:
- Kerninformationssysteme (hauptsächlich Backoffice);
- mittlere Schichten in Form von Microservices verbinden den Kern, aggregieren, erstellen einen Cache usw.;
- Frontline-Systeme richten sich an den Verbraucher;
- eine Integrationsschicht, die im Allgemeinen in Marktplätze, andere Systeme und Ökosysteme integriert ist. Diese Schicht ist so leicht wie möglich, einfach und enthält ein Minimum an Geschäftslogik.
Aber gleichzeitig bin ich ein Befürworter dafür, die alten Prinzipien bei entsprechender Anwendung weiterzuführen.
Nehmen wir an, Sie haben ein klassisches Enterprise-System. Es ist in der Landschaft eines Anbieters angesiedelt und besteht aus zwei Modulen, die miteinander arbeiten. Es gibt auch eine Standard-Integrationsschnittstelle. Warum es wiederholen und dort einen Microservice einführen?
Aber wenn es im Backoffice 5 Module gibt, aus denen Informationen in einem Geschäftsprozess gesammelt werden, der dann von 8–10 Frontline-Systemen genutzt wird, ist der Vorteil sofort spürbar. Sie nutzen fünf Back-Office-Systeme und erstellen einen isolierten Service, der sich auf den Geschäftsprozess konzentriert. Machen Sie den Dienst technologisch fortschrittlich, sodass er Informationen zwischenspeichert, fehlertolerant ist und auch mit Dokumenten oder Geschäftseinheiten funktioniert. Und Sie integrieren es nach einem einzigen Prinzip in alle Frontline-Produkte. Sie haben das Frontline-Produkt gekündigt – sie haben einfach die Integration deaktiviert. Morgen müssen Sie eine mobile Anwendung schreiben oder eine kleine Website erstellen und nur einen Teil in die Funktionalität integrieren – alles ist ganz einfach: Sie haben es wie einen Konstrukteur zusammengestellt. Ich sehe eine weitere Entwicklung in diese Richtung – zumindest in unserem Land.
Alexander:
Sergey hat unseren Ansatz vollständig beschrieben, vielen Dank. Ich sage nur, wohin wir auf keinen Fall gehen werden – zum Kernteil, zum Thema Online-Abrechnung. Das heißt, Bewertung und Aufladung bleiben in der Tat ein „großer“ Drescher, der zuverlässig Geld abschreibt. Und dieses System wird weiterhin von unseren Aufsichtsbehörden zertifiziert. Alles andere, was auf Kunden ausgerichtet ist, sind natürlich Microservices.
Dmitry:
Hier ist die Zertifizierung eine Sache. Wahrscheinlich mehr Unterstützung. Wenn Sie wenig für den Support ausgeben oder das System keinen Support und keine Modifikation benötigt, ist es besser, es nicht anzufassen. Ein vernünftiger Kompromiss.
So entwickeln Sie zuverlässige Microservices
Dmitry:
Bußgeld. Aber ich bin immer noch interessiert. Jetzt erzählen Sie eine Erfolgsgeschichte: Alles war gut, wir sind auf Microservices umgestiegen, haben die Idee gegenüber dem Unternehmen verteidigt und alles hat geklappt. Aber ich habe auch andere Geschichten gehört.
Vor ein paar Jahren schloss ein Schweizer Unternehmen, das zwei Jahre in die Entwicklung einer neuen Microservice-Plattform für Banken investiert hatte, das Projekt schließlich ab. Völlig zusammengebrochen. Es wurden viele Millionen Franken ausgegeben, aber am Ende wurde das Team zerstreut – es hat nicht geklappt.
Hatten Sie ähnliche Geschichten? Gab oder gibt es Schwierigkeiten? Beispielsweise bereiten die Wartung und Überwachung von Microservices auch im operativen Betrieb des Unternehmens Kopfzerbrechen. Schließlich erhöht sich die Anzahl der Komponenten um das Zehnfache. Wie sehen Sie das, gab es hier erfolglose Beispiele für Investitionen? Und was können Sie den Menschen raten, damit sie nicht auf solche Probleme stoßen?
Alexander:
Zu den erfolglosen Beispielen gehörten Unternehmen, die ihre Prioritäten änderten und Projekte absagten. In einem guten Stadium der Bereitschaft (tatsächlich ist der MVP bereit) sagte das Unternehmen: „Wir haben neue Prioritäten, wir gehen zu einem anderen Projekt über und dieses schließen wir ab.“
Wir hatten keine globalen Ausfälle bei Microservices. Wir schlafen ruhig, wir haben einen 24/7-Dienstdienst, der das gesamte BSS [Business Support System] betreut.
Und noch etwas: Wir vermieten Microservices nach den Regeln, die für Boxed-Produkte gelten. Der Schlüssel zum Erfolg liegt darin, dass Sie zunächst ein Team zusammenstellen müssen, das den Microservice vollständig für die Produktion vorbereitet. Die Entwicklung selbst beträgt bedingt 40 %. Der Rest sind Analysen, DevSecOps-Methodik, die richtigen Integrationen und die richtige Architektur. Besonderes Augenmerk legen wir auf die Grundsätze der Erstellung sicherer Anwendungen. Vertreter der Informationssicherheit nehmen an jedem Projekt sowohl in der Architekturplanungsphase als auch während des Implementierungsprozesses teil. Sie verwalten auch Systeme zur Analyse von Code auf Schwachstellen.
Nehmen wir an, wir stellen unsere zustandslosen Dienste bereit – wir haben sie in Kubernetes. Durch die automatische Skalierung und Erhöhung der Dienste kann jeder ruhig schlafen und die Dienstschicht nimmt Vorfälle auf.
Im gesamten Bestehen unserer Microservices gab es nur ein oder zwei Vorfälle, die unsere Leitung erreichten. Jetzt gibt es keine Probleme mit der Bedienung. Wir haben natürlich nicht 200, sondern etwa 50 Microservices, aber sie werden in Flaggschiffprodukten verwendet. Sollten sie scheitern, wären wir die ersten, die davon erfahren würden.
Microservices und HR
Sergey:
Ich stimme mit meinem Kollegen über die Versetzung in den Support überein, dass die Arbeit richtig organisiert sein muss. Aber ich werde Ihnen von den Problemen erzählen, die es natürlich gibt.
Erstens ist die Technologie neu. Das ist im positiven Sinne ein Hype, und es ist eine große Herausforderung, einen Spezialisten zu finden, der das versteht und umsetzen kann. Der Wettbewerb um Ressourcen ist wahnsinnig, da sind Experten Gold wert.
Zweitens muss mit der Schaffung bestimmter Landschaften und einer wachsenden Anzahl von Diensten das Problem der Wiederverwendung ständig gelöst werden. Wie Entwickler es gerne tun: „Lassen Sie uns hier jetzt viele interessante Dinge schreiben ...“ Dadurch wächst das System und verliert seine Wirksamkeit in Bezug auf Geld, Betriebskosten usw. Das heißt, es ist notwendig, die Wiederverwendung in die Systemarchitektur einzubeziehen, sie in die Roadmap für die Einführung von Diensten und die Übertragung von Altlasten auf eine neue Architektur einzubeziehen.
Ein weiteres Problem – obwohl das auf seine Weise gut ist – ist der interne Wettbewerb. „Oh, hier sind neue modische Typen aufgetaucht, sie sprechen eine neue Sprache.“ Menschen sind natürlich unterschiedlich. Es gibt diejenigen, die es gewohnt sind, in Java zu schreiben, und diejenigen, die Docker und Kubernetes schreiben und verwenden. Das sind völlig unterschiedliche Menschen, sie sprechen unterschiedlich, verwenden unterschiedliche Begriffe und verstehen sich manchmal nicht. Auch die Fähigkeit oder Unfähigkeit, Erfahrungen und Wissen zu teilen, ist in diesem Sinne ein Problem.
Nun ja, Ressourcen skalieren. "Großartig! Auf geht's! Und jetzt wollen wir schneller, mehr. Was, du kannst nicht? Ist es nicht möglich, in einem Jahr doppelt so viel zu liefern? Und warum?" Solche Wachstumsschmerzen sind wahrscheinlich bei vielen Dingen, vielen Ansätzen Standard und man kann sie spüren.
Bezüglich Überwachung. Es scheint mir, dass Dienste oder industrielle Überwachungstools bereits lernen oder in der Lage sind, sowohl mit Docker als auch mit Kubernetes in einem anderen, nicht standardmäßigen Modus zu arbeiten. Damit man zum Beispiel nicht bei 500 Java-Maschinen landet, unter denen das alles läuft, also aggregiert. Aber diesen Produkten mangelt es noch an der Reife, das müssen sie durchmachen. Das Thema ist wirklich neu, es wird sich weiterentwickeln.
Dmitry:
Ja, sehr interessant. Und das gilt auch für HR. Vielleicht haben sich Ihr HR-Prozess und Ihre HR-Marke in diesen drei Jahren ein wenig verändert. Sie haben begonnen, andere Leute mit anderen Kompetenzen zu rekrutieren. Und es gibt wahrscheinlich sowohl Vor- als auch Nachteile. Früher waren Blockchain und Data Science der Hype, und Spezialisten dafür waren Millionen wert. Jetzt sinken die Kosten, der Markt wird gesättigt und ein ähnlicher Trend zeichnet sich auch bei Microservices ab.
Sergey:
Ja absolut.
Alexander:
HR stellt die Frage: „Wo ist Ihr rosa Einhorn zwischen Backend und Frontend?“ Die Personalabteilung versteht nicht, was ein Microservice ist. Wir haben ihnen das Geheimnis verraten und ihnen gesagt, dass das Backend alles erledigt und es kein Einhorn gibt. Aber die Personalabteilung verändert sich, lernt schnell und rekrutiert Leute, die über grundlegende IT-Kenntnisse verfügen.
Die Entwicklung von Microservices
Dmitry:
Wenn man sich die Zielarchitektur anschaut, sehen Microservices wie ein solches Monster aus. Ihre Reise dauerte mehrere Jahre. Andere haben ein Jahr, andere drei Jahre. Haben Sie alle Probleme vorhergesehen, die Zielarchitektur, hat sich etwas geändert? Beispielsweise tauchen bei Microservices mittlerweile wieder Gateways und Service Meshes auf. Haben Sie sie am Anfang verwendet oder haben Sie die Architektur selbst geändert? Haben Sie solche Herausforderungen?
Sergey:
Wir haben bereits mehrere Kommunikationsprotokolle neu geschrieben. Zuerst gab es ein Protokoll, jetzt sind wir auf ein anderes umgestiegen. Wir erhöhen Sicherheit und Zuverlässigkeit. Wir haben mit Unternehmenstechnologien begonnen – Oracle, Web Logic. Jetzt entfernen wir uns von technologischen Unternehmensprodukten im Bereich Microservices und bewegen uns hin zu Open-Source- oder vollständig offenen Technologien. Wir geben Datenbanken auf und gehen zu dem über, was in diesem Modell für uns effektiver funktioniert. Wir brauchen keine Oracle-Technologien mehr.
Wir haben einfach als Dienst angefangen, ohne darüber nachzudenken, wie sehr wir einen Cache benötigen, was wir tun würden, wenn keine Verbindung mit einem Microservice besteht, aber Daten benötigt werden usw. Jetzt entwickeln wir eine Plattform, damit die Architektur beschrieben werden kann Nicht in der Sprache der Dienstleistungen, sondern in der Geschäftssprache. Bringen Sie die Geschäftslogik auf die nächste Ebene, wenn wir anfangen, in Worten zu sprechen. Jetzt haben wir gelernt, in Buchstaben zu sprechen, und die nächste Stufe besteht darin, dass die Dienste zu einer Art Aggregat zusammengefasst werden, wenn dies bereits ein Wort ist – zum Beispiel eine ganze Produktkarte. Es wird aus Microservices zusammengestellt, ist aber eine darauf aufbauende API.
Sicherheit ist sehr wichtig. Sobald Sie anfangen, zugänglich zu sein und über einen Dienst verfügen, über den Sie sehr schnell, im Bruchteil einer Sekunde, viele interessante Dinge erhalten können, besteht der Wunsch, diese auf nicht ganz sichere Weise zu erhalten. Um dem zu entgehen, mussten wir die Test- und Überwachungsansätze ändern. Wir mussten das Team, die Liefermanagementstruktur, CI/CD ändern.
Das ist eine Evolution – wie bei Telefonen, nur viel schneller: Zuerst gab es Tastentelefone, dann kamen Smartphones. Sie haben das Produkt neu geschrieben und gestaltet, weil der Markt einen anderen Bedarf hatte. So entwickeln wir uns: erste Klasse, zehnte Klasse, Arbeit.
Iterativ wird pro Jahr etwas aus Sicht der Technologie, etwas anderes aus Sicht des Rückstands und Bedarfs angelegt. Wir verbinden eins mit dem anderen. Das Team gibt 20 % für technische Schulden und technischen Support für das Team aus, 80 % für die Geschäftseinheit. Und wir bewegen uns mit einem Verständnis dafür, warum wir es tun, warum wir diese technologischen Verbesserungen vornehmen und wozu sie führen werden. Ungefähr so.
Dmitry:
Cool. Was ist in MegaFon?
Alexander:
Die größte Herausforderung bei Microservices bestand darin, nicht ins Chaos zu verfallen. Das Architekturbüro MegaFon hat sich uns sofort angeschlossen, wurde sogar zum Initiator und Treiber – jetzt haben wir eine sehr starke Architektur. Seine Aufgabe bestand darin, zu verstehen, welches Zielmodell wir anstreben und welche Technologien erprobt werden müssen. Mit Architektur haben wir diese Piloten selbst durchgeführt.
Die nächste Frage war: „Wie kann man das alles dann ausnutzen?“ Und noch etwas: „Wie kann eine transparente Interaktion zwischen Microservices sichergestellt werden?“ Service Mesh hat uns bei der Beantwortung der letzten Frage geholfen. Wir haben Istio getestet und waren von den Ergebnissen begeistert. Jetzt befinden wir uns in der Phase der Einführung in produktive Zonen. Wir stehen allen Herausforderungen positiv gegenüber – der Tatsache, dass wir ständig den Stack ändern und etwas Neues lernen müssen. Uns geht es darum, alte Lösungen weiterzuentwickeln und nicht auszunutzen.
Dmitry:
Goldene Wörter! Solche Herausforderungen halten das Team und das Unternehmen auf Trab und gestalten die Zukunft. Die DSGVO hat oberste Datenschutzbeauftragte geschaffen, und aktuelle Herausforderungen schaffen oberste Microservices- und Architekturbeauftragte. Und es gefällt.
Wir haben viel diskutiert. Die Hauptsache ist, dass Sie durch ein gutes Design von Microservices und der Architektur selbst viele Fehler vermeiden können. Natürlich ist der Prozess iterativ und evolutionär, aber es ist die Zukunft.
Danke an alle Teilnehmer, danke an Sergei und Alexander!
Fragen aus dem Publikum
Frage aus dem Publikum (1):
Sergey, wie hat sich das IT-Management in Ihrem Unternehmen verändert? Ich verstehe, dass die Verwaltung eines großen Stapels aus mehreren Systemen ein ziemlich klarer und logischer Prozess ist. Wie haben Sie das Management der IT-Komponente neu aufgebaut, nachdem in so kurzer Zeit sehr viele Microservices integriert wurden?
Sergey:
Ich stimme mit meinem Kollegen überein, dass Architektur als Treiber des Wandels sehr wichtig ist. Wir begannen mit einer Architekturabteilung. Architekten sind gleichzeitig Eigentümer der Funktionsverteilung und der Anforderungen an deren Erscheinungsbild in der Landschaft. Sie fungieren also auch als Koordinatoren dieser Veränderungen. Daher gab es bei der Erstellung einer CI/CD-Plattform spezifische Änderungen an einem bestimmten Lieferprozess.
Aber die standardmäßigen Grundprinzipien der Entwicklung, Geschäftsanalyse, Prüfung und Entwicklung wurden nicht aufgehoben. Wir haben gerade die Geschwindigkeit erhöht. Früher dauerte der Zyklus so lange, dass die Installation in Testumgebungen viel länger dauerte. Jetzt sieht die Wirtschaft den Nutzen und sagt: „Warum können wir das nicht auch an anderen Orten tun?“
Es ist im positiven Sinne wie eine Injektion in Form eines Impfstoffs, die zeigt: Man kann es so machen, aber man kann es auch anders machen. Natürlich gibt es ein Problem im Personalbereich, in den Kompetenzen, im Wissen, im Widerstand.
Frage aus dem Publikum (2):
Kritiker der Microservice-Architektur sagen, dass Testen und Entwickeln schwierig seien. Das ist logisch, wenn es kompliziert wird. Vor welchen Herausforderungen stand Ihr Team und wie haben Sie diese gemeistert? Frage an alle.
Alexander:
Bei der Umstellung von Microservices auf eine Plattform gibt es Schwierigkeiten, die jedoch gelöst werden können.
Wir erstellen beispielsweise ein Produkt, das aus 5-7 Microservices besteht. Wir müssen Integrationstests für den gesamten Microservices-Stack bereitstellen, um grünes Licht für den Umzug in den Master-Zweig zu geben. Diese Aufgabe war für uns nicht neu: Wir waren bei BSS schon lange damit beschäftigt, als uns der Anbieter bereits mit ausgelieferten Lösungen belieferte.
Und unser Problem liegt nur im kleinen Team. Für ein bedingtes Produkt wird ein QA-Ingenieur benötigt. Daher liefern wir ein Produkt mit 5–7 Microservices aus, von denen 2–3 von Dritten entwickelt werden können. Wir haben zum Beispiel ein Produkt, an dessen Entwicklung unser Abrechnungssystemanbieter Mail.ru Group und MegaFon R&D beteiligt sind. Wir müssen dies durch Tests abdecken, bevor wir es in die Produktion bringen. Der QA-Ingenieur hat anderthalb Monate an diesem Produkt gearbeitet und der Rest des Teams ist ohne seine Unterstützung da.
Diese Komplexität wird nur durch die Skalierung verursacht. Wir verstehen, dass Microservices nicht im luftleeren Raum existieren können; absolute Isolation gibt es nicht. Bei der Änderung eines Dienstes versuchen wir immer, den API-Vertrag beizubehalten. Sollte sich unter der Haube etwas ändern, bleibt der Frontservice bestehen. Wenn die Änderungen schwerwiegend sind, findet eine Art architektonische Transformation statt und wir wechseln zu einem völlig anderen Datenmetamodell, das völlig inkompatibel ist – erst dann sprechen wir über das Erscheinen der v2-Service-API-Spezifikation. Wir unterstützen die erste und zweite Version gleichzeitig und nachdem alle Verbraucher auf die zweite Version umgestiegen sind, schließen wir einfach die erste.
Sergey:
Ich will hinzufügen. Was Komplikationen betrifft, stimme ich absolut zu – sie passieren. Die Landschaft wird komplexer und die Gemeinkosten, insbesondere für Tests, steigen. So gehen Sie damit um: Wechseln Sie zu automatisierten Tests. Ja, Sie müssen zusätzlich in das Schreiben von Autotests und Unit-Tests investieren. Damit Entwickler keinen Commit durchführen konnten, ohne den Test zu bestehen, konnten sie den Code nicht ändern. Damit auch der Druckknopf ohne Autotest, Unit-Test, nicht funktioniert.
Es ist wichtig, die bisherige Funktionalität beizubehalten, was einen zusätzlichen Aufwand bedeutet. Wenn Sie eine Technologie in ein anderes Protokoll umschreiben, schreiben Sie sie so lange um, bis Sie alles vollständig geschlossen haben.
Wir machen manchmal absichtlich keine End-to-End-Tests, weil wir die Entwicklung nicht stoppen wollen, obwohl wir auch ein Ding nach dem anderen haben. Die Landschaft ist sehr groß, komplex, es gibt viele Systeme. Manchmal sind es nur Stuben – ja, wenn Sie die Sicherheitsmarge verringern, treten mehr Risiken auf. Aber gleichzeitig geben Sie den Vorrat frei.
Alexander:
Ja, mit Autotests und Unit-Tests können Sie einen qualitativ hochwertigen Service erstellen. Wir sind für eine Pipeline, die ohne Unit- und Integrationstests nicht bestanden werden kann. Wir müssen Emulatoren und kommerzielle Systeme oft in Testzonen und Entwicklungsumgebungen verschleppen, da nicht alle Systeme in Testzonen platziert werden können. Darüber hinaus werden sie nicht nur nass – wir erzeugen eine vollwertige Reaktion des Systems. Dies ist ein wichtiger Teil der Arbeit mit Microservices und wir investieren auch darin. Ohne dies wird es Chaos geben.
Frage aus dem Publikum (3):
Soweit ich weiß, sind Microservices ursprünglich aus einem separaten Team entstanden und existieren nun in diesem Modell. Was sind seine Vor- und Nachteile?
Wir haben gerade eine ähnliche Geschichte: Es entstand eine Art Microservices-Fabrik. Nun sind wir konzeptionell an dem Punkt angelangt, dass wir diesen Ansatz auf die Produktion nach Streams und nach Systemen ausweiten. Mit anderen Worten: Wir entfernen uns von der zentralisierten Entwicklung von Microservices und Microservice-Modellen und rücken näher an Systeme heran.
Dementsprechend geht auch unser Betrieb in die Systeme, das heißt wir dezentralisieren dieses Thema. Was ist Ihr Ansatz und was ist Ihre Zielstory?
Alexander:
Der Name „Microservices-Fabrik“ ist Ihnen direkt aus dem Mund gefallen – auch wir wollen skalieren. Erstens haben wir jetzt wirklich ein Team. Wir möchten allen Entwicklungsteams von MegaFon die Möglichkeit bieten, in einem gemeinsamen Ökosystem zu arbeiten. Wir wollen nicht alle Entwicklungsfunktionen, die wir jetzt haben, vollständig übernehmen. Die lokale Aufgabe besteht darin, zu skalieren, die globale Aufgabe besteht darin, die Entwicklung an alle Teams in der Microservice-Schicht weiterzuleiten.
Sergey:
Ich erzähle Ihnen den Weg, den wir eingeschlagen haben. Wir haben wirklich angefangen, als ein Team zu arbeiten, aber jetzt sind wir nicht allein. Ich bin ein Befürworter von Folgendem: Es muss einen Eigentümer des Prozesses geben. Jemand muss den Microservices-Entwicklungsprozess verstehen, verwalten, steuern und aufbauen. Er muss über Ressourcen verfügen und sich am Ressourcenmanagement beteiligen.
Diese Ressourcen, die Technologien und Besonderheiten kennen und wissen, wie man Microservices erstellt, können in Produktteams untergebracht werden. Wir haben eine Mischung, bei der Leute von der Microservice-Plattform im Produktteam sind, das die mobile Anwendung erstellt. Sie sind da, aber sie arbeiten nach dem Prozess der Microservice-Plattform-Management-Abteilung mit ihrem Entwicklungsleiter. Innerhalb dieser Abteilung gibt es ein eigenes Team, das sich mit der Technik beschäftigt. Das heißt, wir mischen einen gemeinsamen Ressourcenpool untereinander, teilen ihn auf und geben ihn an Teams weiter.
Gleichzeitig bleibt der Prozess allgemein und kontrolliert, er läuft nach allgemeinen technologischen Prinzipien ab, mit Unit-Tests usw. – alles, was darauf aufbaut. Es kann Spalten in Form von Ressourcen geben, die aus verschiedenen Abteilungen des Produktansatzes gesammelt wurden.
Alexander:
Sergey, Sie sind eigentlich der Eigentümer des Prozesses, oder? Wird der Aufgabenrückstand geteilt? Wer ist für die Verbreitung verantwortlich?
Sergey:
Schauen Sie: Hier ist noch einmal die Mischung. Es gibt einen Rückstand, der sich aufgrund technologischer Verbesserungen bildet – das ist eine Geschichte. Es gibt einen Rückstand, der aus Projekten formuliert wird, und einen Rückstand aus Produkten. Die Reihenfolge der Einführung in jedes der Serviceprodukte oder die Erstellung dieses Services wird jedoch von einem Produktspezialisten entwickelt. Er ist nicht in der IT-Direktion, er wurde eigens aus dieser entfernt. Aber meine Leute arbeiten definitiv nach dem gleichen Prozess.
Der Eigentümer des Rückstands in verschiedene Richtungen – des Rückstands an Änderungen – werden unterschiedliche Personen sein. Die Vernetzung technologischer Dienste, ihr Organisationsprinzip – all das wird in der IT liegen. Ich besitze auch die Plattform und die Ressourcen. Ganz oben steht, was den Rückstand und die funktionalen Änderungen und in diesem Sinne die Architektur betrifft.
Nehmen wir an, ein Unternehmen sagt: „Wir wollen diese Funktion, wir wollen ein neues Produkt schaffen – einen Kredit neu erstellen.“ Wir antworten: „Ja, wir machen es noch einmal.“ Architekten sagen: „Denken wir mal: Wo im Kredit werden wir Microservices schreiben und wie machen wir das?“ Dann zerlegen wir es in Projekte, Produkte oder einen Technologie-Stack, fassen es in Teams zusammen und setzen es um. Sie haben intern ein Produkt erstellt und sich für den Einsatz von Microservices in diesem Produkt entschieden? Wir sagen: „Jetzt müssen die Legacy-Systeme, die wir hatten, oder Frontline-Systeme, auf diese Microservices umsteigen.“ Die Architekten sagen: „Also: im technologischen Rückstand innerhalb der Frontline-Produkte – der Übergang zu Microservices.“ Gehen". Und Produktspezialisten oder Geschäftsinhaber wissen, wie viel Kapazität zugewiesen wird, wann und warum.
Das Ende der Diskussion, aber nicht alles
Die mailto:CLOUD-Konferenz wurde organisiert .
Wir machen auch andere Veranstaltungen – z.B. @Kubernetes Meetup, wo wir immer auf der Suche nach tollen Rednern sind:
- Verfolgen Sie @Kubernetes und andere @Meetup-Neuigkeiten in unserem Telegram-Kanal
- Haben Sie Interesse, bei einem der @Meetups zu sprechen? Hinterlassen Sie eine Anfrage für
Source: habr.com