Virtualiserade erbjudanden presterar betydligt sämre (se mina experiment 2019: httpsjan.rychter.com/enblog/cloud-server-cpu-performance och kostar mer. Skillnaden är att du kan "skala på efterfrågan", vilket jag inte tyckte var nödvändigt, åtminstone i mitt fall. Och om jag behöver skala kan jag fortfarande göra det, det är bara att få nya servrar tar timmar istället för sekunder. Tja, jag behöver inte skala på några sekunder
I mitt fall är hela min månatliga räkning för hela produktionsmiljön och en dubblerad iscensättning/standby-miljö konstant, enkel, förutsägbar, mycket låg jämfört med vad jag skulle behöva betala AWS, och jag har fortfarande mycket utrymme för prestanda för att
En sak som är värd att notera är att jag behandlar fysiska servrar precis som virtuella: allt hanteras genom ansible och jag kan återskapa allt från grunden. Faktum är att jag använder en annan "devcloud"-miljö på Digital Ocean, och den snurras upp med terraform, innan den skickas vidare till ansible som gör resten av installationen
Jag misstänker att VendorOps och komplexa verktyg som kubernetes gynnas av komplexitetshandlare som har uppstått under det senaste decenniet. Det ser bra ut på CV och ger tekniska ledare en falsk känsla av prestation
Samtidigt kör Stackoverflow, som utan tvekan är viktigare än de flesta nystartade företag, på dedikerade maskiner
1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..
Det verkar som att trenden i detta utrymme är att hoppa direkt till det högsta lagret av abstraktion. Hoppa över grunderna och peka på $buzzword-verktyg, bibliotek och produkter
Man ser glimtar av detta i olika former. Den ena är trådar i sociala medier som frågar saker som hur mycket av X behöver jag veta för att lära mig Y där X är en grundläggande, möjligen mycket stabil teknik eller ett område och Y är något verktyg du kan använda eller direkt en produkt eller tjänst
CORBA hör hemma där. Och kanske till och med den semantiska webbgrejen. Helt klart XML!
XML är bra - om du inte tror på det kan du vara intresserad av smärtan med att analysera JSON: httpseriot.ch/projects/parsing_json.html
Och kom inte igång med YAML..
Den inkrementella kostnaden för att vara på ett moln är helt värt det för mig att ha hanterade databaser, automatiska ögonblicksbilder, värdbaserade belastningsbalanserare, plug and play blocklagring etc.
Jag vill oroa mig för huruvida vår produkt är bra, inte om hårdvarufel mitt i natten, att snurra upp en ny server och att den inte fungerar som den ska eftersom det inte fanns något incitament att använda konfigurationshantering med en enda låda, ha en enda skenande uppgift orsaka OOM eller full disk och bryta allt istället för att bara göra VM, rädsla för att starta om en maskin som har varit uppe i 1000 dagar etc.
För mig är tjusningen med molnet inte någon FAANG-skalbarhetsmodefluga när det inte krävs, utan automatisk OS-patchning, automatisk lastbalansering, NAT-tjänster, centraliserade, analyserbara loggar, databastjänster som jag inte behöver hantera, ur rullande uppgraderingar av tjänster, hantering av kryptonycklar och hemligheter, och naturligtvis objektlagring. (Detta är alla saker vi använder i vår start)
Jag skulle gå hårt och säga att dedikerade servrar kan vara mycket lönsamma/kostnadseffektiva när vi når en viss skala, istället för tvärtom. För tillfället är molnkostnaderna värda det för min start
Om du gör din miljökonfiguration som kod borde det i slutändan inte spela någon roll om ditt mål är en dedikerad server, en vm eller någon molnspecifik inställning konfigurerad via en api
Spelar egentligen ingen roll vilken, poängen är att du har en som kan bygga en ny låda till dig eller föra tillbaka en låda som inte beter sig genom att helt enkelt köra ett kommando
Visst, själva högen med Go(o) som driver den kan förbättras (och den förbättras verkligen)
Som sagt, den svåra sanningen är att ditt tillvägagångssätt är det korrekta, nästan alla företag (startups!) överbygger istället för att fokusera på att ge värde, identifiera den faktiska nischen, etc. (Ja, det finns också efterfrågesidan av detta, eftersom VC-pengar uppblåsta startups överbygger de vill vara beroende av tredje part som kan ta belastningen, skala med dem, SLA:er och annat måste annonseras.)
Kubernetes är fantastiskt! När jag ser ett potentiellt konkurrerande företag börja använda Kubernetes blir jag omedelbart lättad, eftersom jag vet att jag inte behöver oroa mig för dem längre. De är på väg att försvinna i en hög med olösliga tekniska problem, försöker fixa problem som inte kan spåras ner i en teknisk hög av otrolig komplexitet och arbetar kring begränsningar som införs av ett system designat för företag med trafik som är två till tre av storleksordningen större. Deras COGS kommer också att vara mycket högre än min, vilket betyder att de kommer att behöva prissätta sin produkt högre, såvida de inte bara bränner genom VC-pengar (i vilket fall de är en blixt i pannan)
Bra grejer runt om
Ansible är absolut nödvändigt, det kan arbeta mot ett statiskt tillstånd, och det är allt. Om den stöter på ett problem slänger den upp sin SSH-anslutning och gråter massor av python-fel och ger upp för alltid. Även med sitt lager är det långt ifrån deklarativt
k8s är en av kontrollslingor som försöker göra framsteg mot sitt deklarerade tillstånd. Ett misslyckande är inget problem, det kommer att försöka igen. Det kommer ständigt att kontrollera sitt eget tillstånd, det har ett trevligt API för att rapportera det, och tack vare många reifierade koncept är det svårare att ha konstiga sammandrabbningar mellan distribuerade komponenter. (Medan det inte är trivialt att integrera flera spelböcker med Ansible.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
Och även om k8s tar på sig för mycket arv, finns det kommande smalare manifestationer av kärnidéerna. (T.ex. httpsgithub.com/aurae-runtime/aurae )
Och nu föreslår du att folk använder en enklare icke-standardimplementering?
Så självklart kan du implementera en lösning med minimal komplexitet eller så kan du använda något "från hyllan"k8s är komplexitet och en del av det är definitivt onödigt för din situation, men det är också ganska allmänt, flexibelt, väl underbyggt, etc.
>föreslår du att folk använder en enklare icke-standardimplementering?
Vad jag föreslog är att om k8s projektet/mjukvaran blir för stor för att misslyckas, så kan folk byta till ett alternativ. Lyckligtvis är k8s-koncepten och API:er öppen källkod, så de kan implementeras i andra projekt, och jag gav ett sådant exempel för att illustrera att att välja k8s inte är en Oracle-liknande leverantörslåsning
Jag hör alltid om alla fantastiska saker du får praktiskt taget gratis från molnleverantörer. Är det verkligen så lätt att installera och använda? Varje gång jag försökte ställa in min LAMP-stack på en molntjänst var det en så förvirrande och skrämmande process att det slutade med att jag gav upp. Jag undrar om jag bara behöver pressa lite hårdare så kommer jag till Cloud Heaven
Att kunna säga "Jag vill ha en klustrad MySQL här med den här typen av specifikationer"är mycket bättre (tidsmässigt) än att göra det på egen hand. Uppdateringarna är också snyggt inpackade i systemet, så jag säger bara "applicera den senaste uppdateringen"istället för att manuellt se till att felövergångar/omstarter sker i rätt ordning
Du betalar alltså för att förenkla saker och ting, men vinsten från den förenklingen slår in bara vid större projekt. Om du har något på en enda server som du kan starta om medan dina användare får en felsida kanske det inte är värt det
Molnet är inte lätt att försöka få kylning och energieffektivitet i ett litet serverrum i närheten av effektivitetsnivåerna som de flesta stora datacenterpublicerar är näst intill omöjligt, liksom internetanslutning från flera leverantörer
Med molnet försvinner allt sådant eftersom det hanteras av vilken datacenteroperatör som molnet än körs på, men vad folk glömmer är att det också är sant för gammaldags samlokaliseringstjänster som ofta erbjuder en bättre kostnad/värde än molnet
Och även om det definitivt är svårare att hantera saker som AWS eller Azure eftersom det blöder ut många abstraktioner som småskaliga vpc-leverantörer gömmer för dig eller som du inte riktigt får med en enda hemmaserver, är det inte svårt på skalan att behöva köra ett par av rack värda vmware-servrar med SAN-baserad lagringMed Cloud-grejer har du mer att konfigurera eftersom det handlar om att konfigurera virtuella servrar etc.Istället för att bära datorn i en box till ditt rum måste du "konfigurera den"för att göra den tillgängligDO-databaser har säkerhetskopior som du kan konfigurera efter eget tycke, lagra dem på DO Spaces (som S3).DB-användarhantering är lätt.Det finns också cacheservrar för RedisDu kan lägga till en lastbalanserare och ansluta den till dina olika webbservrarJag tror det tog mig ca 30 min för att ställa in 2x webbservrar, en DB-server, cacheserver, lastbalanserare, en lagringsserver och ansluta dem alla efter behov med några enkla formulär.Kan inte riktigt slå detOm du har mer information eller åsikter, dela gärnaMassor av artiklar på internet om härda en Linux-server, de jag har provat tar lite mer än 30 minuter att följa stegen, mycket längre tid om jag verkligen försöker lära mig och förstå vad varje sak gör, varför det är viktigt, vad den underliggande sårbarheten är, och hur jag kan behöva anpassa vissa inställningar för mitt specifika användningsfallJag är säker på att du kan hitta exempel på installationsskript online (konfigurera automatiska uppdateringar, brandvägg, applikationer etc bör vara en fråga att köra 'curl $URL'och sedan 'chmod +x $FILE'och 'bash $FILE'.Jag behövde ingen konfigurationshantering (jag använder min leverantörs säkerhetskopieringstjänst vilket är viktigt antar jag)Något i stil med detta: httpsraw.githubusercontent.com/potts99/Linux-Post-Install..(visas i httpswww.reddit.com/r/selfhosted /comments/f18xi2/ubuntu_d )Uppenbarligen kan samma sak sägas om långkörande virtuella datorer, och detta kan lösas genom att ha ett disciplinerat team, men jag tror att det generellt är mer troligt i en miljö med en enda långkörande dedikerad maskinHetzner har allt detta förutom hanterade databaserhttpswww.hetzner.com/managed-serverWebbhotellpaketen inkluderar även 1. .unlimited DBs (MySQL och PostgreSQL)httpswww.hetzner.com/webhosting/har den automatisk säkerhetskopiering och misslyckas?>Med bokad daglig backup eller backupen som ingår i typen av server, säkerhetskopieras all data dagligen och sparas i maximalt 14 dagar.Återställning av säkerhetskopior (återställning) är möjlig via konsoleHs administrationsgränssnittMen jag får intrycket att databaserna på hanterade servrar är avsedda att användas av appar som körs på den servern, så det finns inte riktigt ett koncept av failoverhttpswww.hetzner.com/legal/managed-server/En enda enhet på en enda server som misslyckas bör aldrig orsaka en produktion avbrottMånga konfigurationsproblem kan spåras till fristående distributioner.Behöver den typsnittsfilen eller JRE verkligen installeras på hela servern eller kan du kombinera den i din distributionVåra distributioner använder lokala och EC2-mål.Implementeringsskriptet är inte annorlunda, bara IP:n för värden ärNu ska jag säga om jag kan använda S3 för något som jag till 100 % kommer att göra.Det finns inte ett lokalt alternativ för det med samma funktionsuppsättningPoängen med DevOps är "Cattle, not pets."Sätt en kula i din server en gång i veckan för att hitta dina felpoängJag skulle älska om du hoppade in i vår Discord/Slack och tog upp några av problemen du såg så att vi kan kl. åtminstone göra upplevelsen bättre för andra som använder Dokku.Känn dig fri att slå mig där uppe (mitt nick är `savant`)Låt mig inleda och säga att jag är en applikationsutvecklare med bara en praktisk kunskap om Docker.Jag är inte superskicklig på infra och applikationen jag kämpade med har speciella installationsparametrar: Det är en Python-app som vid byggtid analyserar flera spelningar av statiska HTML-genomsökningar för att fylla en Postgres-databas som är statisk efter att ha byggts.En Flask-webbapp fungerar sedan mot den databasen.HTML-tolkningen utvecklas snabbt och därför bör den ifyllda DB-datan paketeras som en del av applikationsavbildningarnaIIRC, jag kämpade med struktureringen Dockerfiler när DB inte var beständig utan istället bara en annan övergående del av appen, men det verkade överkomma.Den större frågan verkade vara hur man undviker att dra spelningar med sällan ändrade data från S3 för varje byggnad när den helst skulle cachelagras, särskilt på ett sätt som uppförde sig sunt i DigitalOcean och min lokala miljö.Jag antar att rätt cachning av Docker-bildlager skulle lösa problemet, men jag nådde ganska snabbt slutet av min kunskap och mitt tålamodDokkus DX verkar bra för människor som gör vanliga saker.:)0. httpscoolify.io/Plus vem vill inte leka med den nyaste, coolaste leksaken på en annans krona?Det finns definitivt ett argument för att flytta (vissa) saker från molnet senare under resan när flexibilitet (eller att hantera flöde/svängning) blir mindre av en primär drivkraft och skala/kostnad börjar domineraVisst, du kan få något att fungera på Hetzner men var beredd att svara på många fler frågorKom överens om ditt sista företagsfråga om detta, vilket återigen bara är tråkigt att dessa affärs-"krav"dikterar hur man skapar och är värd för din programvara när ett annat sätt kan vara det mycket bättreÅterställning efter katastrof är ett mycket verkligt problem.Det är därför jag testar det regelbundet.I ett bränd jord-scenario kan jag vara igång på ett sekundärt (staging) system eller ett terraformat molnsystem på mindre än en timme.För min verksamhet räcker det med
Vi gick igenom en tillväxtboom, och som alla tidigare innebar det att det fanns massor av oerfarna människor som fick massor av pengar och brådskande förväntningar. Det är ett recept för lastkultning och exploaterande marknadsföring
Men tillväxten avtar och pengarna blir dyrare, så sakta ner och börja lära dig de gamla lärdomarna igen med nya spännande varianter. (Gilla här: hantera skalning av bar metall och med containrar och orkestrering)
Och hela cykeln kommer att upprepas i nästa boom. Det är vår bransch för nu
En solid dedikerad server är 99% av tiden mycket mer användbar än en förlamad VPS på delad hårdvara, men det kommer uppenbarligen till en ökad kostnad om du inte behöver alla resurser de tillhandahåller
Ja - men längtan efter att "göra vad alla coola barn gör nu"är minst lika starka hos dem som normalt skulle kallas "chefer", jämfört med "anställda"resultat A) enorma mikrotjänster/molnutgifter går fel, ja åtminstone följde du bästa praxis, dessa saker händer, vad kan du göra
resultat B) du gick med en Hetzner-server och något gick fel, ja du är och borde ha gått med mikrotjänster, njut av att leta efter ett nytt jobb
På så sätt uppmuntrar chefer att välja mikrotjänster/moln. Det kanske inte är rätt beslut för företaget, men det är rätt beslut för chefen, och det är chefen som fattar beslutet
(Precis som att vara konsult som vill ha en förlängning och skriva programvara som fungerar, som jag fick reda på den hårda vägen.)
Det finns en koppling mellan grundare och alla andra
Grundare tror att de kommer att bli >10x varje år
Verkligheten är att de är 90% sannolikt att misslyckas
90 % av gångerna - det går bra att misslyckas med vad som helst
Några % av de 10 % av gångerna du lyckas klarar du dig fortfarande utan molnet - åtminstone under flera års framgång, gott om tid att byta om det skulle behövas
Jag har bara en möjlig inställning, och den kan fungera både för virtualiserade servrar och fysiska. Ingen skillnad. Den enda skillnaden är att virtualiserade servrar måste ställas in med terraform först, och fysiska måste beställas först och deras IP-adresser matas in i en konfigurationsfil (inventering)
Självklart är jag också noga med att undvika att bli beroende av många andra molntjänster. Till exempel använder jag VpnCloud (httpsgithub.com/dswd/vpncloud) för kommunikation mellan servrarna. Som en sidofördel ger detta mig också flexibiliteten att när som helst byta till vilken infrastrukturleverantör som helst
Min huvudsakliga poäng var att även om virtualiserade erbjudanden har sina användningsområden, finns det ett (stort) gap mellan en hobby-VPS på $10/månad och ett företag med exploderande B2C-verksamhet. De flesta nya företag hamnar faktiskt i det gapet: du förväntar dig inte exponentiell tillväxt av hockeyklubbor i en lönsam B2B SaaS. Det är där du bör ifrågasätta det vanliga standardvalet "använd AWS". Jag bryr mig om mina COGS och mina marginaler, så jag tittar på detta val mycket noggrant
Du är inte ett mjukvaruföretag, i grunden tillverkar och säljer du Sprockets
Åsikterna här skulle vara att anställa en stor eng/IT-personal för att "köpa och underhålla servrar"(PaaS är dåligt) och sedan troligen "skriva en kod själv"(SaaS är dåligt) eller vad som nu är populärt här (förra tråden här var det "Om du trycker PHP över SFTP utan Git, och du behöver mer"lol)
Men jag tror att företag bör göra en sak bra och undvika att försöka konkurrera (göra det manuellt) om saker som ligger utanför deras kärnkompetens. I det här fallet skulle jag definitivt tycka att Sprocket Masters inte borde försöka hantera sin egen hårdvara och bör förlita sig på en leverantör för att hantera skalning, säkerhet, drifttid, efterlevnad och alla små detaljer. Jag tycker också att deras mjukvara ska vara myrstandard med så lite internt som möjligt. De är inte en mjukvarubutik och borde skriva så lite kod som möjligt
Realistiskt sett kunde Widget Masters köra dessa webbplatser med en ganska liten personal om de inte bestämde sig för att göra allt manuellt, i vilket fall de förmodligen skulle behöva mycket större personal
Men vad jag också ser och vad jag tror att den förra affischen talade om är företag där tekniken är kärnan i verksamheten, och där är det ofta mindre vettigt, och istället för att spara tid verkar det kosta tid. Det finns en anledning till att det finns AWS-experter: det är inte trivialt. "Äkta"servrar är inte heller triviala, men inte heller nödvändigtvis svårare än molntjänster
Men dessa byråer vill inte heller behöva personal för att underhålla fysisk hårdvara.
Men Sprocket Masters måste fortfarande ha en dyr molnkonsult på hållaren helt enkelt för att svara på nödsituationer
Om du ska ha någon i personalen för att ta itu med molnproblemen kan du lika gärna hyra en server istället
Jag personligen har kört dedikerade servrar för vår verksamhet tidigare men när vi expanderade och skalade blev det mycket lättare att gå med molnleverantörerna för att tillhandahålla olika tjänster snabbt även om kostnaderna gick upp. För att inte tala om att det är mycket lättare att berätta för en potentiell kund att du använder "moln som AWS"än "Åh, vi hyr dessa maskiner i ett datacenter som drivs av något företag"(vilket faktiskt kan vara bättre men kunderna kommer oftast inte att få det) . Revision, efterlevnad och andra
För många till och med mycket mindre än så. Jag kör ett litet sidoprojekt[1] som blev viralt några gånger (30K visningar på 24 timmar eller så) och det körs på en CPU-webbserver med en enda kärna och en hanterad Postgres likaså på en enda CPU-kärna. Det har inte ens varit i närheten av fullt utnyttjande
1: httpsaihelperbot.com/Kan jag byta några av dem till lambda-funktioner?Eller byta till ECS?Eller byta till någon annan molntjänst du jour?Kanske.Men den tid jag ägnade åt att skriva den här kommentaren är redan ungefär sex månaders besparingar för en sådan byte.Om det är svårare än "tryckknapp, få 100 % tillförlitligt översatt tjänst", är det svårt att motiveraEn del av detta beror också på att molnet tillhandahåller något annat tjänster nu som möjliggör sånt här.Jag behöver inte köra ett Kafka-kluster för grundläggande meddelandehantering, de kommer alla med en meddelandebuss.Jag använder det.Jag använder de värdbaserade DB-alternativen.Jag använder S3 eller motsvarande, etc.Jag tycker att det som blir över knappast är värt besväret med att försöka hamna i något annat paradigm när jag betalar ensiffriga dollar i månaden för att kör bara på en EC2-instansDet är absolut så att inte alla eller alla projekt kan göra detta.Jag har inte fastnat för detta som ett slutmål.När det inte fungerar vidtar jag omedelbart lämpliga skalningsåtgärder.Jag föreslår inte att du ska bygga om något baserat på detta.Jag säger bara att det inte är ett alternativ att bli föraktad.Det har mycket flexibilitet i det, och faktureringen är ganska konsekvent (eller, för att uttrycka det på ett annat sätt, det faktum att om jag plötsligt har 50x trafiken börjar mitt system kvävas och sprattla märkbart istället för att bara att debitera mig hundratals dollar mer är en funktion för mig snarare än en bugg), och du sträcker dig i allmänhet inte för att förvränga dig till något paradigm som är bekvämt för vissa molntjänster men kanske inte är bekvämt för digHar du någonsin behövt hantera en av dessa miljöer?Saken är den att om du vill få lite grundläggande skalbarhet för mer än en person och korrekt devops måste du överprovisionera av en betydande faktor (möjligen ogiltigförklara dina besparingar)Du kommer oundvikligen att få en skräddarsydd lösning, vilket innebär att nya medarbetare kommer att ha svårare att behärska systemet och betydande personer som lämnar företaget kommer att ta med sig sin intima kunskap om din infrastruktur.Du är tillbaka till husdjur istället för boskap.Vissa servrar är speciella, efter ett tag betyder automatisering "många limskalskript här och där"och en OS-uppgradering betyder att antingen halva infra är KO ett tag eller så gör du inte OS-uppgraderingar allsOch i det lyckliga fallet behöver du skala upp Du kan hitta obehagliga överraskningarOch få mig aldrig igång på nätverkssidan.Om du inte hyr hela ditt rack och placerar din egen nätverkshårdvara, får du vad du får.Vilket kan vara mycket dåligt i antingen funktionalitet eller prestanda Om du antar att du inte gör något fancyOm du vill ha 100,0000 % drifttid, visst.Men du brukar inte.De företag som vill ha den typen av drifttid har vanligtvis team som är dedikerade till det ändåOch skalning fungerar också bra på bare-metal om du skalar vertikalt - har du någon aning om mängden av kraft och genomströmning du kan få från en enda server?Det är oroande att fortsätta att höra om "skalning"när högtalaren betyder "horisontell skalning"Om dina krav är "skalning", kommer vertikal skalning att ta dig långtOm dina krav är "horisontell skalning på begäran", så kommer molnleverantörer att hjälpa till där.Men, få ställen behöver den typen av skalningJag säger inte att 100 % drifttid på ren metall är billig, jag säger att 100 % drifttid ofta inte behövsEftersom branschen är full av människor som jagar trender och nyckelord och där det viktigaste är att lägga till dessa nyckelord i CV:nIME som siktar på skalbarhet är oerhört fel för de flesta tjänster/applikationer/vilket som helst.Och vanligtvis betalar du så mycket omkostnader för de "skalbara"lösningarna att du sedan måste skala för att kompensera för detJag tvivlar verkligen på detta.Det enda temat du ser på nästan alla AWS-förespråkare är en stor mängd villfarelser om vilka garantier AWS faktiskt ger dig Ja visst. Ingen får sparken för att ha köpt från IBM Jo, om stora företag hade någon kompetens i beslutsfattande skulle de vara oslagbara och det vore hopplöst att jobba med något annat överhuvudtaget. Så, ja, det är ett allmännytta Källa: nästan trettio år av ops Hittills har jag inte märkt att om jag spenderar mer för företaget så får jag också mer betalt att få motsvarande tillförlitlighet med strykjärn är mycket dyrare än att hyra "två dedikerade servrar"- nu kanske du klarar dig bra med en server och en backuplösning, och det är rättvist. men en sysad för att skapa allt det, även på ett kort kontrakt för den första installationen och inget underhåll, kommer att gå långt utöver molnprisskillnaden, speciellt om det finns en databas i mixen och du bryr dig om den datan Idag är molnet liknande - tiden till marknaden är snabbare eftersom det finns mindre rörliga delar. När ekonomin går tillbaka och tillväxten avtar kommer bönräknaren in och gör sitt Det händer varje gång Detta gör bara AWS rikare på företag och molnteam Det är trivialt att tillhandahålla och avprovisionera en EC2-instans automatiskt, inom några sekunder om din distribution behöver skalas upp eller ned. Det är det som gör den fundamentalt annorlunda än en barmetallserver
Nu förnekar jag inte att det fortfarande kan vara mer kostnadseffektivt jämfört med AWS att tillhandahålla några fler dedikerade servrar än du behöver, men när du har riktigt oförutsägbara arbetsbelastningar är det inte lätt att hänga med
om du snurrar upp och stänger av virtuella datorer för att möta efterfrågekurvan - något är allvarligt fel med din arkitektur
Har det någonsin fallit dig in, hur kommer det sig att stackoverflow använder ~8 dedikerade servrar för att tjäna hela världen och behöver inte snurra upp och stänga av virtuella datorer för att möta globala kunders efterfrågan?
--
När du planerar datorinfrastruktur är det viktigt att gå tillbaka till grunderna och inte falla för molnleverantörens propaganda
Du sa det själv. Alla applikationer behöver inte tjäna hela världen, därför kommer efterfrågan att bli lägre när folk går och lägger sig
Även med globala applikationer finns det bestämmelser som kräver att du är värd för applikationer och data i specifika regioner. Föreställ dig ett program som används av kunder i Europa, Australien och USA. De måste betjänas från regionala datacenter, och ett kluster kommer mestadels att ligga i viloläge när det andra är igång (på grund av tidszoner). Med dedikerade servrar skulle du slösa bort 60-70 % av dina resurser, medan du använder något som EC2/Fargate kan du skala ner till nästan 0 när din region sover
Det finns en metod till galenskapen, här heter det "anställningstrygghetsdriven utveckling"För det är ett hot mot deras jobb
Det finns ett helt gäng människor som har den tekniska kapaciteten att själv vara värd för, eller vara värd för små tillfällen för sin familj/vänner/förening/vandringsklubb. Denna lilla marginal där du är ok att spendera lite extra för att du vill göra det ordentligt, men du kan inte motivera att betala så mycket och lägga tid på hårt underhåll. En liten VPS, med ett delat Nextcloud eller en liten webbplats, är allt som behövs i många fall
För detta använder jag till och med lite Raspberry Pi 400 i mitt sovrum
httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..
Jag har själv varit värd för mina egna saker i nästan ett decennium nu. Ingen har provat DDoSing min installation, för varför skulle de det? Vilken nytta skulle de möjligen få ut av det? Jag skulle i stort sett vara den enda personen som drabbades, och när de väl slutar skulle det inte ta lång tid att återhämta sig
Det finns lite eller inget incitament att DDoS en personlig box, än mindre genom en internetrando
Du överskattar en tonåring drastiskt
Att bara pinga IP:n om och om igen kommer egentligen inte att göra så mycket. Kanske en DoS-attack beroende på vad målnätverket har vad gäller IPS, men även då är det mer troligt att de kommer att infektera sina datorer med virus innan de får chansen att faktiskt attackera dig
Jag har personligen tagit emot en av dem för på något sätt en fuskare i GTA 5. Det händer definitivt och det är inte kul
Edit: Det ser ut som att detta kan vara automatiskt. Det här är något intressant jag borde titta på lite. Det är förmodligen bara extra komplexitet för min lilla server, men jag har några användningsområden i åtanke
Tekniskt sett är mitt hemlab också på en statisk offentlig IP-adress - det här var mer en övning i "kan jag göra det här"än "faktiskt nödvändigt", men det är fortfarande coolt och jag är väldigt glad
Det enda problemet var att jag var tvungen att konfigurera Wireguard för att hålla tunneln vid liv, annars skulle VPS:en ta emot inkommande trafik och om mitt labb inte hade nått ut på ett tag (vilket, varför skulle det göra det?) skulle tunneln vara nere, och proxyanslutningen skulle. Tack och lov är det inbyggd funktionalitet
Så det verkar som att lägga till RSS / Atom-flöden på en jekyll- eller GitHub-sida är ganska enkelt
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 enhet, 100mbit
Några år av drifttid vid det här laget
Om det inte avbryts: viss uppgradering kan behövas.
Kärnsäkerhetsuppdateringar är en sak
Jag tyckte att Atoms var outhärdligt långsamma, även med Linux. Naturligtvis räcker det för att betjäna webbplatser och vad som helst, men det är förbryllande hur mycket kraft de använder bara inte presterar
Exakt. Dessa under-$10 VPS-instanser är bra för små projekt där du inte vill ingå långa kontrakt eller hantera dina egna servrar
Om du driver ett verkligt företag där marginalerna är tunna och du har all ledig tid i världen för att hantera serverproblem om (när) de dyker upp, kan dessa ~$50 dedikerade servrar vara intressanta att utforska
Men om du driver ett verkligt företag är till och med en AWS-räkning på 10 000 $/månad billigare än att anlita en annan skicklig utvecklare för att hjälpa till att hantera dina dedikerade servrar
Det här är vad som i allmänhet saknas i diskussioner om molnkostnader på platser som HN: Ja, moln är dyrt, men att anställa till och med en enda ytterligare systemadministratör/utvecklare för att hjälpa dig att hantera anpassad infrastruktur är otroligt dyrt och mycket mindre flexibelt. Det är därför att spendera en hypotetisk $5000/månad på en molnbaserad lösning som i teorin skulle kunna specialbyggas på en $50/månad-server med tillräckligt med tidsinvestering kan fortfarande vara en hel del. Ingenjörer är dyra och tiden är begränsad
Uhhh, ursäkta mig men hur mycket betalar du den här DevOps-killen? Detta verkar vara ett väldigt amerikanskt perspektiv, till och med dalområdet. I Europa skulle det vara billigare att anställa en kille
Fulla anställningskostnader är betydligt högre än vad du tar hem i din lönecheck. Det är faktiskt värre i Europa. Ta en titt på dessa diagram: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Om du betalar någon 1000 EUR i Storbritannien kostar det företaget totalt 1245 EUR
Om du betalar någon 1000 EUR i Rumänien kostar det företaget totalt 1747 EUR
Så en $120 000 fulladdad kostnad kanske bara köper dig för $68 000 USD i lön för en EU-devops-person
Men du kan inte ha bara en devops-person. Du behöver minst 2 om du vill tillåta en av dem att någonsin ta en paus, getor åka på semester
Jag kan koppla upp dig om cirka 3 timmar
AWS är mycket kostnadseffektivt för andra tjänster (S3,SES,SQS, etc) men virtuella maskiner är inte en bra affär. Du får mindre RAM& CPU, med virtualiseringskostnader, och betala mycket mer pengar
Speciellt för Postgres om du kör några tester med pgbench kan du verkligen se straffavgiften du betalar för virtualisering
Kanske håller systemadministratörsförmågan att kunna bygga sin egen infrastruktur en förlorad konst, annars kan jag inte förklara varför folk är så förälskade i att betala 5x för mindre prestanda
Hetzner är billigt och pålitligt i Europa, om du är i Nordamerika ta en titt på OVH. Speciellt deras kostnadsbesparande alternativ som heter SoYouStart. Du kan få 4/8 4.5ghz, 64 RAM och en NVME-enhet för $65
(Jag har ingen anknytning till OVH, jag är bara en kund med nästan 100 servrar, och det har fungerat bra för mig)
Jag ska också notera att jag är gammal hehe, och ett av mina första jobb hade vi ett anständigt stort datacenter på plats. Att hantera SAN, bandstationer (automatiska bandrotatorer på den tiden var servrar, etc var en enorm PITA. Att packa ihop band och skicka dem till ett annat kontor för platsöverflöd var alltid roligt
Den speciella applikationen jag hanterar lider verkligen av låg GHz och att inte ha all data i minnet. Jag har kört riktmärkena på EC2, vissa rapporter som slutar på ~5 sekunder kan ta mer än en minut på en jämförbar EC2-instans som kostar ungefär 10 gånger så mycket. Denna applikation behöver verkligen den råa CPU:n. och ja, vi har ett ganska stort ingenjörsteam som har optimerat alla frågor, index etc
När det gäller replikering, säkerhetskopior etc. Jag satte upp allt det där, och ärligt talat var det ingen stor sak. Det är ett par korta kapitel i Postgres-boken som förklarar det hela mycket enkelt, hur man konfigurerar, kontinuerligt (och automatiskt) testar, etc.
Jag håller med om att SAN är en mardröm. Det är därför jag skickar alla mina WALs (PG backup-filer) till S3 (och så småningom Glacier). På så sätt behöver jag inte tänka på att förlora de filerna och det är smutsbilligt
Jag tror att det finns en missuppfattning att den här typen av konfigurationer är för komplicerade för en enskild ingenjör att ställa in, med ett aldrig slutande underhåll som krävs. I verkligheten kan du ställa in allt på mindre än en vecka och det behöver egentligen bara underhållas när du vill uppgradera Postgres (vissa inställningar kan ha ändrats). Jag skulle uppskatta att det tar cirka 5 timmars underhåll per år
Självbetjäningsinfrastrukturen verkar sannolikt bli allt mer lönsam när vi fortsätter att förbättra leveransen på sista milen och utöka fibertillgången. Kommer molnet att bli självkannibaliserande? Definitivt kanske
Vad molnet ger dig är förmågan att placera din data/arbetsbelastning direkt i kärnan utan att behöva göra specialaffärer med din lokala internetleverantör, och med mycket mer motståndskraft än du förmodligen skulle ha råd med om du inte är åtminstone vid den flera 20 fots containern full. av servrar skala av datorbehov
httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..
Edit: Om någon är intresserad av att hosta själv är det enkelt med cloudflared. Jag har en 2017 Google Pixelbook som kör Ubuntu på anpassad firmware som serverar en Flask-baserad webbplats. Iton mitt skrivbord laddar medan jag är ansluten till ett gäst-wifi-nätverk. Den får 100/100 Mobile PageSpeed-poäng och tar 0,8 sekunder att ladda helt
Från DO får jag alla fördelar med ett pålitligt företag, skalbarhet, automatiserade säkerhetskopieringar etc etc. Det finns inget sätt att jag skulle ändra
Hetzner moln har nu två platser i USA. Fortfarande inga dedikerade servrar i USA - de skulle bli riktigt bra. Även om deras nuvarande molnerbjudanden redan är ~30% av priset för de stora molnmotsvarigheterna.
Precis som du kör jag även mina tjänster från en hyrd fysisk server. Jag använde Versaweb, men deras maskiner är för gamla. Jag gillade inte Hetzner tidigare eftersom jag hade hört dåliga saker om att de stör det du kör
Jag flyttade dock till dem i december när min Versaweb-instans precis dog, troligen SSD från ålderdom. Jag betalar nu 50 % av vad jag betalade Versaweb, och jag kan köra 6 sådana Postgres-instanser
Då får det en att undra om det är värt att betala $700 av $800 för en hanterad tjänst med ett snyggt molngränssnitt, automatiska uppgraderingar och säkerhetskopieringar, etc.
För en 1 person show eller liten startup, tror jag inte. Billigare att använda en tillgänglig tjänst och dumpa säkerhetskopior till S3 eller något billigare
Företag som jag brukade arbeta för lyckligt betalda företag A fyra gånger vad företag B tog betalt för exakt samma tjänst, bara för att företag A var villig att skicka kvartalsfakturor på ett sätt som spelade bra med vårt faktureringssystem. För företag är att spara några hundralappar här och där ofta inte värt besväret med att införa någon extra friktion
Det finns en implicit kostnad där. Om det bara är en eller två av dessa saker, ta bara de hanterade tjänsterna
Om du börjar skala, skaffa en administratörstyp av anställd att spara på detta
Annars skulle jag behöva anställa/kontraktera någon mycket erfaren, eller ägna en fast månad eller mer av min tid (vilket inte var tillgängligt), bara för att vara 100% säker på att vi alltid kunde återställa journaliserade PITR-säkerhetskopior snabbt
Jag kan spara stora mängder på molnkostnader på andra ställen, men trovärdig hanterad PostgreSQL var ett ganska enkelt samtal (även om prislappen på ingångsnivå var mer än du förväntar dig)
En tidig start som inte har råd att förlora en timmes produktionsdata är förmodligen för ömtålig för att överleva ändå
Det är en tidig start - det kommer att bli större avbrott än så för tjänsten och alla kunder som flyr efter en timmes förlust av produktionsdata uppskattade helt enkelt inte produkten tillräckligt ändå
(I den specifika uppstarten jag tänkte på hade jag redan några trevliga automatiska frekventa DB-online-dumpningar till S3 med retention påtvingad, men jag tyckte inte att det var tillräckligt bra för det här scenariot. Men jag var inte säker på att vi skulle kunna återhämta oss med PITR/journalföring skulle lägga till en ny enskild misslyckad satsning på framgången för ett företag som annars skulle ha en 9+-siffrig exit om några/flera år, bara för att spara några hundra.)
Jag antar också att en del av de tidiga startups som har mindre krävande behov, men som är lyhörda för sina skyldigheter gentemot kunders/användares data, fortfarande är försumliga med minimala grundläggande praxis
Kanske ett intuitivt sätt att uppskatta: Föreställ dig en bra nyhetsartikel på HN, om några startoperationer som tappar bollen, med startupgrundarnas namn bifogade, och historien säger och det visar sig att de inte hade bra säkerhetskopior. medgrundare, som kanske inte har sovit mycket eftersom deras företag kraschar runt dem, svarar "Kunddata är inte så viktigt i en tidig start; om det vore så skulle vi vara för ömtåliga"(skrivs innan medgrundaren kunde kasta den personens bärbara dator över rummet för att stoppa dem att skriva). Det skulle inte se bra ut
Jag tar upp det här i slutet
>Föreställ dig en kanonnyhet om HN, om att vissa startoperationer släppte bollen, med startupgrundarnas namn bifogade, och berättelsen säger och det visar sig att de inte hade bra säkerhetskopior
ITYM och det visar sig att de inte hade säkerhetskopierat den senaste timmen
Jag kan föreställa mig allt i ditt scenario, även de oklippta bitarna, och allt verkar normalt, om du inte läser "Våra startklienter, som har använt oss i en månad, lämnade alla direkt när vi förlorade den sista timmen av deras data"Jag kan verkligen inte föreställa mig det scenariot
Visst, det finns vissa företag där fördelen med att använda det är att det inte ens finns en timmes förlorad data
IOW, kunder använder det eftersom det inte kommer att förlora någon data: onlinedokumentsamarbete[1], till exempel[2]. Om du har en härdsmälta som förlorar en timme av den senast inmatade datan, förvänta dig verkligen att alla berörda nuvarande användare flyr omedelbart
[1] Även om jag personligen skulle minska risken genom att duplicera det aktuella dokumentet i lokal lagring medan det redigeras
[2] Kanske börsen också behöver systemet för att behålla den sista timmen med data? Vad annars?
Jag tror att även för större team kan det vara vettigt att hantera databaser själv, förutsatt att du har kompetensen att göra det bra. Det finns så många saker som kan gå fel med hanterade tjänster och de döljer inte den underliggande implementeringen på det sätt som saker som blocklagring eller objektlagring gör
Toppprestanda är förvisso sämre - men jag är inte så besvärad om något tar längre tid att köra ändå. Du har verkligen rätt i att ha lika mycket automatisering i provisioneringen av en server, något jag inte gjorde med en fysisk server
Jag brukade ha en rotserver för mina husdjursprojekt, men ärligt talat är det inte vettigt. Jag kör inte hög trafik, beräkna intensiv SaaS på mina maskiner. Det är bara en statisk webbplats och några projekt. Jag är nere på månatliga kostnader på 24 som inkluderar en förvaringsbox på 1 TB för att lagra all min data
Huvudfrågan i alla scenarion som involverar riktig hårdvara är att du behöver personal som är kompetent i både hårdvara och Linux/UNIX-system. Många säger sig vara på sina CV och kan då inte prestera en gång på jobbet (i alla fall enligt min erfarenhet). Enligt min åsikt var en av huvudorsakerna till explosionen av molnvärlden just svårigheten att bygga och den ekonomiska kostnaden för att bygga sådana lag. Dessutom finns det en något naturlig (och nödvändig) friktion mellan applikationsutvecklare och systemfolk. Systemfolket borde alltid trycka tillbaka och argumentera för mer säkerhet, mer process och färre distributioner. Utvecklarteamet bör alltid argumentera för mer flexibilitet, fler releaser och mindre process. God ledning bör då slå mittvägen mellan de två. Tyvärr har inkompetenta chefer ofta bara bestämt sig för att göra sig av med systemmänniskor och flytta saker till AWS-land
Slutligen vill jag bara notera att molnarkitektur är dåligt för planeten eftersom det kräver överprovisionering av molnleverantörer, och det kräver mer datorkraft totalt sett på grund av de många abstraktionsskikten. Medan alla projekt ansvarar för lite av detta avfall, är hela det globala molnet som ett aggregat väldigt slösaktigt. Detta stör mig och uppenbarligen troliga faktorer som en känslomässig fördom i mina åsikter (så stora mängder salt för alla ovanstående)
Argumentet skulle kunna framföras att du kan utveckla ett sätt att hyra fysiska servrar förinkomst, sedan, när det är vettigt, kan du antingen använda standardavskrivning -eller- Section 179 på direkta köp och/eller Section 179 leasing.
Som ett exempel kan du distribuera en otroligt kapabel grupp av låt oss säga fyra absolut fullständigt överprovisionerade $100 000 fysiska 1U-maskiner i olika färganläggningar för redundans. Det finns alla möjliga knep här för lastbalansering och failover med XYZ molntjänst, DNS, anycast, vad du vill. Du kan gå med olika färganläggningar som driver datacenter runt om i världen, skicka hårdvaran från leverantören till dem och sedan förse dem med Ansible eller vad du än gillar utan att någonsin se anläggningen eller röra hårdvara
Så nu har du redundant fysisk hårdvara som absolut kommer att köra cirklar runt de flesta molnleverantörer (särskilt för I/O), fasta kostnader som all you can-bandbredd (som inte har 800%-märkningen av molntjänster, etc) - inte längre att vänta för den oundvikliga molnnotan på 50 000 USD eller för att försöka spåra (i panik) vad som fick dig att överskrida din konfigurerade molnbudget på en dag istället för en månad. Åh btw, du låser dig inte in i de fåniga proprietära API:erna för att tillhandahålla och till och med använda andra tjänster än virtuella maskiner som erbjuds av $BIGCLOUD
Om du gör någon ML kan du träna på din egen hårdvara eller (eller ett och annat moln) och köra inferens 24/7 med saker som NVIDIA A10. Kontinuerlig molnuthyrning för GPU-instanser är otroligt dyrt och avkastningen på investeringen vid köp av hårdvaran ligger vanligtvis inom intervallet några månader (eller långt före nästan omedelbart med avsnitt 179). Som ett exempel gjorde jag nyligen ett riktmärke med Nvidia A10 för en modell vi serverar och den kan göra över 700 slutledningsförfrågningar/s i FP32 med under 10ms latens. Med en enda A10 per chassi över fyra friska instanser är det 2800 req/s (och skulle förmodligen kunna ställas in ytterligare)
Sedan, om du blir RIKTIGT stor, kan du börja skaffa skåp och mer. När det gäller hårdvarufel som nämnts kan jag bara säga att dual PS RAID-ut, etc hårdvara är (enligt min erfarenhet) extremt pålitlig. Efter att ha haft flera kompletta skåp med hårdvara tidigare var det få och långt mellan hårdvara och hårdvara leverantörer kommer att inkludera incredibles SLA för ersättning. Du meddelar dem om felet, de skickar in en tekniker< åtta timmar direkt till colo-anläggningen och byt ut skivan, PS, etc med det blinkande ljuset
Min erfarenhet är att en (bra) FTE-resurs enkelt kan hantera detta upp till flera skåpskala. Till din punkt är den aktuella frågan att många av dessa människor har ryckts upp av de stora molnleverantörerna och ersatts (på marknaden) med resurser som kan navigera i den gränsöverskridande löjligheten som använder dussintals (om inte fler) produkter/tjänster från $ STORT MOLNET
Jag har också funnit att den här konfigurationen faktiskt är MYCKET mer tillförlitlig än de flesta $BIGCLOUD. Du undrar inte längre vad som händer med ett $BIGCLOUD-avbrott som de inte ens kommer att erkänna (och som du absolut inte har någon kontroll över). Med en bakgrund inom telekom och sjukvård är det helt vilt för mig hur drifttiden faktiskt har blivit mycket sämre med molnleverantörer. Vanligtvis kan du bara säga till kunderna "åh, internet har problem idag"eftersom de förmodligen kommer att se rubriker om det, men för många applikationer är det helt oacceptabelt - och vi borde förvänta oss bättre
[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
Om jag vill skapa ett nytt projekt eller prova att vara värd för något nytt tar det ett par minuter och jag har skripten. Implementeringen går snabbt, underhållet är lågt och jag har mycket mer för pengarna
För alla som är intresserade är detta den grova snittet av vad jag använder:
* Kan hantera allt
* En liten bit av terraform för vissa DNS-poster som jag kan ersätta en dag
* restic för säkerhetskopior, återigen kontrollerad av ansible
* tailscale för vpn (jag har några pi's igång hemma, inget större men tailscale gör det enkelt och säkert)
* Docker-compose för i stort sett allt annat
Huvudappen är Clojure, så jag kör en inbyggd JVM. Databasen är fullt distribuerad, RethinkDB, arbetar nu med att flytta till FoundationDB
Det viktiga är att inte hantera något manuellt, t.ex. behandla fysiska servrar precis som alla andra molnservrar. Det borde inte spela någon roll om det är fysiskt eller virtualiserat
Jag har sett många mindre erfarna personer betala för mycket för hetzner och liknande när en $5-10 vps skulle ha fungerat
Ja, du stöder din egen hårdvara vid den tidpunkten. Nej, det är ingen stor huvudvärk
Den största merkostnaden för detta är att hyra fler IPv4-adresser, vilket Hetzner tar mycket betalt för nu när det finns så få tillgängliga
Vad du än skapar kommer att börja med 0 användare, och en hel riktig maskin är helt överdriven för den 0 belastningen du kommer att få. Du uppgraderar din VPS till ett par riktiga maskiner, sedan till ett litet hyrt kluster och sedan till ett datacenter (om någon inte underskrider det). Alla dessa har förutsägbara räkningar och högsta prestanda för sitt pris
Allt du äger i en colo kommer att bli mer per månad också. När jag hade anslutningar där jag kunde betala för en statisk IP var det vanligtvis $5/månad
Jag hyr nu en ganska låg server, men den kostar $30/månad. Mycket mer allt jag behöver, men det är trevligt. Och de släppte inte stödet för mitt operativsystem samtidigt som de höjde priserna för att förbättra supporten eller något. (Även om jag hade en del initialt fläckig hårdvara som behövde bytas ut)
som du påpekade, bar metal är vägen att gå. det fungerar motsatsen till molnet - lite mer arbete i början men mycket mindre kostnader i slutet
Mer info httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..
Att sätta upp och hantera Postgres är jobbigt. Skulle vara trevligt med ett enklare sätt att få det här att gå bra
1. Tvingar konfigurationen att vara reproducerbar, eftersom virtuella datorer kommer att gå ner
2. Du kan få kraftiga rabatter på AWS som minskar smärtan
3. De andra sakerna du har tillgång till ovanpå de virtuella datorerna som är billigare/snabbare när dina saker redan finns i molnet
4. Lättare att ha en dokumenterad systemkonfiguration (t.ex. AWS-dokument) än att utbilda folk/dokumentera vilka speciella grejer du har internt. Särskilt användbart för att anställa nya människor
5. Du behöver inte utrymme eller redundant ström/internet/etc på premesis. Bara tillräckligt för att låta folk köra sina bärbara datorer
Jag använde en VPS innan dess, men slutade och bytte till en fysisk eftersom det var en bättre affär och vi stötte inte på CPU-begränsningar
Diskövervakning är dock inte så svårt. För hårddiskar, kör smartctl en gång i timmen, varna när omfördelade eller väntande sektorer växer snabbt eller når 100. Håll tummarna för SSD-enheter; enligt min erfarenhet med några tusen tenderar de att fungera utmärkt tills de försvinner från bussen, för att aldrig ses igen. Ha en dataåterställningsplan som inte involverar lagring av data på enheter av samma modell med mycket liknande ström på timmar per timme korrelerade firmware-fel är verkliga
Hetzner har trots allt ett API för att beställa dedikerade servrar och ett API för att installera ett OS (eller för att starta om för att rädda och blinka vilken bild du vill)
Jag antar att om jag undersökte kommersiella alternativ skulle jag ha "stammen"sorterad på kontoret med en kommersiell ISP-lösning, statisk IP, bra IT-hårdvara kanske, men vad jag vet just nu om en klient behövde hosting d gå alltid direkt till att hyra en vps
Jag var mer av en junior utvecklare på den tiden så jag kanske var det men jag saknar det inte alls. I teorin håller jag med om det du säger, men att distribuera en Dockerfil till något som Google Cloud Run är mycket enklare. Ja, jag betalar mer än vad jag skulle hantera min egen VPS, men jag tror att detta mer än kompenseras av de sparade dev timmarna
- fysisk hårdvara har problem, t.ex. fläktfel ->min virtuella dator blir livemigrerad till en annan värd, jag märker det eller bryr mig inte
- fysisk hårdvara exploderar ->min virtuella dator startar om på en annan värd, jag kanske märker det men jag bryr mig inte
Katastrofplanering är mycket enklare med virtuella datorer (även med husdjur inte boskap)
För en nybörjare får de billigaste jobbet gjort
Jag är säker på att allt eftersom cloud computing utvecklas, blir dessa erbjudanden vanligare
Det finns en annan aspekt av cloud computing. De medelstora till stora företagen, räknar cloud computing som ensiffriga procentsatser i sina kostnadsberäkningar. Detta innebär att de beslut som fattas av chefer och team, ofta söker efter tillförlitlighet och skalbarhet (att läggas på deras presentationer) snarare än "är min installation dyr eller billig"Min arbetsgivare antog molnet som en affärs/ekonomisk lek, inte en religiös. Vi landar ofta nybyggen i molnet och migrerar till ett datacenter vid behov senare
Apparna på plats kostar cirka 40 % mindre. Appar som är mer kostnadseffektiva i molnet stannar där
Jag tror att det är så att AWS/GCP/Azure inte är särskilt kostnadskonkurrenskraftiga erbjudanden i Europa. Vad jag inte ser är bevis på det för USA
för samma spec, visst. Jag tror att virtuella funktioner är vettiga i båda ändar - antingen är dynamisk skalbarhet för stort N viktigt, eller så behöver du faktiskt bara en liten bråkdel av en fysisk låda. Att betala 45/månad för något som kör find på 5/mo är inte heller klokt, och ger dig mer flexibilitet för att inte blanda ihop saker bara för att använda din server
Behåll säkerhetskopior i alla fall. Helst på en annan leverantör eller åtminstone på en annan fysisk plats. Och, naturligtvis, testa dem
Och om du hanterar en bra backup-regim och övervakar din data/app ändå, är övervakning av enheter en betydande extra svårighet?
--
[1] faktiskt om du automatiserar återställningsprocessen till en annan plats, vilket jag gör för ett par av mina bitar, så kan du bara trycka på den knappen och uppdatera DNS när den är klar, och kanske allokera lite mer RAM+kärnor (mitt test speglar är mindre än live-VM eftersom de inte behöver tjäna riktiga användningsmönster)
Precis vad jag gör för mig själv och mina kunder. Sparar massor av dosh
Även om jag ville uppdatera, är det bara ett fall att dra in den senaste versionen i docker-compose-mallen och köra den eventuella spelboken igen. Uppenbarligen om uppgraderingen kräver mer så är det så, men det är inte annorlunda än någon annan installationsmässigt
Förmodligen det enda jag _behöver_ göra som jag gör manuellt är att testa mina säkerhetskopior. Men jag har ett script för varje projekt som gör det så jag bara SSH på, kör one-liner, kolla resultatet och det är klart. Jag gör det ungefär en gång i månaden eller så, men jag får också e-postmeddelanden om en säkerhetskopiering misslyckas
Så det kan inte vara någon tid alls. Vanligtvis är det nog 1-2 timmar i månaden om jag tar uppdateringar på halvregelbunden basis. Men det kommer att skalas med ju fler saker du är värd för och hanterar
Med andra ord är den enda skillnaden varifrån den eventuella inventeringsfilen kommer. Antingen är det en statisk lista över IP-adresser, eller så kommer den från terraform
Om du vill ha ECC RAM, verkar det vara 60/månad, och det går också upp till en kraftfullare 8-kärnig CPU
Oavsett, om vi pratar om en "full produktionsmiljö och en duplicerad iscensättning/standby-miljö"(för att citera personen du svarade), så är 60/månad * (2 eller 3) fortfarande smutsbilligt jämfört med alla startups AWS räkning som jag har sett
Användningsfallen varierar, men jag brukar hålla med om att AWS/GCP/Azure inte är svaret på alla problem
För någon som kan passa sin applikation på en $4 VPS kommer det uppenbarligen att bli billigare än någonting bar metall, men molnet skalar upp väldigt dyrt i många fall. Bare metal är inte heller svaret på alla problem, men många människor i branschen verkar inte uppskatta när det kan vara rätt svar.
VIRTUELLA PRIVATA SERVER#120
