Architektúra fakturácie novej generácie: transformácia s prechodom na Tarantool

Prečo spoločnosť ako MegaFon potrebuje pri fakturácii Tarantol? Zvonku sa zdá, že predajca zvyčajne príde, prinesie nejakú veľkú krabicu, zapojí zástrčku do zásuvky - a to je účtovanie! Kedysi to tak bolo, no dnes je to už archaické a takéto dinosaury už vyhynuli alebo vymierajú. Účtovanie je spočiatku systém na vystavovanie faktúr - počítadlo alebo kalkulačka. V moderných telekomunikáciách to tak je automatizačný systém počas celého životného cyklu interakcie s účastníkom od uzavretia zmluvy až po jej ukončenievrátane fakturácie v reálnom čase, prijímania platieb a oveľa viac. Účtovanie v telekomunikačných spoločnostiach je ako bojový robot – veľký, výkonný a nabitý zbraňami.

Architektúra fakturácie novej generácie: transformácia s prechodom na Tarantool

Čo s tým má spoločné Tarantool? Budú o tom hovoriť Oleg Ivlev и Andrej Knyazev. Oleg je hlavným architektom spoločnosti Megafón s rozsiahlymi skúsenosťami s prácou v zahraničných spoločnostiach je Andrey riaditeľom obchodných systémov. Z prepisu ich správy o Konferencia Tarantol 2018 dozviete sa, prečo je v korporáciách potrebný výskum a vývoj, čo je Tarantool, ako sa slepá ulička vertikálneho škálovania a globalizácie stali predpokladmi pre vznik tejto databázy v spoločnosti, o technologických výzvach, architektonickej transformácii a ako je technostack MegaFonu podobný Netflixu. , Google a Amazon.

Projekt "Jednotná fakturácia"

Daný projekt sa nazýva „Unified Billing“. Práve tu ukázal Tarantool svoje najlepšie kvality.

Architektúra fakturácie novej generácie: transformácia s prechodom na Tarantool

Rast produktivity Hi-End zariadení nedržal krok s rastom predplatiteľskej základne a rastom počtu služieb, očakával sa ďalší rast počtu predplatiteľov a služieb vďaka funkciám M2M, internetu vecí a pobočiek. k zhoršeniu doby uvedenia na trh. Spoločnosť sa rozhodla vytvoriť jednotný obchodný systém s unikátnou modulárnou architektúrou svetovej úrovne namiesto 8 súčasných rôznych fakturačných systémov.

MegaFon je osem spoločností v jednej. V roku 2009 bola dokončená reorganizácia: pobočky po celom Rusku sa zlúčili do jednej spoločnosti MegaFon OJSC (teraz PJSC). Spoločnosť tak disponuje 8 fakturačnými systémami s vlastnými „custom“ riešeniami, funkciami pobočiek a rôznymi organizačnými štruktúrami, IT a marketingom.

Všetko bolo v poriadku, kým sme nemuseli spustiť jeden spoločný federálny produkt. Tu vzniklo veľa ťažkostí: pre niektorých sa tarify zaokrúhľujú nahor, pre iných nadol a pre iných - na základe aritmetického priemeru. Takých momentov sú tisíce.

Napriek tomu, že existovala len jedna verzia fakturačného systému, jeden dodávateľ, nastavenia sa natoľko rozchádzali, že ich skladanie trvalo dlho. Snažili sme sa znížiť ich počet a narazili sme na druhý problém, ktorý poznajú mnohé korporácie.

Vertikálne škálovanie. Dokonca ani ten najlepší hardvér v tom čase nespĺňal potreby. Použili sme zariadenia Hewlett-Packard z radu Superdome Hi-End, ktoré však nevyhovovali potrebám ani dvoch pobočiek. Chcel som horizontálne škálovanie bez veľkých prevádzkových nákladov a kapitálových investícií.

Očakávanie rastu počtu predplatiteľov a služieb. Konzultanti už dlho prinášajú príbehy o internete vecí a M2M do sveta telekomunikácií: príde čas, keď každý telefón a žehlička budú mať SIM kartu a dve v chladničke. Dnes máme rovnaký počet predplatiteľov, no v blízkej budúcnosti ich bude oveľa viac.

Technologické výzvy

Tieto štyri dôvody nás motivovali k vážnym zmenám. Bolo na výber medzi aktualizáciou systému a navrhovaním od začiatku. Dlho sme rozmýšľali, robili vážne rozhodnutia, hrali tendre. V dôsledku toho sme sa rozhodli navrhovať od samého začiatku a podujali sme sa na zaujímavé výzvy – technologické výzvy.

Škálovateľnosť

Ak to bolo predtým, povedzme, povedzme 8 faktúr pre 15 miliónov predplatiteľov, a teraz by to malo fungovať 100 miliónov predplatiteľov a viac - zaťaženie je rádovo vyššie.

V rozsahu sme sa stali porovnateľnými s veľkými internetovými hráčmi ako Mail.ru alebo Netflix.

Ale ďalší pohyb smerom k zvyšovaniu zaťaženia a predplatiteľskej základne pre nás postavil vážne výzvy.

Geografia našej obrovskej krajiny

Medzi Kaliningradom a Vladivostokom 7500 km a 10 časových pásiem. Rýchlosť svetla je konečná a pri takýchto vzdialenostiach sú už oneskorenia značné. 150 ms na najlepších moderných optických kanáloch je príliš veľa na fakturáciu v reálnom čase, najmä ak je to teraz v telekomunikáciách v Rusku. Navyše potrebujete aktualizovať za jeden pracovný deň a pri rôznych časových pásmach je to problém.

Neposkytujeme len služby za predplatné, máme komplexné tarify, balíčky a rôzne modifikátory. Musíme účastníkovi nielen povoliť alebo odmietnuť hovoriť, ale dať mu určitú kvótu - počítať hovory a akcie v reálnom čase, aby si to nevšimol.

odolnosť proti chybám

Toto je druhá strana centralizácie.

Ak zhromažďujeme všetkých predplatiteľov v jednom systéme, akékoľvek mimoriadne udalosti a katastrofy sú pre podnikanie katastrofálne. Systém preto navrhujeme tak, aby sme eliminovali dopad havárií na celú účastnícku základňu.

Je to opäť dôsledok odmietnutia vertikálnej mierky. Keď sme horizontálne škálovali, zvýšili sme počet serverov zo stoviek na tisíce. Musia byť spravované a zameniteľné, automaticky zálohovať IT infraštruktúru a obnoviť distribuovaný systém.

Čelili sme takým zaujímavým výzvam. Navrhli sme systém a v tom momente sme sa snažili nájsť globálne osvedčené postupy, aby sme si overili, ako sme v trende, nakoľko sledujeme pokročilé technológie.

Svetová skúsenosť

V globálnom telekome sme prekvapivo nenašli ani jednu referenciu.

Európa klesla z hľadiska počtu predplatiteľov a rozsahu, USA z hľadiska plochosti svojich taríf. Pozreli sme sa na niektoré v Číne a niektoré sme našli v Indii a najali sme špecialistov z Vodafone India.

Na analýzu architektúry sme zostavili Dream Team pod vedením IBM – architektov z rôznych oblastí. Títo ľudia mohli adekvátne posúdiť, čo robíme a priniesť určité poznatky do našej architektúry.

mierka

Pár čísel na ilustráciu.

Navrhujeme systém pre 80 miliónov predplatiteľov s rezervou jednej miliardy. Takto odstránime budúce prahové hodnoty. Nie je to preto, že sa chystáme ovládnuť Čínu, ale kvôli náporu internetu vecí a M2M.

300 miliónov dokumentov spracovaných v reálnom čase. Hoci máme 80 miliónov predplatiteľov, v prípade potreby vymáhania pohľadávok spolupracujeme s potenciálnymi klientmi aj s tými, ktorí od nás odišli. Preto sú skutočné objemy výrazne väčšie.

2 miliardy transakcií Zostatok sa mení denne – ide o platby, poplatky, hovory a iné udalosti. 200 TB dát sa aktívne mení, meniť trochu pomalšie 8 PB údajov, pričom nejde o archív, ale o živé dáta v rámci jednej fakturácie. Mierka podľa dátového centra - 5 tisíc serverov na 14 lokalitách.

Technologický zásobník

Keď sme plánovali architektúru a začali montovať systém, doviezli sme najzaujímavejšie a najpokročilejšie technológie. Výsledkom je technologický balík, ktorý pozná každý internetový hráč a korporácie, ktoré vyrábajú systémy s vysokou záťažou.

Architektúra fakturácie novej generácie: transformácia s prechodom na Tarantool

Zásobník je podobný zásobníkom iných veľkých hráčov: Netflix, Twitter, Viber. Skladá sa zo 6 komponentov, no chceme ho skrátiť a zjednotiť.

Flexibilita je dobrá, ale vo veľkej korporácii to bez unifikácie nejde.

Nechystáme sa zmeniť ten istý Oracle na Tarantool. V realite veľkých spoločností je to utópia, alebo krížová výprava na 5-10 rokov s nejasným výsledkom. Ale Cassandra a Couchbase môžu byť ľahko nahradené Tarantoolom, a to je to, o čo sa snažíme.

Prečo Tarantool?

Existujú 4 jednoduché kritériá, prečo sme si vybrali túto databázu.

Rýchlosť. Vykonali sme záťažové testy na priemyselných systémoch MegaFon. Vyhral Tarantool – predviedol najlepší výkon.

To neznamená, že iné systémy nespĺňajú potreby MegaFonu. Súčasné pamäťové riešenia sú také produktívne, že rezervy spoločnosti sú viac než dostatočné. Máme však záujem jednať s lídrom, a nie s niekým, kto zaostáva, a to aj v záťažovom teste.

Tarantool pokrýva potreby spoločnosti aj dlhodobo.

TCO náklady. Podpora Couchbase na objemoch MegaFon stojí astronomické peniaze, no s Tarantoolom je situácia oveľa príjemnejšia a funkčnosťou sú si podobné.

Ďalšou príjemnou vlastnosťou, ktorá mierne ovplyvnila náš výber, je, že Tarantool lepšie pracuje s pamäťou ako iné databázy. On ukazuje maximálna účinnosť.

Spoľahlivosť. MegaFon investuje do spoľahlivosti, pravdepodobne viac ako ktokoľvek iný. Keď sme sa teda pozreli na Tarantool, uvedomili sme si, že ho musíme prispôsobiť našim požiadavkám.

Investovali sme svoj čas a financie a spolu s Mail.ru sme vytvorili podnikovú verziu, ktorá sa dnes používa v niekoľkých ďalších spoločnostiach.

Tarantool-enterprise nás úplne uspokojil z hľadiska bezpečnosti, spoľahlivosti a logovania.

partnerstva

Najdôležitejšia vec pre mňa je priamy kontakt s developerom. Presne týmto podplácali chalani z Tarantool.

Ak prídete za hráčom, najmä za tým, ktorý pracuje s kotviacim klientom, a poviete, že potrebujete databázu, aby ste mohli urobiť toto, toto a toto, zvyčajne odpovie:

- Dobre, dajte požiadavky na spodok tej kôpky - jedného dňa sa k nim pravdepodobne dostaneme.

Mnohí majú cestovnú mapu na najbližšie 2-3 roky a integrovať sa tam je takmer nemožné, no vývojári z Tarantolu uchvacujú svojou otvorenosťou a to nielen od MegaFonu a prispôsobujú svoj systém zákazníkovi. Je to super a veľmi sa nám to páči.

Kde sme použili Tarantool

Tarantool používame vo viacerých prvkoch. Prvý je v pilotnej verzii, ktorý sme vytvorili v systéme adresárov adries. Svojho času som chcel, aby to bol systém podobný Yandex.Maps a Google Maps, no dopadlo to trochu inak.

Napríklad katalóg adries v predajnom rozhraní. V systéme Oracle trvá hľadanie požadovanej adresy 12-13 sekúnd. - nepohodlné čísla. Keď prejdeme na Tarantool, nahradíme Oracle inou databázou v konzole a vykonáme rovnaké vyhľadávanie, dosiahneme 200-násobné zrýchlenie! Mesto sa objaví po treťom písmene. Teraz prispôsobujeme rozhranie tak, aby sa to stalo po prvom. Rýchlosť odozvy je však úplne iná – milisekundy namiesto sekúnd.

Druhou aplikáciou je trendová téma s názvom dvojrýchlostné IT. Konzultanti z každého kúta totiž hovoria, že korporácie by tam mali ísť.

Architektúra fakturácie novej generácie: transformácia s prechodom na Tarantool

Existuje vrstva infraštruktúry, nad ňou sú domény, napríklad fakturačný systém ako telekomunikácie, podnikové systémy, podnikový reporting. Toto je jadro, ktorého sa netreba dotýkať. To je, samozrejme, možné, ale paranoidne zabezpečenie kvality, pretože to prináša peniaze do korporácie.

Nasleduje vrstva mikroslužieb – to, čo odlišuje operátora alebo iného hráča. Mikroslužby môžu byť rýchlo vytvorené na základe určitých vyrovnávacích pamätí a prinášajú tam údaje z rôznych domén. Tu pole pre experimenty — ak niečo nefungovalo, zavrel som jednu mikroslužbu a otvoril ďalšiu. To poskytuje skutočne dlhší čas uvedenia na trh a zvyšuje spoľahlivosť a rýchlosť spoločnosti.

Mikroslužby sú možno hlavnou úlohou Tarantoolu v MegaFone.

Kde plánujeme použiť Tarantool

Ak porovnáme náš úspešný projekt fakturácie s transformačnými programami v Deutsche Telekom, Svyazcom, Vodafone India, je prekvapivo dynamický a kreatívny. V procese implementácie tohto projektu sa transformoval nielen MegaFon a jeho štruktúra, ale na Mail.ru sa objavil aj Tarantool-enterprise a náš predajca Nexign (predtým Peter-Service) - BSS Box (boxové fakturačné riešenie).

Ide v istom zmysle o historický projekt pre ruský trh. Dá sa to prirovnať k tomu, čo je opísané v knihe „The Mythical Man-Month“ od Fredericka Brooksa. Potom, v 60. rokoch, IBM najalo 360 5 ľudí na vývoj nového operačného systému OS/000 pre sálové počítače. Máme menej – 1 800, ale naši sú vo vestách a s prihliadnutím na využitie open source a nových prístupov pracujeme produktívnejšie.

Nižšie sú uvedené domény fakturačných alebo, všeobecnejšie povedané, obchodných systémov. Ľudia z podnikov veľmi dobre poznajú CRM. Každý by už mal mať iné systémy: Open API, API Gateway.

Architektúra fakturácie novej generácie: transformácia s prechodom na Tarantool

Otvorte rozhranie API

Pozrime sa opäť na čísla a na to, ako momentálne funguje Open API. Jeho zaťaženie je 10 000 transakcií za sekundu. Keďže plánujeme aktívne rozvíjať vrstvu mikroslužieb a budovať verejné API MegaFon, v tejto časti očakávame v budúcnosti väčší rast. Určite bude 100 000 transakcií.

Neviem, či môžeme porovnávať s Mail.ru v SSO - zdá sa, že chlapci majú 1 000 0000 transakcií za sekundu. Ich riešenie je pre nás mimoriadne zaujímavé a plánujeme si osvojiť ich skúsenosti – napríklad vytvorenie funkčnej SSO zálohy pomocou Tarantool. Teraz to za nás robia vývojári z Mail.ru.

CRM

CRM je rovnakých 80 miliónov predplatiteľov, ktorých chceme zvýšiť na miliardu, pretože už existuje 300 miliónov dokumentov, ktoré zahŕňajú trojročnú históriu. Veľmi sa tešíme na nové služby a tu bod rastu sú pripojené služby. Toto je ples, ktorý bude rásť, pretože služieb bude stále viac. Preto budeme potrebovať príbeh; nechceme o to naraziť.

Samotnú fakturáciu v rámci vystavovania faktúr, prácu s pohľadávkami odberateľov transformované na samostatnú doménu. Ak chcete zlepšiť výkon, architektonický vzor aplikovanej architektúry domény.

Systém je rozdelený na domény, rozložená záťaž a zabezpečená odolnosť voči poruchám. Okrem toho sme pracovali s distribuovanou architektúrou.

Všetko ostatné sú riešenia na podnikovej úrovni. V úložisku hovorov - 2 miliardy za deň, 60 miliárd mesačne. Niekedy ich musíte spočítať za mesiac a je to lepšie. Finančný monitoring - to je presne tých istých 300 miliónov, ktoré neustále rastú a rastú: predplatitelia často bežia medzi operátormi, čím sa táto časť zvyšuje.

Najviac telekomunikačným komponentom mobilnej komunikácie je online fakturácia. Sú to systémy, ktoré umožňujú volať alebo nevolať, rozhodovať sa v reálnom čase. Tu je zaťaženie 30 000 transakcií za sekundu, ale s prihliadnutím na rast prenosu dát plánujeme 250 000 transakcií, a preto nás Tarantool veľmi zaujíma.

Predchádzajúci obrázok sú domény, kde budeme používať Tarantool. Samotné CRM je, samozrejme, širšie a budeme ho používať v samotnom jadre.

Naša odhadovaná hodnota TTX 100 miliónov predplatiteľov ma ako architekta mätie – čo ak 101 miliónov? Musíte všetko prerobiť znova? Aby sa to nestalo, používame vyrovnávacie pamäte a zároveň zvyšujeme dostupnosť.

Architektúra fakturácie novej generácie: transformácia s prechodom na Tarantool

Vo všeobecnosti existujú dva prístupy k používaniu Tarantoolu. Najprv - vytvoriť všetky vyrovnávacie pamäte na úrovni mikroslužieb. Pokiaľ som pochopil, VimpelCom sleduje túto cestu a vytvára vyrovnávaciu pamäť klientov.

Sme menej závislí od dodávateľov, meníme jadro BSS, takže máme po vybalení jeden súbor klienta. Chceme to však rozširovať. Preto zvolíme trochu iný prístup - vytvárať vyrovnávacie pamäte vo vnútri systémov.

Týmto spôsobom je menšia synchronizácia - jeden systém je zodpovedný za vyrovnávaciu pamäť aj za hlavný hlavný zdroj.

Metóda dobre zapadá do prístupu Tarantool s transakčnou kostrou, keď sa aktualizujú iba časti, ktoré sa týkajú aktualizácií, teda zmien údajov. Všetko ostatné môže byť uložené niekde inde. Neexistuje žiadne obrovské dátové jazero, nespravovaná globálna vyrovnávacia pamäť. Cache sú určené pre systém, alebo pre produkty, alebo pre klientov, alebo na uľahčenie údržby. Keď predplatiteľ zavolá a je naštvaný na kvalitu vašej služby, chcete mu poskytnúť kvalitné služby.

RTO a RPO

V IT existujú dva pojmy - RTO и RPO.

Cieľ doby zotavenia je čas potrebný na obnovenie služby po zlyhaní. RTO = 0 znamená, že aj keď niečo zlyhá, služba naďalej funguje.

Cieľ bodu obnovy - toto je čas obnovy dát, koľko dát môžeme stratiť za určité časové obdobie. RPO = 0 znamená, že nestrácame dáta.

Tarantool úloha

Pokúsme sa vyriešiť problém pre Tarantool.

Dané: košík aplikácií, ktorým rozumie každý, napríklad v Amazone alebo niekde inde. potrebný aby nákupný košík fungoval 24 hodín 7 dní v týždni alebo 99,99 % času. Objednávky, ktoré k nám prichádzajú, musia zostať v poriadku, pretože nemôžeme náhodne zapnúť alebo vypnúť pripojenie predplatiteľa - všetko musí byť prísne konzistentné. Predchádzajúce predplatné ovplyvňuje nasledujúce, takže údaje sú dôležité – nič by nemalo chýbať.

rozhodnutie. Môžete to skúsiť vyriešiť bezhlavo a opýtať sa vývojárov databázy, ale problém sa nedá vyriešiť matematicky. Môžete si pamätať vety, zákony zachovania, kvantovú fyziku, ale prečo - to sa nedá vyriešiť na úrovni DB.

Funguje tu starý dobrý architektonický prístup – treba dobre poznať predmetnú oblasť a použiť ju na vyriešenie tejto hádanky.

Architektúra fakturácie novej generácie: transformácia s prechodom na Tarantool

Naše riešenie: vytvorenie distribuovaného registra aplikácií na Tarantool - geograficky distribuovanom klastri. V diagrame sú to tri rôzne centrá spracovania údajov – dve pred Uralom, jedno za Uralom a medzi tieto centrá rozdeľujeme všetky požiadavky.

Netflix, ktorý je teraz považovaný za jedného z lídrov v IT, mal do roku 2012 iba jedno dátové centrum. V predvečer katolíckych Vianoc, 24. decembra, toto dátové centrum spadlo. Používatelia v Kanade a USA zostali bez svojich obľúbených filmov, boli veľmi naštvaní a písali o tom na sociálnych sieťach. Netflix má teraz tri dátové centrá na západo-východnom pobreží a jedno v západnej Európe.

Na začiatku budujeme geograficky distribuované riešenie – odolnosť voči chybám je pre nás dôležitá.

Takže máme klaster, ale čo RPO = 0 a RTO = 0? Riešenie je jednoduché, v závislosti od témy.

Čo je dôležité v aplikáciách? Dve časti: Hádzanie do koša TO rozhodovanie o kúpe a PO. Časť DO v telekomunikáciách sa zvyčajne nazýva zachytenie objednávky alebo vyjednávanie objednávky. V telekome to môže byť oveľa náročnejšie ako v internetovom obchode, pretože tam treba klienta obslúžiť, ponúknuť mu 5 možností a to všetko sa nejaký čas deje, ale košík je naplnený. V tejto chvíli je možné zlyhanie, ale nie je to desivé, pretože sa to deje interaktívne pod dohľadom človeka.

Ak moskovské dátové centrum náhle zlyhá, potom automatickým prepnutím na iné dátové centrum budeme pokračovať v práci. Teoreticky sa jeden produkt môže stratiť v košíku, ale vy ho vidíte, znova pridajte do košíka a pokračujte v práci. V tomto prípade RTO = 0.

Zároveň je tu aj druhá možnosť: keď klikneme na „odoslať“, chceme, aby sa údaje nestratili. Od tohto momentu začína fungovať automatizácia – toto je RPO = 0. Pomocou týchto dvoch rôznych vzorov by to v jednom prípade mohol byť jednoducho geograficky distribuovaný klaster s jedným prepínateľným masterom, v inom prípade nejakým záznamom kvóra. Vzory sa môžu líšiť, ale problém vyriešime.

Okrem toho, že máme distribuovaný register aplikácií, môžeme to všetko škálovať - ​​máme veľa dispečerov a vykonávateľov, ktorí majú prístup k tomuto registru.

Architektúra fakturácie novej generácie: transformácia s prechodom na Tarantool

Cassandra a Tarantool spolu

Existuje ďalší prípad - "výkladná skriňa zostatkov". Tu je zaujímavý prípad spoločného užívania Cassandry a Tarantoolu.

Používame Cassandru, pretože 2 miliardy hovorov za deň nie sú limitom a bude ich viac. Obchodníci radi prifarbujú návštevnosť podľa zdroja, čoraz viac detailov sa objavuje napríklad na sociálnych sieťach. To všetko pridáva na príbehu.

Cassandra vám umožňuje horizontálne škálovať na ľubovoľnú veľkosť.

S Cassandrou sa cítime dobre, ale má to jeden problém – nečíta dobre. Na nahrávke je všetko v poriadku, 30 000 za sekundu nie je problém - problém s čítaním.

Preto sa objavila téma s vyrovnávacou pamäťou a zároveň sme vyriešili nasledujúci problém: existuje starý tradičný prípad, keď do súborov, ktoré načítame do Cassandry, príde vybavenie z prepínača z online fakturácie. Bojovali sme s problémom spoľahlivého sťahovania týchto súborov, aj keď sme využili rady manažéra prenosu súborov IBM – existujú riešenia, ktoré efektívne spravujú prenos súborov, napríklad pomocou protokolu UDP namiesto TCP. To je dobré, ale stále sú to minúty a ešte sme to všetko nenačítali, operátor v call centre nemôže klientovi odpovedať, čo sa stalo s jeho zostatkom - musíme počkať.

Aby sme tomu zabránili, my používame paralelnú funkčnú rezervu. Keď odošleme udalosť cez Kafku do Tarantoolu, prepočítajúc agregáty v reálnom čase, napríklad pre dnešok, dostaneme hotovostné zostatky, ktorý dokáže previesť zostatky akoukoľvek rýchlosťou, napríklad 100 tisíc transakcií za sekundu a tie isté 2 sekundy.

Cieľom je, aby sa po uskutočnení hovoru do 2 sekúnd na vašom osobnom účte objavil nielen zmenený zostatok, ale aj informácie o tom, prečo sa zmenil.

Záver

Toto boli príklady použitia Tarantoolu. Veľmi sa nám páčila otvorenosť Mail.ru a ich ochota zvažovať rôzne prípady.

Pre konzultantov z BCG alebo McKinsey, Accenture alebo IBM je už teraz ťažké prekvapiť nás niečím novým – veľa z toho, čo ponúkajú, už robíme, urobili sme alebo plánujeme urobiť. Myslím si, že Tarantool zaujme svoje právoplatné miesto v našom technologickom zásobníku a nahradí mnohé existujúce technológie. Sme v aktívnej fáze vývoja tohto projektu.

Správa Olega a Andrey je jednou z najlepších na konferencii Tarantool v minulom roku a 17. júna vystúpi Oleg Ivlev o hod. Konferencia T+ 2019 s prehľadom “Prečo Tarantool v podniku”. S prezentáciou od MegaFonu vystúpi aj Alexander Deulin "Cache a replikácia Tarantool od spoločnosti Oracle". Poďme zistiť, čo sa zmenilo, aké plány sa zrealizovali. Pripojte sa - konferencia je bezplatná, stačí, ak urobíte registrovať, Všetko správy prijaté a program konferencie bol vytvorený: nové prípady, nové skúsenosti s používaním Tarantool, architektúra, podnikanie, návody a mikroslužby.

Zdroj: hab.com

Pridať komentár