Dlaczego takie korporacje, jak MegaFon, potrzebują Tarantoola w billing? Z zewnątrz wydaje się, że zazwyczaj pojawia się dostawca, przynosi jakąś dużą skrzynkę, wkłada wtyczkę do gniazdka — i oto jest billing! Kiedyś tak było, ale teraz to już archaizm, a takie dinozaury już wymarły lub wymierają. Początkowo billing to system do wystawiania rachunków — kalkulator lub liczydło. W nowoczesnym telecomie — to system automatyzacji całego cyklu życia interakcji z abonentem, od zawarcia umowy do rozwiązania, w tym real-time taryfikację, przyjmowanie płatności i wiele więcej. Billing w firmach telekomunikacyjnych przypomina robota bojowego — dużego, potężnego i obwieszonego bronią.
A co ma wspólnego z tym Tarantool? O tym opowiedzą Oleg Iwlew i Andriej Kniaziev. Oleg — główny architekt firmy z ogromnym doświadczeniem w pracy w zagranicznych firmach, Andriej — dyrektor ds. systemów biznesowych. Z wystąpienia ich raportu na dowiesz się, po co potrzebna jest R&D w korporacjach, czym jest Tarantool, jak pułapka pionowego skalowania i globalizacja stały się przesłankami pojawienia się tej bazy danych w firmie, o wyzwaniach technologicznych, transformacji architektury i czym technostek MegaFon przypomina Netflix, Google i Amazon.
Projekt 'Jednolity billing'
Projekt, o którym będzie mowa, nazywa się 'Jednolity billing'. To w nim Tarantool ujawnił swoje najlepsze cechy.
Wzrost wydajności Hi-End sprzętu nie nadążał za wzrostem bazy abonentów i liczby usług, oczekiwano dalszego wzrostu liczby abonentów i usług dzięki M2M, IoT, a charakterystyka filii prowadziła do pogorszenia time-to-market. Firma podjęła decyzję o stworzeniu jednolitego systemu biznesowego z unikalną modułową architekturą światowej klasy, w zamian za 8 różnych aktualnych systemów billingowych.
MegaFon to osiem firm w jednej. W 2009 roku zakończono reorganizację: filie w całej Rosji połączyły się w jedną firmę OAO 'MegaFon' (obecnie PAO). W ten sposób w firmie pojawiło się 8 systemów billingowych z własnymi 'customowymi' rozwiązaniami, cechami filiałów oraz różną strukturą organizacyjną, IT i marketingiem.
Wszystko było w porządku, aż do momentu, gdy trzeba było uruchomić jeden wspólny federalny produkt. Pojawiło się wiele trudności: u niektórych taryfikacja zaokrąglała w górę, u innych w dół, a jeszcze inni stosowali średnią arytmetyczną. Takich sytuacji było tysiące.
Pomimo tego, że wersja systemu billingowego była jedna, jeden dostawca, ustawienia rozchodziły się tak, że było trudno to posklejać. Próbowaliśmy ograniczyć ich liczbę i natknęliśmy się na drugi problem, który jest znany wielu korporacjom.
Pionowe skalowanie. Nawet najlepszy sprzęt w tamtym czasie nie odpowiadał potrzebom. W pracy używano sprzętu Hewlett-Packard, z linii Superdome Hi-End, ale nie zaspokajał on potrzeb nawet dwóch oddziałów. Chcieliśmy poziomego skalowania bez dużych kosztów operacyjnych i kapitałowych.
Oczekiwanie na wzrost liczby abonentów i usług. Konsultanci od lat przynosili do świata telekomunikacji opowieści o IoT i M2M: nadejdą czasy, kiedy w każdym telefonie i żelazku będzie jedna karta SIM, a w lodówce po dwie. Dziś mamy jedną liczbę abonentów, a w najbliższej przyszłości będzie ich znacznie więcej.
Wyzwania technologiczne
Te cztery powody popychały nas ku poważnym zmianom. Był wybór między modernizacją systemu a projektowaniem od podstaw. Długo myśleliśmy, podejmowaliśmy poważne decyzje, przeprowadzaliśmy przetargi. Ostatecznie postanowiliśmy zaprojektować od początku i wzięliśmy się za ciekawe wyzwania - wyzwania technologiczne.
Skalowalność
Jeśli wcześniej było, powiedzmy, 8 billingów po 15 mln abonentów, a teraz miało być 100 mln abonentów i więcej — obciążenie jest znacznie wyższe.
Staliśmy się porównywalni pod względem skali z dużymi graczami internetowymi, jak Mail.ru czy Netflix.
Jednak dalszy wzrost obciążenia i bazy abonentów postawił przed nami poważne wyzwania.
Geografia naszego rozległego kraju
Między Kaliningradem a Władywostokiem 7500 km i 10 stref czasowych. Prędkość światła jest skończona, a przy takich odległościach opóźnienia są już znaczące. 150 ms na najnowocześniejszych kanałach optycznych to za dużo dla taryfikacji w czasie rzeczywistym, zwłaszcza takiej, jak teraz w telekomunikacji w Rosji. Ponadto, należy się zaktualizować w ciągu jednego dnia roboczego, a przy różnych strefach czasowych to problem.
Nie tylko oferujemy usługi abonamentowe, mamy złożone taryfy, pakiety i różne modyfikatory. Musimy nie tylko zezwolić lub zabronić abonentowi na telefonowanie, ale również przydzielić mu określoną kwotę - obliczać połączenia i działania w czasie rzeczywistym w taki sposób, żeby ich nie zauważył.
Odporność na awarie
To jest odwrotna strona centralizacji.
Jeśli zbieramy wszystkich abonentów w jednym systemie, to wszelkie awarie i katastrofy są katastrofalne dla biznesu. Dlatego projektujemy system tak, aby wyeliminować wpływ awarii na całą bazę abonentów.
To jest znowu konsekwencja rezygnacji z pionowego skalowania. Kiedy przeszliśmy na poziome skalowanie, zwiększyliśmy liczbę serwerów z setek do tysięcy. Musimy nimi zarządzać, budować wymienność, automatycznie rezerwować infrastrukturę IT i przywracać rozproszony system.
Przed nami stały takie interesujące wyzwania. Zaprojektowaliśmy system i w tym momencie próbowaliśmy znaleźć światowe najlepsze praktyki, aby sprawdzić, na ile jesteśmy na bieżąco, na ile śledzimy nowoczesne technologie.
Światowe doświadczenie
Zdziwiające, ale w światowym telekomie nie znaleźliśmy żadnego odniesienia.
Europie zabrakło liczby abonentów i skali, USA - przez płaskość swoich taryf. Coś obejrzeliśmy w Chinach, a coś znaleźliśmy w Indiach i wzięliśmy specjalistów z Vodafone India.
Aby przeanalizować architekturę, zebraliśmy Dream Team kierowany przez IBM - architektów z różnych dziedzin. Ci ludzie mogli adekwatnie ocenić, co robimy i wnieść do naszej architektury pewne wiedzę.
Skalowanie
Kilka liczb dla ilustracji.
Projektujemy system na 80 mln abonentów z zapasem na miliard.. Tak rozpinamy przyszłe progi. To nie dlatego, że zamierzamy podbić Chiny, ale z powodu naporu IoT i M2M.
300 mln dokumentów przetwarzanych w czasie rzeczywistym.. Chociaż mamy 80 mln abonentów, pracujemy również z potencjalnymi klientami oraz z tymi, którzy odeszli, jeśli trzeba odzyskać należności. Dlatego rzeczywiste wolumeny są znacznie wyższe.
2 mld transakcji codziennie zmieniają saldo - to płatności, naliczenia, połączenia i inne zdarzenia. 200 Tb danych zmienia się aktywnie,nieco wolniej zmieniają się 8 Pb danych., a to nie jest archiwum, a żywe dane w jednym bilingu. Skala po DC – 5 tysięcy serwerów na 14 lokalizacjach.
Stos technologiczny
Kiedy zaplanowaliśmy architekturę i zabraliśmy się do budowy systemu, zaimportowaliśmy najciekawsze i najnowocześniejsze technologie. Powstał stos technologiczny, znany każdemu graczowi internetu oraz korporacjom, które tworzą systemy o wysokim obciążeniu.
Stos jest analogiczny do stosów innych dużych graczy: Netflix, Twitter, Viber. Składa się z 6 komponentów, ale chcemy go uprościć i zunifikować.
Elastyczność to dobrze, ale w dużej korporacji bez unifikacji nie da się działać.
Nie zamierzamy wymieniać Oracle na Tarantool. W realiach dużych firm to utopia, czy krucjata trwająca 5-10 lat z niepewnym wynikiem. Ale Cassandrę i Couchbase można całkiem dobrze zastąpić Tarantool, i do tego dążymy.
Dlaczego Tarantool?
Są 4 proste kryteria, dlaczego wybraliśmy tę bazę danych.
Szybkość. Przeprowadziliśmy testy obciążeniowe na przemysłowych systemach MegaFon. Tarantool wygrał – pokazał najlepszą wydajność.
Nie można powiedzieć, że inne systemy nie zaspokajają potrzeb MegaFon. Aktualne rozwiązania pamięciowe są tak wydajne, że zapas wystarcza firmie w zupełności. Ale interesuje nas współpraca z liderem, a nie z tym, kto pozostaje w tyle, w tym również z testów obciążeniowych.
Tarantool zaspokaja potrzeby firmy nawet w długoterminowej perspektywie.
Koszt TCO. Wsparcie Couchbase przy wolumenach MegaFon kosztuje kosmiczne pieniądze, z Tarantool sytuacja jest znacznie przyjemniejsza, a pod względem funkcjonalności są bliskie.
Jeszcze jedna miła cecha, która nieco wpłynęła na nasz wybór – Tarantool lepiej niż inne bazy pracuje z pamięcią. Pokazuje maksymalną efektywność.
Niezawodność. MegaFon inwestuje w niezawodność, chyba jak nikt inny. Dlatego, gdy spojrzeliśmy na Tarantool, zrozumieliśmy, że musimy zrobić wszystko, aby spełniał nasze wymagania.
Zainwestowaliśmy swój czas i finanse, i razem z Mail.ru stworzyliśmy wersję enterprise, która jest już używana przez kilka innych firm.
Tarantool-enterprise w pełni zaspokoił nasze potrzeby w zakresie bezpieczeństwa, niezawodności i logowania.
Partnerstwo
Najważniejsze dla mnie – bezpośredni kontakt z deweloperem. To jest właśnie to, czym zespół Tarantool nas ujął.
Kiedy przychodzisz do gracza, szczególnie tego, który pracuje z klientem kluczowym, i mówisz, że potrzebujesz, aby baza danych potrafiła to, to i tamto, zazwyczaj odpowiada:
— Dobrze, włóż wymagania na dół tej sterty — może kiedyś do nich dotrzemy.
Wielu ma plan działania na najbliższe 2-3 lata, i wkomponowanie się w to jest praktycznie niemożliwe, a programiści Tarantool przyciągają otwartością, nie tylko z MegaFonem, i adaptują swój system pod klienta. To świetne i bardzo nam się podoba.
Gdzie zastosowaliśmy Tarantool
Tarantool jest u nas wykorzystywany w kilku elementach. Pierwsze — w pilocie, który zrealizowaliśmy w systemie katalogu adresowego. W swoim czasie chciałem, aby to był system przypominający Yandex.Maps i Google Maps, ale wyszło to nieco inaczej.
Na przykład katalog adresowy w interfejsie sprzedaży. W Oracle wyszukiwanie potrzebnego adresu zajmuje 12-13 s — nieprzyjemne liczby. Kiedy przełączamy się na Tarantool, zastępujemy Oracle inną bazą danych w konsoli i wykonujemy te same wyszukiwania, uzyskujemy przyspieszenie 200 razy! Miasto pojawia się po trzeciej literze. Teraz dostosowujemy interfejs, aby to następowało po pierwszej. Niemniej jednak, czas reakcji jest całkowicie inny — to już milisekundy zamiast sekund.
Drugie zastosowanie — modny temat, który nazywa się IT o dwóch prędkościach. Wszystko dlatego, że konsultanci z każdego kąta mówią, że korporacje powinny iść w tym kierunku.
Tutaj jest warstwa infrastruktury, nad nią domeny, na przykład system billingowy, jak u telekomów, systemy korporacyjne, raportowanie korporacyjne. To jest rdzeń, którego nie należy ruszać. Oczywiście można, ale paranoicznie zapewniając jakość, ponieważ to przynosi pieniądze korporacji.
Dalej jest warstwa mikroserwisów — to, co różnicuje operatora lub innego gracza. Mikroserwisy można szybko tworzyć na podstawie pewnych pamięci podręcznych, pobierając dane z różnych domen. Tutaj jest pole do eksperymentów — jeśli coś nie wyszło, zamykasz jeden mikroserwis, otwierasz inny. To naprawdę zapewnia zwiększony time-to-market oraz zwiększa niezawodność i szybkość firmy.
Mikroserwisy to chyba główna rola Tarantool w MegaFon.
Gdzie planujemy zastosować Tarantool
Porównując nasz udany projekt systemu billingowego z programami transformacyjnymi w Deutsche Telekom, Svyaznoy i Vodafone India, jest on zadziwiająco dynamiczny i kreatywny. W trakcie realizacji tego projektu nie tylko MTS i jego struktura uległy transformacji, ale również pojawił się Tarantool-enterprise w Mail.ru, a nasz dostawca Nexign (wcześniej 'Peterservice') — BSS Box (gotowe rozwiązanie billingowe).
To w pewnym sensie historyczny projekt dla rosyjskiego rynku. Można go porównać do tego, co opisano w książce Fredericka Brooksa „Mityczny człowiek-miesiąc”. Wówczas, w latach 60-tych, do opracowania nowego systemu operacyjnego OS/360 dla mainframe'ów IBM zaangażowano 5000 osób. My mamy mniej— 1800, ale z naszymi w pasiakach, biorąc pod uwagę użycie open source i nowe podejścia, pracujemy efektywniej.
Poniżej przedstawione są domeny billingowe, lub szerzej — systemy biznesowe. Ludzie z enterprise doskonale znają CRM. Inne systemy powinny być już u wszystkich: Open API, API Gateway.
Open API
Przyjrzyjmy się jeszcze raz liczbom i temu, jak obecnie działa Open API. Jego obciążenie to 10 000 transakcji na sekundę. Ponieważ planujemy aktywnie rozwijać warstwę mikroserwisów i budować publiczne API MTS, spodziewamy się większego wzrostu w przyszłości właśnie w tej części. 100 000 transakcji z pewnością będzie.
Nie wiem, czy dorównamy w SSO Mail.ru — oni mają podobno 1 000 0000 transakcji na sekundę. Ich rozwiązanie jest dla nas niezwykle interesujące i planujemy przejąć ich doświadczenia — na przykład tworząc funkcjonalny rezerwowy SSO z pomocą Tarantool. Obecnie programiści z Mail.ru zajmują się tym u nas.
CRM
CRM to ci sami 80 mln abonentów, których chcemy doprowadzić do miliarda, ponieważ już jest 300 mln dokumentów, które obejmują trzyletnią historię. Rzeczywiście czekamy na nowe usługi, a tutaj punktem wzrostu są usługi podłączone. To sfera, która będzie rosła, ponieważ będzie coraz więcej usług. W związku z tym potrzebna będzie historia, nie chcemy na tym potknąć.
Sam billing w zakresie wystawiania faktur, pracy z zadłużeniem klientów przekształcił się w oddzielną domenę. Aby poprawić wydajność, zastosowano architektoniczny wzorzec architektury domenowej..
System jest podzielona na domeny, obciążenie jest rozłożone, a niezawodność zapewniona. Dodatkowo przeprowadzono prace nad architekturą rozproszoną.
Wszystko inne to rozwiązania klasy enterprise. W magazynie połączeń – 2 miliardy dziennie, 60 miliardów miesięcznie. Czasami trzeba je przeliczyć za miesiąc, więc lepiej szybko. Monitorowanie finansowe to te 300 milionów, które stale rosną: abonenci często przechodzą między operatorami, zwiększając tę część.
Najbardziej telekomunikacyjnym składnikiem z mobilnej komunikacji jest online'owe naliczanie opłat. To są systemy, które pozwalają na wykonywanie lub nie wykonywanie połączeń, podejmują decyzje w czasie rzeczywistym. Tutaj obciążenie wynosi 30 000 transakcji na sekundę, ale biorąc pod uwagę wzrost transferu danych, planujemy 250 000 transakcji, dlatego bardzo interesujemy się Tarantool.
Poprzedni obrazek to te domeny, gdzie planujemy zastosować Tarantool. Sam CRM, oczywiście, jest szerszy i zamierzamy go zastosować w samym jądrze.
Moja obliczeniowa liczba TTH w wysokości 100 milionów abonentów niepokoi mnie jako architekta – a co jeśli 101 milionów? Znowu wszystko na nowo? Aby tego uniknąć, stosujemy cache, jednocześnie zwiększając dostępność.
Ogólnie rzecz biorąc, istnieją dwa podejścia do zastosowania Tarantool. Pierwsze to budowanie wszystkich cache'y na poziomie mikrousług.Z tego, co rozumiem, tym szlakiem idzie VympelCom, tworząc cache klientów.
My jesteśmy mniej zależni od dostawców, zmieniamy rdzeń BSS, dlatego mamy wspólną kartotekę klientów już z pudełka. Ale chcemy ją rozszerzyć. Dlatego stosujemy nieco inne podejście – robimy cache wewnątrz systemów.
W ten sposób jest mniej desynchronizacji – jeden system odpowiada zarówno za cache, jak i za główne źródło danych.
Metoda ta dobrze współpracuje z podejściem Tarantool z transakcyjną strukturą, gdy aktualizowane są tylko części związane z aktualizacjami, czyli zmiany danych. Wszystko inne można przechowywać gdzie indziej. Nie ma ogromnego data lake, niezarządzanego globalnego cache'a. Cache'y projektowane są pod system, produkt lub klientów, aby ułatwić życie w zakresie serwisowania. Gdy dzwoni klient niezadowolony z jakości, chcemy go solidnie obsłużyć.
RTO i RPO
W IT istnieją dwa pojęcia – RTO i RPO.
Recovery time objective — to czas przywracania usługi po awarii. RTO = 0 oznacza, że nawet jeśli coś padnie, usługa nadal działa.
cel punktu przywracania — to czas przywracania danych, ile danych możemy stracić w pewnym okresie. RPO = 0 oznacza, że nie tracimy danych.
Zadanie dla Tarantool
Spróbujmy rozwiązać zadanie dla Tarantool.
Dane: powszechnie rozumiany koszyk zamówień, na przykład w Amazonie lub gdzie indziej. Wymagane jest, aby koszyk działał 24 godziny na dobę, 7 dni w tygodniu, czyli 99,99% czasu. Zamówienia, które do nas przychodzą, muszą zachować porządek, ponieważ nie możemy chaotycznie włączać lub wyłączać klienta — wszystko musi być ściśle uporządkowane. Poprzednia subskrypcja wpływa na następną, dlatego dane są ważne — nic nie może zginąć.
Rozwiązanie. Można spróbować rozwiązać to na sucho i zapytać programistów Bazy Danych, ale zadanie matematycznie nie jest rozwiązane. Można przypominać sobie twierdzenia, prawa zachowania, fizykę kwantową, ale po co — nie da się tego rozwiązać na poziomie bazy danych.
Tutaj działa stary, dobry podejście architektoniczne — trzeba dobrze znać obszar tematyczny i dzięki niemu rozwiązać tę zagadkę.
Nasze rozwiązanie: tworzymy rozproszony rejestr zamówień w Tarantool — geograficznie rozproszony klaster. Na schemacie to trzy różne centra przetwarzania danych — dwa przed Uralem, jeden za Uralem, i rozdzielamy wszystkie zamówienia po tych centrach.
Netflix, który teraz uważany jest za jednego z liderów w IT, do 2012 roku miał tylko jedno centrum danych. W wigilię katolickiego Bożego Narodzenia, 24 grudnia, to centrum się zawaliło. Użytkownicy w Kanadzie i USA zostali bez swoich ulubionych filmów, byli bardzo zrozpaczeni i napisali o tym w mediach społecznościowych. Teraz Netflix ma trzy centra danych na zachodnim i wschodnim wybrzeżu oraz jedno w zachodniej Europie.
Od samego początku budujemy geograficznie rozproszone rozwiązanie — ważna jest dla nas odporność na awarie.
Tak więc mamy klaster, ale jak być z RPO = 0 i RTO = 0? Rozwiązanie jest proste, zależne od tematyki.
Co jest ważne w zamówieniach? Dwie części: roboczy koszyk PRZED podjęciem decyzji o zakupie, i PO. Część PRZED w telekomunikacji zwykle nazywa się przechwytywaniem zamówień lub negocjacją zamówienia. W telekomunikacji może to być znacznie bardziej skomplikowane niż w sklepie internetowym, ponieważ tam trzeba obsłużyć klienta, zaproponować 5 opcji, a cały ten proces trwa jakiś czas, ale koszyk się zapełnia. W tym momencie może wystąpić awaria, ale to nie jest straszne, ponieważ dzieje się to w trybie interaktywnym pod nadzorem człowieka.
Jeśli moskiewskie centrum danych nagle się zepsuje, przełączając się automatycznie na inne centrum danych, będziemy kontynuować pracę. Teoretycznie może zniknąć jeden produkt w koszyku, ale to widać, można ponownie uzupełnić koszyk i kontynuować pracę. W tym przypadku RTO = 0.
W tym samym momencie istnieje druga opcja: gdy naciśniemy „submit”, chcemy, aby dane się nie zgubiły. Od tego momentu zaczyna działać automatyka — to już RPO = 0. Zastosowanie tych dwóch różnych wzorców w jednym przypadku może być po prostu geograficznie rozproszony klaster z jednym przełączanym masterem, a w innym przypadku jakaś kworumowa rejestracja. Wzorce mogą się różnić, ale my rozwiązujemy problem.
Dalej, mając rozproszony rejestr zgłoszeń, możemy to wszystko jeszcze skalować — mieć wielu dyspozytorów i wykonawców, którzy odwołują się do tego rejestru.
Cassandra i Tarantool razem
Jest jeszcze jeden przypadek — „witryna bilansów”. Tutaj mamy interesujący przypadek wspólnego zastosowania Cassandry i Tarantoola.
Stosujemy Cassandrę, ponieważ 2 miliardy połączeń dziennie to nie limit, a ich liczba będzie rosła. Marketerzy uwielbiają tworzyć zróżnicowaną analizę ruchu według źródeł, a szczegóły dotyczące mediów społecznościowych stają się coraz bardziej złożone. To wszystko zwiększa historię.
Cassandra pozwala na poziome skalowanie do dowolnych rozmiarów.
Czujemy się komfortowo z Cassandrą, ale ma ona jeden problem — nie nadaje się do odczytu. Z zapisem wszystko jest w porządku, 30 000 na sekundę nie stanowi problemu — problem tkwi w odczycie.
Dlatego pojawił się temat z pamięcią podręczną i przy okazji postanowiliśmy rozwiązać kolejny problem: istnieje stary, tradycyjny przypadek, w którym sprzęt od przełącznika online do rozrachunku przesyła pliki, które ładujemy do Cassandry. Zmagaliśmy się z problemem niezawodnego ładowania tych plików, nawet zastosowaliśmy na radę menedżera IBM transfer plików – istnieją takie rozwiązania, które efektywnie zarządzają przekazywaniem plików za pomocą protokołu UDP, na przykład, a nie TCP. To działa dobrze, ale nadal to trwa kilka minut, i dopóki tego nie załadujemy, operator w centrum kontaktowym nie może odpowiedzieć klientowi, co się stało z jego saldem – trzeba czekać.
Aby do tego nie doszło, stosujemy równoległy funkcjonalny zapas. Kiedy wysyłamy zdarzenie przez Kafkę do Tarantoola, przeliczając agregaty w czasie rzeczywistym, na przykład za dzisiaj, otrzymujemy pamięć podręczną sald, która może zwracać salda z dowolną prędkością, na przykład 100 tysięcy transakcji na sekundę oraz te same 2 sekundy.
Celem jest to, aby po wykonaniu połączenia już po 2 sekundach w panelu osobistym nie tylko było zmienione saldo, ale również informacje o tym, dlaczego ono się zmieniło.
Podsumowanie
To były przykłady zastosowania Tarantoola. Bardzo podobała nam się otwartość Mail.ru, ich gotowość do rozważania różnych przypadków.
Doradcom z BCG czy McKinsey, Accenture lub IBM już trudno nas czymś nowym zaskoczyć – wiele z tego, co oferują, już robimy, zrobiliśmy lub planujemy zrobić. Myślę, że Tarantool zajmie godne miejsce w naszym stosie technologicznym i zastąpi wiele już istniejących technologii. Jesteśmy w aktywnej fazie rozwoju tego projektu.
Wykład Olega i Andrieja był jednym z najlepszych na konferencji Tarantool w zeszłym roku, a już 17 czerwca Oleg Iwlew wystąpi na z wykładem . Również od MTS wystąpi Aleksander Deulin z wykładem . Dowiemy się, co się zmieniło, jakie plany udało się zrealizować. Dołączcie – konferencja jest darmowa, wystarczy tylko . Wszystkie i program konferencji został sformułowany: nowe przypadki, nowe doświadczenia z Tarantool, architektura, enterprise, tutoriale i mikrousługi.
Źródło: habr.com
