Wêrom hat in korporaasje lykas MegaFon Tarantool nedich yn fakturearring? Fan bûten liket it derop dat de ferkeaper meastentiids komt, bringt in soarte fan grutte doaze, stekt de stekker yn 'e socket - en dat is fakturearring! Dat wie eartiids it gefal, mar no is it archaïsk, en sokke dinosaurussen binne al útstoarn of wurde útstoarn. Yn earste ynstânsje is billing in systeem foar it útjaan fan faktueren - in telmasine as rekkenmasine. Yn moderne telekommunikaasje is dit automatisearring systeem foar de heule libbenssyklus fan ynteraksje mei in abonnee fan ôfsluting fan in kontrakt oant beëiniging, ynklusyf real-time fakturearring, akseptaasje fan betelling en folle mear. Billing yn telekombedriuwen is as in fjochtsrobot - grut, krêftich en beladen mei wapens.
Wat hat Tarantool dermei te krijen? Se sille der oer prate Oleg Ivlev и Andrey Knyazev. Oleg is de haadarsjitekt fan it bedriuw mei wiidweidige ûnderfining wurkjen yn bûtenlânske bedriuwen, Andrey is direkteur fan saaklike systemen. Ut it transkripsje fan harren rapport op jo sille leare wêrom R&D nedich is yn bedriuwen, wat Tarantool is, hoe't de impasse fan fertikale skaalfergrutting en globalisearring de betingsten waard foar it ferskinen fan dizze databank yn it bedriuw, oer technologyske útdagings, arsjitektoanyske transformaasje, en hoe't MegaFon's technostack fergelykber is mei Netflix , Google en Amazon.
Projekt "Unified Billing"
It projekt yn kwestje hjit "Unified Billing". It wie hjir dat Tarantool syn bêste kwaliteiten toande.
De groei yn produktiviteit fan Hi-End-apparatuer hâlde net by mei de groei fan 'e abonneebasis en de groei yn it oantal tsjinsten; fierdere groei yn it oantal abonnees en tsjinsten waard ferwachte fanwegen M2M, IoT, en branchfunksjes liede ta in efterútgong yn time-to-market. It bedriuw besleat in unifoarm bedriuwssysteem te meitsjen mei in unike modulêre arsjitektuer fan wrâldklasse, ynstee fan 8 hjoeddeistige ferskillende fakturearringsystemen.
MegaFon is acht bedriuwen yn ien. Yn 2009 waard de reorganisaasje foltôge: filialen yn hiel Ruslân fusearre yn ien bedriuw, MegaFon OJSC (no PJSC). Sa hat it bedriuw 8 billingsystemen mei har eigen "oanpaste" oplossingen, branchfunksjes en ferskate organisatoaryske struktueren, IT en marketing.
Alles wie goed oant wy ien mienskiplik federaal produkt moatte lansearje. Hjir ûntstiene in protte swierrichheden: foar guon wurde tariven nei boppen ôfrûn, foar oaren nei ûnderen en foar oaren - basearre op it rekenkundige gemiddelde. Der binne tûzenen sokke mominten.
Nettsjinsteande it feit dat der mar ien ferzje fan it billing systeem wie, ien leveransier, de ynstellings divergearre sa folle dat it duorre lang om te setten. Wy besochten har oantal te ferminderjen, en kamen oer in twadde probleem dat in protte bedriuwen bekend is.
Fertikale skaalfergrutting. Sels de coolste hardware op dat stuit foldie net oan 'e behoeften. Wy brûkten Hewlett-Packard apparatuer út de Superdome Hi-End line, mar it foldie net oan 'e behoeften fan sels twa tûken. Ik woe horizontale skaalfergrutting sûnder grutte bedriuwskosten en kapitaalynvestearingen.
Ferwachting fan groei yn it oantal abonnees en tsjinsten. Konsultanten hawwe lang ferhalen oer IoT en M2M nei de telekomwrâld brocht: de tiid sil komme dat elke tillefoan en izer in SIM-kaart sil hawwe, en twa yn 'e kuolkast. Hjoed hawwe wy ien oantal abonnees, mar yn de heine takomst sille der noch folle mear.
Technologyske útdagings
Dizze fjouwer redenen motivearren ús om serieuze feroaringen te meitsjen. Der wie in kar tusken it opwurdearjen fan it systeem en it ûntwerpen fanôf it begjin. Wy tochten in lange tiid, namen serieuze besluten, spielden tenders. As gefolch hawwe wy besletten om fan it begjin ôf te ûntwerpen, en namen ynteressante útdagings oan - technologyske útdagings.
Skalberens
As it earder wie, litte wy sizze, litte wy sizze 8 billings foar 15 miljoen abonnees, en no hie it wurke moatten 100 miljoen abonnees en mear - de lading is in oarder fan grutte heger.
Wy binne yn skaal fergelykber wurden mei grutte ynternetspilers lykas Mail.ru of Netflix.
Mar de fierdere beweging om de lading en abonneebasis te fergrutsjen hat serieuze útdagings foar ús steld.
Geografy fan ús grutte lân
Tusken Kaliningrad en Vladivostok 7500 km en 10 tiidsônes. De ljochtsnelheid is einich en op sokke ôfstannen binne de fertragingen al signifikant. 150 ms op 'e coolste moderne optyske kanalen is te folle foar real-time fakturearring, foaral sa't it no is yn telekom yn Ruslân. Derneist moatte jo op ien wurkdei bywurkje, en mei ferskate tiidsônes is dit in probleem.
Wy leverje net allinich tsjinsten foar in abonnemintskosten, wy hawwe komplekse tariven, pakketten en ferskate modifiers. Wy moatte de abonnee net allinich tastean of wegerje om te praten, mar him in bepaald kwota jaan - oproppen en aksjes yn realtime berekkenje, sadat hy it net merkt.
marzje foar flaters
Dit is de oare kant fan sintralisaasje.
As wy alle abonnees yn ien systeem sammelje, dan binne alle needeveneminten en rampen desastreus foar bedriuw. Dêrom ûntwerpe wy it systeem op sa'n manier om de ynfloed fan ûngemakken op 'e heule abonneebasis te eliminearjen.
Dit is wer in gefolch fan de wegering om fertikaal te skaaljen. Doe't wy horizontaal skalen, fergrutte wy it oantal servers fan hûnderten nei tûzenen. Se moatte wurde beheard en útwikselber, automatysk reservekopy fan de IT-ynfrastruktuer en restaurearre it ferspraat systeem.
Wy stiene foar sokke nijsgjirrige útdagings. Wy hawwe it systeem ûntworpen, en op dat stuit besochten wy wrâldwide bêste praktiken te finen om te kontrolearjen hoe yn trend wy binne, hoefolle wy avansearre technologyen folgje.
Wrâldûnderfining
Ferrassend hawwe wy gjin inkele referinsje fûn yn globale telekom.
Jeropa is fuortfallen yn termen fan it oantal abonnees en skaal, de FS - yn termen fan 'e platheid fan har tariven. Wy seagen guon yn Sina, en fûn guon yn Yndia en hierden spesjalisten út Vodafone Yndia.
Om de arsjitektuer te analysearjen, hawwe wy in Dream Team gearstald ûnder lieding fan IBM - arsjitekten út ferskate fjilden. Dizze minsken koene adekwaat beoardielje wat wy diene en bepaalde kennis nei ús arsjitektuer bringe.
Skaalfergrutting
In pear nûmers foar yllustraasje.
Wy ûntwerpe it systeem foar 80 miljoen abonnees mei in reserve fan ien miljard. Dit is hoe't wy takomstige drompels fuortsmite. Dit is net om't wy Sina sille oernimme, mar fanwegen de oanfal fan IoT en M2M.
300 miljoen dokuminten ferwurke yn echte tiid. Hoewol wy 80 miljoen abonnees hawwe, wurkje wy mei sawol potinsjele kliïnten as dejingen dy't ús hawwe ferlitten as wy vorderingen moatte sammelje. Dêrom binne de eigentlike folumes merkber grutter.
2 miljard transaksjes It saldo feroaret alle dagen - dit binne betellingen, kosten, oproppen en oare eveneminten. 200 TB oan gegevens wurdt aktyf feroaret, feroarje in bytsje stadiger 8 PB gegevens, en dit is net in argyf, mar live gegevens yn in inkele fakturearring. Skaal per datasintrum - 5 tûzen tsjinners op 14 siden.
Technology stack
Doe't wy de arsjitektuer planden en it systeem begon te sammeljen, ymporteare wy de meast nijsgjirrige en avansearre technologyen. It resultaat is in technologystack bekend foar elke ynternetspiler en korporaasjes dy't systemen mei hege lading meitsje.
De stapel is fergelykber mei de stapels fan oare grutte spilers: Netflix, Twitter, Viber. It bestiet út 6 komponinten, mar wy wolle it ynkoarte en ferienigje.
Fleksibiliteit is goed, mar yn in grutte korporaasje is d'r gjin manier sûnder ienwurding.
Wy sille itselde Oracle net feroarje nei Tarantool. Yn 'e realiteit fan grutte bedriuwen is dit in utopia, of in krústocht foar 5-10 jier mei in ûndúdlike útkomst. Mar Cassandra en Couchbase kinne maklik wurde ferfongen troch Tarantool, en dat is wat wy stribje nei.
Wêrom Tarantool?
D'r binne 4 ienfâldige kritearia wêrom't wy dizze databank hawwe keazen.
Speed. Wy hawwe load tests útfierd op MegaFon yndustriële systemen. Tarantool wûn - it liet de bêste prestaasje sjen.
Dit is net te sizzen dat oare systemen net foldogge oan de behoeften fan MegaFon. Aktuele ûnthâldoplossingen binne sa produktyf dat de reserves fan it bedriuw mear dan genôch binne. Mar wy binne ynteressearre yn omgean mei in lieder, en net mei immen dy't efterbliuwt, ynklusyf yn 'e load test.
Tarantool dekt de behoeften fan it bedriuw sels op 'e lange termyn.
De priis fan TCO. Stipe foar Couchbase op MegaFon-voluminten kostet astronomyske bedraggen jild, mar mei Tarantool is de situaasje folle nofliker, en se binne ferlykber yn funksjonaliteit.
In oare moaie funksje dy't ús kar in bytsje beynfloede is dat Tarantool better wurket mei ûnthâld dan oare databases. Hy lit sjen maksimale effisjinsje.
Reliabiliteit. MegaFon ynvestearret yn betrouberens, wierskynlik mear as immen oars. Dus doe't wy nei Tarantool seagen, realisearren wy dat wy it oan ús easken moasten foldwaan.
Wy ynvestearre ús tiid en finânsjes, en tegearre mei Mail.ru hawwe wy makke in bedriuw ferzje, dy't no wurdt brûkt yn ferskate oare bedriuwen.
Tarantool-enterprise hat ús folslein tefreden yn termen fan feiligens, betrouberens en logging.
Partnership
It wichtichste is foar my direkt kontakt mei de ûntwikkelder. Dit is krekt wat de jonges fan Tarantool omkeapje mei.
As jo komme ta in spiler, benammen ien dy't wurket mei in anker client, en sizze dat jo nedich hawwe de databank te kinnen dwaan dit, dit en dit, hy meastal antwurd:
- Okee, set de easken ûnderoan dy steapel - ienris komme wy der wol by.
In protte hawwe in roadmap foar de kommende 2-3 jier, en it is hast ûnmooglik om dêr te yntegrearjen, mar Tarantool-ûntwikkelders boeie mei har iepenheid, en net allinich fan MegaFon, en oanpasse har systeem oan 'e klant. It is cool en wy fine it echt leuk.
Wêr't wy Tarantool brûkten
Wy brûke Tarantool yn ferskate eleminten. De earste is yn 'e pilot, dy't wy makke hawwe op it adresmapsysteem. Op in stuit woe ik dat it in systeem wie dat fergelykber wie mei Yandex.Maps en Google Maps, mar it draaide in bytsje oars.
Bygelyks de adreskatalogus yn 'e ferkeapynterface. Op Oracle nimt it sykjen nei it winske adres 12-13 sekonden. - ûngemaklike nûmers. As wy oerstappe nei Tarantool, ferfange Oracle mei in oare databank yn 'e konsole, en fiere deselde sykopdracht, wy krije in 200x speedup! De stêd dûkt op nei de tredde brief. No oanpasse wy de ynterface sadat dit bart nei de earste. De antwurdsnelheid is lykwols folslein oars - millisekonden ynstee fan sekonden.
De twadde applikaasje is in trendy tema neamd twa-snelheid IT. Dit komt om't adviseurs út elke hoeke sizze dat korporaasjes dêr hinne moatte.
D'r is in ynfrastruktuerlaach, dêrboppe binne d'r domeinen, bygelyks in fakturearringsysteem lykas in telekom, bedriuwssystemen, bedriuwsrapportaazje. Dit is de kearn dy't net oanrekke wurde hoecht. Dat is, fansels, it is mooglik, mar paranoïde garandearje kwaliteit, want it bringt jild oan de korporaasje.
Dêrnei komt de laach fan mikrotsjinsten - wat ûnderskiedt de operator as in oare spiler. Mikrotsjinsten kinne fluch oanmakke wurde op basis fan bepaalde caches, en bringe dêr gegevens fan ferskate domeinen. Hjir fjild foar eksperiminten - as der wat net slagge, die ik ien mikroservice ticht en iepene in oare. Dit soarget foar wirklik ferhege tiid-to-merk en fergruttet de betrouberens en snelheid fan it bedriuw.
Mikrotsjinsten binne faaks de haadrol fan Tarantool by MegaFon.
Wêr't wy fan plan binne Tarantool te brûken
As wy ús suksesfolle fakturearringprojekt fergelykje mei de transformaasjeprogramma's by Deutsche Telekom, Svyazcom, Vodafone India, is it ferrassend dynamysk en kreatyf. Yn it proses fan it útfieren fan dit projekt waarden net allinich MegaFon en syn struktuer omfoarme, mar ek Tarantool-enterprise ferskynde op Mail.ru, en ús ferkeaper Nexign (earder Peter-Service) - BSS Box (in faktueroplossing).
Dit is, yn in sin, in histoarysk projekt foar de Russyske merk. It kin fergelike wurde mei wat beskreaun is yn it boek "The Mythical Man-Month" fan Frederick Brooks. Doe, yn 'e jierren '60, hierde IBM 360 minsken om it nije OS/5-bestjoeringssysteem foar mainframes te ûntwikkeljen. Wy hawwe minder - 000, mar ús binne yn vesten, en mei rekken hâldend mei it brûken fan iepen boarne en nije oanpak, wurkje wy produktiver.
Hjirûnder binne de domeinen fan fakturearring of, yn 't algemien, saaklike systemen. Minsken út it bedriuw kenne CRM tige goed. Elkenien moat al oare systemen hawwe: Open API, API Gateway.
Iepenje API
Litte wy nochris nei de sifers sjen en hoe't de Open API op it stuit wurket. Syn lading is 10 transaksjes per sekonde. Om't wy fan plan binne de mikrotsjinsten-laach aktyf te ûntwikkeljen en de MegaFon iepenbiere API te bouwen, ferwachtsje wy in gruttere groei yn 'e takomst yn dit diel. Der sille grif 100 transaksjes wêze.
Ik wit net oft wy kinne fergelykje mei Mail.ru yn SSO - de jonges lykje te hawwen 1 transaksjes per sekonde. Harren oplossing is ekstreem ynteressant foar ús en wy binne fan plan har ûnderfining oan te nimmen - bygelyks in funksjonele SSO-backup meitsje mei Tarantool. No dogge de ûntwikkelders fan Mail.ru dit foar ús.
CRM
CRM is deselde 80 miljoen abonnees dy't wy wolle ferheegje nei in miljard, om't d'r al 300 miljoen dokuminten binne dy't in trijejierrige skiednis omfetsje. Wy binne echt op syk nei nije tsjinsten en hjir groei punt is ferbûn tsjinsten. Dit is in bal dy't groeie sil, om't der hieltyd mear tsjinsten komme. Dêrtroch sille wy in ferhaal nedich wêze; wy wolle hjir net oer stroffelje.
Sels fakturearje yn termen fan it útjaan fan faktueren, wurkje mei te ûntfangen klantrekken omfoarme ta in apart domein. Om prestaasjes te ferbetterjen, tapast domein arsjitektuer arsjitektoanysk patroan.
It systeem is ferdield yn domeinen, de lading wurdt ferdield en fouttolerânsje wurdt garandearre. Dêrneist wurken wy mei ferspraat arsjitektuer.
Al it oare is oplossings op bedriuwsnivo. Yn de opslach opslach - 2 miljard per dei, 60 miljard per moanne. Soms moatte jo telle se yn in moanne, en it is better gau. Finansjeel tafersjoch - dit is krekt deselde 300 miljoen dy't hieltyd groeit en groeit: abonnees faak rinne tusken operators, fergrutsje dit diel.
De meast telekomkomponint fan mobile kommunikaasje is online fakturearring. Dit binne de systemen wêrmei jo te belje of net skilje, meitsje besluten yn real time. Hjir is de lading 30 transaksjes per sekonde, mar rekken hâldend mei de groei yn gegevensferfier, plannen wy 250 transaksjes, en dêrom binne wy tige ynteressearre yn Tarantool.
De foarige ôfbylding is de domeinen wêr't wy Tarantool sille brûke. CRM sels is fansels breder en wy sille it yn 'e kearn sels brûke.
Us skatte TTX-sifer fan 100 miljoen abonnees betizet my as arsjitekt - wat as 101 miljoen? Moatte jo alles wer oerhelje? Om foar te kommen dat bart, brûke wy caches, tagelyk fergrutsje de berikberens.
Yn 't algemien binne d'r twa oanpak foar it brûken fan Tarantool. Earste - bou alle caches op it mikroservicenivo. Sa fier as ik begryp, folget VimpelCom dit paad, it meitsjen fan in cache fan kliïnten.
Wy binne minder ôfhinklik fan leveransiers, wy feroarje de BSS-kearn, dus wy hawwe in inkele klantbestân út 'e doaze. Mar wy wolle it útwreidzje. Dêrom nimme wy in wat oare oanpak - meitsje caches binnen systemen.
Op dizze manier is d'r minder syngronisaasje - ien systeem is ferantwurdlik foar sawol de cache as de haadmasterboarne.
De metoade past goed by de Tarantool-oanpak mei in transaksjeskelet, as allinich dielen dy't relatearje oan updates, dat is gegevensferoarings, wurde bywurke. Al it oare kin earne oars opslein wurde. D'r is gjin enoarme gegevensmar, net beheard globale cache. Caches binne ûntwurpen foar it systeem, of foar produkten, of foar kliïnten, of om it libben makliker te meitsjen foar ûnderhâld. As in abonnee ropt en oerstjoer is oer de kwaliteit fan jo tsjinst, wolle jo kwaliteitstsjinst leverje.
RTO en RPO
D'r binne twa termen yn IT - OTR и RPO.
Objektyf foar hersteltiid is de tiid dy't it nimt om de tsjinst te herstellen nei in mislearring. RTO = 0 betsjut dat sels as der wat mislearret, de tsjinst trochgiet te wurkjen.
Herstelpunt doelstelling - dit is de tiid foar gegevensherstel, hoefolle gegevens wy kinne ferlieze oer in bepaalde perioade. RPO = 0 betsjut dat wy gjin gegevens ferlieze.
Tarantool taak
Litte wy besykje in probleem foar Tarantool op te lossen.
Given: in koer mei applikaasjes dy't elkenien begrypt, bygelyks yn Amazon of earne oars. Ferplicht sadat de winkelkarre wurket 24 oeren 7 dagen yn 'e wike, of 99,99% fan' e tiid. De oarders dy't by ús komme moatte yn oarder bliuwe, om't wy de ferbining fan 'e abonnee net willekeurich kinne yn- of útsette - alles moat strikt konsistint wêze. It foarige abonnemint hat ynfloed op de folgjende, dus de gegevens binne wichtich - neat moat ûntbrekke.
beslút. Jo kinne besykje it head-on op te lossen en freegje de database-ûntwikkelders, mar it probleem kin net wiskundich oplost wurde. Jo kinne stellingen, behâldwetten, kwantumfysika ûnthâlde, mar wêrom - it kin net oplost wurde op it DB-nivo.
De goede âlde arsjitektoanyske oanpak wurket hjir - jo moatte it fakgebiet goed kennen en it brûke om dizze puzel op te lossen.
Us oplossing: it meitsjen fan in ferspraat register fan applikaasjes op Tarantool - in geo-ferdield kluster. Yn it diagram binne dit trije ferskillende gegevensferwurkingssintra - twa foar de Oeral, ien bûten de Oeral, en wy fersprieden alle oanfragen ûnder dizze sintra.
Netflix, dat no wurdt beskôge as ien fan 'e lieders yn IT, hie oant 2012 mar ien datasintrum. Oan 'e foarjûn fan' e katolike Kryst, 24 desimber, gie dit datasintrum del. Brûkers yn Kanada en de FS bleaunen sûnder har favorite films, wiene tige oerstjoer en skreau der oer op sosjale netwurken. Netflix hat no trije datasintra oan 'e west-eastkust en ien yn West-Jeropa.
Wy bouwe yn earste ynstânsje in geo-ferdielde oplossing - fouttolerânsje is wichtich foar ús.
Dat wy hawwe in kluster, mar hoe sit it mei RPO = 0 en RTO = 0? De oplossing is ienfâldich, ôfhinklik fan it ûnderwerp.
Wat is wichtich yn applikaasjes? Twa dielen: Basket Throwing TO it meitsjen fan in oankeap beslút, en NACHT. It DO-diel yn telekom wurdt normaal neamd oarder capture of oarder ûnderhanneling. Yn telekommunikaasje kin dit folle dreger wêze as yn in online winkel, om't dêr de klant moat wurde betsjinne, 5 opsjes oanbean, en dit bart allegear in skoft, mar de koer is fol. Op dit stuit is in mislearring mooglik, mar it is net eng, om't it ynteraktyf bart ûnder minsklik tafersjoch.
As it Moskou datasintrum ynienen mislearret, dan troch automatysk oer te skeakeljen nei in oar datasintrum, sille wy trochgean te wurkjen. Teoretysk kin ien produkt ferlern gean yn 'e karre, mar jo sjogge it, foegje opnij oan' e karre en fierder wurkje. Yn dit gefal RTO = 0.
Op itselde momint is d'r in twadde opsje: as wy op "fertsjinje" klikke, wolle wy dat de gegevens net ferlern gean. Fan dit momint ôf begjint automatisearring te wurkjen - dit is RPO = 0. Mei dizze twa ferskillende patroanen kin it yn ien gefal gewoan in geo-ferdield kluster wêze mei ien wikselbere master, yn in oar gefal in soarte fan quorumrecord. Patterns kinne fariearje, mar wy lossen it probleem.
Fierder, mei in ferspraat register fan applikaasjes, kinne wy it allegear ek skaalje - hawwe in protte dispatchers en útfierers dy't tagong krije ta dit register.
Cassandra en Tarantool tegearre
Der is in oar gefal - "útstalkast fan saldo's". Hjir is in nijsgjirrich gefal fan it mienskiplik gebrûk fan Cassandra en Tarantool.
Wy brûke Cassandra om't 2 miljard oproppen per dei net de limyt is, en d'r sil mear wêze. Marketeers hâlde fan ferkear op boarne te kleurjen; mear en mear details ferskine op sosjale netwurken, bygelyks. It draacht allegear by oan it ferhaal.
Cassandra lit jo horizontaal skaalje nei elke grutte.
Wy fiele ús noflik mei Cassandra, mar it hat ien probleem - it is net goed yn lêzen. Alles is OK op 'e opname, 30 per sekonde is gjin probleem - lêsprobleem.
Dêrom ferskynde in ûnderwerp mei in cache, en tagelyk hawwe wy it folgjende probleem oplost: d'r is in âlde tradisjonele gefal as apparatuer fan in skeakel fan online fakturearring komt yn 'e bestannen dy't wy yn Cassandra lade. Wy stride mei it probleem fan betroubere download fan dizze bestannen, sels mei help fan it advys fan IBM-manager bestânferfier - d'r binne oplossingen dy't bestânferfier effisjint beheare, bygelyks it UDP-protokol ynstee fan TCP. Dit is goed, mar it is noch minuten, en wy hawwe it noch net alles laden, de operator yn it callcenter kin de kliïnt net beantwurdzje wat der bard is mei syn lykwicht - wy moatte wachtsje.
Om foar te kommen dat dit bart, wy wy brûke parallel funksjonele reserve. As wy in evenemint fia Kafka nei Tarantool stjoere, aggregaten yn echte tiid opnij berekkenje, bygelyks foar hjoed, krije wy cash saldo, dy't balâns kin oerdrage op elke snelheid, bygelyks 100 tûzen transaksjes per sekonde en deselde 2 sekonden.
It doel is dat nei it meitsjen fan in oprop binnen 2 sekonden yn jo persoanlike akkount net allinich it feroare saldo sil wêze, mar ynformaasje oer wêrom't it feroare is.
konklúzje
Dit wiene foarbylden fan it brûken fan Tarantool. Wy fûnen echt de iepenheid fan Mail.ru en har reewilligens om ferskate gefallen te beskôgjen.
It is al lestich foar adviseurs fan BCG of McKinsey, Accenture of IBM om ús te ferrassen mei wat nijs - in protte fan wat se biede, dogge wy al, hawwe dien of binne fan plan te dwaan. Ik tink dat Tarantool syn rjochtmjittige plak sil nimme yn ús technologystack en sil in protte besteande technologyen ferfange. Wy binne yn 'e aktive faze fan ûntwikkeling fan dit projekt.
It rapport fan Oleg en Andrey is ien fan 'e bêste op' e Tarantool-konferinsje ferline jier, en op 17 juny sil Oleg Ivlev prate by mei in ferslach . Alexander Deulin sil ek in presintaasje jaan fan MegaFon . Litte wy útfine wat feroare is, hokker plannen binne útfierd. Doch mei oan - de konferinsje is fergees, alles wat jo hoege te dwaan is ... Alles en de konferinsje programma is foarme: nije gefallen, nije ûnderfining yn it brûken fan Tarantool, arsjitektuer, ûndernimming, tutorials en microservices.
Boarne: www.habr.com