Practic Amazon Prime Video a economisit 90% in costuri cu infra dupa ce a migrat de la microservicii si componente serverless catre monolit(blasfemie).
P.S. Lectura e relativ scurta, articolul are vreo luna jumate dar eu acum l-am gasit 
3 Likes
Nu este vorba despre tot serviciul de video, ci doar despre o parte mica (as zice) a lui. Vorbim doar despre serviciul care monitorizeaza calitatea unui stream la care se uita un user, sau mai bine spus care verifica/agrega date cum ca ca un stream sau nu are “defecte” video sau audio. Au avut probleme pentru ca au folosit un serviciu (AWS Step Functions) care nu se preta exact la ce aveau ei nevoie nici ca si cost, nici ca si performanta. Si pentru ca isi trimiteau imagini prin buckets de s3, pentru ca decriptarea streamului si analiza de frame/buffers se faceau in procese diferite. Aparent daca nu pasezi imagini si faci ambii pasi dintr-un proces relativ scurt intr-un singur loc e mai ieftin, mai rapid si mai scalabil. Cine ar fi crezut?
5 Likes
Reacții:
3 Likes
Am citit mai multe posturi de la tipul acela (David Heinemeier Hansson) si pot observa o destul de mare repulsie a lui fata de microservicii. Si fata de cloud. E un fel de IT hipster. Daca majoritatea comunitatii zice ca tehnologia A e buna, el vine cu cateva exemple ca tehnologia A nu e buna. Ceea ce poate fi corect, dar in acelasi timp induce in eroare lumea din cauza mesajului.
Pe scurt, o echipa din Amazon a ales pentru niste procese de calitatea imaginii sa creeze module prea mici si comunicarea intre ele era prea costisitoare. That’s it. Au invatat din greseala and they fixed it.
Mesajul real e ca trebuiau sa faca modulele mai mari pentru ca nu are rost sa faci module mici daca exista tight coupling intre ele. Nu monolit vs microservicii. Nu treaba asta de alb vs negru care e menita sa polarizeze si sa zica oamenilor ca patternul A e câh sau patternul B e mana lui Dumnezeu. Toata discutia se invarte de fapt in jurul marimii ideale a unui modul de software. Si pentru asta e nevoie de multa experienta. Sunt multi factori care pot influenta arhitectura si nu exista o solutie universala. Din cauza asta avem Agile. Fail fast, fail safe, learn, improve, repeat.
5 Likes
Eu inca n-am vazut un proiect pe care microserviciile sa fi fost solutia (sau doar partial erau), dimpotriva, daca ai lua in calcul toata munca depusa de devops si cata confuzie e din cauza infrastructurii/arhitecturii cu microservicii, plus testarea in 99% din cazuri vezi ca de fapt ai fi avut nevoie de un monolit sau cativa monoliti care pot fi paralelizati la nevoie.
Plus 80% din oameni nu stiu sa faca microservicii, se uita si ei pe youtube si fac un endpoint REST, inca o baza de date pe serviciu si au facut un microservice. Dar separation of concerns devine mult mult mai greu cu microservicii cand business requirement-ul e sa poti de exemplu sa incarci datele peste tot din acelasi loc… Nu mai ai nici monoliti, nu mai ai nici microservicii, ai o mamaliga cu cod care nu e in acelasi loc doar sa poti zice ca esti pe microservicii, dar de fapt daca ai vrea sa il scalezi vezi ca nu se poate oricum sau ca devopsii au de 10x mai multa munca fata de developerii care nu s-au mai gandit la scalare cat mai simpla, latente, etc. Iar cand nu ai devopsi iti ia luni sa faci un release.
La NodeJS functioneaza pattern-ul de microservicii fiindca iti permite sa uiti de cat de prost e codul tau sau ca iti lipseste multi-threading si sa te bazezi pe faptul ca fiecare serviciu e efemer. Daca nu ai ceva ce trebuie sa ruleze foarte mult timp iti permiti sa scrii cod prost, dar rapid.
2 Likes
In jurul datei de 1 Mai netul a mers destul de prost in zona mea. Intamplator sau nu Prime Video a fost singurul serviciu pe care l-am putut urmari fluent, celelalte nu mergeau sau se blocau in scurt timp, inclusiv Netflix.
Eu am citit postul ala cand zicea ca renunta la cloud si ii dau dreptate. De ce sa platesti pentru cloud cand ai load previzibil? Cloul-ul ar trebui folosit cand ai nevoie de flexibilitate, fie esti un startup care creste rapid, fie o companie care are load spikes.
Eu am vazut si au sensul lor, daca arhitectura este facuta bine. Poti sa dezvolti in paralel in mai multe echipe, poti sa scalezi mai bine etc. Sa zicem ca ai un monolit f. mare si o componenta are nevoie de scaling 10x. Cum faci?
1 Like
Cresti si orizontal si vertical, incepi sa te gandesti la paralelizare intr-un serviciu dedicat cand costul serverului/infrastructurii depaseste costul developmentului. Exista diferite strategii de load balancing, poti face ceva weighted.
Oricum la majoritatea aplicatiilor nu aplicatia in sine va fi problema ci message bus-ul/baza de date/data storage-ul.
Nici eu. Desi inteleg nevoia de a paraleliza munca pentru un produs cu oarecare succes.
Foarte multe initiative de migrare catre microservicii si/sau serverless s-au facut exclusiv din motive de organizare a echipelor. Nicidecum de scalabilitate, cost, etc. Problema e ca nici acolo nu e simplu.
Si chiar daca stiu sa le faca bine, si am vazut exemple de proiecte unde oamenii chiar aveau habar, asta tot nu inseamna ca scapi de overheadul cu care vine arhitectura asta. De la service registration & discovery pana la observability, messaging, testing si deployment. Apoi cum le imparti? Ce criterii aplici? Care echipa e owner pe ce?
Si pentru mine e clara treaba: 90% din echipele pe care le-am vazut, fie luand contact direct fie indirect, nu sunt capabile sa faca 1 monolit. Pai daca nu esti capabil sa faci 1 monolit…sau reducand la absurd…1 serviciu cat de cat ok, stabil, cu arhitectura decenta si testat decent… hai sa nu ne bagam in rahat care depaseste nivelul nasului.
Mai e o problema: multi manageri nu au inteles nici azi ca daca ai echipa de 5-6 insi mai bine stai in banca ta si nu te apuci de microservicii. Stiu doar ca microservices = hype si vrem si noi.
1 Like
De acord 100%.
Am observat ca multe lume implicata in zona de migrare pe cloud sa enervat pe aceste postari si nu inteleg de ce anume pentru ca explica foarte clar omul ca se refera la cazul lui particular, ceea ce face el acolo nu e neaparat o solutie pentru orice firma.
Daca ar fi un singur mesaj de retinut din tot articolul respectiv cred ca e asta: casca ochii sau o incurci si nu te baza pe pareri populare in alegerea unor tehnologii sau solutii.
2 Likes
De pe linkedin + comentarii.
Nu stiu cat de bune sunt
De pe Reddit
https://www.reddit.com/r/programming/comments/13clrk3/how_to_recover_from_microservices
Postarile duc catre link-urile postate de @iamntz
1 Like
Imi place tare de tipul asta si de canalul lui:
Asta pentru ca probabil nu exista o arhitectura buna. Am lucrat proiecte cu microservicii in ultimii ani si cel mai greu lucru a fost definirea arhitecturii si a modului cum comunica intre ele toate microserviciile. Daca treci de la monolit la microservicii nu spargi aplicatia mare in mai multe mici ci redefinesti arhitectural toata structura.
Hmm, aici parerea mea e ca se face o greseala. Microserviciile sunt una si stocarea e alta iar separarea asta se face tot din arhitectura. La nivel de implementare, decat sa faci mai multe baze de date mai bine folosesti una distribuita pe care o acceseaza toate microserviciile.
Cum 99% din noi lucram cu un Agile/Scrum ciopartit mai niciodata nu o sa faci bine arhitectura si dupa un punct microserviciile sunt adaugate cum apare o nevoie de ceva nou. Daca ai monolitul stii exact ce trebuie facut altfel.
Baza de date distribuita suna bine, dar nu suna bine cand de fapt baza de date nu e distribuita bine si un singur microserviciu le blocheaza pe toate celelalte. Nici eu n-as incepe cu n baze de date, dar cand vezi ca iti faci probleme scriind in acelasi loc/sunt probleme de performanta e necesar.
Well, nu prea inteleg cum adica nu e distribuita bine, daca te referi de exemplu la eventualele inconsitente intre noduri, pana la sincronizare, normale dealtfel in bazele de date distribuite, trebuie ca serviciile tale sa tina cont de asta sau sa folosesti mecanisme de verificare a sincronizarii. Bazele de date distribuite nu prea sunt ACID din motive evidente si trebuie sa faci un mind switch pentru o utilizare eficienta. De asta am spus mai devreme ca rescrierea in sistem microservicii a ceva NU inseamna un split in module mai mici ci redefinirea arhitecturii pentru a lua in calcul exact genul asta de elemente. Pe de alta parte inconsistenta si problemele generate de bazele de date multiple pot fi mult mai mari decat in una distribuita. Ca si efortul de DevOps.
Apoi, un microserviciu poate fi vazut in mod simplificat ca o functie clasica intr-un program care poate da eroare sau nu iar tu tratezi cumva acea eorare. Prin urmare nu are nici o importanta daca un microserviciu esueaza, intrebarea e cum gestionezi respectivul failure iar asta nu se rezolva doar local ci la toate nivelurile (arhitectura, dezvoltare si implementare).
1 Like
Din pacate nu mai e acces gratuit la medium.
BTW, ceva mai detaliat legat de ce a facut Amazon de fapt cu Prime Video:
face toti cei 5$ chiar si numai articolul linkuit de mine… e scris de un principal engineer din amazon, si chiar explica lucruri… in fine…
ce e pe dev acolo la public e o noua incercare de a sapa in intuneric cu cost-based si blah; nu de aia au schimbat arhitectura, colegul lor cplica mult mai simplu dpdv business cum a inceput echipa aia si ce au ajuns sa li se ceara, 2 chestii fundamental diferite pt care e nevoie de arhitecturi fundamental diferite
dar hai sa facem zeci de mii de eur pe luna (not me) si sa ne zgarcim la un abonament medium
3 Likes
Este gratis daca intri prima data pe acel articol.
Dupa cum vedeti in poza, nici nu am cont.
You have 1 free member-only story left this month. Sign up for Medium and get an extra one.
