25 kwietnia w Grupie Mail.ru zorganizowaliśmy konferencję na temat chmur i okolic - . Kilka najważniejszych informacji:
- Główny — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center i Yandex.Cloud opowiedziały o specyfice naszego rynku chmurowego i swoich usług;
- Koledzy z Bitrix24 opowiedzieli, jak to zrobili ;
- Ciekawe były Leroy Merlin, Otkritie, Burger King i Schneider Electric — jakie zadania stawia przed IT biznes i jakie technologie, w tym chmurowe, uważają za najbardziej perspektywiczne.
Wszystkie filmy z konferencji mailto:CLOUD można obejrzeć , a tutaj możesz przeczytać jak przebiegła dyskusja na temat mikroserwisów. Alexander Deulin, szef centrum badań i rozwoju systemów biznesowych MegaFon oraz Siergiej Siergiejew, dyrektor ds. Technologii informatycznych grupy M.Video-Eldorado, podzielili się swoimi udanymi przypadkami pozbycia się monolitów. Poruszaliśmy także kwestie powiązane ze strategią IT, procesami, a nawet HR.
Paneliści
- Siergiej Siergiejew, CIO Grupy „M.Video-Eldorado”;
- Aleksander Deulin, kierownik centrum badań i rozwoju systemów biznesowych MegaFon;
- Moderator — Dmitrij Łazarenko, Szef kierunku PaaS Rozwiązania chmurowe Mail.ru.
Po przemówieniu Aleksandra Deulina do dyskusji dołączają Sergey Sergeev z M.Video-Eldorado i moderator dyskusji Dmitry Lazarenko, Mail.ru Cloud Solutions.
Poniżej przygotowaliśmy dla Was zapis dyskusji, ale możecie też obejrzeć wideo:
Przejście na mikrousługi jest odpowiedzią na potrzeby rynku
Dmitrij:
Czy masz jakieś udane doświadczenia z migracją do mikroserwisów? I ogólnie: gdzie widzisz największe korzyści biznesowe z wykorzystania mikroserwisów lub przejścia z monolitów na mikroserwisy?
Sergey:
Przeszliśmy już pewną drogę w przejściu na mikroserwisy i stosujemy to podejście od ponad trzech lat. Pierwszą potrzebą uzasadniającą potrzebę mikroserwisów była niekończąca się integracja różnych produktów front-endowych z back-office. I za każdym razem byliśmy zmuszeni do dodatkowej integracji i rozwoju, wdrażając własne zasady działania tej czy innej usługi.
W pewnym momencie zdaliśmy sobie sprawę, że musimy przyspieszyć działanie naszych systemów i wydajność funkcjonalności. W tamtym momencie na rynku istniały już takie koncepcje jak mikroserwisy i podejście mikroserwisowe, a my postanowiliśmy to wypróbować. To zaczęło się w 2016 roku. Następnie ułożono platformę i pierwsze 10 usług zostało zrealizowanych przez oddzielny zespół.
Jedną z pierwszych usług, najbardziej obciążoną, była usługa kalkulacji cen. Za każdym razem, gdy wejdziesz na jakikolwiek kanał, do grupy firm M.Video-Eldorado, czy to na stronę internetową, czy do sklepu detalicznego, wybierz tam produkt, zobacz cenę na stronie lub w „Koszyku”, koszt zostanie automatycznie obliczone przez jedną usługę. Dlaczego jest to konieczne: wcześniej każdy system miał własne zasady pracy z promocjami - z rabatami i tak dalej. Za wycenę odpowiada nasz back office, w innym systemie zaimplementowana została funkcjonalność rabatowa. Należało to scentralizować i stworzyć unikalną, wydzieloną usługę w formie procesu biznesowego, który pozwoliłby nam to wdrożyć. Mniej więcej tak zaczęliśmy.
Wartość pierwszych wyników była bardzo duża. Po pierwsze, udało nam się stworzyć odrębne byty, które pozwalają nam pracować osobno i w sposób zagregowany. Po drugie, obniżyliśmy koszt posiadania w zakresie integracji z większą liczbą systemów.
W ciągu ostatnich trzech lat dodaliśmy trzy systemy pierwszej linii. Trudno było je utrzymać przy takiej samej ilości zasobów, na jakie mogła sobie pozwolić firma. Powstało zatem zadanie poszukiwania nowych rynków zbytu, odpowiadających rynkowi pod względem szybkości, kosztów wewnętrznych i efektywności.
Jak mierzyć skuteczność migracji do mikroserwisów
Dmitrij:
Jak określa się powodzenie migracji do mikroserwisów? Jakie było „przed” w każdej firmie? Jakiego miernika użyłeś do określenia powodzenia przejścia i kto tak naprawdę o tym zadecydował?
Sergey:
Przede wszystkim narodził się w IT jako czynnik umożliwiający „odblokowanie” nowych możliwości. Musieliśmy zrobić wszystko szybciej za relatywnie te same pieniądze, odpowiadając na wyzwania rynkowe. Teraz sukces wyraża się w liczbie usług ponownie wykorzystywanych przez różne systemy, ujednoliceniu procesów między sobą. Teraz tak jest, ale wtedy była to szansa na stworzenie platformy i potwierdzenie hipotezy, że da się to zrobić, da to efekt i wyliczy uzasadnienie biznesowe.
Aleksander:
Sukces jest raczej uczuciem wewnętrznym. Biznes zawsze chce więcej, a głębokość naszych backlogów jest dowodem na sukces. Tak mi się wydaje.
Sergey:
Tak, zgadzam się. W ciągu trzech lat mamy już ponad dwieście usług i zaległości. Zapotrzebowanie na zasoby w zespole tylko rośnie – o 30% rocznie. Dzieje się tak, bo ludzie poczuli: jest szybciej, jest inaczej, są inne technologie, to wszystko się rozwija.
Mikrousługi nadejdą, ale rdzeń pozostanie
Dmitrij:
To jak niekończący się proces, w którym inwestujesz w rozwój. Czy przejście na mikrousługi dla biznesu już się skończyło, czy jeszcze nie?
Sergey:
Bardzo łatwo jest odpowiedzieć. Jak myślicie: wymiana telefonów to proces niekończący się? Sami kupujemy telefony co roku. I oto jest: dopóki będzie potrzeba szybkości, dostosowania się do rynku, potrzebne będą pewne zmiany. Nie oznacza to jednak, że porzucamy standardowe rzeczy.
Ale nie jesteśmy w stanie pokryć i przerobić wszystkiego na raz. Mamy starsze, standardowe usługi integracyjne, które istniały wcześniej: autobusy dla przedsiębiorstw i tak dalej. Ale są zaległości i jest też potrzeba. Rośnie liczba aplikacji mobilnych i ich funkcjonalność. Jednocześnie nikt nie mówi, że otrzymasz 30% więcej pieniędzy. Oznacza to, że z jednej strony zawsze są potrzeby, a z drugiej poszukiwanie efektywności.
Dmitrij:
Życie jest w dobrej formie. (Śmiech)
Aleksander:
Ogólnie rzecz biorąc, tak. Nie mamy rewolucyjnego podejścia do usuwania rdzenia z krajobrazu. Trwają systematyczne prace nad dekompozycją systemów tak, aby były bardziej spójne z architekturą mikroserwisową, aby ograniczyć wzajemne oddziaływanie systemów.
Planujemy jednak zachować podstawową część, ponieważ w krajobrazie operatora zawsze będą jakieś platformy, które kupimy. Ponownie potrzebujemy zdrowej równowagi: nie powinniśmy spieszyć się z wycinaniem rdzenia. Układamy systemy obok siebie i teraz okazuje się, że jesteśmy już na szczycie wielu kluczowych części. Ponadto rozwijając funkcjonalność, tworzymy niezbędne reprezentacje dla wszystkich kanałów współpracujących z naszymi usługami komunikacyjnymi.
Jak sprzedawać mikrousługi firmom
Dmitrij:
Ciekawi mnie też - dla tych, którzy nie przeszli, ale planują: jak łatwo było sprzedać ten pomysł biznesowi i czy była to przygoda, projekt inwestycyjny? A może była to świadoma strategia: teraz przechodzimy do mikroserwisów i tyle, nic nas nie zatrzyma. Jak to było dla Ciebie?
Sergey:
Nie sprzedawaliśmy podejścia, ale korzyść biznesową. Wystąpił problem w biznesie i próbowaliśmy go rozwiązać. Wyrażało się to wówczas tym, że różne kanały stosowały odmienne zasady naliczania cen – osobno dla promocji, osobno dla promocji i tak dalej. Był trudny w utrzymaniu, pojawiały się błędy i słuchaliśmy skarg klientów. Oznacza to, że sprzedawaliśmy rozwiązanie problemu, ale przyszliśmy z tym, że potrzebowaliśmy pieniędzy na stworzenie platformy. I pokazali business case na przykładzie pierwszego etapu inwestycji: w jaki sposób będziemy to dalej odzyskiwać i na co nam to pozwoli.
Dmitrij:
Czy zapisałeś w jakiś sposób czas pierwszego etapu?
Sergey:
Tak, oczywiście. Na stworzenie rdzenia jako platformy i przetestowanie pilota przeznaczyliśmy 6 miesięcy. W tym czasie próbowaliśmy stworzyć platformę, na której będzie można jeździć pilotem. Następnie hipoteza została potwierdzona, a skoro działa, oznacza to, że możemy kontynuować. Zaczęli powielać i wzmacniać zespół - przenieśli go do osobnej dywizji, która właśnie się tym zajmowała.
Następnie przychodzi systematyczna praca w oparciu o potrzeby biznesowe, możliwości, dostępność zasobów i wszystko, co jest aktualnie w przygotowaniu.
Dmitrij:
OK. Aleksandrze, co powiesz?
Aleksander:
Nasze mikroserwisy narodziły się z „piany morskiej” – z oszczędności zasobów, z powodu pewnych resztek w postaci pojemności serwerów i redystrybucji sił w zespole. Początkowo nie sprzedawaliśmy tego projektu biznesowi. Był to projekt, w ramach którego oboje prowadziliśmy badania i odpowiednio się rozwijaliśmy. Zaczęliśmy z początkiem 2018 roku i po prostu z entuzjazmem rozwijaliśmy ten kierunek. Sprzedaż właśnie się rozpoczęła i jesteśmy w trakcie.
Dmitrij:
Czy zdarza się, że firma pozwala na robienie takich rzeczy jak Google - w jeden wolny dzień w tygodniu? Czy masz taki kierunek?
Aleksander:
Równolegle z badaniami zajmowaliśmy się także problemami biznesowymi, dlatego wszystkie nasze mikroserwisy są rozwiązaniami problemów biznesowych. Dopiero na początku budowaliśmy mikroserwisy, które obejmowały niewielką część bazy abonentów, a obecnie jesteśmy obecni w niemal wszystkich flagowych produktach.
A materialny wpływ jest już widoczny – już można nas policzyć, tempo wprowadzenia produktów na rynek i utracone przychody można oszacować, gdybyśmy podążali starą ścieżką. Na tym budujemy sprawę.
Mikrousługi: szum czy konieczność?
Dmitrij:
Liczby to liczby. A dochód lub zaoszczędzone pieniądze są bardzo ważne. A co jeśli spojrzysz na drugą stronę? Wydaje się, że mikroserwisy są trendem, szumem i wiele firm je nadużywa? Jak wyraźnie odróżniasz to, co robisz, od tego, czego nie przekładasz na mikrousługi? Jeśli dziedzictwo jest teraz, czy będziesz je nadal mieć za 5 lat? Jaki będzie wiek systemów informatycznych działających w M.Video-Eldorado i MegaFon za 5 lat? Czy będą systemy informacyjne sprzed dziesięciu, piętnastu lat, czy będzie to nowa generacja? Jak to widzisz?
Sergey:
Wydaje mi się, że trudno jest myśleć bardzo daleko. Jeśli spojrzymy wstecz, kto spodziewał się, że rynek technologii, w tym uczenia maszynowego i identyfikacji użytkowników po twarzy, będzie się tak rozwijać? Ale jeśli spojrzeć na najbliższe lata, wydaje mi się, że systemy podstawowe, korporacyjne systemy klasy ERP w firmach – sprawdzają się już dość długo.
Nasze firmy mają łącznie 25 lat, a klasyczny system ERP jest bardzo głęboko zakorzeniony w krajobrazie systemów. Oczywiste jest, że pobieramy stamtąd niektóre elementy i staramy się je zagregować w mikrousługi, ale rdzeń pozostanie. Trudno mi sobie teraz wyobrazić, że wymienimy tam wszystkie podstawowe systemy i szybko przejdziemy na drugą, jasną stronę nowych systemów.
Jestem zwolennikiem tego, że wszystko, co jest bliżej klienta i konsumenta, jest tam, gdzie jest największa korzyść i wartość biznesowa, gdzie elastyczność i skupienie na szybkości, na zmianie, na „spróbuj, anuluj, wykorzystaj ponownie, zrób coś innego” potrzebne” – tam właśnie zmieni się krajobraz. A produkty pudełkowe nie bardzo się tam mieszczą. Przynajmniej my tego nie widzimy. Tam potrzebne są najprostsze rozwiązania.
Widzimy ten rozwój:
- podstawowe systemy informatyczne (głównie back-office);
- warstwy środkowe w postaci mikrousług łączą rdzeń, agregują, tworzą pamięć podręczną i tak dalej;
- systemy pierwszej linii są skierowane do konsumenta;
- warstwa integracji, która jest zazwyczaj zintegrowana z rynkami, innymi systemami i ekosystemami. Warstwa ta jest możliwie najlżejsza, prosta i zawiera minimum logiki biznesowej.
Ale jednocześnie jestem zwolennikiem dalszego stosowania starych zasad, jeśli będą one stosowane właściwie.
Załóżmy, że masz klasyczny system korporacyjny. Znajduje się w krajobrazie jednego dostawcy i składa się z dwóch współpracujących ze sobą modułów. Dostępny jest również standardowy interfejs integracyjny. Po co to przerabiać i wprowadzać tam mikroserwis?
Kiedy jednak w back office znajduje się 5 modułów, z których zbierane są informacje do procesu biznesowego, który następnie jest wykorzystywany przez 8-10 systemów pierwszej linii, korzyść jest natychmiast zauważalna. Bierzesz z pięciu systemów back-office i tworzysz usługę, wyizolowaną, skupioną na procesie biznesowym. Spraw, aby usługa była zaawansowana technologicznie - tak, aby buforowała informacje i była odporna na awarie, a także współpracowała z dokumentami lub podmiotami gospodarczymi. I integrujesz go według jednej zasady ze wszystkimi produktami pierwszej linii. Anulowali produkt pierwszej linii – po prostu wyłączyli integrację. Jutro musisz napisać aplikację mobilną lub zrobić małą stronę internetową i wprowadzić w funkcjonalność tylko jedną część - wszystko jest proste: zmontowałeś to jak konstruktor. Widzę dalszy rozwój w tym kierunku – przynajmniej w naszym kraju.
Aleksander:
Sergey całkowicie opisał nasze podejście, dziękuję. Powiem tylko, gdzie na pewno nie pójdziemy - do sedna, czyli do tematu rozliczeń online. Oznacza to, że ocena i ładowanie pozostaną w rzeczywistości „dużą” młocarnią, która niezawodnie odpisze pieniądze. System ten będzie nadal certyfikowany przez nasze organy regulacyjne. Wszystko inne, co patrzy na klientów, to oczywiście mikrousługi.
Dmitrij:
Tutaj certyfikacja to jedna historia. Pewnie większe wsparcie. Jeśli niewiele wydajesz na wsparcie lub system nie wymaga wsparcia i modyfikacji, lepiej go nie dotykać. Rozsądny kompromis.
Jak rozwijać niezawodne mikroserwisy
Dmitrij:
Cienki. Ale nadal jestem zainteresowany. Teraz opowiadasz historię sukcesu: wszystko było w porządku, przeszliśmy na mikrousługi, broniliśmy pomysłu przed biznesem i wszystko się udało. Ale słyszałem inne historie.
Kilka lat temu szwajcarska firma, która zainwestowała dwa lata w rozwój nowej platformy mikrousług dla banków, ostatecznie zamknęła projekt. Całkowicie upadł. Wydano wiele milionów franków szwajcarskich, a ostatecznie zespół został rozproszony - nie wyszło.
Czy mieliście podobne historie? Czy były lub są jakieś trudności? Przykładowo utrzymanie mikroserwisów i monitorowanie również przyprawiają o ból głowy w działalności operacyjnej firmy. W końcu liczba komponentów wzrasta dziesiątki razy. Jak to widzisz, czy zdarzały się tu przykłady nieudanych inwestycji? A co możesz doradzić ludziom, aby nie spotkali się z takimi problemami?
Aleksander:
Do nieudanych przykładów zaliczały się zmiany priorytetów przedsiębiorstw i anulowanie projektów. Na dobrym etapie gotowości (właściwie MVP jest już gotowy) firma stwierdziła: „Mamy nowe priorytety, przechodzimy do innego projektu, a ten zamykamy”.
Nie mieliśmy żadnych globalnych awarii z mikroserwisami. Śpimy spokojnie, mamy dyżur całodobowy, obsługujący cały BSS.
I jeszcze jedno – mikroserwisy wynajmujemy na zasadach jakie obowiązują w przypadku produktów pudełkowych. Kluczem do sukcesu jest to, że w pierwszej kolejności trzeba skompletować zespół, który kompleksowo przygotuje mikroserwis do produkcji. Sam rozwój wynosi warunkowo 40%. Reszta to analityka, metodyka DevSecOps, odpowiednie integracje i odpowiednia architektura. Szczególną uwagę zwracamy na zasady budowania bezpiecznych aplikacji. Przedstawiciele bezpieczeństwa informacji uczestniczą w każdym projekcie zarówno na etapie planowania architektury, jak i podczas procesu wdrażania. Zarządzają także systemami analizującymi kod pod kątem luk.
Załóżmy, że wdrażamy nasze usługi bezstanowe — mamy je w Kubernetesie. Dzięki temu wszyscy mogą spać spokojnie dzięki automatycznemu skalowaniu i automatycznemu podnoszeniu usług, a zmiana dyżurów wychwytuje incydenty.
W całym istnieniu naszych mikroserwisów tylko jeden lub dwa incydenty dotarły do naszej linii. Teraz nie ma żadnych problemów z działaniem. Mamy oczywiście nie 200, ale około 50 mikroserwisów, ale są one wykorzystywane w sztandarowych produktach. Jeśli im się nie uda, dowiemy się o tym pierwsi.
Mikrousługi i HR
Sergey:
Zgadzam się z kolegą co do przeniesienia do supportu - że trzeba dobrze zorganizować pracę. Ale opowiem o problemach, które oczywiście istnieją.
Po pierwsze, technologia jest nowa. To jest szum w dobrym tego słowa znaczeniu, a znalezienie specjalisty, który to zrozumie i będzie w stanie to stworzyć, jest dużym wyzwaniem. Konkurencja o zasoby jest szalona, więc eksperci są na wagę złota.
Po drugie, wraz z tworzeniem się określonych krajobrazów i rosnącą liczbą usług, należy stale rozwiązywać problem ponownego wykorzystania. Jak to lubią programiści: „Napiszmy tu teraz wiele ciekawych rzeczy…” Z tego powodu system rośnie i traci swoją efektywność pod względem finansowym, kosztu posiadania i tak dalej. Oznacza to, że konieczne jest uwzględnienie ponownego użycia w architekturze systemu, uwzględnienie go w planie działania dotyczącym wprowadzenia usług i przeniesienia dziedzictwa do nowej architektury.
Kolejnym problemem – choć na swój sposób dobrym – jest konkurencja wewnętrzna. „Och, pojawili się tu nowi modni faceci, mówią nowym językiem”. Ludzie są oczywiście różni. Są tacy, którzy są przyzwyczajeni do pisania w Javie, i tacy, którzy piszą i używają Dockera i Kubernetesa. To zupełnie inni ludzie, inaczej mówią, używają innych terminów, a czasami się nie rozumieją. Problemem jest także możliwość lub niemożność dzielenia się praktyką, dzielenia się wiedzą w tym sensie.
Cóż, skalowanie zasobów. "Świetnie, chodźmy! A teraz chcemy szybciej, więcej. Co, nie możesz? Czy nie można dostarczyć dwa razy więcej w ciągu roku? I dlaczego?" Takie bóle wzrostowe są prawdopodobnie standardem w przypadku wielu rzeczy, wielu podejść i można je poczuć.
Odnośnie monitoringu. Wydaje mi się, że usługi czy narzędzia do monitoringu przemysłowego już się uczą lub są w stanie współpracować zarówno z Dockerem, jak i Kubernetesem w innym, niestandardowym trybie. Żeby np. nie skończyło się na 500 maszynach Java, na których to wszystko działa, czyli się agreguje. Ale tym produktom wciąż brakuje dojrzałości, muszą przez to przejść. Temat jest naprawdę nowy, będzie nadal rozwijany.
Dmitrij:
Tak, bardzo interesujące. I to dotyczy HR. Być może Twój proces HR i marka HR nieco się zmieniły przez te 3 lata. Zaczęliście rekrutować kolejne osoby o innych kompetencjach. I prawdopodobnie są zarówno zalety, jak i wady. Wcześniej szumem było blockchain i data science, a specjaliści od nich byli warci miliony. Teraz koszty spadają, rynek się nasyca i podobny trend panuje w mikroserwisach.
Sergey:
Tak, absolutnie.
Aleksander:
HR zadaje pytanie: „Gdzie jest Twój różowy jednorożec pomiędzy backendem a frontendem?” Dział HR nie rozumie, czym jest mikrousługa. Zdradziliśmy im sekret i powiedzieliśmy, że backend zrobił wszystko i nie ma jednorożca. Ale HR się zmienia, szybko się uczy i rekrutuje osoby, które mają podstawową wiedzę IT.
Ewolucja mikroserwisów
Dmitrij:
Jeśli spojrzeć na docelową architekturę, mikroserwisy wyglądają jak taki potwór. Twoja podróż trwała kilka lat. Inni mają rok, inni trzy lata. Czy przewidziałeś wszystkie problemy, docelową architekturę, czy coś się zmieniło? Na przykład w przypadku mikrousług ponownie pojawiają się bramy i siatki usług. Korzystaliście z nich na początku, czy zmienialiście samą architekturę? Czy masz takie wyzwania?
Sergey:
Przepisaliśmy już kilka protokołów komunikacyjnych. Na początku był jeden protokół, teraz przeszliśmy na inny. Zwiększamy bezpieczeństwo i niezawodność. Zaczynaliśmy od technologii korporacyjnych - Oracle, Web Logic. Obecnie odchodzimy od technologicznych produktów korporacyjnych w mikroserwisach na rzecz technologii open source lub całkowicie otwartych. Porzucamy bazy danych i przechodzimy do tego, co w tym modelu sprawdza się dla nas skuteczniej. Nie potrzebujemy już technologii Oracle.
Zaczęliśmy po prostu jako usługa, nie myśląc o tym, jak bardzo potrzebujemy pamięci podręcznej, co byśmy zrobili, gdyby nie było połączenia z mikroserwisem, ale potrzebne były dane itp. Teraz rozwijamy platformę, aby można było opisać architekturę nie w języku usług, a w języku biznesowym, przenieś logikę biznesową na wyższy poziom, gdy zaczniemy mówić słowami. Teraz nauczyliśmy się mówić literami, a następny poziom to moment, w którym usługi zostaną zebrane w jakiś agregat, gdy jest to już słowo – na przykład cała karta produktu. Jest złożony z mikrousług, ale jest to interfejs API zbudowany na tym.
Bezpieczeństwo jest bardzo ważne. Gdy tylko zaczniesz być dostępny i masz usługę, dzięki której możesz uzyskać wiele ciekawych rzeczy i to bardzo szybko, w ułamku sekundy, pojawia się chęć zdobycia tego w niezbyt bezpieczny sposób. Aby temu zaradzić, musieliśmy zmienić podejście do testowania i monitorowania. Musieliśmy zmienić zespół, strukturę zarządzania dostawami, CI/CD.
To ewolucja – podobnie jak w przypadku telefonów, tylko znacznie szybsza: najpierw były telefony z przyciskiem, potem pojawiły się smartfony. Przepisali i przeprojektowali produkt, bo rynek miał inną potrzebę. Tak ewoluujemy: pierwsza klasa, dziesiąta klasa, praca.
Iteracyjnie co roku układa się coś z punktu widzenia technologii, coś innego z punktu widzenia zaległości i potrzeb. Łączymy jedną rzecz z drugą. Zespół wydaje 20% na dług techniczny i wsparcie techniczne zespołu, 80% na podmiot gospodarczy. Poruszamy się ze zrozumieniem, dlaczego to robimy, dlaczego wprowadzamy te udoskonalenia technologiczne i do czego one doprowadzą. Tak.
Dmitrij:
Fajny. Co jest w MegaFonie?
Aleksander:
Głównym wyzwaniem, gdy doszliśmy do mikroserwisów, było nie popadnięcie w chaos. Biuro architektoniczne MegaFon natychmiast dołączyło do nas, a nawet zostało inicjatorem i motorem napędowym - teraz mamy bardzo silną architekturę. Jego zadaniem było zrozumienie, do jakiego modelu docelowego zmierzamy i jakie technologie wymagają pilotażu. W przypadku architektury sami przeprowadziliśmy te pilotaże.
Następne pytanie brzmiało: „Więc jak to wszystko wykorzystać?” I jeszcze jedno: „Jak zapewnić przejrzystą interakcję pomiędzy mikroserwisami?” Service mesh pomógł nam odpowiedzieć na ostatnie pytanie. Pilotowaliśmy Istio i podobały nam się wyniki. Teraz jesteśmy na etapie wchodzenia w strefy produkcyjne. Do wszelkich wyzwań podchodzimy pozytywnie – fakt, że trzeba ciągle zmieniać stos, uczyć się czegoś nowego. Nas interesuje rozwój, a nie wykorzystywanie starych rozwiązań.
Dmitrij:
Złote słowa! Takie wyzwania utrzymują zespół i firmę w dobrej kondycji oraz tworzą przyszłość. RODO stworzyło głównych inspektorów ochrony danych, a obecne wyzwania tworzą głównych inspektorów ds. mikrousług i architektury. I to się podoba.
Dużo dyskutowaliśmy. Najważniejsze, że dobry projekt mikroserwisów i sama architektura pozwala uniknąć wielu błędów. Oczywiście proces ten jest iteracyjny i ewolucyjny, ale jest to przyszłość.
Dziękujemy wszystkim uczestnikom, dziękujemy Siergiejowi i Aleksandrowi!
Pytania od publiczności
Pytanie od publiczności (1):
Siergiej, jak zmieniło się zarządzanie IT w Twojej firmie? Rozumiem, że w przypadku dużego stosu kilku systemów zarządzanie nim jest dość jasnym i logicznym procesem. Jak odbudowaliście zarządzanie komponentem IT po zintegrowaniu bardzo dużej liczby mikroserwisów w tak krótkim czasie?
Sergey:
Zgadzam się z kolegą, że architektura jest bardzo ważna jako siła napędowa zmian. Zaczęliśmy od posiadania działu architektonicznego. Architekci są jednocześnie właścicielami rozkładu funkcjonalności i wymagań dotyczących jej wyglądu w krajobrazie. Pełnią więc także rolę koordynatorów tych zmian. W rezultacie, gdy tworzyliśmy platformę CI/CD, nastąpiły konkretne zmiany w konkretnym procesie dostarczania.
Ale standardowe, podstawowe zasady rozwoju, analizy biznesowej, testowania i rozwoju nie zostały anulowane. Po prostu dodaliśmy prędkość. Poprzednio cykl zajmował tyle czasu, że instalacja na środowiskach testowych zajmowała o wiele więcej. Teraz biznes dostrzega korzyści i mówi: „Dlaczego nie możemy zrobić tego samego w innych miejscach?”
To jak w dobrym tego słowa znaczeniu zastrzyk w postaci szczepionki, który pokazał: można to zrobić w ten sposób, ale można to zrobić w inny sposób. Oczywiście istnieje problem związany z personelem, kompetencjami, wiedzą i oporem.
Pytanie od publiczności (2):
Krytycy architektury mikrousług twierdzą, że testowanie i rozwój są trudne. Jest to logiczne, gdy sprawy się komplikują. Z jakimi wyzwaniami musiał się zmierzyć Twój zespół i jak sobie z nimi poradziłeś? Pytanie do wszystkich.
Aleksander:
Przy przechodzeniu z mikroserwisów na platformę występują trudności, ale można je rozwiązać.
Przykładowo tworzymy produkt składający się z 5-7 mikrousług. Musimy zapewnić testy integracyjne na całym stosie mikrousług, aby dać zielone światło na przejście do gałęzi głównej. To zadanie nie było dla nas nowe: robiliśmy to od dawna w BSS, kiedy dostawca dostarczał nam już dostarczone rozwiązania.
A nasz problem dotyczy tylko małego zespołu. Do jednego produktu warunkowego potrzebny jest jeden inżynier ds. kontroli jakości. I tak dostarczamy produkt składający się z 5-7 mikrousług, z czego 2-3 mogą być rozwijane przez strony trzecie. Na przykład mamy produkt, w rozwoju którego uczestniczy nasz dostawca systemu rozliczeniowego, grupa Mail.ru i dział badawczo-rozwojowy MegaFon. Musimy to objąć testami przed wysłaniem go do produkcji. Inżynier ds. kontroli jakości pracuje nad tym produktem od półtora miesiąca, a reszta zespołu pozostaje bez jego wsparcia.
Ta złożoność jest spowodowana jedynie skalowaniem. Rozumiemy, że mikrousługi nie mogą istnieć w próżni, nie istnieje absolutna izolacja. Zmieniając jedną usługę, zawsze staramy się zachować umowę API. Jeśli coś zmieni się pod maską, serwis z przodu pozostaje. Jeśli zmiany są fatalne, następuje pewnego rodzaju transformacja architektoniczna i przechodzimy do zupełnie innego metamodelu danych, który jest całkowicie niekompatybilny - dopiero wtedy mówimy o pojawieniu się specyfikacji API usługi v2. Obsługujemy jednocześnie pierwszą i drugą wersję, a po przejściu wszystkich konsumentów na drugą wersję, po prostu zamykamy pierwszą.
Sergey:
Chcę dodać. Całkowicie zgadzam się co do komplikacji - one się zdarzają. Krajobraz staje się coraz bardziej złożony, a koszty ogólne rosną, szczególnie w przypadku testowania. Jak sobie z tym poradzić: przejdź na testy automatyczne. Tak, będziesz musiał dodatkowo zainwestować w pisanie autotestów i testów jednostkowych. Aby programiści nie mogli zatwierdzić bez zdania testu, nie mogli zmienić kodu. Aby nawet przycisk nie działał bez autotestu, testu jednostkowego.
Ważne jest, aby zachować poprzednią funkcjonalność, a to wiąże się z dodatkowym obciążeniem. Jeśli przepiszesz technologię na inny protokół, to przepisujesz ją, aż do całkowitego zamknięcia wszystkiego.
Czasem celowo nie przeprowadzamy testów typu end-to-end, bo nie chcemy wstrzymywać rozwoju, chociaż też mamy jedno po drugim. Krajobraz jest bardzo duży, złożony, istnieje wiele systemów. Czasami są to tylko odcinki pośrednie – tak, obniżasz margines bezpieczeństwa, pojawia się większe ryzyko. Ale jednocześnie uwalniasz podaż.
Aleksander:
Tak, autotesty i testy jednostkowe pozwalają stworzyć usługę wysokiej jakości. Jesteśmy za rurociągiem, którego nie można przejść bez testów jednostkowych i integracyjnych. Często musimy przeciągać emulatory i systemy komercyjne do stref testowych i środowisk programistycznych, ponieważ nie wszystkie systemy można umieścić w strefach testowych. Co więcej, nie tylko się zamoczą – generujemy pełnoprawną reakcję systemu. To poważna część pracy z mikroserwisami i my również w to inwestujemy. Bez tego zapanuje chaos.
Pytanie od publiczności (3):
O ile rozumiem, mikroserwisy początkowo wyrosły z osobnego zespołu i obecnie istnieją w tym modelu. Jakie są jego zalety i wady?
Mamy podobną historię: powstała swego rodzaju fabryka mikrousług. Teraz koncepcyjnie doszliśmy do punktu, w którym rozszerzamy to podejście na produkcję poprzez strumienie i systemy. Inaczej mówiąc, odchodzimy od scentralizowanego rozwoju mikroserwisów, modeli mikroserwisów, a zbliżamy się do systemów.
W związku z tym nasze działanie dotyczy również systemów, czyli decentralizujemy ten temat. Jakie jest Twoje podejście i jaka jest Twoja docelowa historia?
Aleksander:
Z ust wyrzuciłeś nazwę „fabryka mikrousług” – my też chcemy skalować. Po pierwsze, naprawdę mamy teraz jeden zespół. Chcemy zapewnić wszystkim zespołom programistów, którymi dysponuje MegaFon, możliwość pracy we wspólnym ekosystemie. Nie chcemy całkowicie przejąć całej funkcjonalności programistycznej, którą mamy obecnie. Zadaniem lokalnym jest skalowanie, zadaniem globalnym jest poprowadzenie rozwoju do wszystkich zespołów w warstwie mikroserwisów.
Sergey:
Opowiem ci drogę, którą przeszliśmy. Tak naprawdę zaczęliśmy pracować jako jeden zespół, ale teraz nie jesteśmy sami. Jestem zwolennikiem następującego założenia: musi być właściciel procesu. Ktoś musi zrozumieć, zarządzać, kontrolować i budować proces rozwoju mikrousług. Musi posiadać zasoby i angażować się w zarządzanie nimi.
Te zasoby, które znają technologie, specyfikę i rozumieją, jak budować mikrousługi, można ulokować w zespołach produktowych. Mamy mieszankę, w której osoby z platformy mikroserwisowej znajdują się w zespole produktowym tworzącym aplikację mobilną. Są tam, ale pracują zgodnie z procesem działu zarządzania platformą mikroserwisową ze swoim menadżerem ds. rozwoju. W ramach tego pionu wyodrębniony jest zespół zajmujący się technologią. Oznacza to, że mieszamy między sobą wspólną pulę zasobów i dzielimy je, przekazując zespołom.
Jednocześnie proces pozostaje ogólny, kontrolowany, przebiega według ogólnych zasad technologicznych, z testami jednostkowymi i tak dalej - wszystko, co jest zbudowane na wierzchu. Mogą występować kolumny w formie zasobów zebranych z różnych działów podejścia produktowego.
Aleksander:
Sergey, właściwie jesteś właścicielem procesu, prawda? Czy backlog zadań jest wspólny? Kto jest odpowiedzialny za jego dystrybucję?
Sergey:
Spójrz: oto znowu miks. Istnieją zaległości, które powstają w wyniku udoskonaleń technologicznych – to jedna historia. Istnieje backlog, który jest formułowany z projektów i jest backlog z produktów. Natomiast kolejność wprowadzania do każdego z produktów usługi czy tworzenia tej usługi ustala specjalista produktowy. Nie należy do dyrekcji IT, został z niej specjalnie usunięty. Ale moi ludzie z pewnością pracują według tego samego procesu.
Właścicielem zaległości w różnych kierunkach – zaległości zmian – będą różne osoby. Połączenie usług technologicznych, zasada ich organizacji - to wszystko będzie w IT. Jestem właścicielem platformy i zasobów. Na górze jest to, co dotyczy zaległości i zmian funkcjonalnych, a także architektury w tym sensie.
Załóżmy, że firma mówi: „Chcemy tej funkcji, chcemy stworzyć nowy produkt – przerobić pożyczkę”. Odpowiadamy: „Tak, przerobimy to”. Architekci mówią: „Zastanówmy się: gdzie w pożyczce napiszemy mikroserwisy i jak to zrobimy?” Następnie rozkładamy to na projekty, produkty czy stos technologii, dzielimy na zespoły i wdrażamy. Stworzyłeś produkt wewnętrznie i zdecydowałeś się na wykorzystanie w nim mikroserwisów? Mówimy: „Teraz dotychczasowe systemy, które mieliśmy lub systemy pierwszej linii, muszą przejść na te mikrousługi”. Architekci mówią: „A więc: w zaległościach technologicznych wewnątrz produktów pierwszej linii – przejście na mikrousługi. Iść". Specjaliści ds. produktów lub właściciele firm rozumieją, ile mocy produkcyjnych zostało przydzielonych, kiedy zostanie to wykonane i dlaczego.
Koniec dyskusji, ale nie wszystko
Zorganizowano konferencję mailto:CLOUD .
Realizujemy także inne wydarzenia - m.in. Spotkanie @Kubernetes, gdzie zawsze poszukujemy świetnych prelegentów:
- Śledź @Kubernetes i inne wiadomości @Meetup na naszym kanale Telegram
- Chcesz przemawiać na jednym z @Meetups? Zostaw prośbę o
Źródło: www.habr.com