Ofertele virtualizate au rezultate semnificativ mai slabe (vezi experimentele mele din 2019: httpsjan.rychter.com/enblog/cloud-server-cpu-performance și costă mai mult. Diferența este că poți „scala la cerere”, ceea ce am considerat că nu este necesar, cel puțin în cazul meu. Și dacă am nevoie să mă scalez, mai pot face asta, doar că obținerea de noi servere durează ore în loc de secunde. Ei bine, nu trebuie să mă scalez în secunde
În cazul meu, întreaga mea factura lunară pentru mediul de producție complet și un mediu de așteptare/în ședință duplicat este constantă, simplă, previzibilă, foarte mică în comparație cu ceea ce ar trebui să plătesc AWS și încă mai am mult spațiu de performanță.
Un lucru care merită remarcat este că tratez serverele fizice la fel ca pe cele virtuale: totul este gestionat prin ansible și pot recrea totul de la zero. De fapt, folosesc un alt mediu „devcloud” la Digital Ocean, iar acesta este creat folosind terraform, înainte de a fi transmis către ansible care face restul setării.
Bănuiesc că VendorOps și instrumentele complexe precum kubernetes sunt favorizate de comercianții de complexitate care au apărut în ultimul deceniu. Arată grozav pe CV și oferă liderilor din tehnologie un fals sentiment de realizare
Între timp, Stackoverflow, care este fără îndoială mai important decât majoritatea startup-urilor, merge cu mașinile dedicate
1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..
Se pare că tendința în acest spațiu este să sari direct la cel mai înalt strat de abstractizare. Sari peste elementele fundamentale si indicati la instrumente, biblioteci si produse $buzzword
Vedeți străluciri ale acestui lucru în diferite forme. Unul este firele de socializare care întreabă lucruri precum Cât din X trebuie să știu pentru a învăța Y Unde X este o tehnologie sau un domeniu fundamental, posibil foarte stabil și Y este un instrument de zi cu zi sau direct un produs sau serviciu
CORBA aparține acolo. Și poate chiar și chestiile web semantică. Cu siguranță XML!
XML este grozav - dacă nu crezi, atunci s-ar putea să fii interesat de durerile de a analiza JSON: httpseriot.ch/projects/parsing_json.html
Și nu mă face să încep cu YAML..
Costul incremental de a fi pe un nor merită din plin pentru mine să am baze de date gestionate, instantanee automate, echilibrare de încărcare găzduite, stocare bloc plug and play etc.
Vreau să-mi fac griji dacă produsul nostru este bun, nu defecțiunile hardware în mijlocul nopții, învârtirea unui nou server și ca acesta să nu funcționeze corect, deoarece nu exista niciun stimulent pentru a utiliza gestionarea configurației cu o singură casetă, având o singură sarcină evasiva. cauza OOM sau disc plin și sparge totul în loc de doar sarcinile VM, teama de a reporni o mașină care a funcționat de 1000 de zile etc.
Pentru mine, atractia cloud-ului nu este un mod de scalabilitate FAANG atunci când nu este necesar, ci corecțiile automate ale sistemului de operare, echilibrarea automată a încărcăturii, serviciile NAT, jurnalele centralizate, analizabile, serviciile de baze de date pe care nu trebuie să le gestionez. cutie rolling upgrade-uri la servicii, gestionarea cripto-cheilor și secrete și, bineînțeles, stocarea obiectelor. (Acestea sunt toate lucrurile pe care le folosim în startup-ul nostru)
Aș merge la un pas și aș spune că serverele dedicate pot fi foarte viabile/eficiente din punct de vedere al costurilor atunci când ajungem la o anumită scară, în loc de invers. Pentru moment, cheltuielile cu cloud-ul merită pentru startup-ul meu
Dacă vă configurați mediul ca cod, în cele din urmă nu ar trebui să conteze dacă ținta dvs. este un server dedicat, un VM sau o configurație specifică cloud configurată printr-o API
Nu contează care dintre ele, ideea este că aveți una care vă poate construi o cutie nouă sau poate aduce o cutie care se comportă prost înapoi la o stare bună, pur și simplu rulând o comandă.
Sigur, cantitatea reală de Go(o) care o conduce poate fi îmbunătățită (și într-adevăr se îmbunătățește)
Acestea fiind spuse, adevărul dur este că abordarea dvs. este cea corectă, aproape toate afacerile (startup-urile!) supraîncărcează în loc să se concentreze pe furnizarea de valoare, identificarea nișei reale etc. (Da, există și partea cererii, deoarece Startup-urile umflate cu bani VC și care doresc să depindă de terțe părți care pot prelua sarcina, pot scala cu ei, SLA-urile și altele trebuie să fie promovate.)
Kubernetes este fantastic! Ori de câte ori văd că o afacere potențial concurentă începe să folosească Kubernetes, sunt imediat ușurată, deoarece știu că nu mai trebuie să-mi fac griji pentru ele. Ei sunt pe cale să dispară într-o grămadă de probleme tehnice de nerezolvat, încercând să rezolve problemele care nu pot fi urmărite într-o stivă tehnologică de o complexitate incredibilă și lucrând în jurul limitărilor impuse de un sistem conceput pentru afaceri cu trafic cu două-trei de magnitudine mai mare. De asemenea, COGS-ul lor va fi mult mai mare decât al meu, ceea ce înseamnă că vor trebui să își pună un preț mai mare pentru produsul lor, cu excepția cazului în care doar ard prin bani VC (caz în care sunt un flash în tigaie)
Lucruri bune peste tot
Ansible este imperativ, poate lucra spre o stare statică și atât. Dacă întâmpină o problemă, își dezactivează conexiunea SSH și plânge tone de erori Python și renunță pentru totdeauna. Chiar și cu inventarul său, este departe de a fi declarativ
k8s este o serie de bucle de control care încearcă să facă progrese către starea lor declarată. Eșecul nu este o problemă, va încerca din nou. Își va verifica în mod constant propria stare, are un API frumos pentru a o raporta și, datorită multor concepte reificate, este mai greu să ai ciocniri ciudate între componentele implementate. (Întrucât integrarea mai multor manuale cu Ansible nu este trivială.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
Și chiar dacă k8s pune prea multe moșteniri, urmează manifestări mai subțiri ale ideilor de bază. (De exemplu, httpsgithub.com/aurae-runtime/aurae)
Și acum sugerați că oamenii folosesc o implementare mai simplă, non-standard?
Deci, desigur, puteți implementa o soluție de complexitate minimă sau puteți folosi ceva „de la raft”
k8s este complexitate și o parte din el este cu siguranță inutilă pentru situația dvs., dar este, de asemenea, destul de general, flexibil, bine susținut etc.
>sugerezi ca oamenii să folosească o implementare mai simplă non-standard?
Ceea ce am sugerat este că, dacă K8s proiectul/software-ul devine prea mare pentru a eșua, atunci oamenii pot trece la o alternativă. Din fericire, conceptele și API-ul k8s sunt open source, deci pot fi implementate în alte proiecte și am dat un astfel de exemplu pentru a ilustra că alegerea k8s nu este o blocare a furnizorului asemănătoare Oracle
Întotdeauna aud despre toate lucrurile grozave pe care le obțineți practic gratuit de la furnizorii de cloud. Aceste lucruri sunt într-adevăr atât de ușor de configurat și de folosit? De fiecare dată când încercam să-mi configurez stiva LAMP pe un serviciu cloud, a fost un proces atât de confuz și înspăimântător încât am ajuns să renunț. Mă întreb dacă trebuie doar să împing puțin mai tare și voi ajunge în Cloud Heaven
A fi capabil să spui „Vreau un MySQL în cluster aici cu acest tip de specificații” este mult mai bine (din punct de vedere al timpului) decât să o faci pe cont propriu. Actualizările sunt, de asemenea, bine împachetate în sistem, așa că spun doar „aplicați cea mai recentă actualizare” în loc să mă asigur manual că erorile/repornirile au loc în ordinea corectă.
Așa că plătiți pentru a simplifica lucrurile, dar câștigul din acea simplificare începe doar cu proiecte mai mari. Dacă aveți ceva într-un singur server pe care îl puteți reporni în timp ce utilizatorii dvs. primesc o pagină de eroare, este posibil să nu merite
Cloud-ul nu este ușor, dar încercarea de a obține răcirea și eficiența energetică a unei camere mici de servere, oriunde aproape de nivelurile de eficiență, publicarea celor mai mari centre de date este aproape imposibilă, așa cum este conexiunea la internet cu mai mulți furnizori.
Odată cu cloud-ul, totul dispare, deoarece este gestionat de orice operator de centru de date pe care rulează acel cloud, dar ceea ce oamenii uită este că acest lucru este valabil și pentru serviciile de colocare de modă veche, care oferă adesea un cost/valoare mai bun decât cloud.
Și, deși este cu siguranță mai greu să gestionezi lucruri precum AWS sau Azure, deoarece sângerează o mulțime de abstracții pe care furnizorii de vpc la scară mică le ascund de tine sau pe care nu le obții cu adevărat cu un singur server de acasă, nu este greu la scara de a trebui să rulezi câteva. de rafturi în valoare de servere vmware cu stocare bazată pe SAN Cu chestii din Cloud aveți mai multe configurații de făcut, deoarece este vorba despre configurarea serverelor virtuale etc. În loc să transportați PC-ul într-o cutie în camera dvs., trebuie să îl „configurați” pentru a-l face disponibil Bazele de date DO au copii de siguranță pe care le puteți configura după bunul plac, stocați-le pe DO Spaces (cum ar fi S3). Gestionarea utilizatorilor DB este simplă. Există și servere cache pentru Redis Puteți adăuga un echilibrator de încărcare și îl puteți conecta la diferitele servere web Cred că mi-a luat aproximativ 30 de minute să configurez 2x servere web, un server DB, un server cache, un echilibrator de încărcare, un server de stocare și să le conectez pe toate după cum este necesar folosind câteva formulare simple. Nu pot depăși asta Dacă aveți mai multe informații sau opinii, vă rugăm să împărtășiți O mulțime de articole pe internet despre întărirea unui server Linux, cele pe care le-am încercat durează puțin mai mult de 30 de minute pentru a urma pașii, mult mai mult dacă încerc să învăț și să înțeleg cu adevărat ce face fiecare lucru, de ce este important, care este vulnerabilitatea de bază și cum ar putea fi necesar să personalizez unele setări pentru cazul meu de utilizare particular Sunt sigur că puteți găsi exemple de scripturi de configurare online (configurați actualizări automate, firewall, aplicații etc. ar trebui să fie o chestiune de a rula „curl $URL” și apoi „chmod +x $FILE” și „bash $FILE”. Nu am avut nevoie de gestionarea configurației (folosesc serviciul de rezervă al furnizorului meu, ceea ce cred că este important) Ceva de genul acesta: httpsraw.githubusercontent.com/potts99/Linux-Post-Install.. (văzut în httpswww.reddit.com/r/selfhosted/comments/f18xi2/ubuntu_d) Evident, același lucru se poate spune și despre VM-urile cu funcționare lungă, iar acest lucru poate fi rezolvat prin a avea o echipă disciplinată, dar cred că este, în general, mai probabil într-un mediu cu o singură mașină dedicată cu funcționare lungă. Hetzner are toate acestea, cu excepția bazelor de date gestionate httpswww.hetzner.com/managed-server Pachetele de găzduire web includ, de asemenea, 1..DB-uri nelimitate (MySQL și PostgreSQL) httpswww.hetzner.com/webhosting/ are backup automat și failover? >Cu backup zilnic rezervat sau backup inclus în tipul de server, toate datele sunt copiate zilnic și păstrate maxim 14 zile. Recuperarea copiilor de rezervă (Restaurare) este posibilă prin interfața de administrare a konsoleH Dar am impresia că bazele de date de pe serverele gestionate sunt destinate utilizării de către aplicațiile care rulează pe acel server, așa că nu există cu adevărat un concept de failover httpswww.hetzner.com/legal/managed-server/ Defectarea unei singure unități pe un singur server nu ar trebui să provoace niciodată o întrerupere a producției O mulțime de probleme de configurare pot fi urmărite până la implementări autonome. Fișierul cu fonturi sau JRE chiar trebuie să fie instalat pe întreg serverul sau îl puteți include în implementarea dvs. Implementările noastre folosesc ținte on-premise și EC2. Scriptul de implementare nu este diferit, doar IP-ul gazdei este diferit Acum, voi spune dacă pot folosi S3 pentru ceva ce voi face 100%. Nu există o alternativă on-premise pentru acesta cu același set de caracteristici Scopul DevOps este „Bovine, nu animale de companie”. Pune un glonț în serverul tău o dată pe săptămână pentru a-ți găsi punctele de eșec Mi-ar plăcea dacă ați sări în Discord/Slack și ați aduce în discuție unele dintre problemele pe care le vedeți, astfel încât să putem măcar să îmbunătățim experiența pentru ceilalți care folosesc Dokku. Simțiți-vă liber să mă lovești acolo sus (porecla mea este „savant”) Permiteți-mi să prefațez și să spun că sunt un dezvoltator de aplicații cu doar cunoștințe de lucru despre Docker.Nu sunt foarte priceput la infra și aplicația cu care m-am luptat are parametri de implementare particulari: este o aplicație Python care, în timpul construirii, analizează mai multe gig-uri de accesări HTML statice pentru a popula o bază de date Postgres care este statică după ce a fost construită. O aplicație web Flask servește apoi împotriva acelei baze de date. Analiza HTML evoluează rapid și, prin urmare, datele populate DB ar trebui să fie grupate ca parte a imaginilor aplicației IIRC, m-am luptat cu structurarea Dockerfiles atunci când DB nu era persistentă, ci doar o altă parte tranzitorie a aplicației, dar părea depășită. Problema mai mare părea să fie cum să evit să tragi date de la S3 rar modificate pentru fiecare build, atunci când în mod ideal ar fi memorat în cache, mai ales într-un mod care s-a comportat sănătos în DigitalOcean și în mediul meu local. Presupun că stocarea în cache a stratului de imagine Docker corect ar rezolva problema, dar am ajuns destul de repede la capătul cunoștințelor și al răbdării mele DX-ul lui Dokku pare grozav pentru oamenii care fac lucruri normale. :) 0. httpscoolify.io/ Plus cine nu vrea să se joace cu cea mai nouă și mai tare jucărie pe banul altuia? Există cu siguranță un argument pentru a muta (unele) lucruri de pe cloud mai târziu în călătorie, când flexibilitatea (sau gestionarea fluxului/pivotației) devine mai puțin un factor principal și scara/costul încep să domine Sigur, puteți obține ceva funcțional la Hetzner, dar fiți pregătit să răspundeți la mult mai multe întrebări Am fost de acord asupra ultimului punct al întreprinderii care a cerut acest lucru, ceea ce, din nou, este doar trist că aceste „cerințe” de afaceri dictează cum să arhitecți și să găzduiești software-ul atunci când o altă modalitate ar putea fi cea mult mai bună Recuperarea în caz de dezastru este o problemă foarte reală. De aceea îl testez în mod regulat. Într-un scenariu de pământ ars, pot fi în stare de funcționare pe un sistem secundar (în scenă) sau un sistem de nor terraformat în mai puțin de o oră. Pentru afacerea mea este suficient
Am trecut printr-un boom de creștere și, la fel ca toți înainte, a însemnat că erau mulți oameni fără experiență cărora li s-au înmânat mulți bani și așteptări urgente. Este o rețetă pentru cultarea mărfurilor și marketingul de exploatare
Dar creșterea încetinește și banii devin mai scumpi, așa că încetinește și începe să reînveți vechile lecții cu noi variante interesante. (Ca aici: gestionarea bare metal scaling și cu containere și orchestrare)
Și întregul ciclu se va repeta în următorul boom. Aceasta este industria noastră deocamdată
Un server dedicat solid este în 99% din timp mult mai util decât un VPS paralizat pe hardware partajat, dar, evident, are un cost crescut dacă nu aveți nevoie de toate resursele pe care le oferă
Da, dar dorința de a „face ceea ce fac toți copiii cool acum” este cel puțin la fel de puternică la cei cărora li s-ar face referire în mod normal ca „manager”, comparativ cu „angajați”
rezultatul A) cheltuiala uriașă pentru microservicii/cloud nu merge bine, cel puțin ați urmat cele mai bune practici, aceste lucruri se întâmplă, ce puteți face
rezultatul B) ați mers cu un server Hetzner și ceva a mers prost, ei bine, sunteți și ar fi trebuit să utilizați microservicii, vă bucurați să căutați un nou loc de muncă
Încurajând astfel managerii să aleagă microservicii/cloud. S-ar putea să nu fie decizia corectă pentru companie, dar este decizia corectă pentru manager și este managerul care ia decizia
(La fel ca și faptul că sunt consultant care dorește o extensie și scrierea unui software care funcționează, așa cum am aflat pe calea grea.)
Există o deconectare între fondatori și toți ceilalți
Fondatorii cred că vor ajunge >de 10 ori în fiecare an
Realitatea este că au 90% șanse să eșueze
90% din timp - ești bine reușind orice
Aproximativ % din cele 10% din cazurile în care reușiți, sunteți încă bine fără cloud - cel puțin pentru câțiva ani de succes, timp suficient pentru a schimba dacă este nevoie vreodată
Am o singură configurare ansible și poate funcționa atât pentru servere virtualizate, cât și pentru cele fizice. Nicio diferenta. Singura diferență este că serverele virtualizate trebuie mai întâi configurate cu terraform, iar cele fizice trebuie mai întâi comandate și IP-urile lor introduse într-un fișier de configurare (inventar)
Desigur, am grijă și să evit să devin dependent de multe alte servicii cloud. De exemplu, folosesc VpnCloud (httpsgithub.com/dswd/vpncloud) pentru comunicarea între servere. Ca un beneficiu secundar, acest lucru îmi oferă și flexibilitatea de a trece la orice furnizor de infrastructură în orice moment
Ideea mea principală a fost că, în timp ce ofertele virtualizate au utilizările lor, există un decalaj (uriaș) între un VPS hobby de 10 USD/lună și o companie cu afaceri B2C cu o creștere explozivă. Majoritatea afacerilor noi se încadrează de fapt în acest decalaj: nu vă așteptați la o creștere exponențială de hochei într-un SaaS B2B profitabil. Acolo ar trebui să puneți la îndoială alegerea implicită obișnuită de „utilizați AWS”. Îmi pasă de COGS și de marjele mele, așa că mă uit la această alegere foarte atent
Nu sunteți o companie de software, în principiu produci și vinzi Sprockets
Opiniile de aici ar fi angajarea unui mare personal IT/ing. care să „cumpere și să întrețină servere” (PaaS este prost) și apoi probabil „scrieți singur codul” (SaaS este rău) sau orice este în prezent popular aici (ultimul thread aici a fost „Impingând PHP peste SFTP fără Git și ești dacă ai nevoie de mai mult” lol)
Dar cred că companiile ar trebui să facă un lucru bine și să evite să încerce să concureze (făcând-o manual) pentru lucruri în afara competențelor lor de bază. În acest caz, aș crede cu siguranță că Sprocket Masters nu ar trebui să încerce să-și gestioneze propriul hardware și ar trebui să se bazeze pe un furnizor pentru a se ocupa de scalare, securitate, timp de funcționare, conformitate și toate micile detalii. De asemenea, cred că software-ul lor ar trebui să fie standard pentru mlaștină, cu cât mai puțin posibil. Nu sunt un magazin de software și ar trebui să scrie cât mai puțin cod posibil
În mod realist, Widget Masters ar putea rula aceste site-uri cu un personal destul de mic, dacă nu decid să facă totul manual, caz în care probabil ar avea nevoie de personal mult mai mare.
Totuși, ceea ce văd și despre ce cred că vorbea posterul anterior sunt afaceri în care tehnologia este în centrul afacerii și acolo de multe ori are mai puțin sens și, în loc să economisească timp, pare să coste timp. Există un motiv pentru care există experți AWS: nu este banal. Serverele „adevărate” nu sunt, de asemenea, banale, dar nici neapărat mai grele decât serviciile cloud
Dar acele agenții nu vor să fie nevoite să facă personal nici pentru întreținerea hardware-ului fizic.
Dar Sprocket Masters trebuie să aibă în continuare un consultant cloud costisitor, pur și simplu pentru a răspunde la urgențe
Dacă veți avea pe cineva în personal care să se ocupe de problemele legate de cloud, puteți închiria un server.
Personal, am rulat servere dedicate pentru afacerea noastră în zilele anterioare, dar pe măsură ce ne-am extins și ne-am extins, a devenit mult mai ușor să mergem cu furnizorii de cloud pentru a furniza rapid diverse servicii, chiar dacă costurile au crescut. Ca să nu mai vorbim că este mult mai ușor să-i spui unui client potențial că folosești „nori precum AWS” decât „O, închiriem aceste mașini într-un centru de date condus de o companie” (ceea ce de fapt poate fi mai bun, dar clienții nu vor primi asta) . Audit, Conformitate și altele
Pentru mulți chiar și mult mai puțin decât atât. Rulez un mic proiect secundar[1] care a devenit viral de câteva ori (30.000 vizualizări în aproximativ 24 de ore) și rulează pe un server web CPU cu un singur nucleu și un Postgres gestionat, de asemenea, pe un singur nucleu CPU. Nici măcar nu a fost aproape de utilizare completă
1: httpsaihelperbot.com/Aș putea trece unele dintre ele la funcții lambda?Sau treci la ECS?Sau să treci la alt serviciu cloud din ziua de azi?Poate.Dar timpul petrecut scriind acest comentariu este deja de aproximativ șase luni de economii pentru o astfel de schimbare.Dacă este mai dificil decât „apăsați butonul, primiți un serviciu 100% tradus în mod fiabil”, este greu de justificatUnele dintre acestea se datorează și faptului că cloud-ul oferă acum alte servicii care permit acest gen de lucru.Nu trebuie să rulez un cluster Kafka pentru mesageria de bază, toate vin cu o magistrală de mesaje.Eu folosesc asta.Folosesc opțiunile DB găzduite.Folosesc S3 sau echivalent etc.Mi se pare că ceea ce a mai rămas aproape că nu merită bătaia de cap de a încerca să mă blochez într-o altă paradigmă când plătesc cu o singură cifră dolari pe lună pentru a rula doar pe o instanță EC2Este absolut adevărat că nu toată lumea sau orice proiect poate face acest lucru.Nu sunt lipit de asta ca obiectiv final.Când nu funcționează, iau imediat măsurile de scalare corespunzătoare.Nu sugerez să rearhitectați ceva pe baza asta.Spun doar, nu este o opțiune de disprețuit.Are multă flexibilitate în el, iar facturarea este destul de consistentă (sau, altfel spus, faptul că, dacă am deodată traficul de 50 de ori, sistemul meu începe să se sufoce și să pulverizeze vizibil mai degrabă decât pur și simplu să mă încarci cu sute de dolari în plus este o caracteristică pentru mine, mai degrabă decât o eroare), și, în general, nu te întinzi pentru a te contorsiona într-o paradigmă care este convenabilă pentru un serviciu cloud, dar care poate să nu fie convenabilă pentru tineAți trebuit vreodată să gestionați unul dintre acele medii?Chestia este că, dacă doriți să obțineți o scalabilitate de bază pentru mai mult de o persoană și devop-uri adecvate, atunci trebuie să supraprovizionați cu un factor semnificativ (posibil anularea economiilor)În mod inevitabil, veți ajunge cu o soluție personalizată, ceea ce înseamnă că noii tamplari vor avea mai greu să stăpânească sistemul și oamenii semnificativi care părăsesc compania își vor aduce cunoștințele intime despre infrastructura dvs. lor.Te-ai întors la animale de companie în loc de bovine.Unele servere sunt speciale, după un timp automatizarea înseamnă „o mulțime de scripturi glue shell ici și colo” și o actualizare a sistemului de operare înseamnă că fie jumătate din infra este KO pentru un timp, fie nu faci upgrade-uri la OS. toateȘi, în cazul fericit în care trebuie să extindeți, S-ar putea să găsiți surprize neplăcuteȘi să nu primiți niciodată Am început pe partea de rețea.Dacă nu vă închiriați întregul rack și vă plasați propriul hardware de rețea, obțineți ceea ce obțineți.Care ar putea fi foarte slabă fie în funcționalități, fie în performanțe Presupunând că nu faci nimic elegantDacă vrei 100,0000% timp de funcționare, sigur.Dar de obicei nu o faci.Companiile care doresc acest tip de uptime au în mod normal echipe dedicate acestuia oricumȘi scalarea funcționează bine și pe bare-metal dacă scalați vertical - ai idee cât de putere și debitul pe care le poți obține de la un singur server?Este îngrijorător să tot auzi despre „scalare” când vorbitorul înseamnă „scalare orizontală”Dacă cerințele sunteți „scalare”, atunci scalarea verticală va să te ducă departeDacă cerințele tale sunt „scalarea orizontală la cerere”, atunci, cu siguranță, furnizorii de cloud vă vor ajuta acolo.Dar, puține locuri au nevoie de acest tip de scalareNu spun că 100% uptime pe bare metal este ieftin, spun 100% Adesea, timpul de funcționare nu este necesarPentru că industria este plină de oameni care urmăresc tendințe și cuvinte cheie și la care cel mai important lucru este să adăugați acele cuvinte cheie în CV-uriIME care vizează scalabilitate este extrem de greșit pentru majoritatea serviciilor/aplicațiilor/orice.Și, de obicei, plătiți atât de mult cheltuielile generale pentru soluțiile „scalabile”, încât trebuie apoi să scalați pentru a compensaChiar mă îndoiesc de acest lucru .Singura temă pe care o vedeți la aproape fiecare susținător AWS este o cantitate mare de iluzie cu privire la garanțiile care vă oferă de fapt AWSDa, sigur.Nimeni nu este concediat pentru că a cumpărat de la IBMEi bine, dacă marile companii ar avea vreo competență în luarea deciziilor, ar fi imbatabile și ar fi fără speranță să lucrăm la orice altceva la toate.Deci, da, acesta este un bun publicSursa: aproape treizeci de ani de operațiuniPână acum nu am observat că dacă cheltuiesc mai mult pentru compania care, de asemenea, sunt plătit mai multobținerea unei fiabilități echivalente cu fiare de călcat este mult mai costisitoare decât închirierea „două servere dedicate” - acum s-ar putea să vă fie bine cu un server și o soluție de rezervă , și asta e corect. dar un sysad pentru a crea toate acestea, chiar și pe un contract scurt pentru configurarea inițială și fără întreținere, va depăși cu mult diferența de preț în cloud, mai ales dacă există o bază de date în amestec și îți pasă de acele dateAstăzi, cloud-ul este similar - timpul de lansare pe piață este mai rapid, deoarece există mai puține părți mobile.Când economia scade și creșterea încetinește, beancounters vin și își fac treabaSe întâmplă de fiecare datăAcest lucru doar face AWS mai bogat la companii și echipe cloudEste banal să furnizați și să anulați furnizarea automată a unei instanțe EC2, în câteva secunde, dacă implementarea dvs. trebuie să se extindă sau să se reducă.Acesta este ceea ce îl face fundamental diferit de un server bare metal
Acum, nu neg că ar putea fi totuși mai rentabil în comparație cu AWS să furnizați câteva servere dedicate mai multe decât veți avea nevoie, dar atunci când aveți sarcini de lucru cu adevărat imprevizibile, nu este ușor să țineți pasul
dacă porniți și închideți mașinile virtuale pentru a satisface curba cererii - ceva este în neregulă cu arhitectura dvs.
Ți-a trecut vreodată prin minte, cum de stackoverflow folosește ~8 servere dedicate pentru a deservi întreaga lume și nu trebuie să pornească și să închidă mașinile virtuale pentru a satisface cererea globală a clienților?
--
Când planificați infrastructura de calcul, este important să reveniți la elementele de bază și să nu vă îndrăgostiți de propaganda furnizorului de cloud
Ai spus-o singur. Nu toate aplicațiile trebuie să deservească întreaga lume, prin urmare cererea va fi mai mică atunci când oamenii merg la culcare
Chiar și cu aplicațiile globale, există reglementări care vă cer să găzduiți aplicații și date în anumite regiuni. Imaginați-vă o aplicație care este utilizată de clienții din Europa, Australia și SUA. Acestea trebuie să fie deservite din centrele de date regionale, iar un cluster va fi în cea mai mare parte adormit când celălalt rulează (din cauza fusurilor orare). Cu servere dedicate, ați irosi 60-70% din resurse, în timp ce folosiți ceva de genul EC2/Fargate, puteți reduce până la aproape 0 atunci când regiunea dvs. este inactivă
Există o metodă pentru nebunie, aici se numește „dezvoltare bazată pe securitatea locului de muncă”
Pentru că este o amenințare pentru locurile de muncă lor
Există o mulțime de oameni care au cunoștințele tehnice să se auto-găzduiască sau să găzduiască mici exemple pentru familia/prietenii/asociația/clubul lor de drumeții. Această marjă mică în care ești ok să cheltuiești puțin în plus pentru că vrei să o faci corect, dar nu poți justifica să plătești atât de mult și să petreci timp făcând întreținere grea. Un mic VPS, cu un Nextcloud partajat sau un site web mic, este tot ceea ce este necesar în multe cazuri
Pentru asta folosesc chiar și puțin Raspberry Pi 400 în dormitorul meu
httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..
De aproape un deceniu am găzduit propriile mele lucruri. Nimeni nu a încercat DDoSing configurația mea, pentru că de ce ar face-o? Ce beneficii ar putea obține din asta? Aș fi aproape singura persoană afectată și, odată ce s-au oprit, nu va dura mult să-și revină
Există puțin sau deloc stimulent pentru DDoS o cutie personală, cu atât mai puțin de un rando pe internet
Supraestimezi drastic abilitățile unui adolescent
Doar să faci ping IP-ul din nou și din nou nu va face mare lucru. Poate un atac DoS, în funcție de ceea ce are rețeaua țintă în ceea ce privește IPS, dar chiar și atunci este mai probabil să-și infecteze computerele cu viruși înainte de a avea șansa să te atace efectiv.
Am fost personal pe partea de primire a unuia dintre cei pentru cumva un trișor în GTA 5. Cu siguranță se întâmplă și nu este distractiv
Edit: Se pare că acest lucru ar putea fi automat. Acesta este ceva interesant pe care ar trebui să mă uit puțin. Probabil că este doar o complexitate suplimentară pentru micul meu server, dar am avut în minte câteva utilizări
Tehnic, laboratorul meu de acasă se află și pe o IP publică statică - acesta a fost mai degrabă un exercițiu de „aș putea face asta” decât „de fapt necesar”, dar este totuși cool și sunt foarte fericit
Singura întrerupere a fost că trebuia să configurez Wireguard pentru a menține tunelul în viață, altfel, uneori, VPS-ul ar primi trafic de intrare și dacă laboratorul meu nu s-ar fi contactat de ceva timp (care, de ce ar fi?) tunelul s-ar fi oprit, și conexiunea proxy ar fi. Din fericire, aceasta este o funcționalitate încorporată
Deci, se pare că adăugarea de fluxuri RSS / Atom pe un site de pagini Jekyll sau GitHub este destul de simplă
1. httpsgithub.com/jekyll/jekyll-feed
2. httpsdocs.github.com/en/pages/setting-up-a-github-pages-s..
3. httpspages.github.com/versions/
atom 2c/4t, 4gb ram, 1tb drive, 100mbit
Câțiva ani de funcționare în acest moment
Dacă nu este întrerupt: poate fi necesară o actualizare.
Actualizările de securitate ale kernelului sunt un lucru
Mi s-a părut că Atoms este insuportabil de lent, chiar și cu Linux. Desigur, este suficient pentru a servi site-uri web și altele, dar este derutant cât de multă putere folosesc, pur și simplu, nu funcționează
Exact. Aceste instanțe VPS sub 10 USD sunt excelente pentru proiecte mici în care nu doriți să încheiați contracte lungi sau să vă ocupați de gestionarea propriilor servere
Dacă conduceți o afacere reală în care marjele sunt subțiri și aveți tot timpul liber din lume pentru a gestiona problemele de server dacă (când) apar, acele servere dedicate de ~ 50 USD ar putea fi interesante de explorat
Dar dacă conduceți o afacere reală, chiar și o factură AWS de 10.000 USD/lună este mai ieftină decât angajarea unui alt dezvoltator calificat care să vă ajute să vă gestionați serverele dedicate
Acesta este ceea ce lipsește în general în discuțiile despre costurile cloud în locuri precum HN: da, cloud-ul este scump, dar angajarea chiar și a unui singur administrator de sistem/dezvoltator suplimentar pentru a vă ajuta să gestionați infrastructura personalizată este incredibil de costisitoare și mult mai puțin flexibilă. De aceea, cheltuirea unui ipotetic 5000 USD/lună pe o soluție găzduită în cloud care ar putea, teoretic, să fie construită la comandă pe un server de 50 USD/lună, cu o investiție suficientă de timp, poate fi totuși o mare afacere. Inginerii sunt scumpi și timpul este limitat
Uhhh, scuză-mă, dar cât plătești tipul ăsta DevOps? Aceasta pare o perspectivă foarte americană, chiar și zona de vale. În Europa, angajarea unui tip ar fi mai ieftin
Costurile de angajare complet încărcate sunt semnificativ mai mari decât cele pe care le luați acasă în salariu. De fapt, este mai rău în Europa. Aruncă o privire la aceste grafice: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Dacă plătiți cuiva 1000 EUR în Marea Britanie, compania costă în total 1245 EUR
Dacă plătești cuiva 1000 EUR în România, costă compania total 1747 EUR
Deci, un cost de 120.000 USD complet încărcat s-ar putea să vă cumpere doar cu un salariu de 68.000 USD pentru un devop din UE
Dar nu poți avea doar o singură persoană devops. Aveți nevoie de cel puțin 2 dacă doriți să permiteți unuia dintre ei să ia vreodată o pauză, sau să plece în vacanță
Te pot conecta în aproximativ 3 ore
AWS este foarte eficient din punct de vedere al costurilor pentru alte servicii (S3, SES, SQS etc.), dar mașinile virtuale nu sunt o afacere bună. Primești mai puțină memorie RAM& CPU, cu suprasarcina de virtualizare, și plătiți mult mai mulți bani
În special pentru Postgres, dacă rulați unele teste cu pgbench, puteți vedea cu adevărat penalitatea pe care o plătiți pentru virtualizare
Poate că abilitatea de administrator de sistem de a-ți putea construi propria infrastructură devine o artă pierdută, altfel nu pot explica de ce oamenii sunt atât de îndrăgostiți să plătească de 5 ori pentru mai puțină performanță
Hetzner este ieftin și de încredere în Europa, dacă ești în America de Nord, aruncă o privire la OVH. Mai ales alternativa lor economică numită SoYouStart. Puteți obține 4/8 4,5 GHz, 64 RAM și o unitate NVME pentru 65 USD
(Nu am nicio afiliere la OVH, sunt doar un client cu aproape 100 de servere si mi-a iesit de minune)
Voi remarca, de asemenea, că sunt bătrân hehe, și una dintre primele mele locuri de muncă am avut un centru de date de dimensiuni decente la fața locului. A face față cu SAN-uri, unități de bandă (rotatoarele de bandă automate la vremea aceea erau servere, etc. a fost o problemă uriașă. Împachetarea benzilor și expedierea lor la alt birou pentru redundanța locației a fost întotdeauna distractiv.
Aplicația pe care o gestionez suferă într-adevăr de un GHz scăzut și de a nu avea toate datele în memorie. Am rulat benchmark-urile pe EC2, anumite rapoarte care se termină în ~5 secunde pot dura mai mult de un minut pe o instanță EC2 comparabilă care costă de aproximativ 10 ori mai mult. Această aplicație are într-adevăr nevoie de CPU brut. și da, avem o echipă de inginerie destul de mare care a optimizat toate interogările, indicii etc
În ceea ce privește replicarea, backup-urile, etc. Am configurat toate astea și, sincer, nu a fost mare lucru. Sunt câteva capitole scurte din cartea Postgres care explică totul foarte simplu, cum se configurează, testul continuu (și automat) etc.
Sunt de acord că SAN sunt un coșmar. De aceea îmi trimit toate WAL-urile (fișierele de rezervă PG) către S3 (și eventual Glacier). În acest fel, nu trebuie să mă gândesc la pierderea acelor fișiere și este foarte ieftin
Cred că există o concepție greșită că aceste tipuri de configurații sunt prea complicate pentru a fi configurate de un singur inginer, fiind necesară întreținerea fără sfârșit. În realitate, puteți configura totul în mai puțin de o săptămână și are nevoie de întreținere doar atunci când doriți să faceți upgrade la Postgres (este posibil ca unele setări să se fi schimbat). Aș estima că durează aproximativ 5 ore pe an de întreținere
Infrastructura de autoservire pare să devină din ce în ce mai viabilă pe măsură ce continuăm să îmbunătățim livrarea pe ultimul kilometru și să extindem accesul la fibră. Va deveni norul autocanibalizant? Cu siguranță poate
Ceea ce vă oferă cloud-ul este abilitatea de a vă pune datele/sarcina de lucru chiar la bază, fără a fi nevoie să faceți oferte speciale cu furnizorul dvs. de furnizori local și cu mult mai multă rezistență decât v-ați permite, dacă nu vă aflați cel puțin la containerul multiplu de 20 de picioare plin. scara serverelor de nevoie de calcul
httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..
Edit: Dacă cineva este interesat de auto-găzduire, este simplu cu cloudflared. Am un Google Pixelbook din 2017 care rulează Ubuntu pe firmware personalizat care deservește un site web bazat pe Flask. Îmi încarc biroul în timp ce sunt conectat la o rețea wifi pentru oaspeți. Primește un scor 100/100 Mobile PageSpeed și durează 0,8 secunde pentru a se încărca complet
De la DO primesc toate beneficiile unei companii de încredere, scalabilitate, backup-uri automate etc etc. Nu am cum să mă schimb
Cloudul Hetzner are acum două locații în SUA. Totuși, nu există servere dedicate din SUA - acestea ar fi reale. Chiar dacă ofertele lor actuale de cloud reprezintă deja ~30% din prețul echivalentelor majore de cloud.
La fel ca tine, îmi rulez serviciile de pe un server fizic închiriat. Am folosit Versaweb, dar mașinile lor sunt prea vechi. Anterior nu mi-a plăcut Hetzner pentru că am auzit lucruri rele despre ele interferând cu ceea ce conduceți
Cu toate acestea, m-am mutat la ele în decembrie, când instanța mea Versaweb tocmai a murit, probabil SSD de la bătrânețe. Acum plătesc 50% din cât am plătit Versaweb și pot rula 6 astfel de instanțe Postgres
Apoi ne face să ne întrebăm dacă merită să plătiți 700 USD din 800 USD pentru un serviciu gestionat cu o interfață de utilizare în cloud elegantă, upgrade-uri și backup-uri automate etc.
Pentru o emisiune de 1 persoană sau un mic startup, cred că nu. Mai ieftin să folosești un serviciu disponibil și să arunci copii de rezervă în S3 sau ceva mai ieftin
Compania pentru care lucram pentru compania A, plătită fericit, de patru ori mai mult decât a taxat compania B pentru exact același serviciu, doar pentru că compania A era dispusă să trimită facturi trimestriale într-un mod care se potrivea bine cu sistemul nostru de facturare. Pentru companii, economisirea de câteva sute de dolari pe ici și pe colo nu merită adesea bătăile de cap de a introduce orice frecare suplimentară
Există un cost implicit acolo. Dacă este doar unul sau două dintre aceste lucruri, luați doar serviciile gestionate
Dacă începeți să scalați, obțineți un angajat de tip administrator care să economisească pe acest lucru
În caz contrar, ar trebui să angajez/contractez pe cineva cu foarte multă experiență sau să-mi dedic o lună solidă sau mai mult din timpul meu (care nu era disponibil), doar pentru a fi 100% sigur că putem restabili întotdeauna rapid backup-urile PITR jurnalizate
Pot economisi mult pe costurile cloud în alte locuri, dar PostgreSQL gestionat credibil a fost un apel destul de ușor (chiar dacă prețul de intrare a fost mai mare decât te-ai aștepta)
O pornire timpurie care nu își permite să piardă o oră de date de producție este probabil prea fragilă pentru a supraviețui oricum
Este o pornire timpurie - vor exista întreruperi mai mari decât atât ale serviciului și toți clienții care fug după o pierdere de o oră a datelor de producție pur și simplu nu au apreciat suficient produsul oricum.
(În pornirea specifică la care mă gândeam, aveam deja niște transferuri automate și frecvente DB-online la S3 cu reținerea impusă, dar nu credeam că este suficient de bun pentru acest scenariu special. Dar nefiind sigur că ne-am putea recupera cu PITR/journaling ar adăuga un nou punct unic de eșec, pariază pe succesul unei afaceri care altfel ar putea avea o ieșire de peste 9 cifre în câțiva/mai mulți ani, doar pentru a economisi câteva sute.)
De asemenea, presupun că unele dintre startup-urile timpurii care au nevoi mai puțin pretențioase, dar sunt cavalieri cu privire la obligațiile lor față de datele clienților/utilizatorilor, sunt încă neglijente față de practicile de bază minime.
Poate o modalitate intuitivă de a aprecia: Imaginați-vă o știre de afaceri despre HN, despre unele operațiuni de pornire, cu numele fondatorilor de startup atașate, iar povestea spune și se dovedește că nu au avut copii de rezervă bune. cofondatorii, care poate nu au dormit prea mult, deoarece compania lor se prăbușește în jurul lor, răspunde „Datele clienților nu sunt atât de importante într-o pornire timpurie; dacă ar fi, am fi prea fragili” (dactilografiat înainte ca cofondatorul să poată arunca laptopul acelei persoane). prin încăpere pentru a-i opri să tasteze). Nu ar fi un aspect bun
Voi aborda asta la final
>Imaginați-vă o știre de afaceri despre HN, despre unele operațiuni de pornire, cu numele fondatorilor de startup atașate, iar povestea spune și se dovedește că nu au avut copii de rezervă bune
ITYM și se dovedește că nu au făcut backup pentru ultima oră
Îmi pot imagina totul în scenariul dvs., chiar și biții nedecupați și totul pare normal, cu excepția cazului în care citiți „Clienții noștri startup, care ne folosesc de o lună, au plecat imediat când le-am pierdut ultima oră de date”
Chiar nu-mi pot imagina acel scenariu
Acum, desigur, există unele companii în care avantajul utilizării este că nu există nici măcar o oră de date pierdute.
IOW, clienții îl folosesc pentru că nu va pierde nicio dată: colaborarea documentelor online[1], de exemplu[2]. Dacă aveți o criză care pierde o oră din ultimele date introduse, atunci sigur, așteptați-vă ca toți utilizatorii actuali afectați să fugă imediat
[1] Deși, personal, aș atenua riscul duplicând documentul curent în localstorage în timp ce acesta este editat
[2] Poate că bursa de valori are nevoie și de sistem pentru a păstra ultima oră de date? Ce altceva?
Cred că chiar și pentru echipele mai mari poate avea sens să gestionezi singur bazele de date, presupunând că ai competența de a face acest lucru bine. Există atât de multe lucruri care pot merge prost cu serviciile gestionate și nu ascund implementarea subiacentă așa cum fac lucruri precum stocarea în bloc sau stocarea obiectelor.
Performanța maximă este cu siguranță mai proastă - dar nu sunt prea deranjat dacă ceva durează mai mult să ruleze oricum. Cu siguranță ai dreptate că ai cât mai multă automatizare în furnizarea unui server, lucru pe care nu l-am făcut cu un server fizic
Am avut un server rădăcină pentru proiectele mele de companie, dar sincer, asta nu are sens. Nu rulez un trafic mare, calculez SaaS intens pe mașinile mele. Este doar un site static și câteva proiecte. Sunt redus la costuri lunare de 24, care include o cutie de stocare de 1 TB pentru a stoca toate datele mele
Principala problemă în orice scenariu care implică hardware real este că aveți nevoie de personal care este competent atât în hardware, cât și în sistemele Linux/UNIX. Mulți pretind că sunt pe CV-urile lor și apoi nu pot performa o singură dată la locul de muncă (oricum, din experiența mea). În opinia mea, unul dintre motivele majore ale exploziei lumii cloud a fost tocmai dificultatea de a construi și costul financiar al construirii unor astfel de echipe. În plus, există o fricțiune oarecum naturală (și necesară) între dezvoltatorii de aplicații și oamenii de sisteme. Oamenii sistemelor ar trebui să se repingă mereu și să susțină mai multă securitate, mai multe procese și mai puține implementări. Echipa de dezvoltatori ar trebui să susțină mereu mai multă flexibilitate, mai multe versiuni și mai puțin proces. Un management bun ar trebui să atingă calea de mijloc între cele două. Din păcate, managerii incompetenți au decis adesea să scape de oamenii de sistem și să mute lucrurile în terenul AWS
În cele din urmă, aș reține doar că arhitectura cloud este dăunătoare pentru planetă, deoarece necesită supraprovizionare de către furnizorii de cloud și necesită mai multă putere a computerului în general datorită numeroaselor straturi de abstractizare. În timp ce oricine proiect este responsabil pentru puțin din aceste deșeuri, întregul cloud global ca agregat este foarte risipitor. Acest lucru mă deranjează și, evident, factori probabili ca o părtinire emoțională în părerile mele (atât de mari cantități de sare pentru toate cele de mai sus)
Ar putea fi argumentat că puteți dezvolta o modalitate de a închiria servere fizice înainte de venit, apoi, atunci când are sens, puteți fie să utilizați amortizarea standard -sau- Secțiunea 179 privind achizițiile directe și/sau contractele de închiriere din Secțiunea 179.
De exemplu, puteți implementa un grup incredibil de capabil de să spunem patru mașini fizice 1U de 100.000 USD absolut supraprovizionate în diferite facilități de culoare pentru redundanță. Există tot felul de trucuri aici pentru echilibrarea sarcinii și failover cu serviciul cloud XYZ, DNS, anycast, orice doriți. Puteți folosi diverse facilități colo care operează centre de date din întreaga lume, să le expediați hardware-ul de la furnizor, apoi să le furnizați cu Ansible sau orice vă place fără să vedeți instalația sau să atingeți hardware-ul.
Deci acum aveți hardware fizic redundant care va rula absolut cercuri în jurul majorității furnizorilor de cloud (în special pentru I/O), costuri fixe ca tot ceea ce puteți lățime de bandă (care nu are marcajul de 800% al serviciilor cloud etc) - nu mai așteptați pentru inevitabila factura cloud de 50.000 USD sau încercarea de a urmări (în panică) ceea ce v-a determinat să depășiți bugetul configurat pentru cloud într-o zi în loc de o lună. Oh, btw, nu vă blocați în API-urile proprietare prostești pentru a furniza și chiar pentru a utiliza alte servicii decât mașinile virtuale oferite de $BIGCLOUD
Dacă faceți orice ML, puteți să vă antrenați pe propriul hardware sau (sau pe cloud ocazional) și să rulați inferențe 24/7 cu lucruri precum NVIDIA A10. Închirierea continuă în cloud pentru instanțele GPU este incredibil de costisitoare, iar rentabilitatea investiției la achiziționarea hardware-ului este de obicei în intervalul de câteva luni (sau mult mai departe aproape imediat cu Secțiunea 179). De exemplu, recent am făcut un benchmark cu Nvidia A10 pentru un model pe care îl servim și poate face peste 700 de solicitări de inferență/s în FP32 cu o latență sub 10 ms. Cu un singur A10 pe șasiu în patru instanțe sănătoase, care este de 2800 req/s (și probabil ar putea fi reglat mai departe)
Apoi, dacă devii cu adevărat mare, poți începe să obții dulapuri și nu numai. În ceea ce privește defecțiunile hardware, așa cum am menționat, tot ce pot spune este o ieșire PS RAID dublă, etc., hardware-ul este (din experiența mea) extrem de fiabil. Având mai multe dulapuri complete de hardware în trecut, defecțiunile hardware au fost puține și îndepărtate și hardware-ul furnizorii vor include SLA-uri incredibile pentru înlocuire. Îi anunțați despre eșec, ei trimit o tehnologie< opt ore direct la instalația de colo și înlocuiți discul, PS, etc. cu lumina intermitentă
Experiența mea este o resursă FTE (bună) care poate gestiona cu ușurință acest lucru la o scară de cabinet multiple. În opinia dvs., problema actuală este că mulți dintre acești oameni au fost smuls de marii furnizori de cloud și înlocuiți (pe piață) cu resurse care pot naviga în ridicolul limită care utilizează zeci (dacă nu mai multe) produse/servicii de la $ BIGCLOUD
De asemenea, am descoperit că această configurație este de fapt MULT mai fiabilă decât majoritatea $BIGCLOUD. Nu vă mai întrebați ce se întâmplă cu o întrerupere $BIGCLOUD pe care nici măcar nu o vor recunoaște (și asupra căreia nu aveți absolut niciun control). Venind dintr-un mediu în telecomunicații și asistență medicală, este complet sălbatic pentru mine cum timpul de funcționare a devenit de fapt mult mai rău cu furnizorii de cloud. De obicei, le puteți spune clienților „oh, internetul are probleme astăzi”, deoarece probabil că vor vedea titluri despre asta, dar pentru multe aplicații acest lucru este total inacceptabil - și ar trebui să ne așteptăm la mai bine
[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
Dacă vreau să creez un nou proiect sau să încerc să găzduiesc ceva nou, durează câteva minute și am scripturile. Implementările sunt rapide, întreținerea este redusă și am mult mai mult pentru banii mei
Pentru oricine este interesat, aceasta este versiunea generală a ceea ce folosesc:
* Capabil să gestioneze totul
* Un pic de terraform pentru unele intrări DNS pe care le pot înlocui într-o zi
* rest pentru backup, din nou controlat de ansible
* tailscale pentru vpn (am niște pi care rulează acasă, nimic major, dar tailscale o face ușor și sigur)
* docker-compose pentru aproape orice altceva
Aplicația principală este Clojure, așa că rulez un JVM nativ. Baza de date este complet distribuită, RethinkDB, lucrând acum la trecerea la FoundationDB
Important este să nu gestionați nimic manual, de ex. tratați serverele fizice la fel ca orice alt server cloud. Nu ar trebui să conteze dacă este fizic sau virtualizat
Am văzut o mulțime de oameni mai puțin experimentați plătind în exces pentru hetzner și similare când ar fi funcționat un vps de 5-10 USD
Da, vă susțineți propriul hardware în acel moment. Nu, nu este o mare durere de cap
Cel mai mare cost suplimentar la acest lucru este închirierea mai multor adrese IPv4, pe care Hetzner le percepe generos pentru moment, deoarece sunt atât de puține disponibile.
Orice ați crea, va începe cu 0 utilizatori și o întreagă mașină reală este complet exagerată pentru acea încărcare 0 pe care o veți obține. Îți upgradezi VPS-ul într-o pereche de mașini reale, apoi într-un mic cluster închiriat și apoi într-un centru de date (dacă cineva nu îl subminează pe acesta). Toate acestea au facturi previzibile și performanță de top pentru prețul lor
Orice dețineți într-un colo va fi și mai mult pe lună. Când aveam conexiuni în care puteam plăti pentru un IP static, acesta era de obicei 5 USD/lună
Acum închiriez un server destul de scăzut, dar costă 30 USD/lună. Mult mai mult tot ce am nevoie, dar este frumos. Și nu au renunțat la suportul pentru sistemul meu de operare în timp ce au crescut prețurile pentru a îmbunătăți suportul sau ceva de genul. (Deși inițial aveam niște componente hardware care trebuiau schimbate)
după cum ați subliniat, bare metal este calea de urmat. Funcționează opusul cloudului - puțin mai multă muncă la început, dar mult mai puține cheltuieli la sfârșit
Mai multe informații httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..
Configurarea și gestionarea Postgres este o problemă. Ar fi bine să existe o modalitate mai simplă de a face totul bine
1. Forțează ca configurația să fie reproductibilă, deoarece mașinile virtuale se vor defecta
2. Puteți obține reduceri mari la AWS care reduc durerea
3. Celelalte lucruri la care aveți acces deasupra mașinilor virtuale, care sunt mai ieftine/mai rapide, odată ce lucrurile dvs. sunt deja în cloud
4. Mai ușor să aveți o configurație de sistem documentată (de exemplu, documente AWS) decât să instruiți oamenii/documentați ce lucruri speciale aveți în interior. Mai ales util în angajarea de oameni noi
5. Nu aveți nevoie de spațiu sau de alimentare redundantă/internet/etc în premesis. Doar suficient pentru a permite oamenilor să-și ruleze laptopurile
Am folosit un VPS înainte de asta, dar m-am oprit și am trecut la unul fizic pentru că era o ofertă mai bună și nu am întâlnit limite de CPU
Monitorizarea discului nu este însă prea grea. Pentru hard disk-uri, rulați smartctl o dată pe oră, alertați când sectoarele realocate sau în așteptare cresc rapid sau ating 100. Pentru SSD-uri, încrucișați degetele; din experiența mea cu câteva mii, tind să funcționeze grozav până când dispar din autobuz, pentru a nu mai fi văzute niciodată. Aveți un plan de recuperare a datelor care nu implică stocarea datelor pe același model de dispozitive cu putere foarte asemănătoare oră de pornire, erori de firmware corelate sunt reale
La urma urmei, Hetzner are un API pentru a comanda servere dedicate și un API pentru instalarea unui sistem de operare (sau pentru repornire pentru a salva și a afișa orice imagine doriți)
Bănuiesc că dacă aș investiga opțiuni comerciale aș avea „trunchiul” sortat la birou cu o soluție comercială ISP, IP static, hardware IT bun poate, dar din câte știu exact în acest moment dacă un client avea nevoie de găzduire eu'd merg întotdeauna direct la închirierea unui vps
Eram mai degrabă un dezvoltator junior la acea vreme, așa că poate că eram și, dar nu-mi lipsește deloc. În teorie, sunt de acord cu ceea ce spui, dar implementarea unui Dockerfile în ceva de genul Google Cloud Run este mult mai ușoară. Da, plătesc mai mult decât aș fi gestionat propriul meu VPS, dar cred că acest lucru este mai mult decât compensat de orele de dezvoltare salvate
- hardware-ul fizic are probleme, de ex. Eșecul ventilatorului ->VM-ul meu este migrat în direct la o altă gazdă, nu observ și nu-mi pasă
- hardware-ul fizic explodează ->VM-ul meu repornește pe o altă gazdă, s-ar putea să observ, dar nu-mi pasă
Planificarea dezastrelor este mult mai ușoară cu VM-urile (chiar și cu animalele de companie, nu cu vite)
Pentru un incepator, cei mai ieftini isi fac treaba
Sunt sigur că, pe măsură ce cloud computing evoluează, aceste oferte devin mai comune
Există un alt aspect al cloud computing-ului. Corporațiile mijlocii până la mari, consideră cloud computing ca procente cu o singură cifră în calculele lor de cost. Aceasta înseamnă că deciziile luate de manageri și echipe caută adesea fiabilitate și scalabilitate (pentru a fi puse în prezentările lor) mai degrabă decât „este configurația mea costisitoare sau ieftină”
Angajatorul meu a adoptat cloud-ul ca un joc de afaceri/financiar, nu unul religios. Adesea, aterizăm noi construcții în cloud și migrăm la un centru de date, dacă este cazul, mai târziu
Aplicațiile on-prem costă cu aproximativ 40% mai puțin. Aplicațiile care sunt mai rentabile în cloud rămân acolo
Cred că este cazul că AWS/GCP/Azure nu sunt oferte foarte competitive din punct de vedere al costurilor în Europa. Ceea ce nu văd este o dovadă în acest sens pentru SUA
pentru aceleași specificații, sigur. Cred că virtualele au sens la ambele capete - fie scalabilitatea dinamică pentru N mare este importantă, fie aveți nevoie de fapt doar de o mică parte dintr-o cutie fizică. Nici să plătiți 45/lună pentru ceva care rulează find pe 5/lună nu este rezonabil și vă oferă mai multă flexibilitate pentru a nu combina lucrurile doar pentru a vă folosi serverul
Păstrați copii de siguranță în orice caz. De preferință pe alt furnizor sau cel puțin într-o locație fizică diferită. Și, bineînțeles, testați-le
Și dacă gestionați un regim de backup bun și monitorizați oricum datele/aplicația, este monitorizarea unităților o dificultate suplimentară semnificativă?
--
[1] de fapt, dacă automatizați procesul de restaurare într-o altă locație, ceea ce fac pentru câțiva biți ai mei, atunci puteți doar să apăsați butonul respectiv și să actualizați DNS-ul când este finalizat și poate să alocați puțin mai mult RAM + nuclee (testul meu oglinzile sunt mai mici decât VM-urile live, deoarece nu trebuie să servească modele reale de utilizare)
Exact ceea ce fac pentru mine și clienții mei. Economisește tone de dosh
Chiar dacă am vrut să actualizez, este doar un caz de a trage cea mai recentă versiune în șablonul docker-compose și de a rula din nou manualul de joc ansible. Evident, dacă upgrade-ul necesită mai mult, așa să fie, dar nu este diferit de orice altă configurare în ceea ce privește lucrul
Probabil singurul lucru pe care trebuie să-l fac manual este să-mi testez backup-urile. Dar am un script pentru fiecare proiect care o face, așa că doar pornesc SSH, rulez one-liner-ul, verific rezultatul și este gata. Fac asta aproximativ o dată pe lună, dar primesc și e-mailuri dacă o copie de rezervă eșuează
Deci nu poate fi deloc timp. De obicei, este probabil 1-2 ore pe lună dacă primesc actualizări în mod semi-regulat. Dar asta se va scala cu cât mai multe lucruri pe care le găzduiești și le gestionezi
Cu alte cuvinte, singura diferență este de unde provine fișierul de inventar ansible. Fie este o listă statică de IP-uri, fie vine de la terraform
Dacă doriți RAM ECC, aceasta pare a fi 60/lună și, de asemenea, trece la un procesor cu 8 nuclee mai puternic
Indiferent, dacă vorbim despre un „mediu de producție complet și un mediu de punere în scenă/stand-by duplicat” (pentru a cita persoana căreia i-ai răspuns), atunci 60/lună * (2 sau 3) este încă foarte ieftin în comparație cu AWS-ul oricărui startup. factura pe care am vazut-o
Cazurile de utilizare variază, dar tind să fiu de acord că AWS/GCP/Azure nu este răspunsul la fiecare problemă
Pentru cineva care își poate potrivi aplicația pe un VPS de 4 USD, evident că va fi mai ieftin decât orice bare metal, dar cloud-ul crește foarte scump în multe cazuri. Nici bare metal nu este răspunsul la fiecare problemă, dar mulți oameni din industrie par să nu înțeleagă când poate fi răspunsul corect.
SERVERE PRIVATE VIRTUALE#120
