We stand to save $7m over five years from our cloud exit

1 Like

Unde lucrez eu, s-a incercat o luna in cloud si am ajuns la concluzie ca e mai bine sa avem infrastructura proprie.

1 Like

Nimeni nu e fan cloud pana ce cladirea unde ai serverele iti ia foc si pierzi toate datele

2 Likes

sau daca esti in banking, telecom si alte domenii unde lucrurile nu pot sta in cloud.

1 Like

Am vazut un trend, adica cred ca exista mereu.

E angajat un senior si trebuie sa dovedeasca, de ce se leaga ?

  1. Reducerea costurilor in cloud
  2. Livrare mai rapida pe mai multe platforme deodata (e.g. Android/iOS vs React Native/Flutter)
  3. Rescrierea de la 0 pentru o arhitectura mai scalabila

Omul uita sa mentioneze ca acum au un sistem intern pe care vreo 10 devopsi interni trebuie sa il intretina, ultima data cand am verificat era vreo 80k/an un devops bun. Nu au nici o certificare ISO, Azure/AWS/Google au certificare inclusiv pentru banci. Ai un sistem custom pe care nimeni nu il cunoaste, iar cand angajezi o sa ia luni pana cand cineva va cunoaste minimul necesar, asta daca totul e bine documentat si exista persoana alocata pentru knowledge transfer/ramp-up.

Dupa el a redus costurile prin aceasta metoda ca sa arate managementului ca merita cei 200-300k/an + actiuni. De fapt cand toti devopsii isi iau concediu sau sunt bolnavi si ceva se duce si trebuie adusi inapoi din concediu vezi ca de fapt a fost o zgarceala.

2 Likes

DHH este managerul…

3 Likes

My bad… se pare ca e o exceptie.

1 Like

Setup-uri de rahat pot să existe și în cloud și on-premise. On-premise o să fie tot timpul mai ieftin. Calitatea și stabilitatea sistemul sunt date de deciziile luate de devops și programatori, nu de cloud/hosting.

Nimeni nu e fan cloud pana ce cladirea unde ai serverele iti ia foc si pierzi toate datele

Pentru că majoritatea nu sunt interesați de backup sau restore. Să nu mai vorbesc de documentat sau testat proceduri de restore. În mod normal ar trebui să te poți muta în câteva ore pe alt server în alt datacenter (limitare care ține mai mult de cât de mare e backup-ul - cât durează transferul).

Late edit: și pe cloud e fain când nu poți să-ți resetezi serverul că nu mai prinzi altul (hint Azure Cloud la început de pandemie).


My two cents e că e fain în cloud când nu-ți permiți un devops bun sau ești la început și ai spike-uri (success neașteptat) și nu știi cum să-ți calibrezi resursele. După aceea ieși mult mai ieftin cu servere dedicate. Și ai și mai multă flexibilitate (poți să te muți oricând de la un provider la altul). În cloud ești legat de tool-urile provider-ului. E ca și cum ai adopta un nou limbaj de programare.

Cunosc multe companii care plătesc milioane pe an pentru cloud și mi se pare risipă.

4 Likes

Cred că mai e un element la mijloc, am observat asta și în alte industrii, și Apple profită maxim de asta: standardizarea.

Adică în ziua de azi de exemplu docker e cam peste tot, și orice aplicație e testată să fie compatibilă cu el. Orice framework, orice platformă, totul e gândit să funcționeze cu el.

Când ai așa nivel de standardizare, numărul de chestii custom de care ai nevoie e minim sau chiar tinde spre zero. Nu mai e ca acum 10-15 ani când fiecare era izolat în ecosistemul lui și aveai nevoie de ditamai hardughia pentru orice dependință.

Da, știu că în realitate tot timpul te lovești de o problemă pentru care e pur și simplu mai rapid/ieftin să faci un script sau ceva și aia e, dar numărul s-a redus considerabil totuși.

Acuma sunt și eu în proces de asta, și deși nu vreau să fac devops, fiind cel și cu experiență în Linux mai multă, am revenit oarecum și am început să reînvăț și comparativ cu ce știam eu de ultima oară când mai făceam din astea…e altă lume efectiv.

3 Likes

La kubernetes pare standardizat, dar de fapt iti prinzi rapid urechile cand vezi ca la cate implementari sunt ceva tot difera.

1 Like

Pai si ce, pentru aws nu iti trebuie devopsi? e cam acelasi lucru. Parerea mea e ca costurile cresc mult in cloud si pentru ca poti sa faci infrastructura din 3 clicuri si nimeni nu se gandeste asa mult si le face. Pe de alta parte pe on prem e complicat sa cumperi un nou server si te gandesti mult mai mult.

On premise e mai ieftin si mai performant, dar nu poti scala in 2 ore ca ai un spike de trafic. De aia probabil mai peste tot sistemele on premise is supradimensionate din start.

Da, dar pentru un produs cum au ei, adica Basecamp, e greu sa ai spikes de trafic de 10x in 2 ore. Nu imposibil, dar greu. Inclin sa cred ca multe usecase-uri incadreaza aici.

Daca insa ai un ecommerce si vrei sa vinzi mult la urmatorul Black Friday, asta e altceva.

Sa nu uitam ca asa a inceput AWS. Amazon.com avea infrastructura supra-dimensionata care statea idle.

1 Like

Nu e vorba doar de scalat în 2 ore. Sunt multe alte lucruri ce țin și de management și forecasting.

Tot bugetul pentru cumpărare de hardware probabil trebuie aprobat la începutul anului fiscal și în timpului anului descoperi că ori ai bugetat prea mult ori rămâi fără bani dacă ai crescut prea rapid.

La cloud ai o factură pe care o plătești și poți uita de ea ca și director .

1 Like

Vorbind din experiența de la jobul actual unde ținem on-premise un shop online destul de mare (printre cele mai populare din țară), există soluții și pentru asta:

  • homepage custom de black friday unde e totul optimizat
  • dezactivezi feature-uri care știi că îți consumă resursele și nu sunt necesare (de exemplu: la rezultatele căutării nu te mai lași userul să vizualizezi 200 de item-uri pe pagină, lași maxim opțiunea cu 100, etc)
  • scalezi serviciile și folosești și hardware-ul care stă degeaba în datacenter (de “backup”/“failover”)

De Black Friday avem minim 10x trafic față de o zi normală și niște spike-uri nasoale. Am făcut însă față cu brio. În primii ani aici am participat la tot optimizări după fiecare Black Friday (vedeam unde erau problemele), însă acum suntem OK. Pregătirile sunt minime (facem doar load testing cu o lună înainte să ne asigurăm că n-am feștelit nimic între timp).


Asta cred că stă la baza popularității cloud-ului.

În cloud e mult mai ușor de justificat costul (cost of doing business). Îți dă flexibilitate și cu optimizările: scapi ușor dacă produci ceva ne-optim (mai adaugi niște resurse și nu se simte), dacă se plânge managementul de costuri, faci optimizări să le reduci. După un ciclu din astea ai două proiecte încheiate cu success și ești promovat :laughing:

On-premise sunt mult mai multe probleme cu care te confrunți: relația cu cei care țin data center-ul, providerii de internet, curentul, providerii de hardware (garanție, suport în caz de probleme), la fiecare 5 ani trebuie să faci refresh hardware, dacă închizi unele servicii rămâi cu hardware care stă degeaba, etc. Însă, în funcție de ce anume faci, merită să îți asumi problemele astea și să economisești o grămadă de bani.

6 Likes

Ai dreptate 100%. Am facut si eu(ma rog, echipa din care faceam parte prin 2014, ca nu imi pot asuma eu singur realizarea) o chestie similara: Am observat ca 80% din clienti erau pe homepage. Am facut un homepage custom complet static, genenerat asincron in functie de ce produse doream sa fie vazute acolo. Apoi undeva la 15-16% erau in Category listing…si alea le-am cache-uit urat rau de tot cu varnish(asta era pe vremea aia). In checkout ramaneau sub 5%…

Problema e ca si asa ajungi la o limita si e bine sa ai sistemele pregatite pentru limita aia ca altfel te faci de ras. Iar limita aia nu o atingi niciodata in timpul anului.

Mai este un punct pozitiv pentru on-premise de care eu personal habar n-aveam pana recent: Amortizarea contabila a hardware-ului. Nu sunt expert in asta, nici pe departe, dar din ce mi s-a spus, in contabilitatea romaneasca se poate amortiza hardware-ul fizic. Daca inchiriezi servere in AWS, nu prea. Treaba cu amortizarea contabila are un rol destul de important in anumite tipuri de companii. Si nu ma refer aici la chestii ilegale, sau la limita legalitatii.

2 Likes