Le offerte virtualizzate hanno prestazioni significativamente peggiori (vedi i miei esperimenti del 2019: httpsjan.rychter.com/enblog/cloud-server-cpu-performance e costano di più. La differenza è che puoi "scalare su richiesta", cosa che ho trovato non necessaria, almeno nel mio caso. E se ho bisogno di scalare, posso ancora farlo, è solo che ottenere nuovi server richiede ore anziché secondi. Beh, non ho bisogno di scalare in secondi
Nel mio caso, la mia intera fattura mensile per l'intero ambiente di produzione e un ambiente di staging/standby duplicato è costante, semplice, prevedibile, molto bassa rispetto a quanto dovrei pagare ad AWS, e ho ancora molto margine di prestazione per
Una cosa da notare è che tratto i server fisici come se fossero virtuali: tutto è gestito tramite ansible e posso ricreare tutto da zero. In effetti, utilizzo un altro ambiente "devcloud"su Digital Ocean, e quello viene creato utilizzando terraform, prima di essere passato ad ansible che fa il resto della configurazione
Ho il sospetto che VendorOps e strumenti complessi come Kubernetes siano favoriti dai commercianti di complessità emersi negli ultimi dieci anni. Ha un bell'aspetto nel curriculum e dà ai leader tecnologici un falso senso di realizzazione
Nel frattempo Stackoverflow, che è probabilmente più importante della maggior parte delle startup, procede a ritmo sostenuto su macchine dedicate
1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..
Sembra che la tendenza in questo spazio sia quella di passare direttamente al livello più alto di astrazione. Tralasciare gli aspetti fondamentali e puntare agli strumenti, alle librerie e ai prodotti $buzzword
Ne vedete scorci in diverse forme. Uno sono i thread sui social media che chiedono cose come Quanto di X devo sapere per imparare Y Dove X è una tecnologia o un campo fondamentale, possibilmente molto stabile e Y è uno strumento del giorno o direttamente un prodotto o servizio
CORBA appartiene a questo. E forse anche il web semantico. Sicuramente XML!
XML è fantastico: se non ci credi, potresti essere interessato ai problemi dell'analisi di JSON: httpseriot.ch/projects/parsing_json.html
E non farmi iniziare con YAML..
Per me vale assolutamente la pena spendere di più per avere database gestiti, snapshot automatici, bilanciatori di carico ospitati, storage a blocchi plug and play, ecc.
Voglio preoccuparmi se il nostro prodotto è buono, non dei guasti hardware nel cuore della notte, dell'avvio di un nuovo server e del fatto che non funziona correttamente perché non c'erano incentivi a utilizzare la gestione della configurazione con un singolo dispositivo, con un unico compito in fuga causare OOM o disco pieno e rompere tutto invece che solo le attività VM, paura di riavviare una macchina che è rimasta attiva per 1000 giorni, ecc.
Per me, il fascino del cloud non è una mania della scalabilità FAANG quando non è richiesta, ma l'applicazione automatica di patch al sistema operativo, il bilanciamento automatico del carico, servizi NAT, registri centralizzati e analizzabili, servizi di database che non devo gestire, fuori dal comune aggiornamenti continui dei servizi, gestione di chiavi crittografiche e segreti e, naturalmente, archiviazione di oggetti. (Queste sono tutte le cose che usiamo nella nostra startup)
Direi che i server dedicati potrebbero essere molto validi/economici quando raggiungiamo una certa scala, invece del contrario. Per il momento, le spese del cloud valgono per la mia startup
Se stai eseguendo la configurazione del tuo ambiente come codice, alla fine non dovrebbe importare se il tuo target è un server dedicato, una macchina virtuale o una configurazione specifica del cloud configurata tramite un'API
Non importa quale, il punto è che ne hai uno che può costruirti una nuova scatola o riportare una scatola che si comporta male a uno stato buono semplicemente eseguendo un comando
Certo, l’attuale mucchio di Go(o) che lo guida può essere migliorato (e sta effettivamente migliorando)
Detto questo, la dura verità è che il tuo approccio è quello corretto, quasi tutte le aziende (startup!) costruiscono eccessivamente invece di concentrarsi sulla fornitura di valore, sull’identificazione della nicchia effettiva, ecc. (Sì, c’è anche il lato della domanda, poiché Le startup gonfiate dal denaro del capitale di rischio si sovraccaricano e vogliono dipendere da terze parti che possono assumersi il carico, scalare con loro, gli SLA e quant'altro devono essere pubblicizzati.)
Kubernetes è fantastico! Ogni volta che vedo un'azienda potenzialmente concorrente iniziare a utilizzare Kubernetes, mi sento immediatamente sollevato, perché so che non devo più preoccuparmi di loro. Stanno per scomparire in un mucchio di problemi tecnici irrisolvibili, cercando di risolvere problemi che non possono essere rintracciati in uno stack tecnologico di incredibile complessità e aggirando le limitazioni imposte da un sistema progettato per aziende con traffico due-tre volte più grande. Inoltre, il loro COGS sarà molto più alto del mio, il che significa che dovranno fissare un prezzo più alto per il loro prodotto, a meno che non stiano semplicemente bruciando denaro VC (nel qual caso sono un fuoco di paglia)
Roba buona ovunque
Ansible è imperativo, può funzionare verso uno stato statico e basta. Se incontra un problema, attiva la sua connessione SSH, grida tonnellate di errori Python e si arrende per sempre. Anche con il suo inventario è tutt'altro che dichiarativo
k8s è un insieme di cicli di controllo che cercano di progredire verso il loro stato dichiarato. Il fallimento non è un problema, ci riproverà. Controllerà costantemente il proprio stato, ha una bella API per segnalarlo e grazie a molti concetti reificati è più difficile avere strani scontri tra i componenti distribuiti. (Mentre l'integrazione di più playbook con Ansible non è banale.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
E anche se K8 mette troppa eredità, ci sono imminenti manifestazioni più sottili delle idee fondamentali. (Es. httpsgithub.com/aurae-runtime/aurae )
E ora stai suggerendo che le persone utilizzino un'implementazione non standard più semplice?
Quindi ovviamente puoi implementare una soluzione di complessità minima oppure puoi usare qualcosa "pronti all'uso"k8s è complesso e in parte è sicuramente non necessario per la tua situazione, ma è anche piuttosto generale, flessibile, ben supportato, ecc.
>stai suggerendo che le persone utilizzino un'implementazione non standard più semplice?
Quello che ho suggerito è che se il progetto/software k8 diventa troppo grande per fallire, le persone possono passare a un'alternativa. Fortunatamente i concetti e l'API di k8s sono open source, quindi possono essere implementati in altri progetti, e ho fornito un esempio del genere per illustrare che la scelta di k8s non è un vincolo del fornitore simile a Oracle
Sento sempre parlare di tutte le fantastiche cose che ottieni praticamente gratuitamente dai provider cloud. Quella roba è davvero così facile da configurare e utilizzare? Ogni volta che provavo a configurare il mio stack LAMP su un servizio cloud il processo era così confuso e spaventoso che alla fine ho rinunciato. Mi chiedo se devo solo spingere un po'di più e arriverò a Cloud Heaven
Essere in grado di dire "Voglio un MySQL in cluster qui con questo tipo di specifiche"è molto meglio (in termini di tempo) che farlo da soli. Anche gli aggiornamenti sono ben integrati nel sistema, quindi dico semplicemente "applica l'ultimo aggiornamento"anziché garantire manualmente che i failover/riavvii avvengano nell'ordine corretto
Quindi si paga per semplificare le cose, ma il guadagno derivante da tale semplificazione si manifesta solo con progetti più grandi. Se hai qualcosa in un singolo server che puoi riavviare mentre i tuoi utenti ricevono una pagina di errore, potrebbe non valerne la pena
Il cloud non è facile, ma cercare di ottenere l'efficienza energetica e di raffreddamento di una piccola sala server avvicinandosi ai livelli di efficienza di pubblicazione della maggior parte dei data center di grandi dimensioni è quasi impossibile, così come la connettività Internet di più fornitori
Con il cloud tutto questo scompare poiché è gestito da qualunque operatore di data center su cui è in esecuzione il cloud, ma ciò che la gente dimentica è che ciò vale anche per i servizi di colocation vecchio stile che spesso offrono un costo/valore migliore rispetto al cloud
E mentre è decisamente più difficile gestire cose come AWS o Azure perché sanguina molte astrazioni che i fornitori di vpc di piccole dimensioni ti nascondono o che non ottieni davvero con un singolo server domestico, non è difficile sulla scala di dover eseguire un paio di rack di server vmware con storage basato su SANCon le cose Cloud hai più configurazioni da fare perché si tratta di configurare server virtuali ecc.Invece di portare il PC in un box nella tua stanza devi "configurarlo"per renderlo disponibileI database DO hanno backup che puoi configurare a tuo piacimento, memorizzali su DO Spaces (come S3).La gestione degli utenti del DB è semplice.Ci sono anche server cache per RedisPuoi aggiungere un bilanciamento del carico e collegarlo ai tuoi vari server webPenso che ci abbia messo circa 30 minuti per configurare 2 server Web, un server DB, un server cache, un bilanciamento del carico, un server di archiviazione e collegarli tutti secondo necessità utilizzando alcuni semplici moduli.Non posso davvero batterloSe hai altre informazioni o opinioni, per favore condividiMolti articoli su Internet su rafforzando un server Linux, quelli che ho provato impiegano poco più di 30 minuti per seguire i passaggi, molto più a lungo se sto cercando di imparare e capire effettivamente cosa sta facendo ogni cosa, perché è importante, qual è la vulnerabilità sottostante è, e come potrei aver bisogno di personalizzare alcune impostazioni per il mio particolare caso d'usoSono sicuro che puoi trovare esempi di script di configurazione online (configurare aggiornamenti automatici, firewall, applicazioni, ecc. dovrebbe essere una questione di eseguire 'curl $URL'e poi 'chmod +x $FILE'e 'bash $FILE'.Non avevo bisogno della gestione della configurazione (uso il servizio di backup del mio provider che è importante credo)Qualcosa del genere: httpsraw.githubusercontent.com/potts99/Linux-Post-Install..(visto in httpswww.reddit.com/r/selfhosted /comments/f18xi2/ubuntu_d )Ovviamente lo stesso si può dire per le macchine virtuali di lunga durata, e questo può essere risolto con un team disciplinato, ma penso che sia generalmente più probabile in un ambiente con un singolo dedicato di lunga durata machineHetzner ha tutto questo tranne i database gestitihttpswww.hetzner.com/managed-serverI pacchetti di webhosting includono anche 1. .DB illimitati (MySQL e PostgreSQL)httpswww.hetzner.com/webhosting/dispone di backup automatico e failover?>Con il backup giornaliero prenotato o il backup incluso nel tipo di server, tutti i dati vengono sottoposti a backup quotidianamente e conservati per un massimo di 14 giorni.Il ripristino dei backup (Restore) è possibile tramite l'interfaccia di amministrazione di konsoleHMa ho l'impressione che i database sui server gestiti siano destinati all'uso da parte delle app in esecuzione su quel server, quindi non esiste davvero un concetto di failoverhttpswww.hetzner.com/legal/managed-server/Un singolo drive su un singolo server che si guasta non dovrebbe mai causare una produzione interruzioneMolti problemi di configurazione possono essere ricondotti a distribuzioni autonome.Quel file di font o JRE deve davvero essere installato sull'intero server o puoi raggrupparlo nella tua distribuzioneLe nostre distribuzioni utilizzano target on-premise e EC2.Lo script di distribuzione non è diverso, solo l'IP per l'host èOra, dirò se posso usare S3 per qualcosa che lo farò al 100%.Non esiste un'alternativa on-premise con lo stesso set di funzionalitàIl punto di DevOps è "Bestiame, non animali domestici". Metti una pallottola nel tuo server una volta alla settimana per trovare i tuoi punti di erroreMi piacerebbe se entrassi nel nostro Discord/Slack e sollevassi alcuni dei problemi che stavi riscontrando in modo che possiamo almeno rendere l'esperienza migliore per gli altri che usano Dokku.Sentiti libero di chiamarmi lassù (il mio nick è `savant`)Lasciami premettere che sono uno sviluppatore di applicazioni con solo una conoscenza pratica di Docker.Non sono super abile in infra e l'applicazione con cui ho lottato ha parametri di distribuzione peculiari: è un'app Python che in fase di compilazione analizza diversi concerti di crawl HTML statici per popolare un database Postgres che è statico dopo essere stato costruito.Un'app Web Flask viene quindi utilizzata per quel database.L'analisi HTML si evolve rapidamente e quindi i dati del DB popolato dovrebbero essere raggruppati come parte delle immagini dell'applicazioneIIRC, ho faticato con la strutturazione dei file Docker quando il DB non era t persistente ma invece solo un'altra parte transitoria dell'app, ma sembrava superabile.Il problema più grande sembrava essere come evitare di estrarre concerti di dati raramente modificati da S3 per ogni build quando idealmente sarebbe stato memorizzato nella cache, specialmente in un modo che si comportasse in modo sano su DigitalOcean e nel mio ambiente locale.Presumo che la corretta memorizzazione nella cache del livello dell'immagine Docker risolverebbe il problema, ma ho raggiunto abbastanza rapidamente la fine delle mie conoscenze e della mia pazienzaLa DX di Dokku sembra ottima per le persone che fanno cose normali .:)0. httpscoolify.io/Inoltre chi non vorrebbe giocare con il giocattolo più nuovo e più figo a spese di un altro?C'è sicuramente un argomento per spostare (alcune) cose fuori dal cloud più avanti nel viaggio quando la flessibilità (o la gestione del flusso/pivoting) diventa meno di un driver principale e la scala/costo inizia a dominareCerto, puoi far funzionare qualcosa su Hetzner, ma preparati a rispondere a molte più domandeD'accordo sul tuo ultimo punto di impresa chiedendo questo che ancora una volta è solo triste che questi affari "requisiti"dettano come progettare e ospitare il tuo software quando un altro modo potrebbe essere quello miglioreIl ripristino di emergenza è un problema molto reale.Ecco perché lo collaudo regolarmente.In uno scenario di terra bruciata, posso essere operativo su un sistema secondario (staging) o su un sistema cloud terraformato in meno di un'ora.Per la mia attività è sufficiente
Abbiamo attraversato un boom di crescita e, come tutti prima, significava che c'erano molte persone inesperte che ricevevano molti soldi e aspettative urgenti. È una ricetta per il culto del carico e il marketing di sfruttamento
Ma la crescita sta rallentando e il denaro sta diventando più costoso, quindi rallenta e inizia a reimparare le vecchie lezioni con nuove entusiasmanti variazioni. (Come qui: gestione del ridimensionamento bare metal e con contenitori e orchestrazione)
E l'intero ciclo si ripeterà nel prossimo boom. Questo è il nostro settore per ora
Un solido server dedicato è il 99% delle volte molto più utile di un VPS paralizzato su hardware condiviso, ma ovviamente ha un costo maggiore se non hai bisogno di tutte le risorse che forniscono
Sì, ma il desiderio di "fare quello che stanno facendo tutti i ragazzi fantastici adesso"è almeno altrettanto forte in coloro che normalmente verrebbero definiti "manager", rispetto ai "dipendenti"risultato A) l'enorme spesa per microservizi/cloud va storta, beh, almeno stavi seguendo le migliori pratiche, queste cose accadono, cosa puoi fare
risultato B) sei andato con un server Hetzner e qualcosa è andato storto, beh sei e avresti dovuto andare con i microservizi, divertiti a cercare un nuovo lavoro
Incoraggiando così i manager a scegliere microservizi/cloud. Potrebbe non essere la decisione giusta per l'azienda, ma è la decisione giusta per il manager, ed è il manager che prende la decisione
(Così come essere un consulente che desidera un'estensione e scrivere un software che funzioni, come ho scoperto nel modo più duro.)
C'è una disconnessione tra i fondatori e tutti gli altri
I fondatori credono che andranno a >10 volte ogni anno
La realtà è che hanno il 90% di probabilità di fallire
Il 90% delle volte, stai bene fallendo su qualunque cosa
Circa il 10% delle volte in cui hai successo stai ancora bene senza il cloud, almeno per diversi anni di successo, un sacco di tempo per cambiare se necessario
Ho solo una configurazione ansible e può funzionare sia per i server virtualizzati che per quelli fisici. Nessuna differenza. L'unica differenza è che i server virtualizzati devono essere configurati prima con terraform e quelli fisici devono essere ordinati prima e i loro IP inseriti in un file di configurazione (inventario)
Naturalmente, sto anche attento a evitare di diventare dipendente da molti altri servizi cloud. Ad esempio, utilizzo VpnCloud (httpsgithub.com/dswd/vpncloud) per la comunicazione tra i server. Come vantaggio collaterale, questo mi dà anche la flessibilità di passare a qualsiasi fornitore di infrastrutture in qualsiasi momento
Il mio punto principale era che mentre le offerte virtualizzate hanno i loro usi, c'è un (enorme) divario tra un VPS per hobby da $ 10 al mese e un'azienda con attività B2C in crescita esplosiva. La maggior parte delle nuove imprese in realtà cade in questa lacuna: non ti aspetti una crescita esponenziale da mazza da hockey in un SaaS B2B redditizio. È qui che dovresti mettere in discussione la solita scelta predefinita di "usa AWS". Ci tengo ai miei COGS e ai miei margini, quindi guardo questa scelta con molta attenzione
Non sei un'azienda di software, fondamentalmente produci e vendi Sprockets
Le opinioni qui sarebbero assumere un grande staff di ingegneria / IT per "acquistare e mantenere server"(PaaS è cattivo) e quindi probabilmente "scrivere un codice tu stesso"(SaaS è cattivo) o qualunque cosa sia attualmente popolare qui (l'ultimo thread qui era "Spingendo PHP su SFTP senza Git, e se ne hai bisogno di più"lol)
Ma credo che le aziende dovrebbero fare One Thing Well ed evitare di provare a competere (facendolo manualmente) per cose al di fuori della loro competenza principale. In questo caso, penserei sicuramente che Sprocket Masters non dovrebbe tentare di gestire il proprio hardware e dovrebbe affidarsi a un provider per gestire il ridimensionamento, la sicurezza, il tempo di attività, la conformità e tutti i piccoli dettagli. Penso anche che il loro software dovrebbe essere uno standard da palude con il minimo interno possibile. Non sono un negozio di software e dovrebbero scrivere il minor codice possibile
Realisticamente Widget Masters potrebbe gestire questi siti con uno staff piuttosto ridotto a meno che non decidano di fare tutto manualmente, nel qual caso probabilmente avrebbero bisogno di uno staff molto più grande
Tuttavia, ciò che vedo anche e ciò di cui penso parlasse il poster precedente sono aziende in cui la tecnologia è al centro del business, e lì spesso ha meno senso, e invece di risparmiare tempo sembra costare tempo. C'è un motivo per cui ci sono esperti AWS: non è banale. Anche i server "reali"non sono banali, ma nemmeno necessariamente più difficili dei servizi cloud
Ma quelle agenzie non vogliono nemmeno avere personale per la manutenzione dell'hardware fisico.
Ma Sprocket Masters deve ancora avere un costoso consulente cloud a pagamento semplicemente per rispondere alle emergenze
Se hai intenzione di avere qualcuno nello staff per affrontare i problemi del cloud, puoi anche noleggiare un server
Personalmente ho gestito server dedicati per la nostra attività in passato, ma man mano che ci siamo espansi e ridimensionati, è diventato molto più facile andare con i fornitori di servizi cloud per fornire rapidamente vari servizi anche se i costi sono aumentati. Per non parlare del fatto che è molto più facile dire a un potenziale cliente che usi "cloud come AWS"piuttosto che "Oh, affittiamo queste macchine in un data center gestito da qualche azienda"(che in realtà può essere migliore ma i clienti per lo più non lo capiranno) . Audit, Conformità e altri
Per molti anche molto meno. Gestisco un piccolo progetto secondario[1] che è diventato virale un paio di volte (30.000 visualizzazioni in 24 ore circa) ed è in esecuzione su un server web CPU single core e un Postgres gestito allo stesso modo su un singolo core CPU. Non è nemmeno stato vicino al pieno utilizzo
1: httpsaihelperbot.com/Posso passare alcuni di essi alle funzioni lambda?Oppure passare a ECS?Oppure passare a qualche altro servizio cloud del giorno?Forse.Ma il tempo che ho dedicato a scrivere questo commento equivale già a circa sei mesi di risparmio per un simile passaggio.Se è più difficile di "premi un pulsante, ricevi un servizio tradotto in modo affidabile al 100%", è difficile da giustificareIn parte ciò è dovuto anche al fatto che il cloud fornisce altre funzionalità servizi ora che consentono questo genere di cose.Non ho bisogno di eseguire un cluster Kafka per la messaggistica di base, sono tutti dotati di un bus di messaggi.Lo uso.Utilizzo le opzioni DB ospitate.Uso S3 o equivalente, ecc.Trovo che ciò che rimane difficilmente valga la pena di provare a incastrarmi in qualche altro paradigma quando pago dollari a una cifra al mese per eseguilo semplicemente su un'istanza EC2È assolutamente vero che non tutti o tutti i progetti possono farlo.Non sono vincolato a questo come obiettivo finale.Quando non funziona, intraprendo immediatamente l'azione di ridimensionamento appropriata.Non sto suggerendo di riprogettare qualcosa in base a questo.Sto solo dicendo che non è un'opzione da disprezzare.Ha molta flessibilità e la fatturazione è abbastanza coerente (o, per dirla in altro modo, il fatto che se all'improvviso ho 50 volte il traffico, il mio sistema inizia a bloccarsi e a scoppiettare notevolmente anziché semplicemente farmi pagare centinaia di dollari in più è una caratteristica per me piuttosto che un bug) e generalmente non ti sforzi di contorcerti in qualche paradigma che è conveniente per alcuni servizi cloud ma potrebbe non essere conveniente per teHai mai dovuto gestire uno di questi ambienti?Il fatto è che, se vuoi ottenere una scalabilità di base per più di una persona e un devop adeguato, allora devi eccedere di un fattore significativo (possibilmente annullando i tuoi risparmi)Inevitabilmente ti ritroverai con una soluzione su misura, il che significa che i nuovi entranti avranno più difficoltà ad acquisire la padronanza del sistema e le persone significative che lasciano l'azienda porteranno con sé la loro conoscenza approfondita della tua infrastruttura.Sei tornato agli animali domestici invece che ai bovini.Alcuni server sono speciali, dopo un po'l'automazione significa "un sacco di script di shell incollati qua e là"e un aggiornamento del sistema operativo significa che metà infra è KO per un po'oppure non si eseguono affatto aggiornamenti del sistema operativoE nel caso fortunato che tu abbia bisogno di espanderti potresti trovare spiacevoli sorpreseE non farmi mai iniziare dal punto di vista del networking.A meno che tu non noleggi l'intero rack e installi il tuo hardware di rete, ottieni quello che ottieni.Il che potrebbe essere molto scarso sia in termini di funzionalità che di prestazioni Supponendo che tu non stia facendo nulla di specialeSe vuoi un tempo di attività del 100,0000%, certo.Ma di solito non lo fai.Le aziende che desiderano questo tipo di tempo di attività normalmente hanno comunque dei team dedicatiE la scalabilità funziona bene anche su bare metal se si scala verticalmente: hai idea dell'importo di potenza e throughput che puoi ottenere da un singolo server?È preoccupante continuare a sentire parlare di "scala"quando chi parla intende "scala orizzontale"Se i tuoi requisiti sono "scala", allora la scala verticale ti porterà lontanoSe le tue esigenze sono "scalabilità orizzontale su richiesta", allora sicuramente i fornitori di servizi cloud ti aiuteranno.Ma pochi posti necessitano di questo tipo di scalabilitàNon sto dicendo che il tempo di attività del 100% su bare metal sia economico, sto dicendo che il tempo di attività del 100% spesso non è necessarioPerché il settore è pieno di persone che inseguono tendenze e parole chiave e per cui la cosa più importante è aggiungere quelle parole chiave ai CVIME che punta a la scalabilità è estremamente sbagliata per la maggior parte dei servizi/applicazioni/qualunque cosa.E di solito si paga così tanto per le soluzioni "scalabili", che poi è necessario ridimensionarle per compensareNe dubito davvero.L'unico tema che vedi in quasi tutti i sostenitori di AWS è un'elevata delusione su quali garanzie AWS ti offre effettivamente Si certo. Nessuno viene licenziato per aver acquistato da IBM Ebbene, se le grandi aziende avessero una qualche competenza decisionale, sarebbero imbattibili e sarebbe inutile lavorare su qualsiasi altra cosa. Quindi sì, è un bene pubblico Fonte: quasi trent'anni di op Finora non ho notato che se spendo di più per l’azienda vengo anche pagato di più ottenere l'affidabilità equivalente con i ferri da stiro è molto più costoso che noleggiare "due server dedicati": ora potresti stare bene con un server e una soluzione di backup, e questo è giusto. ma un sysad per creare tutto ciò, anche con un contratto breve per la configurazione iniziale e nessuna manutenzione, andrà ben oltre la differenza di prezzo del cloud, soprattutto se c'è un database nel mix e ti interessano quei dati Oggi, il cloud è simile: il time-to-market è più rapido poiché ci sono meno parti in movimento. Quando l’economia crolla e la crescita rallenta, i contatori entrano e fanno il loro dovere Succede ogni volta Ciò non fa altro che rendere AWS più ricco a livello di aziende e team cloud È banale effettuare e annullare il provisioning di un'istanza EC2 automaticamente, in pochi secondi, se la tua distribuzione deve essere aumentata o ridotta. Questo è ciò che lo rende fondamentalmente diverso da un server bare metal
Ora, non sto negando che potrebbe essere ancora più conveniente rispetto ad AWS fornire alcuni server dedicati in più rispetto a quelli necessari, ma quando si hanno carichi di lavoro davvero imprevedibili non è facile tenere il passo
se stai avviando e spegnendo le macchine virtuali per soddisfare la curva della domanda, c'è qualcosa di seriamente sbagliato nella tua architettura
Ti è mai venuto in mente, come mai StackOverflow utilizza ~ 8 server dedicati per servire il mondo intero e non ha bisogno di avviare e arrestare le macchine virtuali per soddisfare la domanda globale dei clienti?
--
Quando si pianifica l'infrastruttura di elaborazione, è importante tornare alle origini e non cadere nella propaganda del fornitore di servizi cloud
L'hai detto tu stesso. Non tutte le applicazioni devono servire il mondo intero, quindi la domanda sarà inferiore quando le persone vanno a dormire
Anche con le applicazioni globali esistono normative che richiedono di ospitare applicazioni e dati in regioni specifiche. Immagina un'applicazione utilizzata da clienti in Europa, Australia e Stati Uniti. Devono essere serviti dai data center regionali e un cluster rimarrà per lo più inattivo mentre l'altro è in esecuzione (a causa dei fusi orari). Con server dedicati sprecheresti il 60-70% delle tue risorse, mentre usando qualcosa come EC2/Fargate puoi ridimensionare fino quasi a 0 quando la tua regione è inattiva
C'è un metodo per la follia, qui si chiama "sviluppo guidato dalla sicurezza del lavoro"Perché è una minaccia per il loro lavoro
C'è un'intera banda di persone che ha le competenze tecniche per ospitare autonomamente o ospitare piccole istanze per la propria famiglia/amici/associazione/club di escursionismo. Questo piccolo margine in cui sei d'accordo a spendere un po'di più perché vuoi renderlo corretto, ma non puoi giustificare il pagamento di così tanto e passare il tempo a fare una dura manutenzione. Un piccolo VPS, con un Nextcloud condiviso o un piccolo sito Web, è tutto ciò che serve in molti casi
Per questo uso persino un piccolo Raspberry Pi 400 nella mia camera da letto
httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..
Ho ospitato personalmente le mie cose per quasi un decennio ormai. Nessuno ha provato a eseguire DDoS sulla mia configurazione, perché dovrebbero farlo? Quale beneficio ne trarrebbero? Sarei praticamente l'unica persona colpita, e una volta che smetteranno non ci vorrà molto per riprendersi
C'è poco o nessun incentivo per DDoS su una casella personale, figuriamoci da una ricerca su Internet
Stai drasticamente sopravvalutando le capacità di un adolescente
Il semplice ping dell'IP più e più volte non farà molto. Forse un attacco DoS a seconda di ciò che la rete di destinazione ha in termini di IPS, ma anche in questo caso è più probabile che infetteranno i loro computer con virus prima che abbiano la possibilità di attaccarti effettivamente
Personalmente ho ricevuto uno di quelli per in qualche modo off un imbroglione in GTA 5. Succede sicuramente e non è divertente
Modifica: sembra che questo potrebbe essere automatico. Questo è qualcosa di interessante che dovrei esaminare un po'. Probabilmente è solo una complessità extra per il mio piccolo server, ma ho in mente alcuni usi
Tecnicamente anche il mio homelab è su un IP pubblico statico - questo è stato più un esercizio su "potrei farlo"che su "effettivamente necessario", ma è comunque bello e sono molto felice
L'unico problema era che dovevo configurare Wireguard per mantenere attivo il tunnel, altrimenti a volte il VPS riceveva traffico in entrata e se il mio laboratorio non si era avvicinato per un po'(che, perché dovrebbe?) il tunnel sarebbe stato interrotto, e la connessione proxy lo farebbe. Per fortuna questa è una funzionalità integrata
Quindi, sembra che l'aggiunta di feed RSS/Atom su un sito di pagine jekyll o GitHub sia piuttosto semplice
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, ram 4gb, drive 1tb, 100mbit
Alcuni anni di uptime a questo punto
Se ininterrotto: potrebbe essere necessario un aggiornamento.
Gli aggiornamenti di sicurezza del kernel sono una cosa
Ho trovato Atoms insopportabilmente lento, anche con Linux. Ovviamente è sufficiente per servire siti Web e quant'altro, ma è sconcertante quanta potenza usano solo per non funzionare
Esattamente. Queste istanze VPS inferiori a $ 10 sono ottime per piccoli progetti in cui non si desidera stipulare lunghi contratti o occuparsi della gestione dei propri server
Se gestisci un'attività reale in cui i margini sono sottilissimi e hai tutto il tempo libero del mondo per gestire i problemi del server se (quando) si presentano, quei server dedicati da ~ $ 50 potrebbero essere interessanti da esplorare
Ma se gestisci un'attività reale, anche una bolletta AWS di $ 10.000 al mese è più economica che assumere un altro sviluppatore esperto per aiutarti a gestire i tuoi server dedicati
Questo è ciò che generalmente manca nelle discussioni sui costi del cloud in luoghi come HN: Sì, il cloud è costoso, ma assumere anche un singolo amministratore di sistema/sviluppatore aggiuntivo per aiutarti a gestire l'infrastruttura personalizzata è incredibilmente costoso e molto meno flessibile. Ecco perché spendere un ipotetico $ 5000 al mese su una soluzione ospitata nel cloud che potrebbe, in teoria, essere costruita su misura su un server da $ 50 al mese con un investimento di tempo sufficiente può essere comunque un ottimo affare. Gli ingegneri sono costosi e il tempo è limitato
Uhhh, scusami ma quanto stai pagando questo ragazzo DevOps? Questa sembra una prospettiva molto americana, anche nell'area della valle. In Europa, assumere un ragazzo sarebbe più economico
I costi del lavoro a pieno carico sono significativamente più alti di quello che porti a casa nella tua busta paga. In realtà è peggio in Europa. Dai un'occhiata a questi grafici: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Se paghi 1000 EUR a qualcuno nel Regno Unito, all'azienda costa un totale di 1245 EUR
Se paghi 1000 EUR a qualcuno in Romania, all'azienda costa 1747 EUR in totale
Quindi un costo di $ 120.000 a pieno carico potrebbe farti guadagnare solo $ 68.000 USD di stipendio per una persona devops dell'UE
Ma non puoi avere una sola persona devops. Ne servono almeno 2 se vuoi permettere a uno di loro di prendersi una pausa, andare in vacanza o andare in vacanza
Posso collegarti in circa 3 ore
AWS è molto conveniente per altri servizi (S3, SES, SQS, ecc.) ma le macchine virtuali non sono un buon affare. Ottieni meno RAM& CPU, con il sovraccarico della virtualizzazione, e paga molti più soldi
Soprattutto per Postgres se esegui alcuni test con pgbench puoi davvero vedere la penalità che paghi per la virtualizzazione
Forse l'abilità dell'amministratore di sistema di costruire la propria infrastruttura sta diventando un'arte perduta, altrimenti non riesco a spiegare perché le persone sono così innamorate di pagare 5 volte per prestazioni inferiori
Hetzner è economico e affidabile in Europa, se sei in Nord America dai un'occhiata a OVH. Soprattutto la loro alternativa economica chiamata SoYouStart. Puoi ottenere 4/8 da 4,5 GHz, 64 RAM e un'unità NVME per $ 65
(Non ho alcuna affiliazione con OVH, sono solo un cliente con quasi 100 server e per me ha funzionato benissimo)
Noterò anche che sono vecchio eheh e uno dei miei primi lavori avevamo un data center di discrete dimensioni in loco. Avere a che fare con SAN, unità nastro (rotatori automatici di nastri all'epoca, server mannari, ecc.) Era un'enorme PITA. Imballare i nastri e spedirli a un altro ufficio per la ridondanza della posizione era sempre divertente
La particolare applicazione che gestisco soffre davvero di bassi GHz e di non avere tutti i dati in memoria. Ho eseguito i benchmark su EC2, alcuni report che terminano in circa 5 secondi possono richiedere più di un minuto su un'istanza EC2 comparabile che costa circa 10 volte di più. Questa applicazione ha davvero bisogno della CPU grezza. e sì, abbiamo un team di ingegneri piuttosto ampio che ha ottimizzato tutte le query, gli indici, ecc
Per quanto riguarda la replica, i backup, ecc. Ho impostato tutto e onestamente non è stato un grosso problema. Sono un paio di brevi capitoli nel libro Postgres che spiegano tutto in modo molto semplice, come configurare, testare continuamente (e automaticamente), ecc.
Sono d'accordo sul fatto che i SAN siano un incubo. Ecco perché spedisco tutti i miei WAL (file di backup PG) a S3 (e infine a Glacier). In questo modo non devo pensare di perdere quei file ed è poco costoso
Penso che ci sia un'idea sbagliata secondo cui questo tipo di configurazioni sono troppo complicate per essere configurate da un singolo ingegnere, con la necessità di una manutenzione infinita. In realtà puoi configurare tutto in meno di una settimana e necessita di manutenzione solo quando desideri aggiornare Postgres (alcune impostazioni potrebbero essere cambiate). Stimerei che siano necessarie circa 5 ore all'anno di manutenzione
Sembra probabile che le infrastrutture self-service diventino sempre più praticabili man mano che continuiamo a migliorare la consegna dell’ultimo miglio e ad espandere l’accesso alla fibra. Il cloud diventerà auto-cannibalizzante? Senza dubbio forse
Ciò che il cloud ti offre è la capacità di mettere i tuoi dati/carico di lavoro al centro senza dover fare accordi speciali con il tuo ISP locale e con molta più resilienza di quella che probabilmente ti permetteresti a meno che tu non sia almeno pieno di più container da 20 piedi dei server, scala delle esigenze di elaborazione
httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..
Modifica: se qualcuno è interessato al self-hosting, è semplice con cloudflared. Ho un Google Pixelbook del 2017 con Ubuntu su firmware personalizzato che serve un sito Web basato su Flask. Si ricarica sulla mia scrivania mentre sono connesso a una rete Wi-Fi ospite. Riceve un punteggio Mobile PageSpeed 100/100 e impiega 0,8 secondi per caricarsi completamente
Da DO ottengo tutti i vantaggi di un'azienda affidabile, scalabilità, backup automatizzati, ecc. Ecc. Non cambierei in alcun modo
Il cloud di Hetzner ora ha due sedi negli Stati Uniti. Tuttavia, non ci sono ancora server dedicati negli Stati Uniti: quelli sarebbero davvero efficaci. Anche se le loro attuali offerte cloud sono già circa il 30% del prezzo dei principali equivalenti cloud.
Come te, anch'io gestisco i miei servizi da un server fisico noleggiato. Usavo Versaweb, ma le loro macchine sono troppo vecchie. In precedenza non mi piaceva Hetzner perché avevo sentito cose brutte sul fatto che interferissero con ciò che stai eseguendo
Tuttavia, mi sono trasferito da loro a dicembre quando la mia istanza Versaweb è appena morta, probabilmente SSD per vecchiaia. Ora sto pagando il 50% di quanto ho pagato a Versaweb e posso eseguire 6 istanze Postgres di questo tipo
Quindi viene da chiedersi se valga la pena pagare $ 700 su $ 800 per un servizio gestito con un'interfaccia utente cloud fantasiosa, aggiornamenti e backup automatici, ecc.
Per uno spettacolo individuale o una piccola startup, penso di no. È più economico utilizzare un servizio disponibile e scaricare i backup su S3 o qualcosa di più economico
L'azienda per cui lavoravo pagava felicemente la società A quattro volte quello che la società B addebitava per lo stesso identico servizio, solo perché la società A era disposta a inviare fatture trimestrali in un modo che si adattava bene al nostro sistema di fatturazione. Per le aziende, risparmiare qualche centinaio di dollari qua e là spesso non vale la pena di introdurre ulteriori attriti
C'è un costo implicito lì. Se sono solo una o due di queste cose, prendi semplicemente i servizi gestiti
Se inizi a crescere, chiedi a un dipendente di tipo amministratore di risparmiare su questo
In caso contrario, avrei dovuto assumere/assumere qualcuno molto esperto o dedicare un mese solido o più del mio tempo (che non era disponibile), solo per essere sicuro al 100% di poter sempre ripristinare rapidamente i backup PITR registrati
Posso risparmiare di grandezza sui costi del cloud in altri posti, ma PostgreSQL gestito in modo credibile è stata una chiamata abbastanza semplice (anche se il prezzo di base era più di quanto ti aspetteresti)
Una startup iniziale che non può permettersi di perdere un'ora di dati di produzione è probabilmente troppo fragile per sopravvivere comunque
È un avvio precoce: ci saranno interruzioni maggiori rispetto a quelle del servizio e tutti i clienti che fuggono dopo un'ora di perdita di dati di produzione non hanno comunque valutato abbastanza il prodotto
(Nell'avvio specifico a cui stavo pensando, avevo già dei bei dump DB-online automatizzati frequenti su S3 con la conservazione applicata, ma non pensavo che fosse abbastanza buono per questo particolare scenario. Ma non essendo sicuro che potremmo recuperare con PITR/journaling aggiungerebbe un nuovo singolo punto di errore scommettendo sul successo di un'azienda che altrimenti potrebbe avere un'uscita di oltre 9 cifre in pochi/diversi anni, solo per risparmiare qualche centinaio.)
Inoltre, suppongo che alcune delle prime startup che hanno esigenze meno impegnative, ma sono sprezzanti riguardo ai loro obblighi nei confronti dei dati dei clienti/utenti, siano ancora negligenti nei confronti delle pratiche di base minime
Forse un modo intuitivo per apprezzare: immagina una notizia di biz su HN, su alcune operazioni di avvio che lasciano cadere la palla, con i nomi dei fondatori di startup allegati, e la storia dice e si scopre che non avevano buoni backup Quindi uno dei cofondatori, che forse non hanno dormito molto perché la loro azienda si sta schiantando intorno a loro, risponde "I dati dei clienti non sono così importanti in una startup iniziale; se lo fossero, saremmo troppo fragili"(digitato prima che il cofondatore potesse lanciare il laptop di quella persona dall'altra parte della stanza per impedire loro di digitare). Non sarebbe un bell'aspetto
Ne parlerò alla fine
>Immagina una notizia biz su HN, su alcune operazioni di avvio che lasciano cadere la palla, con i nomi dei fondatori di startup allegati, e la storia dice e si scopre che non avevano buoni backup
ITYM e si scopre che non hanno eseguito il backup dell'ultima ora
Posso immaginare tutto nel tuo scenario, anche i bit non tagliati, e sembra tutto normale, a meno che tu non legga "I nostri clienti startup, che ci usano da un mese, se ne sono andati tutti immediatamente quando abbiamo perso l'ultima ora dei loro dati"Non riesco proprio a immaginare quello scenario
Ora, scontato, ci sono alcune aziende in cui il vantaggio di usarlo è che non c'è nemmeno un'ora di dati persi
IOW, i clienti lo usano perché non perderà alcun dato: la collaborazione di documenti online[1], per esempio[2]. Se hai un crollo che perde un'ora degli ultimi dati immessi, allora certo, aspettati che tutti gli attuali utenti interessati fuggano immediatamente
[1] Sebbene, personalmente, mitigherei il rischio duplicando il documento corrente in localstorage mentre viene modificato
[2] Forse anche la Borsa ha bisogno del sistema per conservare i dati dell'ultima ora? Cos'altro?
Penso che anche per i team più grandi possa avere senso gestire i database da soli, supponendo che tu abbia la competenza per farlo bene. Ci sono così tante cose che possono andare storte con i servizi gestiti e non nascondono l'implementazione sottostante come fanno cose come l'archiviazione a blocchi o l'archiviazione di oggetti
Le massime prestazioni sono certamente peggiori, ma non sono troppo preoccupato se qualcosa richiede più tempo per funzionare comunque. Hai sicuramente ragione sull'avere tanta automazione nel provisioning di un server, cosa che non ho fatto con un server fisico
Avevo un root server per i miei progetti preferiti, ma onestamente non ha senso. Non sto eseguendo un traffico elevato, calcolo SaaS intenso sulle mie macchine. È solo un sito web statico e alcuni progetti. Sono sceso a costi mensili di 24 che include una scatola di archiviazione di 1 TB per archiviare tutti i miei dati
Il problema principale in qualsiasi scenario che coinvolga hardware reale è che è necessario personale competente sia nell'hardware che nei sistemi Linux/UNIX. Molti affermano di essere nei loro curriculum e quindi non possono esibirsi una volta sul lavoro (secondo la mia esperienza comunque). A mio avviso, uno dei motivi principali dell'esplosione del mondo del cloud è stata proprio la difficoltà nella costruzione e il costo finanziario della creazione di tali team. Inoltre, c'è un attrito in qualche modo naturale (e necessario) tra gli sviluppatori di applicazioni e la gente dei sistemi. Gli addetti ai sistemi dovrebbero sempre respingere e discutere per una maggiore sicurezza, più processi e meno distribuzioni. Il team di sviluppo dovrebbe sempre discutere per una maggiore flessibilità, più rilasci e meno processi. Una buona gestione dovrebbe quindi trovare la via di mezzo tra i due. Sfortunatamente, i manager incompetenti hanno spesso deciso di sbarazzarsi degli addetti ai sistemi e spostare le cose nella terra di AWS
Infine, vorrei solo notare che l'architettura cloud è dannosa per il pianeta in quanto richiede un provisioning eccessivo da parte dei fornitori di servizi cloud e richiede una maggiore potenza del computer in generale a causa dei numerosi livelli di astrazione. Sebbene qualsiasi progetto sia responsabile di poco di questo spreco, l'intero cloud globale come aggregato è molto dispendioso. Questo mi infastidisce e ovviamente i probabili fattori come un pregiudizio emotivo nelle mie opinioni (così grandi quantità di sale per tutto quanto sopra)
Si potrebbe sostenere che è possibile sviluppare un mezzo per affittare i server fisici prima del reddito, quindi, quando ha senso, è possibile utilizzare l'ammortamento standard -o- la Sezione 179 sugli acquisti definitivi e/o i contratti di locazione della Sezione 179
Ad esempio, è possibile distribuire un gruppo incredibilmente capace di, diciamo, quattro macchine fisiche 1U da $ 100.000 con provisioning assolutamente eccessivo in diverse strutture colo per la ridondanza. Ci sono tutti i tipi di trucchi qui per il bilanciamento del carico e il failover con il servizio cloud XYZ, DNS, anycast, qualunque cosa tu voglia. Puoi rivolgerti a varie strutture colo che gestiscono data center in tutto il mondo, spedire loro l'hardware dal fornitore, quindi fornirli con Ansible o qualunque cosa ti interessi senza mai vedere la struttura o toccare l'hardware
Quindi ora disponi di hardware fisico ridondante che girerà in tondo attorno alla maggior parte dei provider cloud (soprattutto per I/O), costi fissi come la larghezza di banda all you can (che non ha il markup dell'800% dei servizi cloud, ecc.) - niente più attese per l'inevitabile fattura cloud di 50.000 dollari o per cercare di rintracciare (in preda al panico) cosa ti ha portato a superare il budget cloud configurato in un giorno anziché in un mese. Oh comunque, non ti stai rinchiudendo nelle sciocche API proprietarie per fornire e persino utilizzare servizi diversi dalle macchine virtuali offerte da $BIGCLOUD
Se stai facendo ML, puoi allenarti sul tuo hardware o (o sul cloud occasionale) ed eseguire l'inferenza 24 ore su 24, 7 giorni su 7 con cose come NVIDIA A10. Il noleggio continuo del cloud per le istanze GPU è incredibilmente costoso e il ROI sull'acquisto dell'hardware è in genere dell'ordine di pochi mesi (o quasi immediato con la Sezione 179). Ad esempio, di recente ho eseguito un benchmark con Nvidia A10 per un modello che stiamo servendo e può eseguire oltre 700 richieste di inferenza/s in FP32 con una latenza inferiore a 10 ms. Con un singolo A10 per chassis su quattro istanze integre si arriva a 2800 richieste/s (e probabilmente potrebbe essere ottimizzato ulteriormente)
Quindi, se diventi VERAMENTE grande, puoi iniziare a procurarti armadi e oltre. In termini di guasti hardware, come menzionato, tutto quello che posso dire è che l'hardware è dotato di doppia uscita RAID PS, ecc. L'hardware è (secondo la mia esperienza) estremamente affidabile. Avendo avuto più cabinet hardware completi in passato, i guasti hardware erano pochi e rari e l'hardware i fornitori includeranno incredibili SLA per la sostituzione. Li avvisi dell'errore e loro inviano un tecnico< otto ore direttamente all'impianto di colo e sostituire il disco, PS, ecc. con la luce lampeggiante
La mia esperienza è che una (buona) risorsa FTE può facilmente gestirla fino a più scale di armadi. Per il tuo punto, il problema attuale è che molte di queste persone sono state catturate dai grandi fornitori di cloud e sostituite (sul mercato) con risorse in grado di superare il ridicolo limite che utilizza dozzine (se non di più) prodotti/servizi da $ BIGLOUD
Ho anche scoperto che questa configurazione è in realtà MOLTO più affidabile della maggior parte dei $BIGCLOUD. Non dovrai più chiederti cosa sta succedendo con un'interruzione di $BIGCLOUD che non riconosceranno nemmeno (e su cui non hai assolutamente alcun controllo). Provenendo da un background nelle telecomunicazioni e nell'assistenza sanitaria, è completamente strano per me come il tempo di attività sia effettivamente peggiorato molto con i fornitori di servizi cloud. Di solito puoi semplicemente dire ai clienti "oh, Internet sta avendo problemi oggi"perché probabilmente vedranno titoli a riguardo, ma per molte applicazioni è assolutamente inaccettabile - e dovremmo aspettarci di meglio
[0] - https://www.section179.org/section_179_deduction/
[1] = https://www.section179.org/section_179_leases/
Se voglio avviare un nuovo progetto o provare a ospitare qualcosa di nuovo, ci vogliono un paio di minuti e ho gli script. Le distribuzioni sono veloci, la manutenzione è bassa e ho molto di più per i miei soldi
Per chiunque sia interessato, questo è il taglio approssimativo di ciò che sto usando:
* Ansible per gestire tutto
* Un po'di terraform per alcune voci DNS che potrei sostituire un giorno
* restistico per i backup, sempre controllato da ansible
* tailscale per vpn (ho alcuni pi in esecuzione a casa, niente di importante ma tailscale lo rende facile e sicuro)
* docker-compose praticamente per tutto il resto
L'app principale è Clojure, quindi eseguo una JVM nativa. Il database è completamente distribuito, RethinkDB, ora sta lavorando per passare a FoundationDB
L'importante è non gestire nulla manualmente, ad es. trattare i server fisici come qualsiasi altro server cloud. Non dovrebbe importare se è fisico o virtualizzato
Ho visto molte persone meno esperte pagare più del dovuto per hetzner e simili quando un vps da $ 5-10 avrebbe funzionato
Sì, a quel punto stai supportando il tuo hardware. No, non è un enorme mal di testa
Il più grande costo aggiuntivo per questo è l'affitto di più indirizzi IPv4, che Hetzner addebita profumatamente per ora che ce ne sono così pochi disponibili
Qualunque cosa tu crei, inizierà con 0 utenti e un'intera macchina reale è completamente eccessiva per quel carico 0 che otterrai. Aggiorni il tuo VPS in un paio di macchine reali, quindi in un piccolo cluster in affitto e poi in un data center (se qualcuno non lo taglia). Tutti hanno fatture prevedibili e prestazioni al top per il loro prezzo
Tutto ciò che possiedi in un colo sarà anche di più al mese. Quando avevo connessioni in cui potevo pagare per un IP statico, di solito era $ 5 al mese
Ora sto affittando un server di fascia piuttosto bassa, ma costa $ 30 al mese. Molto di più di tutto ciò di cui ho bisogno, ma è carino. E non hanno abbandonato il supporto per il mio sistema operativo aumentando i prezzi per migliorare il supporto o qualcosa del genere. (Anche se avevo un hardware inizialmente instabile che doveva essere scambiato)
come hai sottolineato, il bare metal è la strada da percorrere. Funziona l'opposto del cloud: un po'più di lavoro all'inizio ma molto meno spese alla fine
Maggiori informazioni httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..
Configurare e gestire Postgres è una seccatura. Sarebbe bello avere un modo più semplice per farlo bene
1. Impone la riproducibilità della configurazione, in quanto le VM si arrestano
2. Puoi ottenere forti sconti su AWS che riducono il dolore
3. Le altre cose a cui hai accesso in cima alle macchine virtuali che sono più economiche/più veloci una volta che le tue cose sono già nel cloud
4. È più facile avere una configurazione di sistema documentata (ad es. Documenti AWS) piuttosto che formare le persone/documentare le cose speciali che hai internamente. Particolarmente utile nell'assunzione di nuove persone
5. Non hai bisogno di spazio o alimentazione ridondante/internet/ecc. Quanto basta per consentire alle persone di eseguire i propri laptop
Ho usato un VPS prima, ma mi sono fermato e sono passato a uno fisico perché era un affare migliore e non ci siamo imbattuti nei limiti della CPU
Tuttavia, il monitoraggio del disco non è troppo difficile. Per i dischi rigidi, esegui smartctl una volta all'ora, avvisa quando i settori riallocati o in attesa crescono rapidamente o raggiungono 100. Per gli SSD, incrocia le dita; nella mia esperienza con poche migliaia, tendono a funzionare alla grande finché non scompaiono dall'autobus, per non essere più visti. Disporre di un piano di ripristino dei dati che non implichi l'archiviazione dei dati sullo stesso modello di dispositivi con orari di accensione molto simili Gli errori del firmware correlati all'accensione sono reali
Dopo tutto, Hetzner ha un'API per ordinare server dedicati e un'API per l'installazione di un sistema operativo (o per il riavvio per salvare e far lampeggiare qualsiasi immagine tu voglia)
Immagino che se stessi indagando su opzioni commerciali avrei smistato il "baule"in ufficio con una soluzione ISP commerciale, IP statico, forse un buon hardware IT, ma da quello che so in questo preciso momento se un cliente aveva bisogno di hosting io'Andavo sempre direttamente al noleggio di un vps
All'epoca ero più uno sviluppatore junior, quindi forse ero un ma non mi manca affatto. In teoria sono d'accordo con quello che stai dicendo, ma distribuire un Dockerfile a qualcosa come Google Cloud Run è molto più semplice. Sì, sto pagando più di quanto avrei gestito il mio VPS, ma penso che questo sia più che compensato dalle ore di sviluppo risparmiate
- l'hardware fisico ha problemi, ad es. guasto della ventola ->la mia VM viene migrata in tempo reale su un host diverso, non me ne accorgo né mi interessa
- l'hardware fisico esplode ->la mia VM si riavvia su un host diverso, potrei notarlo ma non mi interessa
La pianificazione dei disastri è molto più semplice con le VM (anche con animali domestici e non bovini)
Per un principiante, i più economici fanno il lavoro
Sono sicuro che con l'evolversi del cloud computing, queste offerte diventeranno più comuni
C'è un altro aspetto del cloud computing. Le aziende medio-grandi contano il cloud computing come percentuali a una cifra nei loro calcoli dei costi. Ciò significa che le decisioni prese da manager e team, spesso ricercano affidabilità e scalabilità (da mettere nelle loro presentazioni) piuttosto che "la mia configurazione è costosa o economica"Il mio datore di lavoro ha adottato il cloud come gioco commerciale/finanziario, non religioso. Spesso portiamo nuove build nel cloud e migriamo in un data center, se appropriato, in un secondo momento
Le app on-prem costano circa il 40% in meno. Le app che sono più convenienti nel cloud rimangono lì
Penso che AWS/GCP/Azure non siano offerte molto competitive in Europa. Quello che non vedo è la prova di ciò per gli Stati Uniti
per le stesse specifiche, certo. Penso che i virtuali abbiano senso da entrambe le parti: o la scalabilità dinamica per N grandi è importante, o in realtà hai solo bisogno di una piccola frazione di una scatola fisica. Anche pagare 45/mese per qualcosa che funziona find su 5/mese non è sensato e ti offre maggiore flessibilità per non mettere insieme le cose solo per usare il tuo server
Conserva i backup in ogni caso. Preferibilmente su un altro provider o almeno in un luogo fisico diverso. E, naturalmente, provali
E se stai gestendo un buon regime di backup e monitorando comunque i tuoi dati/app, il monitoraggio comporta un notevole disagio aggiuntivo?
--
[1] infatti se automatizzi il processo di ripristino in un'altra posizione, cosa che faccio per un paio dei miei bit, allora puoi semplicemente premere quel pulsante e aggiornare il DNS una volta completato, e magari allocare un po'più di RAM+core (il mio test i mirror sono più piccoli delle VM live in quanto non hanno bisogno di servire modelli di utilizzo reali)
Esattamente quello che faccio per me e per i miei clienti. Risparmia tonnellate di dosh
Anche se volessi aggiornare, si tratta solo di inserire l'ultima versione nel modello di composizione docker e di rieseguire il playbook ansible. Ovviamente se l'aggiornamento richiede di più, allora così sia, ma non è diverso da qualsiasi altra configurazione dal punto di vista del lavoro
Probabilmente l'unica cosa che _ho bisogno_ di fare manualmente è testare i miei backup. Ma ho uno script per ogni progetto che lo fa, quindi mi limito a SSH, eseguo l'one-liner, controllo il risultato ed è fatto. Lo faccio all'incirca una volta al mese, ma ricevo anche e-mail se un backup fallisce
Quindi non può essere affatto il tempo. Di solito sono probabilmente 1-2 ore al mese se prendo aggiornamenti su base semi-regolare. Ma ciò si ridimensionerà con più cose che ospiti e gestisci
In altre parole, l'unica differenza è la provenienza del file di inventario ansible. O è un elenco statico di IP o proviene da terraform
Se vuoi la RAM ECC, sembra essere 60 al mese, e passa anche a una CPU a 8 core più potente
Indipendentemente da ciò, se stiamo parlando di un "ambiente di produzione completo e di un duplicato dell'ambiente di staging/standby"(per citare la persona a cui hai risposto), allora 60/mese* (2 o 3) sono ancora poco costosi rispetto ad AWS di qualsiasi startup conto che ho visto
I casi d'uso variano, ma tendo a concordare sul fatto che AWS/GCP/Azure non è la risposta a tutti i problemi
Per qualcuno che può adattare la propria applicazione a un VPS da $ 4, ovviamente sarà più economico di qualsiasi cosa bare metal, ma in molti casi il cloud si ridimensiona in modo molto costoso. Anche il bare metal non è la risposta a tutti i problemi, ma molte persone nel settore non sembrano apprezzare quando può essere la risposta giusta.
VIRTUAL PRIVATE SERVERS#120
