Salut,
Un gand nu imi da pace.
AWS este recunoscut pentru serviciile misto pe care le ofera si cel mai important este scalarea.
Cel mai usoara metoda prin care un developer nu isi rupi capul cu configurari complicate este AWS EB (ElasticBeanstalk) care practic este un fel de wizzard care dintr-un singur loc iti configureaza un ELB (Elastic Load Balancer) care in spate are niste masini EC2. Asta este un amanunt care nu este important.
Caz concret: O configuratie cu AWS EB creaza o masina EC2 care costa 7$ pe luna si este configrat sa scaleze la 3 instante daca loadul depaseste 80% si sta in medie undeva la mult sub 10%. Nu a fost nevoie sa porneasca niciodata o alta instanta are un cost asociat de load balancer se 13$. Cu alte cuvinte load balancerul costa mai mult decat masina in sine.
Alte calcule:
Daca masina sta constant in 70%, deci mai mic de 80% => VM-ul costa tot 7$ dar load balancerul ajunge la 91$.(Calculat ochiometric)
Pentru cei care nu stiu pretul la load balancer consta intr-un cost fix pe ora, numar conexiuni noi, numar conexiuni active si trafic.
Imi scapa mie ceva sau e mai ieftin sa supraprovizionezi serverul (mai mult cpu power si ram) decat sa pui masini mai mici care sa scaleze la load mare?
eu stiam ca load balancerul e pret fix, faci load balancing si pt redundancy, eg in alta zona, sau vre-un crash, o erroare ne-recuperabila in cod, pierzi connexiunea cu baza de date, sau alte connexiuni etc.
Amazon au o politica un pic neortodoxa cand e vorba de preturi. Undeva e calculat cum sa iti ia fiecare cent, asa ca orice solutie alegi sa iesi tot pe la acelasi nivel de pret. Nu stiu in detaliu cat sunt costurile cu o masina mai performanta vs un load balancer dar as paria ca ai si acolo costuri ascunse care in final tot acolo te duc.
Si noi am avut probleme similare pe pricing cu AWS, intr-un final am mers cu digital ocean, preturi mai transparente si acceptabile, undeva de cel putin 5 ori mai putin.
Preturile sunt transparente la AWS, numai ca sunt foarte greu de estimat in varianta initiala si foarte mari. Cati gandesc in numar de conexiuni create, active la o aplicatie.
In ultima vreme de cand am migrat pe AWS am tot citit la documentatia lor. Toate descrierile lor incep cu “a cost effective”. Comparativ cu ce ma intreb?
O comparatie intre hostingul clasic si cloud din perspectiva inchiriatului de masini ar fi:
- hosting clasic: iei masina si te costa x euro pe zi
- cloud: iti dau masina gratis dar fiecare apasare de pedala te costa x, schimbarea vitezei y, apasarea franei z, aer conditionat t, …
La inceput te bucuri ca zici ca te costa mai putin, dar cand te dai jos din masina constati ca de fapt, ai platit mult mai mult pe mai putin.
E un punct in care Amazon e o alegere buna, daca dintr-o data ai dat lovitura si ai 10 milioane de vizitatori pe site-ul tau care ti-ar aduce 10 milioane de euro tu nu ai avea cum sa ii servesti cu servere clasice. Poate esti un developer si nu ai nimic deaface cu servere/linux si administrare. Inveti amazon si iti pui serviciul pe el, ii facturezi clientului gazduirea si stii ca nu iti trebuie administrator de sistem, nu trebuie sa te ocupi de update-uri, scalare, etc. Costa mult, dar cum serviciul tau castiga de 5 ori mai mult iti permiti sa dai 1/3 din bani pe Amazon. Cand nu mai e rentabil te muti cu un parteneriat undeva, ca deja poti negocia preturile.
Sunt nise in care intr-adevar nu se merita, unul din acestea sunt serverele de jocuri.
Amazon nu prea cade, la o aplicatie/un serviciu cel mai important e sa fii online mereu, nu ai cum sa garantezi acest lucru cu digitalocean. Cel mai bun serviciu pe care il au e S3, daca ai un serviciu care consta din incarcarea de binare atunci e foarte practic sa implementezi ceva redundant pe amazon. Daca ai pierde datele ar trebui sa iti inchizi serviciul.
Hosting-ul clasic nu are audit, Amazon are audit constant, poti sa iti faci inclusiv un pipeline cu serverless pe S3 cand cineva incarca ceva automat sa scanezi cu lambda fisierul.
La development iti trebuie tot felul de servere pentru CI/CD si testare, environment-uri de dev, staging, performance testing, prod (chiar in mai multe regiuni sau la mai multi clienti), workers pentru jenkins. Pe cloud ti le setezi una doua si stii si costul estimativ pentru ele. Poti avea login cu SSO pentru devi/testeri/devops pe servere.
O chestie pe care am vazut-o si e o idee buna e sa setezi honeypot-uri sau site-uri false inainte sa intrii direct pe serverele tale de la amazon. La hosting clasic nu e posibil, iti trebuie retele virtuale. (grupuri de securitate cu retea dedicata per aplicatie si subnet-uri bastion)
Acum au ceva si mai smecher numit Session Manager ca sa controlezi la sange acces-ul prin SSH cu SSO cu two-factor auth si sa vezi fiecare comanda care s-a dat.
Multumesc tuturor pentru raspunsuri, si in special @isti37 .
Inca o data, imi plac foarte mult serviciile lor si ma gandesc in viitor foarte apropiat sa le folosesc serviciile si pentru un pet project.
O sa fac o arhitectura prin care o sa folosesc serviciile AWS pentru a avea scalabilitate si uptime mare dar puterea de procesare o sa fie o parte pe alte servere si comunicarea cu SQS.
Totusi mi-ar placea sa mai aud alte pareri cu privire la AWS.
Hmm… Pare ca aws lightsale este un punct de plecare foarte bun pentru a gazdui onaplicatie in cloud care sa si scaleze dar in acelasti timp sa aiba costuri predictibile.
A folosit cineva? Ceva impresii?
Un detaliu foarte important e că îți trebuie microservicii ca să fii intr-un caz ideal.
Lightsail e un VM clasic, dacă îți ajunge un VM clasic sunt opțiuni mai ieftine și rapide.
Eu aș folosi GCP cu kubernetes cu orice proiect mai mare. În cel mai rău caz rancher os pe cloud propriu. Amazon era ok, acum sunt opțiuni mai elegante.
La Amazon trebuie să folosești baza lor de date, redisul lor, load balancerul lor, adică microservicii. (La fel și la google doar că ai kubernetes ce îl poți rula și local)
Nu sunt avocalul AWS sau ceva, dar parca au si ei K8S.
Poate ar fi interesanta o comparatie de pret.
Nu ma pricep la fel de bine ca ceilalti colegi, dar sa documentezi incercarea. Imi pare un subiect foarte interesant. 
Poti sa sari si cu un articol pe #blogs
Dacă vrei poti folosi mySQL sau postgres în aws, inclusiv în mod server less.
Legat de scalare cel mai ieftin e sa ai microservicii în lambda uri, care îți scaleaza relativ automat. Dzr trebuie să-ți gândești aplicația asa de la început ceea ce nu e ușor.
vezi ca e aici un thead cum lambda functii i-a bagat in faliment.
Pe subiectul asta, o prezentare foarte fain facuta. Ofera foarte multa informatie utila, pe langa subiect:
EKS (Amazon Elastic Kubernetes Service) pare compromisul perfect pentru a rula very large scale apps, la un pret minim in AWS.
Kubernetes te ajuta enorm pe partea de auto-scaling, iti ofera posibilitatea de a seta reguli destul de complexe pentru adaugarea/stergerea pod-urilor. Reguli bazate pe CPU/Memory/Disk IO, care iti permit sa ai o utilizare foarte eficienta a instantelor, evitand situatiile in care ai o gramada de instante cu load de 10-20% din resurse, cum, probabil, ca este si cazul in multe situatii.
.
Poti merge si mai departe cu optimizarea costurilor folosind o combinatie dintre EC2 Spot Instances (care sunt servere disponibile doar temporar, vandute mai ieftin) si on-demand instances (pentru servicii vitale, cu care nu-ti permiti sa risti), in care sa ai si reliability, dar si costuri mici.