Hoeveel kunt u halen uit een VPS van $ 4?

Gevirtualiseerde aanbiedingen presteren aanzienlijk slechter (zie mijn experimenten uit 2019: httpsjan.rychter.com/enblog/cloud-server-cpu-performance en kosten meer. Het verschil is dat je kunt "schalen op aanvraag", wat ik niet nodig vond, tenminste in mijn geval. En als ik moet schalen, kan ik dat nog steeds doen, alleen duurt het verkrijgen van nieuwe servers uren in plaats van seconden. Nou, ik hoef niet in seconden te schalen

In mijn geval is mijn volledige maandelijkse factuur voor de volledige productieomgeving en een dubbele staging/standby-omgeving constant, eenvoudig, voorspelbaar, zeer laag in vergelijking met wat ik aan AWS zou moeten betalen, en ik heb nog steeds veel prestatieruimte om

Een ding dat het vermelden waard is, is dat ik fysieke servers net zo behandel als virtuele: alles wordt beheerd via weerwort en ik kan alles vanaf het begin opnieuw creëren. Sterker nog, ik gebruik een andere "devcloud"-omgeving bij Digital Ocean, en die wordt opgezet met behulp van terraform, voordat deze wordt doorgegeven aan ansible die de rest van de installatie doet

Ik vermoed dat VendorOps en complexe tools zoals kubernetes de voorkeur genieten van complexiteitshandelaren die de afgelopen tien jaar zijn ontstaan. Het staat geweldig op je CV en geeft technologieleiders een vals gevoel van prestatie

Ondertussen sukkelt Stackoverflow, dat aantoonbaar belangrijker is dan de meeste startups, voort op speciale machines

1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..

Het lijkt erop dat de trend in deze ruimte is om direct naar de hoogste abstractielaag te springen. Sla de basisprincipes over en wijs naar $buzzword-tools, -bibliotheken en -producten

Je ziet hiervan een glimp in verschillende vormen. Een daarvan zijn discussies op sociale media waarin dingen worden gevraagd als Hoeveel van X moet ik weten om Y te leren, waarbij X een fundamentele, mogelijk zeer stabiele technologie of vakgebied is en Y een tool du jour is of rechtstreeks een product of dienst

CORBA hoort daar thuis. En misschien zelfs de semantische webdingen. Absoluut XML!
XML is geweldig - als je het niet gelooft, dan ben je misschien geïnteresseerd in de pijn van het parseren van JSON: httpseriot.ch/projects/parsing_json.html
En laat me niet beginnen over YAML..

De extra kosten van het werken in de cloud zijn mij absoluut de moeite waard om te beschikken over beheerde databases, automatische snapshots, gehoste load balancers, plug-and-play blokopslag enz.
Ik wil me zorgen maken over de vraag of ons product goed is, niet over hardwarestoringen midden in de nacht, een nieuwe server draaien en niet goed werken omdat er geen stimulans was om configuratiebeheer te gebruiken met een enkele box, met een enkele op hol geslagen taak OOM of volledige schijf veroorzaken en alles breken in plaats van alleen die VM-taken, angst voor het herstarten van een machine die al 1000 dagen actief is, enz.

Voor mij is de aantrekkingskracht van de cloud niet een FAANG-rage op het gebied van schaalbaarheid wanneer deze niet vereist is, maar automatische OS-patching, automatische load balancing, NAT-services, gecentraliseerde, analyseerbare logs, databaseservices die ik niet hoef te beheren, uit de box-rolling-upgrades voor services, het beheren van crypto-sleutels en geheimen, en natuurlijk objectopslag. (Dit zijn alle dingen die we gebruiken in onze startup)
Ik zou durven zeggen dat dedicated servers zeer levensvatbaar/kosteneffectief kunnen zijn wanneer we een bepaalde schaal bereiken, in plaats van andersom. Op dit moment zijn de cloudkosten de moeite waard voor mijn startup

Als u uw omgevingsconfiguratie uitvoert als code, zou het er uiteindelijk niet toe moeten doen of uw doel een dedicated server, een vm of een cloudspecifieke setup is die is geconfigureerd via een api

Het maakt niet echt uit welke, het punt is dat je er een hebt die een nieuwe doos voor je kan bouwen of een zich misdragende doos terug kan brengen naar een goede staat door simpelweg een commando uit te voeren

Natuurlijk, de daadwerkelijke stapel Go(o) die het aandrijft, kan worden verbeterd (en het verbetert inderdaad)

Dat gezegd hebbende, de harde waarheid is dat uw aanpak de juiste is, bijna alle bedrijven (startups!) bouwen te veel in plaats van zich te concentreren op het bieden van waarde, het identificeren van de daadwerkelijke niche, enz. (Ja, er is ook de vraagzijde hiervan, aangezien de VC geld opgeblazen startups hebben te veel gebouwd, ze willen afhankelijk zijn van derde partijen die de belasting kunnen nemen, mee kunnen schalen, SLA's en wat dan ook moet worden geadverteerd.)
Kubernetes is fantastisch! Telkens wanneer ik een potentieel concurrerend bedrijf Kubernetes zie gebruiken, ben ik onmiddellijk opgelucht, omdat ik weet dat ik me daar geen zorgen meer over hoef te maken. Ze staan ​​op het punt te verdwijnen in een stapel onoplosbare technische problemen, proberen problemen op te lossen die niet kunnen worden getraceerd in een technische stapel van ongelooflijke complexiteit en werken om beperkingen heen die worden opgelegd door een systeem dat is ontworpen voor bedrijven met verkeer dat twee tot drie keer zo groot is. Ook zullen hun COGS veel hoger zijn dan de mijne, wat betekent dat ze hun product hoger zullen moeten prijzen, tenzij ze gewoon VC-geld verbranden (in welk geval ze een flits in de pan zijn)

Overal goede dingen

Ansible is absoluut noodzakelijk, het kan naar een statische toestand toe werken, en dat is alles. Als het een probleem tegenkomt, werpt het zijn SSH-verbinding op, en huilt tonnen python-fouten, en geeft het voor altijd op. Zelfs met zijn inventaris is het verre van declaratief
k8s is een van controlelussen die proberen vooruitgang te boeken in de richting van hun verklaarde staat. Falen is geen probleem, het zal het opnieuw proberen. Het controleert constant zijn eigen status, het heeft een mooie API om dit te rapporteren, en dankzij veel gereïficeerde concepten is het moeilijker om vreemde botsingen tussen geïmplementeerde componenten te hebben. (Terwijl het integreren van meerdere playbooks met Ansible niet triviaal is.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
En zelfs als k8s teveel legacy-heid opdoet, zijn er aankomende slankere manifestaties van de kernideeën. (Bijvoorbeeld httpsgithub.com/aurae-runtime/aurae)
En nu suggereer je dat mensen een eenvoudigere, niet-standaard implementatie gebruiken?
U kunt dus natuurlijk een oplossing met minimale complexiteit implementeren of u kunt iets "van de plank"gebruiken

k8s is complexiteit en een deel ervan is absoluut niet nodig voor uw situatie, maar het is ook vrij algemeen, flexibel, goed ondersteund, enz.

>je suggereert dat mensen een eenvoudigere, niet-standaard implementatie gebruiken?
Wat ik suggereerde, is dat als k8s het project / de software te groot wordt om te mislukken, mensen kunnen overschakelen naar een alternatief. Gelukkig zijn de k8s-concepten en API open source, dus ze kunnen in andere projecten worden geïmplementeerd, en ik gaf zo'n voorbeeld om te illustreren dat het kiezen van k8s geen Oracle-achtige vendor lock-in is

Ik hoor altijd over alle geweldige dingen die je praktisch gratis krijgt van cloudproviders. Is dat spul eigenlijk zo eenvoudig in te stellen en te gebruiken? Elke keer dat ik probeerde mijn LAMP-stack op een cloudservice in te stellen, was het zo'n verwarrend en beangstigend proces dat ik het uiteindelijk opgaf. Ik vraag me af of ik gewoon wat harder moet pushen om naar Cloud Heaven te komen
In staat zijn om te zeggen "Ik wil hier een geclusterde MySQL met dit soort specificaties"is veel beter (qua tijd) dan het alleen te doen. De updates zijn ook mooi verpakt in het systeem, dus ik zeg alleen "pas de laatste update toe"in plaats van handmatig te zorgen dat failovers/herstarts in de juiste volgorde plaatsvinden

Je betaalt dus om dingen te vereenvoudigen, maar de winst van die vereenvoudiging wordt pas zichtbaar bij grotere projecten. Als u iets op een enkele server heeft dat u kunt herstarten terwijl uw gebruikers een foutpagina krijgen, is het misschien niet de moeite waard

De cloud is niet eenvoudig, maar proberen om de koeling en energie-efficiëntie van een kleine serverruimte ergens in de buurt te krijgen van de efficiëntieniveaus die de meeste publicaties van grote datacenters publiceren, is bijna onmogelijk, net als internetconnectiviteit van meerdere leveranciers

Met de cloud verdwijnt al dat soort zaken, omdat het wordt beheerd door de datacenteroperator waarop de cloud draait, maar wat mensen vergeten is dat dit ook geldt voor ouderwetse colocatiediensten, die vaak een betere prijs/kwaliteitverhouding bieden dan de cloud.
En hoewel het zeker moeilijker is om zaken als AWS of Azure te beheren omdat het veel abstracties bevat die kleine vpc-providers voor je verbergen of die je niet echt krijgt met een enkele thuisserver, is het niet moeilijk op de schaal van het moeten draaien van een paar aan racks aan VMware-servers met op SAN gebaseerde opslagMet Cloud-dingen heb je meer configuratie te doen, omdat het gaat om het configureren van virtuele servers enz.In plaats van de pc in een box naar uw kamer toe te voegen, moet u het "configureren"om het beschikbaar te makenDO-databases hebben back-ups die u naar wens kunt configureren, sla ze op DO Spaces (zoals S3).DB-gebruikersbeheer is eenvoudig.Er zijn ook cacheservers voor RedisU kunt een load balancer toevoegen en deze verbinden met uw verschillende webserversIk denk dat het mij kostte ongeveer 30 minuten om 2x webservers, een DB-server, cacheserver, load balancer en een opslagserver in te stellen en ze allemaal indien nodig te verbinden met behulp van een paar eenvoudige formulieren.Kan dat niet echt verslaanAls je meer informatie of meningen hebt, deel die dan alsjeblieftEr zijn veel artikelen op internet over bij het harden van een Linux-server, duurt het bij degenen die ik heb geprobeerd iets meer dan 30 minuten om de stappen te volgen, en veel langer als ik echt probeer te leren en te begrijpen wat elk ding doet, waarom het belangrijk is, wat de onderliggende kwetsbaarheid is, en hoe ik mogelijk enkele instellingen moet aanpassen voor mijn specifieke gebruikssituatieIk weet zeker dat je online voorbeelden van installatiescripts kunt vinden (automatische updates configureren, firewall, applicaties, enz. zou een kwestie moeten zijn van het uitvoeren van 'curl $URL'en vervolgens 'chmod +x $FILE'en 'bash $FILE'.Ik had geen configuratiebeheer nodig (ik gebruik wel de back-upservice van mijn provider, wat belangrijk is, denk ik)Zoiets als dit: httpsraw.githubusercontent.com/potts99/Linux-Post-Install..(te zien in httpswww.reddit.com/r/selfhosted /comments/f18xi2/ubuntu_d )Uiteraard kan hetzelfde worden gezegd voor langlopende VM's, en dit kan worden opgelost door een gedisciplineerd team te hebben, maar ik denk dat dit over het algemeen waarschijnlijker is in een omgeving met één enkele, langlopende dedicated machineHetzner heeft dit allemaal behalve beheerde databaseshttpswww.hetzner.com/managed-serverDe webhostingpakketten bevatten ook 1. .unlimited DBs (MySQL en PostgreSQL)httpswww.hetzner.com/webhosting/Heeft het automatische back-up en failover?>Bij een geboekte dagelijkse back-up of de back-up die bij het type server is inbegrepen, wordt er dagelijks een back-up van alle gegevens gemaakt en maximaal 14 dagen bewaard.Herstel van back-ups (Restore) is mogelijk via de konsoleH-beheerinterfaceMaar ik krijg de indruk dat de databases op beheerde servers bedoeld zijn voor gebruik door apps die op die server draaien, er is dus niet echt een concept van failoverhttpswww.hetzner.com/legal/managed-server/Het falen van een enkele schijf op een enkele server mag nooit een productie veroorzaken uitvalVeel configuratieproblemen kunnen worden herleid tot op zichzelf staande implementaties.Moet dat lettertypebestand of JRE echt op de hele server worden geïnstalleerd of kunt u het in uw implementatie bundelenOnze implementaties maken gebruik van on-premise en EC2-doelen.Het implementatiescript is niet anders, alleen het IP-adres voor de host isNu zal ik zeggen dat als ik S3 ergens voor kan gebruiken, ik dat 100% zal doen.Er is geen alternatief op locatie met dezelfde functieset.Het punt van DevOps is "Vee, geen huisdieren."Zet één keer per week een kogel in je server om je faalpunten te vindenIk zou het leuk vinden als je in onze Discord/Slack zou springen en een aantal van de problemen die je tegenkwam ter sprake zou brengen, zodat we dit kunnen doen maak de ervaring op zijn minst beter voor anderen die Dokku gebruiken.Bel me gerust (mijn bijnaam is `savant`)Laat me inleiden en zeggen dat ik een applicatie-ontwikkelaar ben met alleen praktische kennis van Docker.Ik ben niet super bedreven in infra en de applicatie waarmee ik worstelde heeft eigenaardige implementatieparameters: het is een Python-app die tijdens het bouwen verschillende optredens van statische HTML-crawls parseert om een ​​Postgres-database te vullen die statisch is nadat deze is gebouwd.Een Flask-webapp dient vervolgens voor die database.De HTML-parsering evolueert snel en dus moeten de ingevulde DB-gegevens worden gebundeld als onderdeel van de applicatie-image(s)IIRC, ik had moeite met het structureren van Dockerfiles toen de DB dat niet was Het was niet hardnekkig, maar in plaats daarvan gewoon een voorbijgaand onderdeel van de app, maar het leek overkomelijk.Het grotere probleem leek te zijn hoe te voorkomen dat voor elke build optredens met zelden gewijzigde gegevens uit S3 moesten worden opgehaald, terwijl deze idealiter in de cache zouden worden opgeslagen, vooral op een manier die zich in DigitalOcean en mijn lokale omgeving goed gedroeg.Ik neem aan dat de juiste caching van de Docker-afbeeldingslaag het probleem zou oplossen, maar ik bereikte vrij snel het einde van mijn kennis en geduldDokku's DX lijkt geweldig voor mensen die normale dingen doen .:)0. httpscoolify.io/En wie wil er nou niet met het nieuwste, coolste speelgoed spelen voor andermans dubbeltje?Er is zeker een argument om (sommige) zaken later in de reis uit de cloud te halen, wanneer flexibiliteit (of het omgaan met flux/pivoting) minder een primaire drijfveer wordt en schaal/kosten gaan dominerenTuurlijk, je kunt iets aan Hetzner laten werken, maar wees bereid om nog veel meer vragen te beantwoordenIk ben het eens over je laatste ondernemingspunt om hierom te vragen, wat wederom gewoon triest is dat deze zaken "vereisten"bepalen hoe u uw software moet ontwerpen en hosten, terwijl een andere manier de veel betere zou kunnen zijnHerstel na een ramp is een zeer reëel probleem.Daarom test ik het regelmatig.In een scenario van de verschroeide aarde kan ik in minder dan een uur operationeel zijn op een secundair (staging) systeem of een geterraformeerd cloudsysteem.Voor mijn bedrijf is dat genoeg
We maakten een groeigolf door, en net als alle andere jaren betekende dit dat er veel onervaren mensen veel geld en dringende verwachtingen kregen. Het is een recept voor het cultiveren van vracht en uitbuitende marketing

Maar de groei vertraagt ​​en geld wordt duurder, dus vertragen en beginnen met het opnieuw leren van de oude lessen met opwindende nieuwe variaties. (Zoals hier: bare metal-schaling beheren en met containers en orkestratie)
En de hele cyclus herhaalt zich in de volgende boom. Dat is onze branche voor nu

Een solide dedicated server is 99% van de tijd veel nuttiger dan een kreupele VPS op gedeelde hardware, maar het brengt uiteraard hogere kosten met zich mee als je niet alle bronnen nodig hebt die ze bieden

Ja, maar het verlangen om "te doen wat alle coole kinderen nu doen"is minstens zo sterk bij degenen die normaal gesproken "managers"zouden worden genoemd, versus "werknemers"uitkomst A) enorme microservices/clouduitgaven gaan fout, nou ja, je volgde tenminste best practices, deze dingen gebeuren, wat kun je doen

uitkomst B) je ging met een Hetzner-server en er ging iets mis, nou, je bent en had moeten gaan met microservices, veel plezier met het zoeken naar een nieuwe baan

Zo worden managers aangemoedigd om voor microservices/cloud te kiezen. Het is misschien niet de juiste beslissing voor het bedrijf, maar het is de juiste beslissing voor de manager en het is de manager die de beslissing neemt

(Net als een consultant die een extensie wil en software schrijft die werkt, zoals ik op de harde manier ontdekte.)
Er is een kloof tussen de oprichters en alle anderen

Oprichters denken dat ze elk jaar>10x gaan

De realiteit is dat ze 90% kans hebben om te mislukken

90% van de tijd - het is prima als je faalt op wat dan ook

Sommige % van de 10% van de tijd dat u slaagt, kunt u nog steeds prima zonder de cloud - in ieder geval voor meerdere jaren van succes, voldoende tijd om over te schakelen indien nodig

Ik heb maar één weerwort-configuratie en die kan zowel voor gevirtualiseerde als fysieke servers werken. Geen verschil. Het enige verschil is dat gevirtualiseerde servers eerst met terraform moeten worden opgezet en dat fysieke servers eerst moeten worden besteld en hun IP's moeten worden ingevoerd in een configuratiebestand (inventaris).

Natuurlijk let ik er ook op dat ik niet afhankelijk word van veel andere clouddiensten. Ik gebruik bijvoorbeeld VpnCloud (httpsgithub.com/dswd/vpncloud) voor de communicatie tussen de servers. Als bijkomend voordeel geeft dit me ook de flexibiliteit om op elk moment over te stappen naar een willekeurige infrastructuuraanbieder
Mijn belangrijkste punt was dat hoewel gevirtualiseerde aanbiedingen hun nut hebben, er een (enorme) kloof is tussen een hobby-VPS van $ 10/maand en een bedrijf met een snelgroeiende B2C-business. De meeste nieuwe bedrijven vallen eigenlijk in dat gat: je verwacht geen exponentiële hockeystick-groei in een winstgevende B2B SaaS. Dat is waar u de gebruikelijke standaardkeuze van "gebruik AWS"in twijfel moet trekken. Ik geef om mijn COGS en mijn marges, dus ik kijk heel zorgvuldig naar deze keuze

Je bent geen softwarebedrijf, in wezen maak en verkoop je Sprockets

De meningen hier zouden zijn: huur een groot eng / IT-personeel in om "servers te kopen en te onderhouden"(PaaS is slecht) en dan waarschijnlijk "zelf een code te schrijven"(SaaS is slecht) of wat dan ook dat momenteel populair is hier (laatste thread hier was het "Pushing PHP over SFTP zonder Git, en je hebt meer nodig"lol)
Maar ik ben van mening dat bedrijven One Thing Well moeten doen en moeten voorkomen dat ze proberen te concurreren (handmatig doen) voor dingen die buiten hun kerncompetentie vallen. In dit geval zou ik zeker denken dat Sprocket Masters niet zou moeten proberen hun eigen hardware te beheren en zou moeten vertrouwen op een provider voor het afhandelen van schaalvergroting, beveiliging, uptime, compliance en alle kleine details. Ik vind ook dat hun software bog-standaard moet zijn met zo min mogelijk intern. Ze zijn geen softwarewinkel en zouden zo min mogelijk code moeten schrijven

Realistisch gezien zouden Widget Masters deze sites met een vrij kleine staf kunnen runnen, tenzij ze besloten om alles handmatig te doen, in welk geval ze waarschijnlijk veel meer staf nodig zouden hebben

Wat ik echter ook zie en waarvan ik denk dat de vorige poster het had, zijn bedrijven waar technologie de kern van het bedrijf vormt, en daar heeft het vaak minder zin, en in plaats van tijd te besparen, lijkt het tijd te kosten. Er is een reden waarom er AWS-experts zijn: het is niet triviaal. "Echte"servers zijn ook niet triviaal, maar ook niet noodzakelijkerwijs moeilijker dan cloudservices

Maar die bureaus willen ook geen personeel hebben voor het onderhoud van fysieke hardware..

Maar Sprocket Masters moet nog steeds een dure Cloud Consultant in dienst hebben om te reageren op noodsituaties

Als je iemand in dienst hebt om de cloudproblemen op te lossen, kun je net zo goed een server huren

Ik heb in het verleden persoonlijk Dedicated Servers voor ons bedrijf gerund, maar naarmate we uitbreidden en schaalden, werd het een stuk eenvoudiger om met de cloudproviders samen te werken om verschillende diensten snel te leveren, ook al stegen de kosten. Om nog maar te zwijgen van het feit dat het een stuk eenvoudiger is om een ​​potentiële klant te vertellen dat u "cloud zoals AWS"gebruikt dan "Oh, we huren deze machines in een datacenter dat door een of ander bedrijf wordt gerund"(wat eigenlijk beter kan zijn, maar klanten zullen dat meestal niet begrijpen) . Audit, naleving en anderen

Voor velen zelfs veel minder dan dat. Ik run een klein zijproject[1] dat een paar keer viraal ging (30.000 weergaven in ongeveer 24 uur) en het draait op een single-core CPU-webserver en een beheerde Postgres eveneens op een enkele CPU-core. Het is nog niet eens in de buurt van volledig gebruik
1: httpsaihelperbot.com/ Kan ik sommige ervan omschakelen naar lambda-functies? Of overstappen naar ECS? Of overstappen naar een andere clouddienst du jour? Misschien. Maar de hoeveelheid tijd die ik heb besteed aan het schrijven van deze opmerking is al ongeveer zes maanden aan besparing voor zo'n overstap. Als het moeilijker is dan "druk op de knop, ontvang 100% betrouwbaar vertaalde service", is het moeilijk te rechtvaardigen  Een deel hiervan komt ook doordat de cloud nu een aantal andere diensten biedt die dit soort dingen mogelijk maken. Ik hoef geen Kafka-cluster te gebruiken voor basisberichten; ze worden allemaal geleverd met een berichtenbus. Ik gebruik dat. Ik gebruik de gehoste DB-opties. Ik gebruik S3 of gelijkwaardig, enz. Ik merk dat wat er overblijft bijna nauwelijks de moeite waard is om mezelf in een ander paradigma te proppen, terwijl ik eencijferige dollars per maand betaal om gewoon op een EC2-instantie te draaien  Het is absoluut zo dat niet iedereen of elk project dit kan. Ik houd mij hier niet aan vast als einddoel. Als het niet werkt, onderneem ik onmiddellijk passende schaalmaatregelen. Ik suggereer niet dat je op basis hiervan iets opnieuw gaat ontwerpen. Ik zeg alleen maar dat het geen optie is om veracht te worden. Het heeft veel flexibiliteit, en de facturering is vrij consistent (of, om het anders te zeggen, het feit dat als ik plotseling 50x zoveel verkeer heb, mijn systeem merkbaar begint te stikken en te sputteren in plaats van me simpelweg honderden dollars in rekening te brengen meer is voor mij eerder een functie dan een bug), en over het algemeen rek je jezelf niet uit om je in een of ander paradigma te wurmen dat handig is voor een bepaalde cloudservice, maar misschien niet handig voor jou  Heeft u ooit een van die omgevingen moeten beheren? Het punt is dat als je een fundamentele schaalbaarheid van meer dan één persoon en goede devops wilt, je een aanzienlijke factor moet overprovisioneren (waardoor je spaargeld mogelijk verloren gaat)  U zult onvermijdelijk eindigen met een op maat gemaakte oplossing, wat betekent dat nieuwe medewerkers het moeilijker zullen hebben om het systeem onder de knie te krijgen en dat belangrijke mensen die het bedrijf verlaten hun grondige kennis van uw infrastructuur met zich mee zullen brengen. Je bent weer bij huisdieren in plaats van vee. Sommige servers zijn speciaal, na een tijdje betekent automatisering "hier en daar veel lijmshell-scripts"en een OS-upgrade betekent dat de helft van de infrastructuur een tijdje KO is of dat je helemaal geen OS-upgrades doet  En in het gelukkige geval moet je opschalen. Het kan zijn dat je voor onaangename verrassingen komt te staan  En laat me nooit beginnen aan de netwerkkant. Tenzij u uw hele rack huurt en uw eigen netwerkhardware plaatst, krijgt u wat u krijgt. Dat kan erg slecht zijn qua functionaliteit of prestaties. Ervan uitgaande dat je niets bijzonders doet  Als je 100,0000% uptime wilt, zeker. Maar dat doe je meestal niet. De bedrijven die dat soort uptime willen, hebben normaal gesproken toch teams die zich daarvoor inzetten  En schalen werkt ook goed op bare-metal als je verticaal schaalt. Heb je enig idee hoeveel stroom en doorvoer je uit een enkele server kunt halen? Het is zorgwekkend om steeds maar over 'schalen'te horen terwijl de spreker 'horizontale schaalvergroting'bedoelt  Als uw vereisten "schalen", dan zal verticaal schalen u ver brengen  Als uw vereisten "horizontaal schalen op aanvraag"zijn, dan zullen cloudproviders u daar zeker bij helpen. Maar er zijn maar weinig plaatsen die dit soort schaalvergroting nodig hebben  Ik zeg niet dat 100% uptime op bare metal goedkoop is, ik zeg dat 100% uptime vaak niet nodig is  Omdat de branche vol zit met mensen die op jacht zijn naar trends en trefwoorden en waarbij het belangrijkste is om die trefwoorden toe te voegen aan de cv’s  Het streven van IME naar schaalbaarheid is buitengewoon verkeerd voor de meeste diensten/applicaties/wat dan ook. En meestal betaal je zoveel overhead voor de ‘schaalbare’ oplossingen, dat je vervolgens moet opschalen om het goed te maken  Ik betwijfel dit echt.Het enige thema dat je bij bijna elke AWS-voorstander ziet, is een grote mate van waanvoorstellingen over de garanties die AWS je daadwerkelijk biedtJa, zeker.Niemand wordt ontslagen omdat hij bij IBM kooptAls grote bedrijven ook maar enige competentie hadden op het gebied van besluitvorming, zouden ze onverslaanbaar zijn en zou het hopeloos zijn om aan iets anders te werken alle.Dus ja, dat is een publiek goedBron: bijna dertig jaar operatieTot nu toe heb ik niet gemerkt dat als ik meer uitgeef voor het bedrijf waarvoor ik ook meer betaald krijghet verkrijgen van de gelijkwaardige betrouwbaarheid met strijkijzers is een stuk duurder dan het huren van "twee dedicated servers"- nu komt het misschien wel goed met één server en een back-upoplossing , en dat is eerlijk. maar een sysad om dat allemaal te creëren, zelfs met een kort contract voor de initiële installatie en geen onderhoud, zal veel verder gaan dan het prijsverschil in de cloud, vooral als er een database in de mix zit en je om die gegevens geeftTegenwoordig is de cloud vergelijkbaar: de time-to-market is sneller omdat er minder bewegende delen zijn.Als de economie vertraagt ​​en de groei vertraagt, komen de bonentellers binnen en doen hun dingHet gebeurt elke keerDit maakt AWS alleen maar rijker bij theof companies en cloudteamsHet is triviaal om een ​​EC2-instantie binnen enkele seconden automatisch in en uit te richten als uw implementatie moet worden opgeschaald of verkleind.Dat is wat hem fundamenteel anders maakt dan een bare metal server
Nu ontken ik niet dat het in vergelijking met AWS nog steeds kosteneffectiever kan zijn om een ​​paar meer dedicated servers in te richten dan je nodig hebt, maar als je echt onvoorspelbare workloads hebt, is het niet eenvoudig om bij te blijven

als u VM's laat draaien en afsluiten om aan de vraagcurve te voldoen, is er iets ernstig mis met uw architectuur

Is het ooit bij je opgekomen, hoe komt het dat stackoverflow ~8 dedicated servers gebruikt om de hele wereld te bedienen en geen VM's hoeft op te starten en uit te schakelen om aan de wereldwijde vraag van klanten te voldoen?
--
Bij het plannen van een computerinfrastructuur is het belangrijk om terug te gaan naar de basis en niet te trappen in de propaganda van cloudleveranciers
Je zei het zelf. Niet alle applicaties hoeven de hele wereld te bedienen, daarom zal de vraag lager zijn als mensen gaan slapen

Zelfs met wereldwijde applicaties zijn er voorschriften die vereisen dat u applicaties en gegevens in specifieke regio's host. Stel je een applicatie voor die wordt gebruikt door klanten in Europa, Australië en de VS. Ze moeten worden bediend vanuit regionale datacenters en het ene cluster zal grotendeels slapen als het andere actief is (vanwege tijdzones). Met dedicated servers zou je 60-70% van je resources verspillen, terwijl je met zoiets als EC2/Fargate kunt schalen tot bijna 0 wanneer je regio slaapt

Er is een methode voor de waanzin, hier wordt het "baanzekerheid-gedreven ontwikkeling"genoemd

Omdat het een bedreiging vormt voor hun baan

Er is een hele groep mensen die de technische snufjes hebben om zichzelf te hosten, of om kleine instanties te hosten voor hun familie/vrienden/vereniging/wandelclub. Deze kleine marge waar je best een beetje extra kunt uitgeven omdat je het goed wilt maken, maar je kunt het niet rechtvaardigen om zoveel te betalen en tijd te besteden aan hard onderhoud. Een kleine VPS, met een gedeelde Nextcloud of een kleine website is in veel gevallen voldoende

Hiervoor gebruik ik zelfs een kleine Raspberry Pi 400 in mijn slaapkamer

httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..

Ik heb nu bijna tien jaar mijn eigen spullen gehost. Niemand heeft DDoSing mijn setup geprobeerd, want waarom zouden ze? Welk voordeel zouden ze er eventueel uit kunnen halen? Ik zou vrijwel de enige getroffen persoon zijn, en als ze eenmaal stoppen, zou het niet lang duren om te herstellen

Er is weinig tot geen stimulans om een ​​persoonlijke DDoS-box te gebruiken, laat staan ​​een internetrando

Je overschat de capaciteiten van een tiener drastisch

Gewoon het IP-adres keer op keer pingen, zal niet echt veel uithalen. Misschien een DoS-aanval, afhankelijk van wat het doelnetwerk heeft in termen van IPS, maar zelfs dan is de kans groter dat ze hun computers infecteren met virussen voordat ze de kans krijgen om u daadwerkelijk aan te vallen

Ik ben persoonlijk aan de ontvangende kant geweest van een van die dingen voor een cheater in GTA 5. Het gebeurt zeker en het is niet leuk
Bewerken: het lijkt erop dat dit automatisch gaat. Dit is iets interessants waar ik een beetje naar moet kijken. Het is waarschijnlijk gewoon extra complexiteit voor mijn kleine server, maar ik heb een aantal toepassingen in gedachten

Technisch gezien is mijn homelab ook op een statisch openbaar IP-adres - dit was meer een oefening in "zou ik dit kunnen doen"dan "eigenlijk nodig", maar het is nog steeds cool en ik ben erg blij

Ongeveer het enige probleem was dat ik Wireguard moest configureren om de tunnel in leven te houden, anders zou de VPS soms binnenkomend verkeer ontvangen en als mijn lab al een tijdje geen contact had opgenomen (wat, waarom zou dat?), zou de tunnel niet werken, en de proxyverbinding zou dat doen. Gelukkig is dat ingebouwde functionaliteit

Het lijkt er dus op dat het toevoegen van RSS / Atom-feeds op een site met jekyll- of GitHub-pagina's vrij eenvoudig is

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 schijf, 100mbit
Op dit moment een paar jaar uptime
Indien ononderbroken: er kan een upgrade nodig zijn.
Kernel-beveiligingsupdates zijn iets


Ik vond Atoms ondraaglijk traag, zelfs met Linux. Natuurlijk is het genoeg voor het bedienen van websites en zo, maar het is verbijsterend hoeveel stroom ze gebruiken om gewoon niet te presteren

Precies. Deze VPS-instanties van minder dan $ 10 zijn geweldig voor kleine projecten waarbij u geen lange contracten wilt aangaan of uw eigen servers wilt beheren

Als je een echt bedrijf runt waar de marges flinterdun zijn en je alle vrije tijd van de wereld hebt om serverproblemen op te lossen als (wanneer) ze zich voordoen, dan kunnen die toegewijde servers van ~ $ 50 interessant zijn om te verkennen

Maar als u een echt bedrijf runt, is zelfs een AWS-rekening van $ 10.000/maand goedkoper dan het inhuren van een andere bekwame ontwikkelaar om uw dedicated servers te helpen beheren

Dit is wat over het algemeen over het hoofd wordt gezien in discussies over cloudkosten op plaatsen als HN: ja, cloud is duur, maar zelfs maar een enkele extra systeembeheerder/ontwikkelaar inhuren om u te helpen bij het beheren van aangepaste infrastructuur is ongelooflijk duur en veel minder flexibel. Daarom kan een hypothetische $ 5000/maand uitgeven aan een in de cloud gehoste oplossing die in theorie op maat kan worden gebouwd op een server van $ 50/maand met voldoende tijdsinvestering, nog steeds veel zijn. Ingenieurs zijn duur en de tijd is beperkt

Uhhh, sorry, maar hoeveel betaal je deze DevOps-man? Dit lijkt een heel Amerikaans perspectief, zelfs in de vallei. In Europa zou het inhuren van een man goedkoper zijn

Volledig beladen arbeidskosten zijn aanzienlijk hoger dan wat u mee naar huis neemt in uw salaris. In Europa is het eigenlijk nog erger. Bekijk deze grafieken eens: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Als je iemand in het VK 1000 EUR betaalt, kost dat het bedrijf in totaal 1245 EUR

Als je iemand in Roemenië 1000 EUR betaalt, kost dat het bedrijf in totaal 1747 EUR

Dus een volledig geladen kosten van $ 120.000 kunnen u alleen kopen voor een salaris van $ 68.000 USD voor een EU-devops-persoon

Maar je kunt niet slechts één devops-persoon hebben. Je hebt er minimaal 2 nodig als je wilt dat een van hen ooit een pauze neemt, of op vakantie gaat

Ik kan je aansluiten in ongeveer 3 uur

AWS is zeer kostenefficiënt voor andere services (S3, SES, SQS, enz.), Maar virtuele machines zijn geen goede deal. Je krijgt minder RAM& CPU, met de virtualisatie-overhead, en betaal veel meer geld

Vooral voor Postgres kun je, als je een aantal tests met pgbench uitvoert, echt zien hoeveel boete je betaalt voor virtualisatie

Misschien wordt de sysadmin-vaardigheid om je eigen infrastructuur te kunnen bouwen een verloren kunst, anders kan ik niet uitleggen waarom mensen zo verliefd zijn op het betalen van 5x voor minder prestaties

Hetzner is goedkoop en betrouwbaar in Europa, als je in Noord-Amerika bent, kijk dan eens naar OVH. Vooral hun kostenbesparende alternatief genaamd SoYouStart. Je kunt 4/8 4,5 GHz, 64 RAM en een NVME-schijf krijgen voor $ 65

(Ik heb geen band met OVH, ik ben gewoon een klant met bijna 100 servers, en het is voor mij prima gelukt)
Ik zal ook opmerken dat ik oud ben, hehe, en bij een van mijn eerste banen hadden we een datacenter van behoorlijke omvang ter plaatse. Omgaan met SAN's, tapedrives (automatische tape-rotators waren destijds servers, enz.) was een enorme PITA. Tapes inpakken en naar een ander kantoor verzenden voor locatieredundantie was altijd leuk

De specifieke applicatie die ik beheer, heeft echt last van een lage GHz en heeft niet alle gegevens in het geheugen. Ik heb de benchmarks op EC2 uitgevoerd, maar bepaalde rapporten die in ~5 seconden klaar zijn, kunnen meer dan een minuut duren op een vergelijkbare EC2-instantie die ongeveer 10x zoveel kost. Deze applicatie heeft echt de onbewerkte CPU nodig. en ja, we hebben een behoorlijk groot technisch team dat alle zoekopdrachten, indexen enz. heeft geoptimaliseerd

Wat betreft replicatie, back-ups, enz. Ik heb dat allemaal ingesteld, en eerlijk gezegd was het geen probleem. Er zijn een paar korte hoofdstukken in het Postgres-boek waarin het allemaal heel eenvoudig wordt uitgelegd, hoe te configureren, continu (en automatisch) te testen, enz.

Ik ben het ermee eens dat SAN's een nachtmerrie zijn. Daarom verzend ik al mijn WAL's (PG-back-upbestanden) naar S3 (en uiteindelijk naar Glacier). Op die manier hoef ik er niet aan te denken om die bestanden te verliezen en het is spotgoedkoop

Ik denk dat er een misvatting bestaat dat dit soort configuraties te ingewikkeld zijn om door één ingenieur te worden opgezet, en dat er nooit eindigend onderhoud nodig is. In werkelijkheid kun je het allemaal in minder dan een week instellen en heeft het pas echt onderhoud nodig als je Postgres wilt upgraden (sommige instellingen zijn mogelijk gewijzigd). Ik schat dat het ongeveer 5 uur per jaar onderhoud kost

Het lijkt waarschijnlijk dat de zelfbedieningsinfrastructuur steeds levensvatbaarder zal worden naarmate we doorgaan met het verbeteren van de last mile-levering en het uitbreiden van de glasvezeltoegang. Zal de cloud zelfkannibaliserend worden? Misschien

Wat de cloud u oplevert, is de mogelijkheid om uw gegevens/werklast precies in de kern te plaatsen zonder dat u speciale deals hoeft te sluiten met uw lokale internetprovider, en met veel meer veerkracht dan u zich waarschijnlijk zou veroorloven, tenzij u op zijn minst meerdere containers van 20 voet vol heeft. van de serverschaal van de computerbehoefte

https://www.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..

Bewerken: als iemand geïnteresseerd is in zelfhosting, is dat eenvoudig met cloudflared. Ik heb een Google Pixelbook uit 2017 met Ubuntu op aangepaste firmware die een op Flask gebaseerde website bedient. Ik laad op op mijn bureau terwijl ik verbonden ben met een wifi-gastnetwerk. Het krijgt een 100/100 Mobile PageSpeed-score en het duurt 0,8 seconden om volledig te laden

Van DO krijg ik alle voordelen van een betrouwbaar bedrijf, schaalbaarheid, geautomatiseerde back-ups etc etc. Ik zou op geen enkele manier veranderen

De Dezner-cloud heeft nu twee Amerikaanse locaties. Er zijn echter nog steeds geen speciale Amerikaanse servers - die zouden echt werken. Zelfs als hun huidige cloudaanbod zelf al ~30% van de prijs van de grote cloud-equivalenten bedraagt.

Net als jij voer ik mijn diensten ook uit vanaf een gehuurde fysieke server. Ik gebruikte Versaweb, maar hun machines zijn te oud. Ik hield voorheen niet van Hetzner omdat ik slechte dingen had gehoord over het feit dat ze interfereerden met wat je gebruikt

Ik ben echter in december naar hen verhuisd toen mijn Versaweb-exemplaar net stierf, waarschijnlijk SSD door ouderdom. Ik betaal nu 50% van wat ik aan Versaweb heb betaald, en ik kan zes van dergelijke Postgres-instanties uitvoeren

Dan vraag je je af of het de moeite waard is om $700 of $800 te betalen voor een beheerde service met een mooie cloud-gebruikersinterface, automatische upgrades en back-ups, enz.

Voor een show voor één persoon of een kleine startup denk ik van niet. Goedkoper om een ​​beschikbare service te gebruiken en back-ups naar S3 te dumpen of iets goedkopers

Bedrijf waar ik voor werkte, betaalde bedrijf A vier keer zoveel als bedrijf B voor exact dezelfde service rekende, alleen maar omdat bedrijf A bereid was kwartaalfacturen te sturen op een manier die goed paste bij ons facturatiesysteem. Voor bedrijven is het besparen van hier en daar een paar honderd dollar vaak niet de moeite waard om extra wrijving te veroorzaken

Daar zijn impliciete kosten aan verbonden. Als het maar een of twee van die dingen zijn, neem dan gewoon de beheerde services

Als je gaat opschalen, schakel dan een beheerderstype medewerker in om hierop te besparen
Anders zou ik iemand met veel ervaring moeten inhuren of een maand of meer van mijn tijd moeten besteden (wat niet beschikbaar was), om er 100% zeker van te zijn dat we gejournaliseerde PITR-back-ups altijd snel kunnen herstellen

Ik kan op andere plaatsen enorm besparen op cloudkosten, maar geloofwaardig beheerde PostgreSQL was een vrij gemakkelijke beslissing (zelfs als het instapprijskaartje hoger was dan je zou verwachten)

Een vroege startup die het zich niet kan veroorloven een uur aan productiegegevens kwijt te raken, is waarschijnlijk toch te kwetsbaar om te overleven

Het is een vroege start - er zullen grotere onderbrekingen zijn in de service en klanten die vluchten na een verlies van productiegegevens van een uur, waardeerden het product toch niet genoeg

(Bij de specifieke startup waar ik aan dacht, had ik al een aantal mooie geautomatiseerde frequente DB-online dumps naar S3 met afgedwongen retentie, maar ik dacht niet dat dat goed genoeg was voor dit specifieke scenario. Maar omdat ik er niet zeker van was dat we daarmee konden herstellen PITR/journaling zou een nieuwe single point of fail-gok toevoegen aan het succes van een bedrijf dat anders over een paar jaar een exit van meer dan 9 cijfers zou kunnen hebben, alleen maar om er een paar honderd te redden.)
Ik veronderstel ook dat sommige van de vroege startups die minder veeleisende behoeften hebben, maar arrogant zijn over hun verplichtingen ten aanzien van de gegevens van klanten/gebruikers, nog steeds nalatig zijn met betrekking tot minimale basispraktijken.

Misschien een intuïtieve manier om het te waarderen: stel je een biz-nieuwsverhaal voor op HN, over een aantal startup-operaties die de bal laten vallen, met de namen van de oprichters van startups eraan, en het verhaal zegt en het blijkt dat ze geen goede back-ups hadden. Medeoprichters, die misschien niet veel geslapen hebben omdat hun bedrijf om hen heen crasht, antwoordt: "Klantgegevens zijn niet zo belangrijk bij een vroege startup; als dat wel zo was, zouden we te kwetsbaar zijn"(getypt voordat de medeoprichter de laptop van die persoon zou kunnen weggooien door de kamer om te voorkomen dat ze typen). Het zou geen goed gezicht zijn

Ik zal dit aan het einde bespreken

>Stel je een biz-nieuwsverhaal voor op HN, over een aantal startup-operaties die de bal laten vallen, met de namen van de startup-oprichters eraan, en het verhaal zegt en het blijkt dat ze geen goede back-ups hadden

ITYM en het blijkt dat ze geen back-up van het afgelopen uur hadden
Ik kan me alles in jouw scenario voorstellen, zelfs de niet-geknipte stukjes, en het lijkt allemaal normaal, tenzij je leest: "Onze startende klanten, die ons al een maand gebruiken, zijn allemaal onmiddellijk vertrokken toen we het laatste uur aan hun gegevens kwijt waren"Dat scenario kan ik me echt niet voorstellen

Toegegeven, er zijn een aantal bedrijven waarbij het voordeel van het gebruik ervan is dat er nog geen uur aan gegevens verloren gaat
IOW, klanten gebruiken het omdat er geen gegevens verloren gaan: bijvoorbeeld online documentsamenwerking[1][2]. Als je een meltdown hebt waarbij een uur van de laatst ingevoerde gegevens verloren gaat, verwacht dan zeker dat alle getroffen huidige gebruikers onmiddellijk vluchten

[1] Hoewel ik persoonlijk het risico zou verkleinen door het huidige document in lokale opslag te dupliceren terwijl het wordt bewerkt

[2] Misschien heeft de beurs het systeem ook nodig om het laatste uur aan gegevens bij te houden? Wat nog meer?
Ik denk dat het zelfs voor grotere teams zinvol kan zijn om zelf databases te beheren, ervan uitgaande dat je de competentie hebt om het goed te doen. Er zijn zoveel dingen die fout kunnen gaan met beheerde services en ze verbergen de onderliggende implementatie niet zoals zaken als blokopslag of objectopslag dat doen

Piekprestaties zijn zeker slechter - maar het maakt me niet al te veel uit als iets toch langer duurt. Je hebt zeker gelijk als je zoveel automatisering hebt bij het inrichten van een server, iets wat ik niet deed met een fysieke server

Ik had vroeger een rootserver voor mijn pet-projecten, maar eerlijk gezegd slaat dat nergens op. Ik heb geen druk verkeer, bereken intense SaaS op mijn machines. Het is gewoon een statische website en wat projecten. Ik heb maandelijkse kosten van 24, inclusief een opslagbox van 1 TB om al mijn gegevens op te slaan

Het belangrijkste probleem in elk scenario met echte hardware is dat je personeel nodig hebt dat bekwaam is in zowel hardware als Linux/UNIX-systemen. Velen beweren op hun cv te staan ​​en kunnen dan niet één keer op het werk presteren (in mijn ervaring in ieder geval). Naar mijn mening was een van de belangrijkste redenen voor de explosie van de cloudwereld juist de moeilijkheid om dergelijke teams op te bouwen en de financiële kosten ervan. Bovendien is er een enigszins natuurlijke (en noodzakelijke) wrijving tussen applicatieontwikkelaars en systeemmensen. De systeemmensen moeten altijd terugdringen en pleiten voor meer beveiliging, meer processen en minder implementaties. Het ontwikkelteam zou altijd moeten pleiten voor meer flexibiliteit, meer releases en minder processen. Goed management moet dan de middenweg tussen beide vinden. Helaas hebben incompetente managers vaak net besloten om systeemmensen uit de weg te ruimen en dingen naar AWS-land te verhuizen

Tot slot zou ik nog willen opmerken dat cloudarchitectuur slecht is voor de planeet, omdat het overprovisioning door cloudproviders vereist, en het vereist over het algemeen meer computerkracht vanwege de vele abstractielagen. Hoewel elk project verantwoordelijk is voor weinig van deze verspilling, is de hele wereldwijde cloud als geheel zeer verspillend. Dit stoort me en uiteraard waarschijnlijke factoren als een emotionele vooringenomenheid in mijn opvattingen (zo grote hoeveelheden zout voor al het bovenstaande)
Het argument zou kunnen worden aangevoerd dat u een manier kunt ontwikkelen om fysieke servers vóór inkomen te huren, en vervolgens, wanneer het zinvol is, ofwel standaardafschrijving kunt gebruiken -of- artikel 179 voor rechtstreekse aankopen en/of artikel 179-leasecontracten

U kunt bijvoorbeeld een ongelooflijk capabele groep van, laten we zeggen, vier absoluut volledig overgeprovisioneerde fysieke 1U-machines van $ 100.000 inzetten in verschillende colo-faciliteiten voor redundantie. Er zijn hier allerlei trucs voor load balancing en failover met XYZ-cloudservice, DNS, anycast, wat je maar wilt. U kunt kiezen voor verschillende colo-faciliteiten die datacenters over de hele wereld exploiteren, de hardware van de leverancier naar hen verzenden en ze vervolgens voorzien van Ansible of wat u maar wilt zonder ooit de faciliteit te zien of hardware aan te raken

Dus nu heb je redundante fysieke hardware die absoluut rond de meeste cloudproviders zal draaien (vooral voor I/O), vaste kosten zoals alles wat je kunt bandbreedte (die niet de 800% markup van cloudservices heeft, enz.) - niet meer wachten voor de onvermijdelijke cloudrekening van $ 50.000 of proberen (in paniek) op te sporen waardoor u uw geconfigureerde cloudbudget binnen een dag in plaats van een maand overschreed. Oh trouwens, je sluit jezelf niet op in de gekke propriëtaire API's om andere services dan virtuele machines aangeboden door $BIGCLOUD te voorzien en zelfs te gebruiken

Als je ML doet, kun je trainen op je eigen hardware of (of af en toe een cloud) en 24/7 gevolgtrekkingen uitvoeren met zaken als de NVIDIA A10. Voortdurende cloudverhuur voor GPU-instances is ongelooflijk duur en de ROI bij aanschaf van de hardware ligt doorgaans binnen een bereik van een paar maanden (of vrijwel onmiddellijk ver vooruit met Section 179). Ik heb bijvoorbeeld onlangs een benchmark gedaan met de Nvidia A10 voor een model dat we bedienen en het kan meer dan 700 deductieverzoeken/s doen in FP32 met een latentie van minder dan 10 ms. Met een enkele A10 per chassis over vier gezonde instanties is dat 2800 req/s (en kan waarschijnlijk verder worden afgesteld)

Als je dan ECHT groot wordt, kun je beginnen met het krijgen van kasten en meer. In termen van hardwarestoringen zoals vermeld, kan ik alleen maar zeggen dat dual PS RAID-ed out, enz. Hardware is (naar mijn ervaring) uiterst betrouwbaar. Ik heb in het verleden meerdere volledige kasten met hardware gehad, hardwarestoringen waren er maar heel weinig tussen en hardware leveranciers zullen ongelooflijke SLA's opnemen voor vervanging. U stelt hen op de hoogte van de storing, zij sturen een techneut< acht uur rechtstreeks naar de colo-faciliteit en de schijf, PS, enz. Vervangen door het knipperlicht

Mijn ervaring is dat een (goede) FTE-resource dit gemakkelijk kan beheren tot meerdere kastschalen. Naar uw mening is het huidige probleem dat veel van deze mensen zijn weggerukt door de grote cloudproviders en (in de markt) zijn vervangen door middelen die kunnen navigeren door de grens van belachelijkheid die tientallen (zo niet meer) producten / diensten van $ BIGCLOUD

Ik heb ook ontdekt dat deze configuratie eigenlijk VEEL betrouwbaarder is dan de meeste $BIGCLOUD. Je hoeft je niet meer af te vragen wat er aan de hand is met een $BIGCLOUD-storing die ze niet eens erkennen (en waar je absoluut geen controle over hebt). Omdat ik een achtergrond heb in telecom en gezondheidszorg, vind ik het volkomen gek hoe de uptime bij cloudproviders veel slechter is geworden. Gewoonlijk kun je klanten gewoon vertellen "oh het internet heeft vandaag problemen", omdat ze er waarschijnlijk de krantenkoppen over zullen zien, maar voor veel toepassingen is dat gewoon totaal onaanvaardbaar - en we zouden beter moeten verwachten

[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
Als ik een nieuw project wil opstarten of iets nieuws wil hosten, duurt het een paar minuten en ik heb de scripts. Implementaties zijn snel, onderhoud is laag en ik heb veel meer waar voor mijn geld

Voor iedereen die geïnteresseerd is, is dit de ruwe versie van wat ik gebruik:
* Ansible om alles te beheren
* Een klein beetje terraform voor sommige DNS-vermeldingen die ik op een dag kan vervangen
* restic voor back-ups, opnieuw gecontroleerd door ansible
* staartschaal voor vpn (ik heb thuis wat pi's draaien, niets belangrijks, maar staartschaal maakt het gemakkelijk en veilig)
* docker-compose voor vrijwel al het andere
De belangrijkste app is Clojure, dus ik voer een native JVM uit. Database is volledig gedistribueerd, RethinkDB, werkt nu aan de overstap naar FoundationDB

Het belangrijkste is om niets handmatig te beheren, b.v. behandel fysieke servers net als elke andere cloudserver. Het zou niet uit moeten maken of het fysiek of gevirtualiseerd is

Ik heb veel minder ervaren mensen te veel zien betalen voor hetzner en dergelijke terwijl een vps van $ 5-10 zou hebben gewerkt

Ja, je ondersteunt op dat moment je eigen hardware. Nee, het is geen enorme hoofdpijn

De grootste extra kosten hiervoor zijn het huren van meer IPv4-adressen, die Hetzner flink in rekening brengt nu er zo weinig beschikbaar zijn

Wat je ook maakt, het begint met 0 gebruikers, en een hele echte machine is compleet overdreven voor die 0 lading die je krijgt. U upgradet uw VPS naar een paar echte machines, vervolgens naar een klein gehuurd cluster en vervolgens naar een datacenter (als iemand dat niet ondermijnt). Die hebben allemaal voorspelbare rekeningen en topprestaties voor hun prijs

Alles wat je in een colo bezit, wordt ook meer per maand. Toen ik verbindingen had waarbij ik voor een statisch IP-adres kon betalen, was dat meestal $ 5 per maand
Ik huur nu een vrij goedkope server, maar het kost $ 30 per maand. Veel meer alles wat ik nodig heb, maar het is leuk. En ze hebben de ondersteuning voor mijn besturingssysteem niet stopgezet terwijl ze de prijzen verhoogden om de ondersteuning te verbeteren of zoiets. (Hoewel ik aanvankelijk wat zwakke hardware had die vervangen moest worden)
zoals je al zei, is bare metal de juiste keuze. Het werkt het tegenovergestelde van de cloud: in het begin wat meer werk, maar aan het eind veel minder kosten

Meer info httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..

Het opzetten en beheren van Postgres is lastig. Het zou fijn zijn als er een eenvoudigere manier was om dit allemaal goed te krijgen

1. Dwingt de configuratie reproduceerbaar te maken, omdat VM's uitvallen

2. U kunt flinke kortingen krijgen op AWS die de pijn verminderen

3. De andere dingen waartoe je toegang hebt bovenop de VM's, zijn goedkoper/sneller zodra je spullen al in de cloud staan
4. Het is gemakkelijker om een ​​gedocumenteerde systeemconfiguratie te hebben (bijvoorbeeld AWS-documenten) dan mensen op te leiden/te documenteren welke speciale dingen je in huis hebt. Vooral handig bij het aannemen van nieuwe mensen

5. U heeft geen ruimte of redundante stroom/internet/etc op locatie nodig. Net genoeg om mensen hun laptop te laten gebruiken

Ik gebruikte daarvoor een VPS, maar stopte en schakelde over naar een fysieke omdat dit een betere deal was en we niet tegen CPU-limieten aanliepen

Schijfmonitoring is echter niet zo moeilijk. Voor harde schijven voert u smartctl één keer per uur uit en waarschuwt u wanneer opnieuw toegewezen of in behandeling zijnde sectoren snel groeien of de 100 bereiken. Voor SSD's: kruis uw vingers; in mijn ervaring met een paar duizend werken ze meestal prima totdat ze uit de bus verdwijnen en nooit meer worden gezien. Zorg voor een dataherstelplan waarbij de gegevens niet worden opgeslagen op apparaten van hetzelfde model met zeer vergelijkbare power-on-hourspower-on-hour gecorreleerde firmwarefouten zijn reëel

Hetzner heeft een API om toch dedicated servers te bestellen, en een API om een ​​besturingssysteem te installeren (of om opnieuw op te starten om de gewenste afbeelding te redden en te flashen)
Ik denk dat als ik commerciële opties zou onderzoeken, ik de "trunk"op kantoor zou laten sorteren met een commerciële ISP-oplossing, statisch IP-adres, goede IT-hardware misschien, maar van wat ik op dit exacte moment weet, als een klant hosting nodig had, zou ik 'd ga altijd direct over naar het huren van een vps

Ik was destijds meer een junior-ontwikkelaar, dus misschien was ik dat wel, maar ik mis het helemaal niet. In theorie ben ik het eens met wat je zegt, maar het implementeren van een Dockerfile naar zoiets als Google Cloud Run is gewoon een stuk eenvoudiger. Ja, ik betaal meer dan wat ik mijn eigen VPS zou beheren, maar ik denk dat dit ruimschoots wordt gecompenseerd door de bespaarde ontwikkeluren

- fysieke hardware heeft problemen, b.v. ventilatorfout ->mijn VM wordt live gemigreerd naar een andere host, ik merk het niet en het kan me niets schelen
- fysieke hardware explodeert ->mijn VM start opnieuw op een andere host, ik merk het misschien, maar het kan me niet schelen
 Rampenplanning is een stuk eenvoudiger met VM's (zelfs met huisdieren en geen vee)

Voor een beginner krijgen de goedkoopste het werk gedaan

Ik ben er zeker van dat naarmate cloud computing evolueert, dit aanbod steeds gebruikelijker wordt

Er is nog een ander aspect van cloud computing. De middelgrote tot grote bedrijven rekenen cloud computing als percentages van één cijfer in hun kostenberekeningen. Dit betekent dat de beslissingen die door managers en teams worden genomen, vaak zoeken naar betrouwbaarheid en schaalbaarheid (om in hun presentaties te plaatsen) in plaats van "is mijn opstelling duur of goedkoop"Mijn werkgever adopteerde de cloud als een zakelijk/financieel spel, niet als een religieus spel. Vaak plaatsen we nieuwe builds in de cloud en migreren we later indien nodig naar een datacenter

De apps op locatie kosten ongeveer 40% minder. Apps die kosteneffectiever zijn in de cloud, blijven daar

Ik denk dat het waar is dat AWS/GCP/Azure geen erg kostenconcurrerende aanbiedingen zijn in Europa. Wat ik niet zie, is daarvan een bewijs voor de VS

voor dezelfde specificaties, zeker. Ik denk dat virtuals aan beide kanten zinvol zijn: óf dynamische schaalbaarheid voor grote N is belangrijk, óf je hebt eigenlijk maar een klein deel van een fysieke doos nodig. 45/maand betalen voor iets dat find op 5/maand draait is ook niet verstandig, en geeft je meer flexibiliteit om dingen niet samen te voegen alleen maar om je server te gebruiken

Bewaar in ieder geval back-ups. Bij voorkeur bij een andere aanbieder of in ieder geval op een andere fysieke locatie. En natuurlijk testen

En als u een goed back-upregime beheert en toch uw gegevens/app monitort, levert monitoring dan een aanzienlijk extra probleem op?
--
[1] Als je het herstelproces naar een andere locatie automatiseert, wat ik voor een paar van mijn bits doe, dan kun je gewoon op die knop drukken en DNS bijwerken wanneer dit voltooid is, en misschien wat meer RAM+cores toewijzen (mijn test mirrors zijn kleiner dan de live VM's, omdat ze geen echte gebruikspatronen hoeven te bedienen)

Precies wat ik doe voor mezelf en mijn klanten. Bespaart tonnen dosh

Zelfs als ik zou willen updaten, is het gewoon een kwestie van de nieuwste versie naar de docker-compose-sjabloon halen en het ansible-playbook opnieuw uitvoeren. Het is duidelijk dat als de upgrade meer vereist, het zij zo, maar qua werk is het niet anders dan bij andere configuraties

Waarschijnlijk is het enige dat ik handmatig moet doen, het testen van mijn back-ups. Maar ik heb voor elk project een script dat dit doet, dus ik gebruik gewoon SSH, voer de oneliner uit, controleer het resultaat en het is klaar. Dat doe ik ongeveer een keer per maand, maar ik krijg ook e-mails als een back-up mislukt
Het kan dus helemaal geen tijd zijn. Meestal is het waarschijnlijk 1-2 uur per maand als ik op semi-regelmatige basis updates ontvang. Maar dat zal toenemen naarmate u meer dingen host en beheert

Met andere woorden: het enige verschil is waar het weerwortinventarisbestand vandaan komt. Of het is een statische lijst met IP's, of het komt van terraform

Als je ECC RAM wilt, lijkt dat 60 per maand te zijn, en het gaat ook over naar een krachtigere 8-core CPU

Hoe dan ook, als we het hebben over een "volledige productieomgeving en een dubbele staging/standby-omgeving"(om de persoon te citeren waarop je hebt geantwoord), dan is 60/maand * (2 of 3) nog steeds spotgoedkoop vergeleken met de AWS van elke startup rekening die ik heb gezien

De gebruiksscenario's variëren, maar ik ben het er meestal mee eens dat AWS/GCP/Azure niet het antwoord op elk probleem is

Voor iemand die zijn applicatie op een VPS van $ 4 kan passen, zal dat uiteraard goedkoper zijn dan alles wat bare metal is, maar de cloud schaalt in veel gevallen erg duur op. Bare metal is ook niet het antwoord op elk probleem, maar veel mensen in de branche lijken het niet op prijs te stellen wanneer dit het juiste antwoord kan zijn.