Am 25. April veranstalteten wir von der Mail.ru Group eine Konferenz über Wolken und Umgebung -
mailto: CLOUD . Einige Highlights:
- Die wichtigsten russischen Anbieter versammelten sich auf einer Bühne - Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center und Yandex.Cloud sprachen über die Besonderheiten unseres Cloud-Marktes und ihre Dienste.
- Kollegen von Bitrix24 erzählten, wie sie zu Multiclaud kamen ;
- Leroy Merlin, Otkrytie, Burger King und Schneider Electric gaben einen interessanten Überblick über die Cloud-Konsumenten - welche Aufgaben ihr Unternehmen für die IT stellt und welche Technologien, einschließlich Cloud-Technologien, sie als die vielversprechendsten ansehen.
Alle Videos von der mailto: CLOUD-Konferenz können hier angesehen
werden , aber hier können Sie lesen, wie die Diskussion über Microservices verlaufen ist. Alexander Deulin, Leiter des Forschungs- und Entwicklungszentrums für MegaFon-Geschäftssysteme, und Sergey Sergeyev, Direktor für Informationstechnologie der M. Video-Eldorado-Gruppe, berichteten über ihre - erfolgreichen - Fälle, in denen Monolithen beseitigt wurden. Sie diskutierten auch verwandte Themen der IT-Strategie, der Prozesse und sogar der Personalabteilung.
Diskussionsteilnehmer
- Sergey Sergeev , Direktor für Informationstechnologie , M.Video-Eldorado Group ;
- Alexander Deulin , Leiter des Forschungs- und Entwicklungszentrums für MegaFon- Geschäftssysteme;
- Moderator - Dmitry Lazarenko , Leiter der PaaS-Richtung Mail.ru Cloud Solutions .
Nach einer Rede von Alexander Deulin
„Wie MegaFon sein Geschäft durch eine Microservice-Plattform erweitert“ nimmt Sergey Sergeev von M.Video-Eldorado an der Diskussion teil und moderiert die Diskussion Dmitry Lazarenko, Mail.ru Cloud Solutions.
Nachfolgend haben wir für Sie eine Abschrift der Diskussion vorbereitet, aber Sie können sich auch das Video ansehen:
Umstellung auf Microservices - eine Antwort auf die Marktanforderungen
Dmitry:Haben Sie erfolgreiche Erfahrungen mit der Umstellung auf Microservices gemacht? Und im Allgemeinen: Wo sehen Sie den größten Nutzen in der Wirtschaft durch den Einsatz von Microservices oder den Übergang von Monolithen zu Microservices?
Sergey:Wir haben bereits einen Weg zum Übergang zu Microservices gefunden und verwenden diesen Ansatz seit mehr als drei Jahren. Das erste Bedürfnis, das den Bedarf an Microservices rechtfertigte, war die endlose Integration verschiedener Front-Line-Produkte in das Backoffice. Und jedes Mal mussten wir zusätzliche Integration, Entwicklung und Implementierung unserer Regeln für den Betrieb eines Dienstes durchführen.
Irgendwann wurde uns klar, dass wir unsere Systeme und Ausgabefunktionen beschleunigen mussten. Zu diesem Zeitpunkt gab es bereits Konzepte wie Microservices und Microservice auf dem Markt, und wir haben beschlossen, es auszuprobieren. Es begann im Jahr 2016. Dann wurde die Plattform gelegt und die ersten 10 Dienste wurden von einem separaten Team implementiert.
Einer der ersten Dienste, der am stärksten belastet war, war ein Preisberechnungsdienst. Jedes Mal, wenn Sie zu einem Kanal der Unternehmensgruppe M.Video-Eldorado kommen, egal ob es sich um eine Website oder ein Einzelhandelsgeschäft handelt, Waren dort abholen, den Preis auf der Website oder im „Warenkorb“ anzeigen, berechnet ein Dienst automatisch den Preis. Warum dies erforderlich ist: Zuvor hatte jedes System seine eigenen Prinzipien für die Arbeit mit Promo-Rabatten und so weiter. Das Backoffice beschäftigt sich mit der Preisgestaltung, die Rabattfunktionalität ist in einem anderen System implementiert. Es war notwendig, einen solch einzigartigen, abnehmbaren Service in Form eines Geschäftsprozesses zu zentralisieren und zu schaffen, der es uns ermöglichen würde, dies umzusetzen. So haben wir angefangen.
Der Wert der ersten Ergebnisse war sehr groß. Erstens konnten wir abnehmbare Entitäten erstellen, die es uns ermöglichen, getrennt und aggregiert zu arbeiten. Zweitens haben wir die Betriebskosten im Hinblick auf die Integration in eine große Anzahl von Systemen gesenkt.
In den letzten drei Jahren haben wir drei Frontsysteme hinzugefügt. Es war schwierig, sie in der Menge an Ressourcen zu halten, die sich das Unternehmen leisten konnte. Daher bestand die Aufgabe darin, nach neuen Ausgängen zu suchen, die in Bezug auf Geschwindigkeit, interne Kosten und Effizienz auf den Markt reagieren.
Wie bewertet man den Erfolg des Übergangs zu Microservices?
Dmitry:Wie wird der Erfolg bei der Umstellung auf Microservices festgestellt? Was war das „Vorher“ in jedem Unternehmen? Welche Metrik haben Sie verwendet, um den Erfolg des Übergangs zu bestimmen, wer hat ihn tatsächlich bestimmt?
Sergey:Zuallererst wurde es in der IT als Enabler geboren - das „Freischalten“ neuer Funktionen. Wir mussten alles schneller für relativ das gleiche Geld erledigen, um auf die Herausforderungen des Marktes zu 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, und in diesem Moment war es eine Gelegenheit, eine Plattform zu schaffen und die Hypothese zu bestätigen, dass wir dies tun können. Dies wird den Effekt und die Berechnung des Geschäftsfalls ergeben.
Alexander:Erfolg ist eher eine innere Sensation. Unternehmen wollen immer mehr und die Tiefe unseres Rückstands ist die Bestätigung des Erfolgs. Ich denke schon.
Sergey:Ja, ich stimme zu. Seit drei Jahren haben wir bereits mehr als zweihundert Dienstleistungen und einen Auftragsbestand. Der Ressourcenbedarf im Team wächst nur - jährlich um 30%. Dies liegt daran, dass die Menschen das Gefühl hatten: Es ist schneller, anders, andere Technologien, all dies entwickelt sich.
Microservices werden kommen, aber der Kern wird bleiben
Dmitry:Dies ist wie ein endloser Prozess, in dem Sie in die Entwicklung investieren. Ist der Übergang zu Microservices für das Geschäft selbst bereits beendet oder nicht?
Sergey:Sehr einfach zu beantworten. Was denkst du: Das Ersetzen von Telefonen ist ein endloser Prozess? Wir selbst kaufen jedes Jahr Telefone. Und hier ist es: Während bei der Anpassung an den Markt Geschwindigkeit gefragt ist, sind einige Änderungen erforderlich. Dies bedeutet nicht, dass wir Standardsachen ablehnen.
Aber wir können nicht sofort alles umarmen und wiederholen. Wir haben ältere Standardintegrationsdienste, die zuvor verfügbar waren: Unternehmensbusse und so weiter. Aber es gibt einen Rückstand, und es besteht auch ein Bedarf. Die Anzahl mobiler Anwendungen und ihre Funktionalität nehmen zu. Gleichzeitig sagt niemand, dass sie Ihnen 30% mehr Geld geben werden. Das heißt, es gibt immer einerseits Bedürfnisse und andererseits eine Suche nach Effizienz.
Dmitry:Das Leben ist in guter Verfassung.
(Lacht)Alexander:Im Allgemeinen ja. Wir haben keine revolutionären Ansätze, um Kernteile aus der Landschaft zu entfernen. Derzeit wird systematisch daran gearbeitet, Systeme so zu zerlegen, dass sie besser mit der Microservice-Architektur übereinstimmen, um den Einfluss von Systemen aufeinander zu verringern.
Wir planen jedoch, den Kernbereich beizubehalten, da es in der Betreiberlandschaft immer einige Plattformen geben wird, die wir kaufen. Auch hier brauchen Sie ein gesundes Gleichgewicht: Wir sollten nicht in den "schneidenden" Kern stürzen. Wir stellen die Systeme nebeneinander, und jetzt stellt sich heraus, dass bereits über viele Kernteile. Bei der Weiterentwicklung der Funktionalität machen wir die erforderlichen Darstellungen für alle Kanäle, die mit unseren Kommunikationsdiensten arbeiten.
Wie man Microservices an ein Unternehmen verkauft
Dmitry:Ich bin immer noch interessiert - für diejenigen, die noch nicht gewechselt haben, aber werden: Wie einfach war es, diese Idee an Unternehmen zu verkaufen, und war es ein Glücksspiel, ein Investitionsprojekt? Oder es war eine bewusste Strategie: Jetzt gehen wir zu Microservices und das ist alles, nichts wird uns aufhalten. Wie war es bei dir?
Sergey:Wir haben nicht den Ansatz verkauft, sondern den Geschäftsgewinn. Es gab ein Problem im Geschäft, und wir haben versucht, es zu beseitigen. Zu diesem Zeitpunkt drückte sich die Tatsache aus, dass in verschiedenen Kanälen unterschiedliche Preisprinzipien angewendet wurden - getrennt für Werbeaktionen, für Aktien usw. Es war schwer zu warten, es traten Fehler auf, wir hörten auf Kundenbeschwerden. Das heißt, wir haben die Beseitigung des Problems verkauft, kamen aber mit der Tatsache, dass wir Geld brauchen, um eine Plattform zu schaffen. Und sie zeigten am Beispiel der ersten Investitionsphase einen Business Case: Wie werden wir weiterhin dafür bezahlen und was können wir damit tun?
Dmitry:Hast du irgendwie die Zeit der ersten Stufe festgelegt?
Sergey:Ja natürlich. Wir haben 6 Monate gebraucht, um Core als Plattform und Pilotversuche zu erstellen. In dieser Zeit haben wir versucht, eine Plattform zu schaffen, auf der der Pilot skatete. Sie haben die Hypothese weiter bestätigt, und da sie funktioniert, können wir fortfahren. Sie begannen, das Team zu replizieren und zu stärken - sie brachten es zu einer separaten Einheit, die nur damit beschäftigt ist.
Als nächstes folgt die systematische Arbeit, die sich aus den Anforderungen des Unternehmens, den Möglichkeiten, der Verfügbarkeit von Ressourcen und allem, was jetzt in Arbeit ist, ergibt.
Dmitry:Okay Alexander, was sagst du?
Alexander:Unsere Microservices wurden aus dem „Seeschaum“ geboren - aufgrund von Ressourceneinsparungen, aufgrund einiger Rückstände in Form von Serverkapazitäten und Umverteilung der Kräfte innerhalb des Teams. Dieses Projekt haben wir zunächst nicht an Unternehmen verkauft. Es war ein Projekt, bei dem wir beide entsprechend recherchiert und entwickelt haben. Wir haben Anfang 2018 angefangen und diese Richtung nur begeistert entwickelt. Der Verkauf hat gerade erst begonnen und wir sind dabei.
Dmitry:Aber es kommt vor, dass ein Unternehmen es Ihnen ermöglicht, solche Dinge nach dem Prinzip von Google zu tun - an einem freien Tag in der Woche? Hast du eine solche Richtung?
Alexander:Gleichzeitig mit der Forschung waren wir mit Geschäftsaufgaben beschäftigt, da alle unsere Microservices Lösungen für geschäftliche Probleme sind. Erst zu Beginn haben wir Microservices entwickelt, die einen kleinen Teil der Abonnentenbasis abdecken, und jetzt sind wir in fast allen Flaggschiffprodukten vertreten.
Und die wesentlichen Auswirkungen sind bereits klar: Wir können bereits gezählt werden, wir können die Geschwindigkeit der Produktproduktion und den Umsatzverlust abschätzen, wenn wir den alten Weg gehen. Hier bauen wir den Fall auf.
Microservices: Hype oder Bedürfnis?
Dmitry:Zahlen sind Zahlen. Und Einnahmen oder gespartes Geld sind sehr wichtig. Und 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 übersetzen, und dem, was Sie nicht in Microservices übersetzen? Wenn das Vermächtnis jetzt ist, werden Sie in 5 Jahren noch Vermächtnis haben? Wie alt werden Informationssysteme sein, die in 5 Jahren in M. Video-Eldorado und MegaFon funktionieren? Wird es zehnjährige, fünfzehnjährige Informationssysteme geben oder wird es eine neue Generation geben? Wie siehst du das
Sergey:Es scheint mir, dass sehr weit weg schwer zu machen ist. Wenn Sie zurückblicken, wer hat vorgeschlagen, dass dies den Markt für Technologie und das gleiche maschinelle Lernen, die Benutzeridentifikation durch Gesicht, entwickeln würde? Aber wenn Sie in den kommenden Jahren schauen, scheint es mir, dass Kernsysteme, Unternehmenssysteme der ERP-Klasse in Unternehmen - sie haben lange gearbeitet.
Unsere Unternehmen sind seit 25 Jahren zusammen, in ihnen befindet sich das klassische ERP sehr tief in der Systemlandschaft. Es ist klar, dass wir einige Stücke von dort herausnehmen und versuchen, sie zu Microservices zusammenzufassen, aber der Kern wird bleiben. Es fällt mir jetzt schwer, mir vorzustellen, dass wir dort alle Kernsysteme ersetzen und schnell auf die andere, hellere Seite neuer Systeme übergehen werden.
Ich bin ein Befürworter dafür, dass alles, was näher am Kunden und am Verbraucher liegt, wo es den größten geschäftlichen Nutzen und Wert gibt, wo Sie Anpassungsfähigkeit benötigen und sich auf Geschwindigkeit konzentrieren, auf Änderungen, auf „versuchen, abbrechen, wiederverwenden, etwas anderes tun "- dort wird sich die Landschaft verändern. Und Box-Produkte sind dort nicht sehr gut eingebaut. Zumindest sehen wir das nicht. Es erfordert die leichtesten und einfachsten Lösungen.
Wir sehen eine solche Entwicklung:
- Kerninformationssysteme (meistens Backoffice);
- mittlere Schichten in Form von Mikrodiensten verbinden den Kern, aggregieren, erstellen einen Cache und so weiter;
- Front-Line-Systeme richten sich an den Verbraucher;
- Integrationsschicht, die im Allgemeinen in Marktplätze, andere Systeme und Ökosysteme integriert ist. Diese Schicht ist so leicht wie möglich, einfach und mit einem Minimum an Geschäftslogik versehen.
Gleichzeitig bin ich ein Befürworter der Fortsetzung der alten Prinzipien, wenn sie an den Ort gewöhnt sind.
Angenommen, Sie haben ein klassisches Unternehmenssystem. Es befindet sich in der Landschaft eines Anbieters und besteht aus zwei Modulen, die miteinander arbeiten. Es gibt auch eine Standard-Integrationsschnittstelle. Warum wiederholen und dort einen Microservice bringen?
Wenn sich im Backoffice jedoch 5 Module befinden, aus denen Informationen in den Geschäftsprozess aufgenommen werden, die dann von 8 bis 10 Front-End-Systemen verwendet werden, sind die Vorteile sofort spürbar. Sie nehmen aus fünf Back-Office-Systemen heraus, erstellen darüber hinaus einen isolierten Service, der sich auf den Geschäftsprozess konzentriert. Sie machen einen Service technologisch - damit er Informationen zwischenspeichert und fehlertolerant ist und auch mit Dokumenten oder Geschäftseinheiten funktioniert. Und integrieren Sie es nach einem einzigen Prinzip in alle Front-Line-Produkte. Sie haben das Front-Line-Produkt storniert - sie haben einfach die Integration deaktiviert. Morgen müssen Sie eine mobile Anwendung schreiben oder eine kleine Site und nur einen Teil erstellen, um in der Funktion zu landen - es ist ganz einfach: Sie stellen sie als Konstruktor zusammen. Ich sehe die Entwicklung in diese Richtung mehr - zumindest in unserem Land.
Alexander:Sergey hat unseren Ansatz vollständig beschrieben, danke. Ich sage nur, wohin wir definitiv nicht gehen werden - zum Kernteil, zum Thema Online-Aufladung. Das heißt, die Bewertung und das Aufladen bleiben in der Tat ein Drescher, der zuverlässig Geld abschreibt. Und dieses System wird weiterhin von unseren Aufsichtsbehörden zertifiziert. Alles andere, was sich an Kunden richtet, sind natürlich Microservices.
Dmitry:Hier ist die Zertifizierung nur eine Geschichte. Wahrscheinlich mehr Unterstützung. Wenn Sie ein wenig für Support ausgeben oder das System keinen Support und keine Verbesserung benötigt, ist es besser, es nicht zu berühren. Angemessener Kompromiss.
Wie man zuverlässige Mikrodienste entwickelt
Dmitry:Gut. Aber ich bin immer noch interessiert. Jetzt erzählen Sie eine Erfolgsgeschichte: Alles war in Ordnung, wir sind zu Microservices gewechselt, haben die Idee vor dem Geschäft verteidigt und alles hat geklappt. Aber ich habe andere Geschichten gehört.
Vor einigen Jahren schloss ein Schweizer Unternehmen, das zwei Jahre in die Entwicklung einer neuen Microservice-Plattform für Banken investiert hatte, dieses Projekt schließlich ab. Komplett gefaltet. Viele Millionen Schweizer Franken wurden ausgegeben, aber am Ende haben sie das Team zerstreut - das war nicht der Fall.
Hattest du ähnliche Geschichten? Gab oder gibt es Schwierigkeiten? Zum Beispiel bei der Wartung von Mikroservices ist die gleiche Überwachung auch ein Problem im Betrieb des Unternehmens. Immerhin 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 Menschen geraten werden, damit sie nicht auf ähnliche Probleme stoßen?
Alexander:Erfolglose Beispiele waren, dass das Unternehmen Prioritäten änderte und Projekte stornierte. In einem guten Stadium der Bereitschaft (MVP ist tatsächlich bereit) sagte das Unternehmen: "Wir haben neue Prioritäten, wir gehen zu einem anderen Projekt und wir schließen dieses."
Wir hatten keine globalen Dateien mit Microservices. Wir schlafen friedlich, wir haben eine 24/7-Schicht, die das gesamte BSS [Business Support System] bedient.
Und doch - wir vermieten Microservices nach den Regeln, nach denen verpackte Produkte vermietet werden. Der Schlüssel zum Erfolg ist, dass Sie zunächst ein Team zusammenstellen müssen, das den Microservice vollständig auf die Produktion vorbereitet. Die Entwicklung selbst beträgt bedingt 40%. Der Rest sind Analysen, DevSecOps-Methoden, die richtigen Integrationen und die richtige Architektur. Besonderes Augenmerk legen wir auf die Prinzipien der Erstellung sicherer Anwendungen. In jedem Projekt beteiligen sich Vertreter der Informationssicherheit sowohl an der Planungsphase der Architektur als auch am Implementierungsprozess. Sie verwalten auch Code-Analysesysteme für Schwachstellen.
Angenommen, wir stellen unsere zustandslosen Dienste bereit - wir haben sie in Kubernetes. Dies ermöglicht es jedem, dank automatischer Skalierungs- und automatischer Erhöhungsdienste ruhig zu schlafen, und die Verlagerung des Dienstes nimmt Vorfälle auf.
Während der gesamten Zeit der Existenz unserer Mikrodienste gab es nur ein oder zwei Vorfälle, die unsere Linie erreichten. Jetzt gibt es keine betrieblichen Probleme. Natürlich haben wir nicht 200, sondern etwa 50 Microservices, aber sie werden in Flaggschiffprodukten verwendet. Wenn sie versagten, würden wir als erste davon erfahren.
Microservices und HR
Sergey:Ich stimme meinem Kollegen hinsichtlich der Übertragung zur Unterstützung zu - dass Sie die Arbeit korrekt organisieren müssen. Aber ich werde über die Probleme sprechen, die es natürlich gibt.
Erstens ist die Technologie neu. Dies ist in guter Weise ein Hype, und es ist eine große Herausforderung, einen Spezialisten zu finden, der dies versteht und in der Lage ist, dies zu schaffen. Der Wettbewerb um Ressourcen ist verrückt, Experten sind Gold wert.
Zweitens sollte bei der Schaffung bestimmter Landschaften und einer wachsenden Anzahl von Diensten das Problem der Wiederverwendung ständig gelöst werden. Wie Entwickler gerne tun: "Schreiben wir hier viele interessante Dinge ..." Aus diesem Grund wächst das System und verliert seine Effektivität in Bezug auf Geld, Betriebskosten usw. Das heißt, Sie müssen die Architektur von Systemen wiederverwenden, die Einführung von Diensten und die Übertragung von Legacy auf die neue Architektur in die Roadmap aufnehmen.
Ein weiteres Problem - obwohl dies auf seine Weise gut ist - ist der interne Wettbewerb. "Oh, hier sind neue Modefans aufgetaucht, sie sprechen eine neue Sprache." Die Leute sind natürlich anders. Es gibt diejenigen, die es gewohnt sind, in Java zu schreiben, und diejenigen, die Docker und Kubernetes schreiben und verwenden. Dies sind völlig unterschiedliche Menschen, sie sprechen unterschiedlich, verwenden unterschiedliche Begriffe und verstehen sich manchmal nicht. Die Fähigkeit oder Unfähigkeit, Praxis und Wissensaustausch in diesem Sinne zu teilen, ist ebenfalls ein Problem.
Nun, Ressourcen skalieren. „Großartig, lass uns gehen! Und jetzt wollen wir schneller, mehr. Kannst du nicht? Ist es unmöglich, in einem Jahr doppelt so viel zu liefern? Und warum?" Solche Wachstumsprobleme sind Standard, wahrscheinlich für viele Dinge, viele Ansätze, und sie sind zu spüren.
In Bezug auf die Überwachung. Es scheint mir, dass Dienste oder industrielle Überwachungstools bereits lernen oder in der Lage sind, mit Docker und Kubernetes in einem anderen, nicht standardmäßigen Modus zu arbeiten. Damit Sie beispielsweise nicht über 500 Java-Maschinen verfügen, auf denen all dies ausgeführt wird, nämlich Aggregate. Aber diese Produkte sind noch nicht ausgereift, sie müssen dies durchmachen. Das Thema ist wirklich neu, es wird noch weiterentwickelt.
Dmitry:Ja, sehr interessant. Und das gilt für die Personalabteilung. Vielleicht haben sich Ihr HR-Prozess und Ihre HR-Marke in diesen 3 Jahren etwas verändert. Sie haben begonnen, andere Personen mit einer anderen Kompetenz zu rekrutieren. Und es gibt wahrscheinlich Vor- und Nachteile. Zuvor waren Blockchain und Data Science Hightech, und Spezialisten waren nur Millionen wert. Jetzt fällt der Preis, der Markt ist gesättigt und es gibt einen ähnlichen Trend bei Microservices.
Sergey:Ja, absolut.
Alexander:HR stellt die Frage: "Wo ist Ihr rosa Einhorn zwischen Backend und Frontend?" HR versteht nicht, was Microservice ist. Wir haben ihnen ein Geheimnis gelüftet und gesagt, dass dieses Backend alles getan hat und es kein Einhorn gibt. Aber die Personalabteilung verändert sich, lernt schnell und rekrutiert Mitarbeiter mit grundlegenden IT-Kenntnissen.
Die Entwicklung der Mikrodienste
Dmitry:Wenn Sie sich die Zielarchitektur ansehen, sehen Microservices wie ein solches Monster aus. Ihre Reise dauerte mehrere Jahre. Andere haben ein Jahr, andere drei Jahre. Sie haben alle Probleme vorausgesehen, die Zielarchitektur, hat sich etwas geändert? Beispielsweise werden bei Microservices, Gateways und Service-Meshes jetzt wieder angezeigt. Haben Sie sie am Anfang verwendet oder die Architektur selbst geändert? Hast du solche Herausforderungen?
Sergey:Wir haben bereits mehrere Interaktionsprotokolle umgeschrieben. Anfangs wurde ein Protokoll auf ein anderes umgestellt. Wir erhöhen die Sicherheit und Zuverlässigkeit. Wir haben mit Enterprise-Technologie begonnen - Oracle, Web Logic. Jetzt bewegen wir uns weg von technologischen Unternehmensprodukten in Microservices und hin zu Open Source oder vollständig offenen Technologien. Wir verlassen die Datenbanken und gehen zu dem über, was in diesem Modell für uns effizienter funktioniert. Wir brauchen keine Oracle-Technologien mehr.
, , , , , , . . , , -, - , . , — - , — , . , API.
. , , , , . , . , , CI/CD.
— , : , . , , . : , , .
- , - — backlog' . . 20% , 80% — -. , , , , . .
:. «»?
:— . , «» — . , . .
: « ?». : « ?». service mesh. Istio, . . — , , - . , .
:! . GDPR chief data protection officers, . .
. — . , , .
, !
(1):, IT- ? , , — . IT- , ?
:, . , . , . . , CI/CD.
, , -, — . . -, — -. : « ?».
, , , : , -. , , , , .
(2):, . , - . ? .
:, .
, , 5-7 . , -. : BSS, .
. QA-. , 5-7 , 2-3 . , , , Mail.ru Group R&D «». , . QA- , .
. , , . , API-. - , front . , - , — , API- v2. , .
:. — . , , . : . , unit-. , . push , unit-.
, . , , .
end-to-end , , . , , . — , , . .
:, unit- . , unit- . , , . — . , . .
(3):, . ?
: . , . , , , .
, , . ?
:« » — . -, . , «», . , . — , — .
:, . , . : . - , , . -.
, , , , . , , . , . , . , .
, , , unit- — , . , .
:, , ? Backlog ? ?
:: . backlog, , — . backlog, , backlog . . IT-, . .
backlog' — backlog' — . , — IT. , — . , backlog' , .
, : « , — ». : «, ». : « : ?». , , . ? : « legacy-, , , ». : «: backlog — . ». , capacity, .
,
Die mailto: CLOUD-Konferenz wurde von Mail.ru Cloud Solutions veranstaltet .Wir machen auch andere Events - zum Beispiel @Kubernetes Meetup , wo wir immer nach coolen Rednern suchen: