Waarom het 'n korporasie soos MegaFon Tarantool nodig vir faktuur? Van buite af lyk dit asof 'n verkoper gewoonlik kom, 'n soort groot boks bring, die prop in 'n uitlaat prop - dit is rekening! Eens was dit, maar nou is dit argaïes, en sulke dinosourusse het reeds uitgesterf of sterf uit. Aanvanklik is faktuur 'n stelsel vir fakturering - 'n rympie of sakrekenaar. In vandag se telekommunikasie outomatiseringstelsel vir die hele lewensiklus van interaksie met 'n intekenaar vanaf die sluiting van 'n ooreenkoms tot beëindiging, insluitend intydse fakturering, betalingsaanvaarding en nog baie meer. Fakturering in telekommunikasiemaatskappye is soortgelyk aan 'n gevegsrobot - groot, kragtig en met wapens gehang.
En wat van Tarantool? Sal daarvan vertel Oleg Ivlev и Andrey Knyazev. Oleg is die hoofargitek van die maatskappy met uitgebreide ondervinding in buitelandse maatskappye, is Andrey die direkteur van besigheidstelsels. Uit 'n transkripsie van hul verslag oor jy sal leer hoekom R&D in korporasies benodig word, wat Tarantool is, hoe die vertikale skaal doodloopstraat en globalisering die voorvereistes geword het vir die verskyning van hierdie databasis in die maatskappy, oor tegnologiese uitdagings, argitektuurtransformasie, en hoe MegaFon technostack soortgelyk is aan Netflix , Google en Amazon.
Projek "Verenigde fakturering"
Die projek wat bespreek gaan word, word "Unified Billing" genoem. Dit was daarin dat Tarantool sy beste eienskappe getoon het.
Die prestasiegroei van Hi-End-toerusting het nie tred gehou met die groei van die intekenaarbasis en die groei in die aantal dienste nie, verdere groei in die aantal intekenare en dienste is verwag as gevolg van M2M, IoT, en takkenmerke het gelei tot 'n verswakking in tyd-tot-mark. Die maatskappy het besluit om 'n enkele besigheidstelsel te skep met 'n unieke wêreldklas modulêre argitektuur, in plaas van 8 huidige verskillende faktuurstelsels.
MegaFon is agt maatskappye in een. In 2009 is die herorganisasie voltooi: takke regoor Rusland het saamgesmelt in 'n enkele maatskappy MegaFon OJSC (nou PJSC). Die maatskappy het dus 8 faktuurstelsels met hul eie "pasgemaakte" oplossings, takkenmerke en verskillende organisasiestruktuur, IT en bemarking.
Alles was goed totdat een algemene federale produk bekendgestel moes word. Baie probleme het hier voorgekom: iemand het fakturering met afronding, iemand het 'n kleiner een en iemand het 'n rekenkundige gemiddelde. Daar is duisende sulke oomblikke.
Ten spyte van die feit dat daar net een weergawe van die faktuurstelsel is, een verskaffer, het die instellings so uiteengeloop dat dit lank neem om vas te plak. Ons het probeer om hul getal te verminder, en het op die tweede probleem afgekom, wat aan baie korporasies bekend is.
Vertikale skaal. Selfs die coolste yster op daardie tydstip het nie aan die behoeftes voldoen nie. Ons het Hewlett-Packard-toerusting, die Superdome Hi-End-lyn, gebruik, maar dit het nie eers aan die behoeftes van twee takke voldoen nie. Ek wou horisontale skaal hê sonder hoë bedryfskoste en kapitaalbeleggings.
Verwagting van groei in die aantal intekenare en dienste. Konsultante het lankal stories oor IoT en M2M na die telekommunikasiewêreld gebring: daar sal 'n tyd kom wanneer elke foon en strykyster 'n SIM-kaart sal hê, en twee in die yskas. Vandag het ons een aantal intekenare, en in die nabye toekoms sal daar 'n orde van grootte meer wees.
Tegnologiese uitdagings
Hierdie vier redes het ons tot groot veranderinge gedryf. Daar was 'n keuse tussen die opgradering van die stelsel en die ontwerp van nuuts af. Ons het lank gedink, ernstige besluite geneem, tenders gespeel. Gevolglik het ons besluit om van die begin af te ontwerp en interessante uitdagings aangepak - tegnologiese uitdagings.
Skaalbaarheid
As dit voorheen was, sê voorwaardelik, 8 fakture vir 15 miljoen intekenareen nou moet dit wees 100 miljoen intekenare en meer - die vrag is baie hoër.
Ons het in skaal vergelykbaar geword met groot internetspelers soos Mail.ru of Netflix.
Maar verdere beweging om die las te verhoog en die intekenaarbasis het ernstige take vir ons gestel.
Die geografie van ons uitgestrekte land
Tussen Kaliningrad en Vladivostok 7500 km en 10 tydsones. Die spoed van lig is eindig en op sulke afstande is die vertragings reeds aansienlik. 150 ms op die coolste moderne optiese kanale is 'n bietjie te veel vir intydse fakturering, veral soos dit nou in telekommunikasie in Rusland is. Daarbenewens moet jy in een werksdag opdateer, en met verskillende tydsones is 'n probleem.
Ons verskaf nie net dienste vir 'n maandelikse fooi nie, ons het komplekse tariewe, pakkette, verskeie wysigers. Ons hoef nie net die intekenaar toe te laat of te verbied om te praat nie, maar om hom 'n sekere kwota te gee - om oproepe en aksies intyds te bereken sodat hy dit nie agterkom nie.
fout verdraagsaamheid
Dit is die ander kant van sentralisasie.
As ons alle intekenare in een stelsel versamel, is enige noodgevalle en rampe betreurenswaardig vir besigheid. Daarom ontwerp ons die stelsel op so 'n manier dat dit die impak van ongelukke op die hele intekenaarbasis uitsluit.
Dit is weer 'n gevolg van die verwerping van vertikale skalering. Toe ons in horisontale skaal ingegaan het, het ons die aantal bedieners van honderde tot duisende verhoog. Hulle moet bestuur en uitruilbaar wees, IT-infrastruktuur outomaties rugsteun en 'n verspreide stelsel herstel.
Sulke interessante uitdagings was voor ons. Ons het die stelsel ontwerp, en op daardie oomblik het ons probeer om die wêreld se beste praktyke te vind om te kyk hoe nuwerwets ons is, hoeveel ons gevorderde tegnologieë volg.
Wêreld ervaring
Verbasend genoeg het ons nie 'n enkele verwysing in die wêreld telekommunikasie gevind nie.
Europa het verdwyn in terme van die aantal intekenare en die skaal, die Verenigde State - in terme van die platheid van sy tariewe. Hulle het na iets in China gekyk, en iets in Indië gekry en spesialiste van Vodafone Indië geneem.
Om die argitektuur te ontleed, het hulle 'n Droomspan saamgestel onder leiding van IBM - argitekte van verskillende gebiede. Hierdie mense kan voldoende assesseer wat ons doen en sekere kennis na ons argitektuur bring.
skaal
'n Paar syfers om te illustreer.
Ons ontwerp 'n stelsel vir 80 miljoen intekenare met meer as 'n miljard. Dit is hoe ons toekomstige drempels verwyder. Dit is nie omdat ons China gaan oorneem nie, maar weens die druk van IoT en M2M.
300 miljoen dokumente in reële tyd verwerk. Alhoewel ons 80 miljoen intekenare het, werk ons met beide potensiële kliënte en diegene wat ons verlaat het as dit nodig is om debiteure in te vorder. Daarom is die werklike volumes baie groter.
2 miljard transaksies die saldo verander daagliks - dit is betalings, toevallings, oproepe en ander gebeurtenisse. 200 TB se data is aktief besig om te verander, verander 'n bietjie stadiger 8 Pb data, en dit is nie 'n argief nie, maar lewendige data in 'n enkele faktuur. Skaal volgens datasentrum — 5 duisend bedieners op 14 werwe.
Tegnologie stapel
Toe ons die argitektuur beplan en onderneem het om die stelsel saam te stel, het ons die interessantste en gevorderdste tegnologieë vir onsself ingevoer. Die resultaat was 'n tegnologiese stapel wat bekend was vir enige internetspeler en korporasies wat hoëladingstelsels maak.
Die stapel is soortgelyk aan die stapels van ander groot spelers: Netflix, Twitter, Viber. Dit bestaan uit 6 komponente, maar ons wil dit verminder en verenig.
Buigsaamheid is goed, maar in 'n groot korporasie is daar geen manier sonder eenwording nie.
Ons gaan nie dieselfde Oracle vir Tarantool verander nie. In die realiteite van groot maatskappye is dit 'n utopie, of 'n kruistog vir 5-10 jaar met 'n onverstaanbare uitkoms. Maar Cassandra en Couchbase kan heeltemal deur Tarantool vervang word, en ons streef daarna.
Hoekom Tarantool?
Daar is 4 eenvoudige kriteria waarom ons hierdie databasis gekies het.
Spoed. Ons het lastoetse op MegaFon-industriële stelsels uitgevoer. Tarantool het gewen – dit het die beste prestasie getoon.
Daar kan nie gesê word dat ander stelsels nie aan die behoeftes van MegaFon voldoen nie. Huidige geheue-oplossings is so produktief dat die maatskappy se voorraad meer as genoeg is. Maar dit is vir ons interessant om met die leier te handel, en nie met die een wat agter loop nie, ook in die strestoets.
Tarantool voldoen selfs op die lang termyn aan die behoeftes van die maatskappy.
TCO koste. Couchbase-ondersteuning op MegaFon-volumes kos ruimtegeld, terwyl die situasie met Tarantool baie lekkerder is, en hulle is naby in funksionaliteit.
Nog 'n lekker kenmerk wat ons keuse effens beïnvloed het, is dat Tarantool beter met geheue werk as ander databasisse. Hy wys maksimum doeltreffendheid.
Betroubaarheid. MegaFon belê in betroubaarheid soos geen ander nie. Daarom, toe ons na Tarantool gekyk het, het ons besef dat ons moet seker maak dat dit aan ons vereistes voldoen.
Ons het ons tyd en geld belê, en saam met Mail.ru het ons 'n ondernemingsweergawe geskep, wat nou deur verskeie ander maatskappye gebruik word.
Tarantool-onderneming het ons heeltemal tevrede gestel in terme van sekuriteit, betroubaarheid en aanteken.
Vennootskap
Die belangrikste ding vir my is direkte kontak met die ontwikkelaar. Dit is presies wat die ouens van Tarantool omgekoop het.
As jy by 'n speler kom, veral een wat met 'n ankerkliënt werk, en sê dat jy die databasis nodig het om dit, dit en dat te kan doen, sal hy gewoonlik antwoord:
"Nou goed, plaas die vereistes onderaan daardie stapel - ons sal waarskynlik eendag daarby uitkom."
Baie het 'n padkaart vir die volgende 2-3 jaar, en dit is amper onmoontlik om daar in te pas, terwyl Tarantool-ontwikkelaars omkoop met openheid, en nie net met MegaFon nie, en hul stelsel aanpas by die kliënt. Dit is gaaf en ons is mal daaroor.
Waar ons Tarantool toegepas het
Ons het Tarantool wat in verskeie elemente gebruik word. Die eerste is in die loods, wat ons op die adresgidsstelsel gemaak het. Op 'n tyd wou ek hê dit moet 'n stelsel wees wat soortgelyk is aan Yandex.Maps en Google Maps, maar dit het 'n bietjie anders uitgedraai.
Byvoorbeeld, die adreskatalogus in die verkoopskoppelvlak. Op Oracle neem dit 12-13 sekondes om die regte adres te vind. - ongemaklike getalle. Wanneer ons na Tarantool oorskakel, Oracle vervang met 'n ander databasis in die konsole, en dieselfde soektog uitvoer, kry ons 'n 200x versnelling! Die stad duik na die derde brief op. Nou pas ons die koppelvlak aan sodat dit ná die eerste een gebeur. Die reaksiespoed is egter heeltemal anders – reeds millisekondes in plaas van sekondes.
Die tweede toepassing is 'n nuwerwetse tema genaamd tweespoed-IT. Dit is omdat die konsultante van elke yster sê dat korporasies daarheen moet gaan.
Hier is 'n infrastruktuurlaag, bo dit is domeine, byvoorbeeld 'n faktuurstelsel, soos 'n telekommunikasie, korporatiewe stelsels, korporatiewe verslagdoening. Dit is die kern, wat nie aangeraak moet word nie. Dit is natuurlik, dit is moontlik, maar paranoïes verseker kwaliteit, want dit bring geld na die korporasie.
Vervolgens kom die laag mikrodienste - wat die operateur of 'n ander speler onderskei. Mikrodienste kan vinnig geskep word op grond van sommige kas, wat data vanaf verskillende domeine daar insamel. Hier veld vir eksperimente - as iets nie uitgewerk het nie, maak een mikrodiens toe, maak 'n ander oop. Dit bied 'n werklik verbeterde tyd-tot-mark en verhoog die betroubaarheid en spoed van die maatskappy.
Mikrodienste is miskien die hoofrol van Tarantool in MegaFon.
Waar beplan ons om Tarantool te gebruik
As ons ons suksesvolle faktuurprojek vergelyk met die transformasieprogramme by Deutsche Telekom, Svyazcom, Vodafone India, is dit verbasend dinamies en kreatief. In die proses om hierdie projek te implementeer, is nie net MegaFon en sy struktuur getransformeer nie, maar ook Tarantool-enterprise het by Mail.ru verskyn, en ons verskaffer Nexign (voorheen Peter-Service) het BSS Box ('n boks-fakturering-oplossing) gehad.
Dit is in 'n sekere sin 'n historiese projek vir die Russiese mark. Dit kan vergelyk word met wat beskryf word in die boek van Frederick Brooks "The Mythical Man-Month". Destyds, in die 60's, het IBM 360 5 mense aangestel om die nuwe OS/000-bedryfstelsel vir die hoofraam te ontwikkel. Ons het minder - 1 800, maar ons s'n is in baadjies, en met inagneming van die gebruik van oopbron en nuwe benaderings, werk ons meer produktief.
Hieronder is die domeine van fakturering of, meer algemeen, besigheidstelsels. Ondernemingsmense ken CRM baie goed. Almal behoort reeds ander stelsels te hê: Open API, API Gateway.
Oop API
Kom ons kyk weer na die getalle en hoe die Open API nou werk. Sy vrag is 10 000 transaksies per sekonde. Aangesien ons beplan om aktief die mikrodienste-laag te ontwikkel en MegaFon se publieke API te bou, verwag ons meer groei in die toekoms in hierdie spesifieke deel. 100 000 transaksies sal beslis wees.
Ek weet nie of ons SSO met Mail.ru kan vergelyk nie - die ouens het blykbaar 1 transaksies per sekonde. Ons is uiters geïnteresseerd in hul oplossing en ons beplan om uit hul ervaring te leer - byvoorbeeld om 'n funksionele reserwe van SSO te maak deur Tarantool te gebruik. Nou doen die ontwikkelaars van Mail.ru dit saam met ons.
CRM
CRM is dieselfde 80 miljoen intekenare wat ons tot 'n miljard wil bring, want daar is reeds 300 miljoen dokumente wat 'n drie-jaar geskiedenis insluit. Ons sien baie uit na nuwe dienste, en hier groeipunt is gekoppelde dienste. Dit is 'n bal wat sal groei, want daar sal meer en meer dienste wees. Gevolglik sal geskiedenis nodig wees, ons wil nie hieroor struikel nie.
Fakturering self in terme van fakturering, werk met klante debiteure omskep in 'n aparte domein. Om prestasie te verbeter, domein argitektuur argitektoniese patroon toegepas.
Die stelsel word in domeine verdeel, die las word versprei en fouttoleransie word verskaf. Daarbenewens het ons met 'n verspreide argitektuur gewerk.
Al die ander is oplossings op ondernemingsvlak. Oproepberging - 2 miljard per dag, 60 miljard per maand. Soms moet jy hulle vir 'n maand tel, en dit is beter om vinnig. Finansiële monitering - dit is presies dieselfde 300 miljoen wat voortdurend groei en groei: intekenare loop dikwels tussen operateurs, wat hierdie deel vergroot.
Die mees telekommunikasie-komponent van mobiele kommunikasie is aanlyn faktuur. Dit is die stelsels wat jou toelaat om te bel of nie te bel nie, maak 'n besluit in reële tyd. Hier is die las 30 000 transaksies per sekonde, maar gegewe die groei in data-oordrag, beplan ons 250 000 transaksies, en daarom stel ons baie belang in Tarantool.
Die vorige prentjie is die domeine waar ons Tarantool gaan toepas. CRM self is natuurlik wyer en ons gaan dit in die kern toepas.
Ons berekende TTX-syfer van 100 miljoen intekenare verwar my as argitek – maar wat as 101 miljoen? Alles weer oordoen? Om dit te voorkom, gebruik ons kas, wat terselfdertyd beskikbaarheid verhoog.
Oor die algemeen is daar twee benaderings tot die gebruik van Tarantool. Eerstens - bou alle kas op die mikrodiensvlak. Sover ek verstaan, volg VimpelCom hierdie pad en skep 'n kliëntkas.
Ons is minder afhanklik van verskaffers, ons verander die kern van BSS, so ons het 'n enkele kaartlêer van kliënte wat reeds uit die boks is. Maar ons wil dit uitbrei. Daarom neem ons 'n effens ander benadering - maak caches binne stelsels.
Daar is dus minder desinchronisasie - een stelsel is verantwoordelik vir beide die kas en die hoofhoofbron.
Die metode pas goed by die Tarantool-benadering met 'n transaksionele skelet, wanneer slegs dele wat verband hou met opdaterings, dit wil sê dataveranderings, bygewerk word. Alles anders kan iewers anders gestoor word. Daar is geen groot datameer, onbestuurde globale kas nie. Kas is ontwerp vir die stelsel, of vir produkte, of vir kliënte, of om die lewe makliker te maak vir instandhouding. Wanneer 'n intekenaar wat ontsteld is oor die kwaliteit bel, wil ek hom met hoë gehalte bedien.
RTO en RPO
Daar is twee terme in IT − OTR и RPO.
Hersteltyddoelwit is die hersteltyd van die diens na 'n mislukking. RTO = 0 beteken dat selfs al het iets geval, die diens aanhou werk.
Herstelpuntdoelwit is die dataherwinningstyd, hoeveel data ons oor 'n tydperk kan verloor. RPO = 0 beteken dat ons nie data verloor nie.
Tarantool taak
Kom ons probeer om 'n taak vir Tarantool op te los.
Gegee: 'n duidelike mandjie van toepassings vir almal, byvoorbeeld in Amazon of iewers anders. vereis vir die inkopiemandjie om 24 uur, 7 dae per week, of 99,99% van die tyd te werk. Die bestellings wat na ons toe kom moet in orde gehou word, want ons kan nie die intekenaar se verbinding lukraak aan- of afskakel nie – alles moet streng opeenvolgend wees. Die vorige intekening beïnvloed die volgende, dus die data is belangrik – niks moet verlore gaan nie.
besluit. Jy kan dit reguit probeer oplos en die databasisontwikkelaars vra, maar die probleem kan nie wiskundig opgelos word nie. Jy kan stellings, bewaringswette, kwantumfisika herroep, maar hoekom - dit kan nie op databasisvlak opgelos word nie.
Die goeie ou argitektoniese benadering werk hier – jy moet die vakgebied goed ken en hierdie legkaart op sy koste oplos.
Ons oplossing: die skep van 'n verspreide Tarantool-kaartjieregister - 'n geo-verspreide groep. In die diagram is dit drie verskillende dataverwerkingsentrums – twee na die Oeral, een anderkant die Oeral, en ons versprei alle toepassings na hierdie sentrums.
Netflix, wat nou as een van die leiers in IT beskou word, het tot 2012 net een datasentrum gehad. Op die vooraand van Katolieke Kersfees op 24 Desember het hierdie datasentrum gaan lê. Gebruikers in Kanada en die Verenigde State is sonder hul gunsteling films gelaat, hulle was baie ontsteld en het daaroor op sosiale netwerke geskryf. Netflix het nou drie datasentrums aan die wes-ooskus en een in Wes-Europa.
Ons bou aanvanklik 'n geo-verspreide oplossing - foutverdraagsaamheid is vir ons belangrik.
So, ons het 'n groepie, maar wat van RPO = 0 en RTO = 0? Die oplossing is eenvoudig, wat afhang van die onderwerp.
Wat is belangrik in toepassings? Twee dele: gooi die mandjie OM TE 'n aankoopbesluit te neem, en NADAT. Die DO-deel in telekommunikasie word gewoonlik genoem bestelling vaslê of bestelling onderhandeling. In telekommunikasie kan dit baie moeiliker wees as in 'n aanlynwinkel, want daar moet die kliënt bedien word, 5 opsies aangebied word, en dit gebeur alles vir 'n geruime tyd, maar die mandjie is gevul. Op hierdie stadium is 'n mislukking moontlik, maar dit is nie skrikwekkend nie, want dit gebeur interaktief onder die toesig van 'n persoon.
As die Moskou-datasentrum skielik misluk, en dan outomaties oorskakel na 'n ander datasentrum, sal ons voortgaan om te werk. Teoreties kan een produk in die mandjie verlore gaan, maar jy sien dit, voeg weer by die mandjie en gaan voort om te werk. In hierdie geval RTO = 0.
Terselfdertyd is daar 'n tweede opsie: wanneer ons "submit" geklik het, wil ons hê dat die data nie verlore moet gaan nie. Van hierdie oomblik af begin outomatisering werk - dit is reeds RPO = 0. Die gebruik van hierdie twee verskillende patrone in een geval kan net 'n geo-verspreide kluster wees met een omskakelbare meester, in die ander geval, 'n soort kworumrekord. Sjablone kan verskil, maar ons los die probleem op.
Verder, met 'n verspreide register van toepassings, kan ons ook dit alles skaal - het baie versenders en eksekuteurs wat toegang tot hierdie register het.
Cassandra en Tarantool Saam
Daar is nog 'n geval - "uitstalvenster van saldo's". Hier is net 'n interessante geval van die gekombineerde gebruik van Cassandra en Tarantool.
Ons gebruik Cassandra omdat 2 miljard oproepe per dag nie die limiet is nie, en daar sal meer wees. Bemarkers hou daarvan om verkeer volgens bron in te kleur, meer en meer besonderhede verskyn byvoorbeeld op sosiale netwerke. Dit dra alles by tot die storie.
Cassandra laat jou toe om horisontaal na enige volume te skaal.
Ons voel gemaklik met Cassandra, maar sy het een probleem – sy is nie goed met lees nie. Alles is reg op rekord, 30 000 per sekonde is nie 'n probleem nie - probleem met lees.
Daarom het die probleem met die kas verskyn, en terselfdertyd het ons die volgende probleem opgelos: daar is 'n ou tradisionele geval, wanneer die toerusting van die skakelaar van aanlyn-fakturering na die lêers kom wat ons na Cassandra oplaai. Ons het gesukkel met die probleem van betroubare aflaai van hierdie lêers, selfs toegepas op advies van IBM-bestuurder lêeroordrag - daar is oplossings wat lêeroordrag doeltreffend bestuur deur byvoorbeeld die UDP-protokol en nie TCP nie. Dit is goed, maar dit is nog minute, en totdat ons dit alles oplaai, kan die operateur in die inbelsentrum nie die kliënt antwoord wat met sy balans gebeur het nie - ons moet wag.
Om te voorkom dat dit gebeur, ons parallelle funksionele reserwe toe te pas. Wanneer ons 'n gebeurtenis via Kafka na Tarantool stuur, en aggregate in reële tyd herbereken, byvoorbeeld vir vandag, kry ons kontantsaldo's, wat saldo's teen enige spoed kan gee, byvoorbeeld 100 duisend transaksies per sekonde en dieselfde 2 sekondes.
Die doel is dat daar na 'n oproep, na 2 sekondes, in jou persoonlike rekening nie net 'n veranderde saldo sal wees nie, maar inligting oor hoekom dit verander het.
Gevolgtrekking
Dit was voorbeelde van die gebruik van Tarantool. Ons het baie gehou van die openheid van Mail.ru, hul bereidwilligheid om verskillende sake te oorweeg.
Dit is reeds moeilik vir konsultante van BCG of McKinsey, Accenture of IBM om ons te verras met iets nuuts – baie van wat hulle bied, doen ons óf reeds, óf gedoen het, óf beplan om te doen. Ek dink dat Tarantool sy regmatige plek in ons tegnologiestapel sal inneem en baie bestaande tegnologieë sal vervang. Ons is in die aktiewe fase van die ontwikkeling van hierdie projek.
Die verslag van Oleg en Andrey is een van die beste by die Tarantool-konferensie verlede jaar, en op 17 Junie sal Oleg Ivlev praat by met 'n verslag . Alexander Deulin sal ook 'n aanbieding van MegaFon maak . Vind uit wat verander het, watter planne geïmplementeer is. Sluit aan - die konferensie is gratis, jy hoef net . alle en die konferensieprogram word gevorm: nuwe gevalle, nuwe ervaring van die gebruik van Tarantool, argitektuur, onderneming, tutoriale en mikrodienste.
Bron: will.com