(Public) cloud architect – cunostiinte solide sau hype?

Ma uitam peste diverse anunturi sau articole cu privire la "noile" abordari in materie de solutii enterprise si imi sare in ochi o treaba ciudata. Unde se vorbeste de angajare in domeniu sunt insiruite o serie de tehnologii foarte specifice ale marilor furnizori de pe piata.

Chiar pe asta se pune cel mai mult accent cand vine vorba de dezvoltatori ai aplicatiilor ce vor rula in cloud: sa stie tot ce ofera AWS/Azure/Google in materie de servicii prefabricate? Nimic mai adanc, mai independent? Ma duce cu gandul la multitudinea de frameworks din lumea Java si certificarile aferente.

Imi scapa ceva?

Nu-ti scapa nimic, se plateste super bine.
Am un prieten care face consultanta DevOps cu Doker/Kubernates/GoogleCloud pentru Home Office in Londra, 900 de lire pe zi.
Alt exemplu Docker/AWS-ECS/CloudFormation remote din Canada 100$/ora.
Amandoi in zona tehnologiilor financiare.

In general reteta se pare ca e: container tool (docker nu prea are concurent) + orchestration tool (Kubernates, Mesos) + platforma cloud (AWS, GC, Azure).

Edited by denisen, 22 November 2016 - 00:23.

denisen, on 22 noiembrie 2016 - 00:18, said:

și câte ore/zile facturează într-o lună?

Full time, am impresia ca la ei e 7.5h/zi, 20 zile pe luna.
Angajatorii sunt in general corporatii/directii de stat.
Au chestii de pus in productie si tinut in picioare, si bani fara numar fara numar, vorba lu Salam.
Nu startup rahat.

Edited by denisen, 22 November 2016 - 00:47.

Apoi nimic nu supara business-ul mai mult decat sa nu mearga productia. Sau sa mearga ca naiba.

Avantajul hostingului in cloud e scalarea pe orizontala on demand. Cel mai banal exemplu e un site de vanzari - in mod obisnuit sa zicem ca ruleaza pe 2 instante; de Black Friday scalezi instant la 3-4-x instante daca sunt multi utilizatori dupa care revi la cele 2 obisnuite.

Nu contest utilitatea serviciilor respective, a posibilitatiilor de scalare, etc.

Dilema vine mai degraba pe partea de dezvoltare a acestor tipuri de solutii unde peste tot parca aud doar de denumiri de servicii (imi vine sa le compar cu anunturi unde se cere sa stii n patternuri si m frameworks). Doar amestecand ce ni se pune pe tava, nu exista riscul sa obtinem solutii puternic sub/supra-dimensionate? In vine in minte un articol unde unuia i se cerea sa foloseasca Hadoop pentru 700 MB de date.

Edited by dani.user, 23 November 2016 - 18:48.

shiva, on 23 noiembrie 2016 - 18:07, said:

Oare emag pe ce claud ii, claudu retardatilor?

shiva, on 23 noiembrie 2016 - 18:07, said:

Mda, in teorie asa e. In practica 99% din dezvoltatori habar nu au sa scrie o aplicatie capabila sa scaleze orizontal. Vezi de exemplu citirea de la mai multe SLAVE DBs. Plus ca cei mai multi isi trateaza serverele pe post de animale de companie, iar daca le pica un server, sunt in pom. Ca fapt divers, orice solutie bazata pe cloud ar trebui sa fie inapoi in picioare in mai putin de 2 ore daca pica orice server.

In general fiecare dintre ofertantii mari (MS/Google/Amazon) au pentru platforma lor foarte multe tehnologii. Iti trebuie ani sa inveti cat de cat o parte din ele. Pentru o companie care e deja pe una din platforme, nu are mare relevanta unul care le stie pe celelalte, desi unele tehnologii sau concepte se intrepatrund pana la un punct. Nu vorbim aici de programatori carora le dai de scris 3 clase si trebuie sa stie bine limbajul de programare preferat pt platforma respectiva, ca ala nu are treaba cu arhitectura de dedesubt prea mult. Daca vrei arhitecti, senior devs, atunci e bine ca aia sa fie deja familiarizati cu tehnologia pe care esti si tu cu produsele, nu sa stai dupa ei sa-i convertesti. Eu lucrez de 3 ani pe Azure si e atat de vasta toata povestea incat nici macar nu pot spune ca sunt expert in Azure. Ma limitez eventual la a spune ca stiu despre cele cateva tehnologii Azure pe care le folosim in proiectul la care lucrez. Sunt o multime pe care le stiu doar dupa nume si avand in vedere ca nici in cele ce ne trebuie nu prea am cum sa devin expert peste noapte si e un proces continuu de invatare, sa invat si restul de tehnologii doar sa ma aflu in treaba nu merita. Nu mai zic de a studia si tehnologii similare de la AWS/GC.

HashiCorp au niste produse de uniformizare, un fel de strat comun sub care sa poti sa schimbi AWS cu GC.
Da la cat de alambicate sunt proiectele in general tot iesi pe aratura dincolo de ce-ti ofera toolurile alea, si dai tot in APIuri native.

dani.user, on 23 noiembrie 2016 - 18:41, said:

700 Mb poate merita mutarea, dacă previi că va crește rapid, de exemplu atunci când ai un serviciu secundar sau intern de 700mb și îl vei face public și pentru alții.

denisen, on 24 noiembrie 2016 - 01:19, said:

Exact. De aceea noi am ales să preluăm toată responsabilitatea pentru coordonarea, provizionarea, etc de noi noduri. AWS, GC, etc, sunt doar întâmplător acolo și pot fi înlocuiți oricând. Dar am făcut asta pentru că se potrivea use case-ului nostru: nu avem nevoie de scalare dinamică foarte rapidă, putem prevede timpurile de trafic ridicat cu cel puțin o zi înainte.

Și dacă mă gândesc bine, nu e dificil să adaugi un watchdog pentru HAProxy, unde e deja înregistrat load-ul, și să faci câteva apeluri la un api și să adaugi adresele IP ale backend-urilor noi create. Ar fi un proiect de 1 săptămână adăugarea acestei dinamicități.

OriginalCopy, on 24 noiembrie 2016 - 08:59, said:

Partea de infrastructura e relativ straight-forward, indiferent de platforma.

Au aparut insa o gramada de abordari foarte specifice de arhitectura, puternic integrate in fiecare platforma. De exemplu, in cazul Azure, web role, worker role, service fabric practic iti "impun" cum sa-ti organizezi aplicatia pentru a beneficia de diverse servicii, deobicei axate pe scalabilitate. In cazul asta parca nu mai vorbim de un simplu furnizor ci de-o platforma intreaga care trebuie integrata la fiecare pas (cum testezi, cum faci deploy, etc). O analogie fortata ar fi sa luam aplicatia pt desktop si sa rescriem o buna parte din ea pt un telefon mobil. O fi bine, o fi rau?

Edited by dani.user, 24 November 2016 - 23:10.

dani.user, on 24 noiembrie 2016 - 23:05, said:

Lucrurile de genul ala sunt BS de marketing al caror scop e sa te lege de ei, sa te "fidelizeze", a.k.a. vendor lock-in.

Imi imaginez ca trebuie doar sa scrii un nume de clasa pe undeva, o configuratie, etc, si gata, totul e cloud. E bine daca vrei sa cresti rapid, dar cresterea asta nu e gratuita, te costa technical debt.

Nu spun sa nu folosesti ce zic ei, imi imaginez ca e bun, dar trebuie sa faci un pas in spate si sa te gandesti ce faci de fapt, in acest caz: distribuirea muncii. Apoi sa iti creezi puncte de inflexiune in arhitectura care permit o eventuala schimbare in viitor. Culmea e ca nu costa mult, e vorba de una sau mai multe interfete, si cate o implementare pentru acele interfete care intamplator folosesc azure.

Ca analogie, e ca in anii '90, cand a dat internetul navala peste noi, si eram bucurosi ca ne cumparam hosting, si ne mai dadeau si oferte cu inregistrarea gratuita a domeniului... pe primii 2 ani. Dar apoi, surpriza, intrarile DNS erau la ei, te tineau de oo ca sa te fidelizeze... cu forta.

Acum cand ne-a mai venit mintea la cap, ne ducem mai intai la un registrar oficial, si din control panelul lui punem adresele IP ale serverelor noastre, unele in azure, altele in aws, etc.

Cam asa va fi si cu cloud, dupa ce va trece hype-ul peste noi.

Deci ca sa raspund la intrebarea despre hype, este 50/50 hype, dar sunt si lucruri bune. Fiecare vendor de cloud impacheteaza lucrurile bune pe care le ofera in marketing, hype, postari pe bloguri, etc, si ti le vara sub nas. Poti sa tragi pe nas direct ce iti vara iei, sau sa iei doar partea esentiala, si sa iti creezi spatiu pentru un "plan B". Nu trebuie neaparat sa ai planul B gata de actiune, dar macar sa ai locul lui rezervat.

"Adevarul" e undeva la mijloc.

Abordarea opt-in pentru cloud pe care am luat-o face ca astfel de probleme sa nu apara: https://about.gitlab...ose-bare-metal/

load balancerul este pe servere dedicate. cloud il adaugam (sau il scoatem) din pictura in functie de nevoi.

Nu ne aspira cloud-ul, ci noi il aspiram pe cloud, cand si cum vrem.

Iar fix agilitatea asta de a face miscari largi inseamna o arhitectura buna.