Wie viel können Sie aus einem 4-Dollar-VPS herausholen?

Virtualisierte Angebote schneiden deutlich schlechter ab (siehe meine Experimente von 2019: httpsjan.rychter.com/enblog/cloud-server-cpu-performance) und kosten mehr. Der Unterschied besteht darin, dass man „nach Bedarf skalieren“ kann, was ich nicht für notwendig hielt. Zumindest in meinem Fall. Und wenn ich skalieren muss, kann ich das immer noch tun, nur dass die Anschaffung neuer Server Stunden statt Sekunden dauert. Nun, ich muss nicht in Sekunden skalieren

In meinem Fall ist meine gesamte monatliche Rechnung für die vollständige Produktionsumgebung und eine duplizierte Staging-/Standby-Umgebung konstant, einfach, vorhersehbar, sehr niedrig im Vergleich zu dem, was ich AWS bezahlen müsste, und ich habe immer noch viel Leistungsspielraum

Bemerkenswert ist, dass ich physische Server genauso behandle wie virtuelle: Alles wird über Ansible verwaltet und ich kann alles von Grund auf neu erstellen. Tatsächlich verwende ich bei Digital Ocean eine andere „Devcloud“-Umgebung, und diese wird mit Terraform erstellt, bevor sie an Ansible übergeben wird, das den Rest der Einrichtung übernimmt

Ich vermute, dass VendorOps und komplexe Tools wie Kubernetes von Komplexitätshändlern bevorzugt werden, die im letzten Jahrzehnt entstanden sind. Es sieht im Lebenslauf gut aus und vermittelt Technologieführern ein falsches Erfolgserlebnis

Mittlerweile läuft Stackoverflow, das wohl wichtiger ist als die meisten Startups, auf dedizierten Rechnern

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

Es scheint, als ob der Trend in diesem Bereich darin besteht, direkt zur höchsten Abstraktionsebene zu springen. Überspringen Sie die Grundlagen und verweisen Sie auf Tools, Bibliotheken und Produkte von $buzzword

Einblicke hiervon gibt es in unterschiedlicher Form. Eine davon sind Social-Media-Threads, in denen Dinge wie „Wie viel von X muss ich wissen, um Y zu lernen“ gefragt werden, wobei

CORBA gehört dorthin. Und vielleicht sogar das Semantic-Web-Zeug. Auf jeden Fall XML!
XML ist großartig – wenn Sie es nicht glauben, dann interessieren Sie sich vielleicht für die Mühe, die das Parsen von JSON mit sich bringt: httpseriot.ch/projects/parsing_json.html
Und lassen Sie mich nicht mit YAML anfangen.

Für mich lohnen sich die zusätzlichen Kosten, die eine Cloud mit verwalteten Datenbanken, automatischen Snapshots, gehosteten Load Balancern, Plug-and-Play-Blockspeicher usw. mit sich bringt, auf jeden Fall
Ich möchte mir Gedanken darüber machen, ob unser Produkt gut ist, und nicht über Hardwareausfälle mitten in der Nacht, über das Hochfahren eines neuen Servers und dessen Fehlfunktion, weil es keinen Anreiz gab, das Konfigurationsmanagement mit einer einzigen Box zu nutzen und eine einzige außer Kontrolle geratene Aufgabe zu haben verursachen OOM oder eine volle Festplatte und machen alles kaputt, anstatt nur die Aufgaben der VM, Angst vor dem Neustart einer Maschine, die seit 1000 Tagen in Betrieb ist usw

Für mich liegt der Reiz der Cloud nicht in einer Modeerscheinung der FAANG-Skalierbarkeit, wenn sie nicht erforderlich ist, sondern in automatischem Betriebssystem-Patching, automatischem Lastausgleich, NAT-Diensten, zentralisierten, analysierbaren Protokollen und Datenbankdiensten, die ich nicht verwalten muss Box-Rolling-Upgrades für Dienste, Verwaltung von Kryptoschlüsseln und Geheimnissen und natürlich Objektspeicher. (Das sind alles Dinge, die wir in unserem Startup verwenden)
Ich würde es auf die leichte Schulter nehmen und sagen, dass dedizierte Server ab einer bestimmten Größenordnung sehr rentabel/kosteneffizient sein können, und nicht umgekehrt. Im Moment lohnen sich die Cloud-Kosten für mein Startup

Wenn Sie Ihre Umgebungskonfiguration als Code durchführen, sollte es letztendlich keine Rolle spielen, ob Ihr Ziel ein dedizierter Server, eine VM oder ein cloudspezifisches Setup ist, das über eine API konfiguriert wird

Es spielt keine Rolle, welche, der Punkt ist, dass Sie eine haben, die Ihnen eine neue Box bauen oder eine sich schlecht verhaltende Box wieder in einen funktionierenden Zustand versetzen kann, indem Sie einfach einen Befehl ausführen

Sicher, der eigentliche Go(o)-Stapel, der ihn antreibt, kann verbessert werden (und er verbessert sich tatsächlich).

Die harte Wahrheit ist jedoch, dass Ihr Ansatz der richtige ist. Fast alle Unternehmen (Startups!) überbauen, anstatt sich auf die Bereitstellung von Mehrwert, die Identifizierung der eigentlichen Nische usw. zu konzentrieren. (Ja, es gibt auch die Nachfrageseite, da die Mit VC-Geldern aufgeblähte Start-ups bauen zu stark darauf auf, auf Dritte angewiesen zu sein, die die Last tragen und mit ihnen skalieren können. SLAs und so weiter müssen beworben werden.)
Kubernetes ist fantastisch! Immer wenn ich sehe, dass ein potenziell konkurrierendes Unternehmen Kubernetes nutzt, bin ich sofort erleichtert, da ich weiß, dass ich mir um sie keine Sorgen mehr machen muss. Sie sind dabei, in einem Haufen unlösbarer technischer Probleme zu verschwinden, indem sie versuchen, Probleme zu beheben, die sich in einem Tech-Stack von unglaublicher Komplexität nicht aufspüren lassen, und indem sie die Einschränkungen umgehen, die ein System mit sich bringt, das für Unternehmen mit einem um zwei bis drei Größenordnungen größeren Datenverkehr konzipiert ist. Außerdem werden ihre COGS viel höher sein als meine, was bedeutet, dass sie ihr Produkt höher bepreisen müssen, es sei denn, sie verbrennen nur VC-Geld (in diesem Fall sind sie eine Eintagsfliege).

Rundum gute Sachen

Ansible ist zwingend erforderlich, es kann auf einen statischen Zustand hinarbeiten, und das war's. Wenn ein Problem auftritt, bricht es die SSH-Verbindung ab, stößt Unmengen von Python-Fehlern aus und gibt für immer auf. Trotz seines Inventars ist es alles andere als deklarativ
k8s besteht aus Regelkreisen, die versuchen, sich ihrem deklarierten Zustand zu nähern. Ein Fehler ist kein Problem, es wird ein neuer Versuch unternommen. Es überprüft ständig seinen eigenen Status, verfügt über eine nette API, um ihn zu melden, und dank vieler verifizierter Konzepte ist es schwieriger, seltsame Konflikte zwischen bereitgestellten Komponenten zu haben. (Während die Integration mehrerer Playbooks mit Ansible nicht trivial ist.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
Und auch wenn k8s zu sehr auf Vermächtnis setzt, gibt es bald schlankere Ausprägungen der Kernideen. (Zum Beispiel httpsgithub.com/aurae-runtime/aurae)
Und jetzt schlagen Sie vor, dass die Leute eine einfachere, nicht standardmäßige Implementierung verwenden?
Sie können also natürlich eine Lösung mit minimaler Komplexität implementieren oder etwas „von der Stange“ verwenden.

k8s ist komplex und einiges davon ist für Ihre Situation definitiv unnötig, aber es ist auch ziemlich allgemein, flexibel, gut unterstützt usw

>Schlagen Sie vor, dass die Leute eine einfachere, nicht standardmäßige Implementierung verwenden?
Was ich vorgeschlagen habe, ist, dass die Leute zu einer Alternative wechseln können, wenn das Projekt/die Software zu groß wird, um zu scheitern. Glücklicherweise sind die k8s-Konzepte und die API Open Source, sodass sie in anderen Projekten implementiert werden können, und ich habe ein solches Beispiel gegeben, um zu veranschaulichen, dass die Auswahl von k8s keine Oracle-ähnliche Anbieterbindung darstellt

Ich höre immer von all den tollen Dingen, die man von Cloud-Anbietern praktisch kostenlos bekommt. Ist das Zeug wirklich so einfach einzurichten und zu verwenden? Jedes Mal, wenn ich versuchte, meinen LAMP-Stack auf einem Cloud-Dienst einzurichten, war der Prozess so verwirrend und beängstigend, dass ich schließlich aufgab. Ich frage mich, ob ich mich einfach noch ein bisschen mehr anstrengen muss, um den Wolkenhimmel zu erreichen
Zu sagen: „Ich möchte hier ein geclustertes MySQL mit dieser Art von Spezifikationen“, ist (zeitlich gesehen) viel besser, als es alleine zu tun. Die Updates sind außerdem gut im System integriert, daher sage ich nur „das neueste Update anwenden“, anstatt manuell sicherzustellen, dass Failover/Neustarts in der richtigen Reihenfolge erfolgen

Sie zahlen also für die Vereinfachung, aber der Gewinn aus dieser Vereinfachung stellt sich erst bei größeren Projekten ein. Wenn Sie auf einem einzelnen Server etwas haben, das Sie neu starten können, während Ihre Benutzer eine Fehlerseite erhalten, lohnt sich das möglicherweise nicht

Die Cloud ist nicht einfach, aber der Versuch, die Kühlung und Energieeffizienz eines kleinen Serverraums auch nur annähernd auf das Effizienzniveau zu bringen, das die meisten großen Rechenzentren veröffentlichen, ist nahezu unmöglich, ebenso wie die Internetkonnektivität mehrerer Anbieter

Mit der Cloud entfällt all das, da es von dem jeweiligen Rechenzentrumsbetreiber verwaltet wird, auf dem die Cloud läuft. Was die Leute jedoch vergessen, ist, dass dies auch für altmodische Colocation-Dienste gilt, die oft ein besseres Preis-Leistungs-Verhältnis bieten als die Cloud
Und während es auf jeden Fall schwieriger ist, Dinge wie AWS oder Azure zu verwalten, weil dadurch viele Abstraktionen verloren gehen, die kleine Scall-VPC-Anbieter vor Ihnen verbergen oder die Sie mit einem einzelnen Heimserver nicht wirklich bekommen, ist es in der Größenordnung nicht schwer, mehrere davon betreiben zu müssen von Racks im Wert von VMware-Servern mit SAN-basiertem Speicher  Bei Cloud-Anwendungen müssen Sie mehr Konfigurationen durchführen, da es um die Konfiguration virtueller Server usw. geht. Anstatt den PC in einer Box in Ihr Zimmer zu tragen, müssen Sie ihn „konfigurieren“, um ihn verfügbar zu machen  DO-Datenbanken verfügen über Backups, die Sie nach Ihren Wünschen konfigurieren und in DO Spaces (wie S3) speichern können. Die DB-Benutzerverwaltung ist einfach. Es gibt auch Cache-Server für Redis  Sie können einen Load Balancer hinzufügen und ihn mit Ihren verschiedenen Webservern verbinden  Ich glaube, ich habe etwa 30 Minuten gebraucht, um zwei Webserver, einen DB-Server, einen Cache-Server, einen Load Balancer und einen Speicherserver einzurichten und sie alle nach Bedarf mithilfe einiger einfacher Formulare zu verbinden. Das ist wirklich nicht zu schlagen  Wenn Sie weitere Informationen oder Meinungen haben, teilen Sie diese bitte mit  Im Internet gibt es viele Artikel über das Absichern eines Linux-Servers. Bei denen, die ich ausprobiert habe, dauert es etwas mehr als 30 Minuten, bis ich die einzelnen Schritte befolgt habe, viel länger, wenn ich wirklich lernen und verstehen möchte, was die einzelnen Dinge tun und warum Es ist wichtig, was die zugrunde liegende Schwachstelle ist und wie ich möglicherweise einige Einstellungen für meinen speziellen Anwendungsfall anpassen muss  Ich bin mir sicher, dass Sie Beispiel-Setup-Skripte online finden können (die Konfiguration von automatischen Updates, Firewall, Anwendungen usw. sollte durch Ausführen von „curl $URL“ und dann „chmod +x $FILE“ und „bash $FILE“ erfolgen). Ich brauchte kein Konfigurationsmanagement (ich nutze den Backup-Dienst meines Anbieters, was meiner Meinung nach wichtig ist)  Etwa so: httpsraw.githubusercontent.com/potts99/Linux-Post-Install..  (gesehen in httpswww.reddit.com/r/selfhosted/comments/f18xi2/ubuntu_d) Das Gleiche gilt natürlich auch für VMs mit langer Laufzeit, und dieses Problem kann durch ein diszipliniertes Team gelöst werden. Ich denke jedoch, dass dies im Allgemeinen in einer Umgebung mit einer einzigen dedizierten Maschine mit langer Laufzeit wahrscheinlicher ist  Hetzner verfügt über all dies außer verwalteten Datenbanken  httpswww.hetzner.com/managed-server Die Webhosting-Pakete beinhalten außerdem 1..unbegrenzte DBs (MySQL und PostgreSQL) httpswww.hetzner.com/webhosting/ Verfügt es über automatische Sicherung und Failover? >Bei gebuchter täglicher Sicherung oder der im Servertyp inkludierten Sicherung werden alle Daten täglich gesichert und maximal 14 Tage vorgehalten. Die Wiederherstellung von Backups (Restore) ist über die konsoleH-Administrationsoberfläche möglich  Aber ich habe den Eindruck, dass die Datenbanken auf verwalteten Servern für die Verwendung durch Apps gedacht sind, die auf diesem Server ausgeführt werden, sodass es kein wirkliches Failover-Konzept gibt  httpswww.hetzner.com/legal/managed-server/ Der Ausfall eines einzelnen Laufwerks auf einem einzelnen Server sollte niemals zu einem Produktionsausfall führen  Viele Konfigurationsprobleme lassen sich auf eigenständige Bereitstellungen zurückführen. Muss diese Schriftartdatei oder JRE wirklich auf dem gesamten Server installiert werden, oder können Sie sie in Ihrer Bereitstellung bündeln?  Unsere Bereitstellungen verwenden On-Premise- und EC2-Ziele. Das Bereitstellungsskript unterscheidet sich nicht, nur die IP für den Host  Nun möchte ich sagen, wenn ich S3 für etwas verwenden kann, werde ich es zu 100 % tun. Es gibt keine On-Premise-Alternative mit demselben Funktionsumfang  Bei DevOps geht es um „Rinder, nicht um Haustiere“. Setzen Sie einmal pro Woche eine Kugel in Ihren Server ein, um Ihre Fehlerquellen zu finden  Ich würde mich freuen, wenn Sie in unseren Discord/Slack einsteigen und einige der Probleme ansprechen würden, die Sie gesehen haben, damit wir das Erlebnis für andere, die Dokku nutzen, zumindest verbessern können. Fühlen Sie sich frei, mich dort oben zu kontaktieren (mein Spitzname ist „savant“)  Lassen Sie mich vorab sagen, dass ich ein Anwendungsentwickler bin, der nur über Grundkenntnisse in Docker verfügt.Ich kenne mich mit Infrastruktur nicht besonders gut aus und die Anwendung, mit der ich zu kämpfen hatte, weist besondere Bereitstellungsparameter auf: Es handelt sich um eine Python-App, die zur Erstellungszeit mehrere Gigs statischer HTML-Crawls analysiert, um eine Postgres-Datenbank zu füllen, die nach der Erstellung statisch ist. Eine Flask-Webanwendung stellt dann diese Datenbank bereit. Das HTML-Parsing entwickelt sich schnell weiter und daher sollten die gefüllten DB-Daten als Teil der Anwendungsbilder gebündelt werden.  IIRC, ich hatte Probleme mit der Strukturierung von Docker-Dateien, als die Datenbank nicht dauerhaft, sondern nur ein weiterer vorübergehender Teil der App war, aber es schien überwindbar. Das größere Problem schien zu sein, wie man vermeiden kann, für jeden Build große Mengen selten geänderter Daten aus S3 abzurufen, wenn diese idealerweise zwischengespeichert würden, insbesondere auf eine Weise, die sich in DigitalOcean und meiner lokalen Umgebung einwandfrei verhält. Ich gehe davon aus, dass das richtige Docker-Image-Layer-Caching das Problem lösen würde, aber ich hatte ziemlich schnell das Ende meines Wissens und meiner Geduld erreicht  Dokkus DX scheint großartig für Leute zu sein, die normale Dinge tun. :) :) 0. httpscoolify.io/ Und wer möchte nicht für den Cent eines anderen mit dem neuesten, coolsten Spielzeug spielen? Es gibt definitiv ein Argument dafür, (einige) Dinge später auf der Reise aus der Cloud zu verlagern, wenn Flexibilität (oder der Umgang mit Flux/Pivoting) weniger zum primären Faktor wird und Größe/Kosten dominieren  Natürlich können Sie mit Hetzner etwas zum Laufen bringen, aber seien Sie darauf vorbereitet, noch viel mehr Fragen zu beantworten  Ich bin mit Ihrer letzten Frage in Ihrem Unternehmen einverstanden, was wiederum einfach traurig ist, dass diese geschäftlichen „Anforderungen“ vorschreiben, wie Sie Ihre Software entwerfen und hosten, obwohl ein anderer Weg möglicherweise der viel bessere ist Disaster Recovery ist ein sehr reales Problem. Deshalb teste ich es regelmäßig. In einem Szenario mit verbrannter Erde kann ich in weniger als einer Stunde auf einem sekundären (Staging-)System oder einem terraformierten Cloud-System betriebsbereit sein. Für mein Unternehmen reicht das 
Wir erlebten einen Wachstumsboom, und wie alle zuvor bedeutete dies, dass vielen unerfahrenen Menschen viel Geld und dringende Erwartungen in die Hand gedrückt wurden. Es ist ein Rezept für Frachtkult und ausbeuterisches Marketing

Aber das Wachstum verlangsamt sich und das Geld wird teurer. Machen Sie also langsamer und beginnen Sie, die alten Lektionen mit aufregenden neuen Variationen neu zu lernen. (Wie hier: Verwaltung der Bare-Metal-Skalierung sowie mit Containern und Orchestrierung)
Und der ganze Zyklus wird sich beim nächsten Boom wiederholen. Das ist im Moment unsere Branche

Ein solider dedizierter Server ist in 99 % der Fälle weitaus nützlicher als ein lahmgelegter VPS auf gemeinsam genutzter Hardware, aber er ist natürlich mit höheren Kosten verbunden, wenn Sie nicht alle von ihm bereitgestellten Ressourcen benötigen

Ja – aber die Sehnsüchte danach, „das zu tun, was all die coolen Kids jetzt machen“, sind bei denen, die man normalerweise als „Manager“ bezeichnen würde, mindestens genauso stark wie bei denen, die man als „Angestellte“ bezeichnen würde.

Ergebnis A) Riesige Microservices-/Cloud-Ausgaben gehen schief. Nun, Sie haben sich zumindest an Best Practices gehalten, diese Dinge passieren, was können Sie tun?

Ergebnis B) Sie haben sich für einen Hetzner-Server entschieden und etwas ist schief gelaufen. Nun, das sind Sie und hätten sich für Microservices entscheiden sollen. Viel Spaß bei der Suche nach einem neuen Job

Dies ermutigt Manager, sich für Microservices/Cloud zu entscheiden. Es ist vielleicht nicht die richtige Entscheidung für das Unternehmen, aber es ist die richtige Entscheidung für den Manager, und der Manager trifft die Entscheidung

(Ebenso wie der Wunsch eines Beraters nach einer Erweiterung und dem Schreiben funktionierender Software, wie ich auf die harte Tour feststellen musste.)
Es besteht eine Kluft zwischen Gründern und allen anderen

Gründer glauben, dass sie jedes Jahr mehr als das Zehnfache erreichen werden

Die Realität ist, dass die Wahrscheinlichkeit, dass sie scheitern, bei 90 % liegt

In 90 % der Fälle ist es kein Problem, wenn man bei irgendetwas scheitert

In einigen 10 % der Fälle, in denen Sie erfolgreich sind, kommen Sie auch ohne die Cloud zurecht – zumindest für mehrere Erfolgsjahre, mit genügend Zeit, um bei Bedarf zu wechseln

Ich habe nur ein Ansible-Setup und es kann sowohl für virtualisierte als auch für physische Server funktionieren. Kein Unterschied. Der einzige Unterschied besteht darin, dass virtualisierte Server zuerst mit Terraform eingerichtet werden müssen und physische Server zuerst bestellt und ihre IPs in eine Konfigurationsdatei (Inventar) eingegeben werden müssen.

Natürlich achte ich auch darauf, nicht von vielen anderen Cloud-Diensten abhängig zu werden. Ich verwende zum Beispiel VpnCloud (httpsgithub.com/dswd/vpncloud) für die Kommunikation zwischen den Servern. Als Nebeneffekt habe ich dadurch auch die Flexibilität, jederzeit zu jedem Infrastrukturanbieter wechseln zu können
Mein Hauptargument war, dass virtualisierte Angebote zwar ihren Nutzen haben, es aber eine (große) Lücke zwischen einem Hobby-VPS für 10 $/Monat und einem Unternehmen mit explodierend wachsendem B2C-Geschäft gibt. Die meisten neuen Unternehmen fallen tatsächlich in diese Lücke: Bei einem profitablen B2B-SaaS kann man kein exponentielles Wachstum erwarten. Hier sollten Sie die übliche Standardauswahl „AWS verwenden“ in Frage stellen. Da mir meine COGS und meine Margen am Herzen liegen, überlege ich mir diese Wahl sehr genau

Sie sind kein Softwareunternehmen, im Grunde produzieren und verkaufen Sie Sprockets

Die Meinungen hier wären, dass man ein großes Technik-/IT-Personal einstellen soll, um „Server zu kaufen und zu warten“ (PaaS ist schlecht) und dann wahrscheinlich „einen Teil des Codes selbst schreibt“ (SaaS ist schlecht) oder was auch immer hier gerade beliebt ist (letzter Thread hier). „PHP über SFTP ohne Git pushen, und du weißt, dass du mehr brauchst“ lol)
Aber ich bin der Meinung, dass Unternehmen eine Sache gut machen sollten und es vermeiden sollten, um Dinge außerhalb ihrer Kernkompetenz zu konkurrieren (diese Aufgabe manuell zu erledigen). In diesem Fall würde ich auf jeden Fall der Meinung sein, dass Sprocket Masters nicht versuchen sollten, ihre eigene Hardware zu verwalten, sondern sich auf einen Anbieter verlassen sollten, der sich um Skalierung, Sicherheit, Betriebszeit, Compliance und all die kleinen Details kümmert. Ich bin auch der Meinung, dass ihre Software dem Standard entsprechen sollte und so wenig firmenintern wie möglich vorhanden sein sollte. Sie sind kein Software-Shop und sollten so wenig Code wie möglich schreiben

Realistisch gesehen könnten Widget Masters diese Websites mit eher kleinem Personal betreiben, es sei denn, sie entscheiden sich dafür, alles manuell zu erledigen. In diesem Fall würden sie wahrscheinlich viel mehr Personal benötigen

Was ich jedoch auch sehe und worüber der vorherige Poster meiner Meinung nach gesprochen hat, sind Unternehmen, in denen Technologie den Kern des Geschäfts ausmacht, und dort macht sie oft weniger Sinn, und statt Zeit zu sparen, scheint sie Zeit zu kosten. Es gibt einen Grund, warum es AWS-Experten gibt: Es ist nicht trivial. Auch „echte“ Server sind nicht trivial, aber auch nicht unbedingt schwieriger als Cloud-Dienste

Aber diese Agenturen möchten auch kein Personal für die Wartung der physischen Hardware haben.

Aber Sprocket Masters muss immer noch einen teuren Cloud-Berater beauftragen, nur um auf Notfälle reagieren zu können

Wenn Sie jemanden haben, der sich um die Cloud-Probleme kümmert, können Sie stattdessen auch einen Server mieten

Ich persönlich habe früher dedizierte Server für unser Unternehmen betrieben, aber als wir expandierten und skalierten, wurde es viel einfacher, mit den Cloud-Anbietern zusammenzuarbeiten, um verschiedene Dienste schnell bereitzustellen, auch wenn die Kosten gestiegen sind. Ganz zu schweigen davon, dass es viel einfacher ist, einem potenziellen Kunden zu sagen, dass Sie eine „Cloud wie AWS“ nutzen, als „Oh, wir vermieten diese Maschinen in einem Rechenzentrum, das von einem Unternehmen betrieben wird“ (was tatsächlich besser sein kann, aber die Kunden werden das meistens nicht verstehen). . Audit, Compliance und andere

Für viele sogar deutlich weniger. Ich betreibe ein kleines Nebenprojekt[1], das ein paar Mal viral ging (30.000 Aufrufe in etwa 24 Stunden) und es läuft auf einem Single-Core-CPU-Webserver und einem verwalteten Postgres ebenfalls auf einem Single-CPU-Core. Es war noch nicht einmal annähernd voll ausgelastet
1: httpsaihelperbot.com/ Könnte ich einige davon auf Lambda-Funktionen umstellen? Oder auf ECS umsteigen? Oder sofort zu einem anderen Cloud-Dienst wechseln? Vielleicht. Aber die Zeit, die ich mit dem Schreiben dieses Kommentars verbracht habe, entspricht bereits einer Ersparnis von etwa sechs Monaten für einen solchen Wechsel. Wenn es schwieriger ist als „auf Knopfdruck einen 100 % zuverlässig übersetzten Service erhalten“, lässt es sich kaum rechtfertigen  Dies liegt zum Teil auch daran, dass die Cloud inzwischen einige andere Dienste bereitstellt, die so etwas ermöglichen. Für grundlegende Nachrichten muss ich keinen Kafka-Cluster ausführen, alle verfügen über einen Nachrichtenbus. Ich benutze das. Ich verwende die gehosteten DB-Optionen. Ich verwende S3 oder gleichwertig usw. Ich finde, dass das, was übrig bleibt, den Aufwand kaum wert ist, mich in ein anderes Paradigma einzuzwängen, wenn ich einen einstelligen Dollar pro Monat bezahle, um einfach auf einer EC2-Instanz zu laufen  Es ist durchaus so, dass dies nicht jeder bzw. jedes Projekt kann. Das ist für mich kein Endziel. Wenn es nicht funktioniert, ergreife ich sofort die entsprechenden Skalierungsmaßnahmen. Ich schlage nicht vor, dass Sie auf dieser Grundlage etwas neu entwerfen. Ich sage nur, es ist keine Option, die man verachten sollte. Es bietet viel Flexibilität und die Abrechnung ist ziemlich konsistent (oder, anders ausgedrückt, die Tatsache, dass mein System, wenn ich plötzlich das 50-fache des Datenverkehrs habe, merklich zu drosseln und zu stottern beginnt, anstatt mir einfach Hunderte von Dollar in Rechnung zu stellen mehr ist für mich eher eine Funktion als ein Fehler), und Sie bemühen sich im Allgemeinen nicht, sich in ein Paradigma zu versetzen, das für einen Cloud-Dienst praktisch ist, für Sie jedoch möglicherweise nicht  Mussten Sie jemals eine dieser Umgebungen verwalten? Die Sache ist die: Wenn Sie eine grundlegende Skalierbarkeit für mehr als eine Person und ordnungsgemäße Entwickler erhalten möchten, müssen Sie die Bereitstellung um einen erheblichen Faktor übersteigen (was möglicherweise Ihre Ersparnisse zunichte macht).  Am Ende erhalten Sie unweigerlich eine maßgeschneiderte Lösung, was bedeutet, dass es für neue Mitarbeiter schwieriger wird, sich mit dem System vertraut zu machen, und wichtige Personen, die das Unternehmen verlassen, ihre intimen Kenntnisse Ihrer Infrastruktur mitbringen. Sie sind wieder bei Haustieren statt bei Rindern. Einige Server sind etwas Besonderes, nach einer Weile bedeutet die Automatisierung „hier und da viele Glue-Shell-Skripte“ und ein Betriebssystem-Upgrade bedeutet, dass entweder die halbe Infrastruktur für eine Weile KO ist oder Sie überhaupt keine Betriebssystem-Upgrades durchführen  Und im glücklichen Fall müssen Sie den Maßstab vergrößern. Es kann sein, dass Sie unangenehme Überraschungen erleben  Und lassen Sie mich gar nicht erst mit der Networking-Seite beginnen. Sofern Sie nicht Ihr gesamtes Rack mieten und Ihre eigene Netzwerkhardware aufstellen, bekommen Sie, was Sie bekommen. Das könnte sowohl hinsichtlich der Funktionalität als auch der Leistung sehr schlecht sein, vorausgesetzt, Sie machen nichts Besonderes  Wenn Sie eine Verfügbarkeit von 100,0000 % wünschen, sicher. Aber normalerweise nicht. Die Unternehmen, die diese Art von Betriebszeit wünschen, verfügen normalerweise ohnehin über eigene Teams  Und die Skalierung funktioniert auch gut auf Bare-Metal, wenn Sie vertikal skalieren – haben Sie eine Vorstellung davon, wie viel Leistung und Durchsatz Sie von einem einzelnen Server erhalten können? Es ist besorgniserregend, immer wieder von „Skalierung“ zu hören, wenn der Sprecher „horizontale Skalierung“ meint.  Wenn Ihre Anforderungen „skalieren“, dann bringt Sie die vertikale Skalierung weit  Wenn Ihre Anforderungen „horizontale Skalierung nach Bedarf“ sind, dann helfen Ihnen Cloud-Anbieter sicherlich weiter. Aber nur wenige Orte benötigen eine solche Skalierung  Ich sage nicht, dass eine 100-prozentige Betriebszeit auf Bare-Metal-Basis billig ist, sondern dass eine 100-prozentige Betriebszeit häufig nicht erforderlich ist  Denn die Branche ist voll von Leuten, die Trends und Schlüsselwörtern hinterherjagen und bei denen es am wichtigsten ist, diese Schlüsselwörter in den Lebenslauf aufzunehmen  Das auf Skalierbarkeit abzielende IME ist für die meisten Dienste/Anwendungen/was auch immer völlig falsch. Und normalerweise zahlen Sie für die „skalierbaren“ Lösungen so viel Overhead, dass Sie dann skalieren müssen, um das auszugleichen  Das bezweifle ich wirklich.Das einzige Thema, das Sie bei fast jedem AWS-Befürworter sehen, ist ein hohes Maß an Wahnvorstellungen darüber, welche Garantien AWS Ihnen tatsächlich bietet.Ja, klar.Niemand wird entlassen, weil er bei IBM kauftNun, wenn große Unternehmen überhaupt Entscheidungskompetenz hätten, wären sie unschlagbar und es wäre aussichtslos, an etwas anderem zu arbeiten alle.Also, ja, das ist ein öffentliches GutQuelle: fast dreißig Jahre OpsBisher ist mir das nicht aufgefallen, wenn ich mehr ausgebe Für das Unternehmen, bei dem ich auch mehr bezahlt bekommeDie entsprechende Zuverlässigkeit mit Eisen zu erreichen, ist viel teurer als die Anmietung von „zwei dedizierten Servern“ – jetzt könnten Sie mit einem Server und einer Backup-Lösung zufrieden sein , und das ist fair. Aber ein System, das all das erstellt, selbst bei einem kurzen Vertrag für die Ersteinrichtung und ohne Wartung, wird weit über den Cloud-Preisunterschied hinausgehen, insbesondere wenn eine Datenbank im Mix ist und Sie sich um diese Daten kümmernHeutzutage ist es bei der Cloud ähnlich – die Markteinführungszeit ist kürzer, da es weniger bewegliche Teile gibt.Wenn die Wirtschaft abstürzt und das Wachstum nachlässt, kommen die Erbsenzähler und machen ihr DingDas passiert jedes MalDas macht AWS nur reicher bei Unternehmen und Cloud-TeamsEs ist trivial, eine EC2-Instanz innerhalb von Sekunden automatisch bereitzustellen und die Bereitstellung aufzuheben, wenn Ihre Bereitstellung vergrößert oder verkleinert werden muss.Das ist der grundlegende Unterschied zu einem Bare-Metal-Server
Nun bestreite ich nicht, dass es im Vergleich zu AWS möglicherweise immer noch kosteneffizienter ist, ein paar mehr dedizierte Server bereitzustellen, als Sie benötigen, aber wenn Sie wirklich unvorhersehbare Arbeitslasten haben, ist es nicht einfach, mitzuhalten

Wenn Sie VMs hochfahren und herunterfahren, um der Nachfragekurve gerecht zu werden, stimmt etwas ernsthaft mit Ihrer Architektur nicht

Ist Ihnen jemals in den Sinn gekommen, warum Stackoverflow etwa acht dedizierte Server verwendet, um die ganze Welt zu bedienen, und keine VMs hoch- und herunterfahren muss, um die globale Kundennachfrage zu erfüllen?
--
Bei der Planung einer Recheninfrastruktur ist es wichtig, sich auf das Wesentliche zu besinnen und nicht auf die Propaganda der Cloud-Anbieter hereinzufallen
Du hast es selbst gesagt. Nicht alle Anwendungen müssen die ganze Welt bedienen, daher wird die Nachfrage geringer sein, wenn die Menschen schlafen gehen

Selbst bei globalen Anwendungen gibt es Vorschriften, die das Hosten von Anwendungen und Daten in bestimmten Regionen vorschreiben. Stellen Sie sich eine Anwendung vor, die von Kunden in Europa, Australien und den USA verwendet wird. Sie müssen von regionalen Rechenzentren aus bedient werden, und ein Cluster schläft größtenteils, während der andere läuft (aufgrund der Zeitzonen). Mit dedizierten Servern würden Sie 60–70 % Ihrer Ressourcen verschwenden, während Sie mit etwas wie EC2/Fargate auf fast 0 herunterskalieren können, wenn Ihre Region schläft

Der Wahnsinn hat Methode, hier heißt er „arbeitsplatzsichere Entwicklung“

Weil es eine Bedrohung für ihre Arbeitsplätze darstellt

Es gibt eine ganze Gruppe von Leuten, die über die technischen Fähigkeiten verfügen, selbst Gastgeber zu sein oder kleine Veranstaltungen für ihre Familie/Freunde/Vereine/Wandervereine zu veranstalten. Diese kleine Marge, bei der Sie ruhig etwas mehr ausgeben können, weil Sie es richtig machen wollen, aber Sie können es nicht rechtfertigen, so viel zu bezahlen und Zeit für harte Wartungsarbeiten aufzuwenden. In vielen Fällen reicht ein kleiner VPS mit einer gemeinsamen Nextcloud oder einer kleinen Website aus

Dafür verwende ich sogar einen kleinen Raspberry Pi 400 in meinem Schlafzimmer

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

Seit fast einem Jahrzehnt hoste ich meine eigenen Sachen selbst. Niemand hat versucht, mein Setup per DDoSing zu attackieren, denn warum sollten sie das tun? Welchen Nutzen hätten sie möglicherweise daraus? Ich wäre so ziemlich die Einzige, die davon betroffen ist, und sobald sie aufhört, würde es nicht lange dauern, bis ich mich erholt habe

Es gibt kaum oder gar keinen Anreiz für einen DDoS-Angriff auf eine persönliche Box, ganz zu schweigen von einem Internet-Rando

Sie überschätzen die Fähigkeiten eines Teenagers drastisch

Nur immer wieder die IP anzupingen wird nicht wirklich viel bringen. Vielleicht ein DoS-Angriff, je nachdem, was das Zielnetzwerk an IPS hat, aber selbst dann ist es wahrscheinlicher, dass sie ihre Computer mit Viren infizieren, bevor sie die Chance bekommen, Sie tatsächlich anzugreifen

Ich persönlich war schon einmal Opfer einer solchen Attacke, weil ich einen Betrüger in GTA 5 irgendwie ausgeschaltet habe. Das passiert auf jeden Fall und macht keinen Spaß
Bearbeiten: Es sieht so aus, als ob dies automatisch geschehen könnte. Das ist etwas Interessantes, mit dem ich mich ein wenig befassen sollte. Es ist wahrscheinlich nur eine zusätzliche Komplexität für meinen kleinen Server, aber ich habe einige Verwendungsmöglichkeiten im Sinn

Technisch gesehen befindet sich mein Homelab auch auf einer statischen öffentlichen IP – das war eher eine Übung in „Könnte ich das machen“ als in „eigentlich notwendig“, aber es ist immer noch cool und ich bin sehr glücklich

Der einzige Aufhänger war, dass ich Wireguard so konfigurieren musste, dass der Tunnel am Leben blieb, sonst würde der VPS manchmal eingehenden Datenverkehr empfangen und wenn mein Labor eine Weile nicht erreichbar gewesen wäre (was, warum sollte es?), wäre der Tunnel ausgefallen. und die Proxy-Verbindung würde. Zum Glück ist das eine integrierte Funktionalität

Das Hinzufügen von RSS-/Atom-Feeds zu einer Jekyll- oder GitHub-Seiten-Site scheint also ziemlich einfach zu sein

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, 4 GB RAM, 1 TB Laufwerk, 100 Mbit
Zu diesem Zeitpunkt sind es einige Jahre Betriebszeit
Bei ununterbrochener Unterbrechung: Möglicherweise ist ein Upgrade fällig.
Kernel-Sicherheitsupdates sind eine Sache


Ich fand Atoms selbst unter Linux unerträglich langsam. Natürlich reicht es für die Bereitstellung von Websites und so weiter, aber es ist verblüffend, wie viel Energie sie verbrauchen, wenn sie einfach nicht funktionieren

Exakt. Diese VPS-Instanzen für unter 10 US-Dollar eignen sich hervorragend für kleine Projekte, bei denen Sie keine langen Verträge abschließen oder sich um die Verwaltung Ihrer eigenen Server kümmern möchten

Wenn Sie ein echtes Unternehmen betreiben, in dem die Margen hauchdünn sind und Sie die ganze freie Zeit der Welt haben, um Serverprobleme zu lösen, wenn sie auftreten, könnten diese dedizierten Server für etwa 50 US-Dollar interessant sein

Aber wenn Sie ein echtes Unternehmen betreiben, ist selbst eine AWS-Rechnung von 10.000 US-Dollar pro Monat günstiger, als einen anderen erfahrenen Entwickler einzustellen, der Sie bei der Verwaltung Ihrer dedizierten Server unterstützt

Das ist es, was in Diskussionen über Cloud-Kosten an Orten wie HN im Allgemeinen übersehen wird: Ja, Cloud ist teuer, aber die Einstellung auch nur eines einzigen zusätzlichen Systemadministrators/Entwicklers, der Sie bei der Verwaltung Ihrer benutzerdefinierten Infrastruktur unterstützt, ist unglaublich teuer und viel weniger flexibel. Aus diesem Grund kann es immer noch ein gutes Geschäft sein, hypothetische 5.000 US-Dollar pro Monat für eine in der Cloud gehostete Lösung auszugeben, die theoretisch mit genügend Zeitaufwand auf einem Server für 50 US-Dollar pro Monat individuell erstellt werden könnte. Ingenieure sind teuer und die Zeit ist begrenzt

Ähhh, entschuldigen Sie, aber wie viel zahlen Sie diesem DevOps-Typen? Dies scheint eine sehr amerikanische Perspektive zu sein, sogar im Talbereich. In Europa wäre es günstiger, einen Mann einzustellen

Die Anstellungskosten bei voller Auslastung sind deutlich höher als das, was Sie auf Ihrem Gehaltsscheck mit nach Hause nehmen. In Europa ist es tatsächlich noch schlimmer. Schauen Sie sich diese Diagramme an: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Zahlt man im Vereinigten Königreich jemandem 1000 EUR, kostet das das Unternehmen insgesamt 1245 EUR

Wenn Sie jemandem in Rumänien 1000 EUR zahlen, kostet das das Unternehmen insgesamt 1747 EUR

Bei einem Gesamtpreis von 120.000 US-Dollar erhalten Sie als EU-Entwickler möglicherweise nur ein Gehalt von 68.000 US-Dollar

Aber man kann nicht nur eine DevOps-Person haben. Sie benötigen mindestens 2, wenn Sie einem von ihnen erlauben möchten, jemals eine Pause zu machen, zu gehen oder in den Urlaub zu fahren

Ich kann Sie in etwa 3 Stunden anschließen

AWS ist für andere Dienste (S3, SES, SQS usw.) sehr kosteneffizient, virtuelle Maschinen sind jedoch kein gutes Geschäft. Sie erhalten weniger RAM& CPU, mit dem Virtualisierungsaufwand, und zahlen viel mehr Geld

Insbesondere bei Postgres können Sie deutlich sehen, welche Strafe Sie für die Virtualisierung zahlen, wenn Sie einige Tests mit pgbench durchführen

Vielleicht wird die Fähigkeit eines Systemadministrators, eine eigene Infrastruktur aufzubauen, zu einer verlorenen Kunst, sonst kann ich nicht erklären, warum die Leute so gern das Fünffache für weniger Leistung bezahlen

Hetzner ist in Europa günstig und zuverlässig. Wenn Sie in Nordamerika sind, werfen Sie einen Blick auf OVH. Vor allem ihre kostensparende Alternative namens SoYouStart. Für 65 US-Dollar erhalten Sie 4/8 4,5 GHz, 64 RAM und ein NVME-Laufwerk

(Ich habe keine Verbindung zu OVH, ich bin nur Kunde mit fast 100 Servern und bei mir hat es großartig geklappt)
Ich möchte auch anmerken, dass ich alt bin, hehe, und bei einem meiner ersten Jobs hatten wir ein Rechenzentrum von angemessener Größe vor Ort. Der Umgang mit SANs, Bandlaufwerken (automatische Bandrotatoren waren damals noch Server usw.) war eine große PITA. Bänder einzupacken und zur Standortredundanz in ein anderes Büro zu schicken, hat immer Spaß gemacht

Die spezielle Anwendung, die ich verwalte, leidet wirklich unter niedrigem GHz und nicht allen Daten im Speicher. Ich habe die Benchmarks auf EC2 ausgeführt. Bestimmte Berichte, die in etwa 5 Sekunden abgeschlossen sind, können auf einer vergleichbaren EC2-Instanz, die etwa zehnmal so viel kostet, mehr als eine Minute dauern. Diese Anwendung benötigt wirklich die rohe CPU. Und ja, wir haben ein ziemlich großes Engineering-Team, das alle Abfragen, Indizes usw. optimiert hat

Was Replikation, Backups usw. betrifft, habe ich das alles eingerichtet, und ehrlich gesagt war es keine große Sache. Es sind ein paar kurze Kapitel im Postgres-Buch, die alles sehr einfach erklären, wie man konfiguriert, kontinuierlich (und automatisch) testet usw

Ich stimme zu, dass SANs ein Albtraum sind. Deshalb versende ich alle meine WALs (PG-Sicherungsdateien) an S3 (und schließlich an Glacier). Auf diese Weise muss ich nicht darüber nachdenken, diese Dateien zu verlieren, und es ist spottbillig

Ich glaube, dass es ein Missverständnis gibt, dass diese Art von Konfigurationen zu kompliziert sind, als dass ein einzelner Techniker sie einrichten könnte, und dass eine endlose Wartung erforderlich wäre. In Wirklichkeit können Sie alles in weniger als einer Woche einrichten und es muss nur wirklich gewartet werden, wenn Sie Postgres aktualisieren möchten (einige Einstellungen haben sich möglicherweise geändert). Ich schätze, dass die Wartung etwa 5 Stunden pro Jahr in Anspruch nimmt

Die Selbstbedienungs-Infrastruktur wird voraussichtlich immer rentabler, da wir die Zustellung auf der letzten Meile weiter verbessern und den Glasfaserzugang ausbauen. Wird sich die Cloud selbst ausschlachten? Auf jeden Fall vielleicht

Was Ihnen die Cloud bietet, ist die Möglichkeit, Ihre Daten/Arbeitslast direkt im Kern zu platzieren, ohne spezielle Vereinbarungen mit Ihrem lokalen ISP treffen zu müssen, und mit viel mehr Ausfallsicherheit, als Sie sich wahrscheinlich leisten würden, wenn Ihr Container nicht mindestens mit mehreren 20-Fuß-Containern voll ist Anzahl der Server, Umfang des Rechenbedarfs

httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..

Bearbeiten: Wenn sich jemand für Selbsthosting interessiert, ist das mit Cloudflared ganz einfach. Ich habe ein Google Pixelbook aus dem Jahr 2017, auf dem Ubuntu mit benutzerdefinierter Firmware läuft und eine Flask-basierte Website bereitstellt. Ich lade es auf meinem Schreibtisch auf, während ich mit einem Gast-WLAN-Netzwerk verbunden bin. Es erhält einen Mobile PageSpeed-Score von 100/100 und benötigt 0,8 Sekunden, um vollständig zu laden

Von DO erhalte ich alle Vorteile eines zuverlässigen Unternehmens, Skalierbarkeit, automatisierte Backups usw. usw. Ich würde auf keinen Fall wechseln

Hetzner Cloud hat jetzt zwei Standorte in den USA. Allerdings gibt es immer noch keine dedizierten Server in den USA – diese würden echt funktionieren. Auch wenn ihre aktuellen Cloud-Angebote selbst bereits etwa 30 % des Preises der großen Cloud-Äquivalente kosten.

Wie Sie betreibe auch ich meine Dienste auf einem gemieteten physischen Server. Früher habe ich Versaweb verwendet, aber ihre Maschinen sind zu alt. Früher mochte ich Hetzner nicht, weil ich schlechte Dinge darüber gehört hatte, dass sie Ihren Betrieb störten

Allerdings bin ich im Dezember zu ihnen gewechselt, als meine Versaweb-Instanz gerade gestorben ist, wahrscheinlich eine SSD aus Altersgründen. Ich zahle jetzt 50 % von dem, was ich für Versaweb bezahlt habe, und kann 6 solcher Postgres-Instanzen ausführen

Dann fragt man sich, ob es sich lohnt, 700 von 800 US-Dollar für einen verwalteten Dienst mit einer schicken Cloud-Benutzeroberfläche, automatischen Upgrades und Backups usw. zu zahlen

Für eine Einzelausstellung oder ein kleines Startup glaube ich nicht. Günstiger ist es, einen verfügbaren Dienst zu nutzen und Backups auf S3 oder etwas günstigerem zu speichern

Firma Ich habe früher für Firma A gearbeitet, die das Vierfache dessen bezahlte, was Firma B für genau die gleiche Dienstleistung verlangte, nur weil Firma A bereit war, vierteljährliche Rechnungen auf eine Weise zu versenden, die gut mit unserem Rechnungssystem zusammenspielte. Für Unternehmen lohnt es sich oft nicht, hier und da ein paar Hundert Dollar zu sparen und zusätzliche Reibungsverluste zu verursachen

Es entstehen implizite Kosten. Wenn es nur ein oder zwei dieser Dinge sind, nehmen Sie einfach die Managed Services

Wenn Sie mit der Skalierung beginnen, beauftragen Sie einen Mitarbeiter vom Typ „Administrator“, um hier Geld zu sparen
Andernfalls müsste ich jemanden mit sehr viel Erfahrung einstellen/beauftragen oder einen ganzen Monat oder mehr meiner Zeit (die nicht verfügbar war) darauf verwenden Seien Sie zu 100 % sicher, dass wir aufgezeichnete PITR-Backups immer schnell wiederherstellen können

An anderen Orten kann ich beträchtliche Cloud-Kosten einsparen, aber glaubwürdig verwaltetes PostgreSQL war eine ziemlich einfache Sache (auch wenn der Einstiegspreis höher war, als man erwarten würde)

Ein frühes Startup, das es sich nicht leisten kann, eine Stunde Produktionsdaten zu verlieren, ist wahrscheinlich ohnehin zu fragil, um zu überleben

Es handelt sich um eine frühe Inbetriebnahme – es wird noch größere Unterbrechungen des Dienstes geben und alle Kunden, die nach einem einstündigen Produktionsdatenverlust fliehen, haben das Produkt ohnehin nicht genug wertgeschätzt

(Bei dem speziellen Start, an den ich gedacht habe, hatte ich bereits einige nette automatisierte, häufige DB-Online-Dumps auf S3 mit erzwungener Aufbewahrung, aber ich dachte nicht, dass das für dieses spezielle Szenario gut genug war. Ich bin mir aber nicht sicher, ob wir damit eine Wiederherstellung durchführen können PITR/Journaling würde einen neuen Single Point of Failure hinzufügen und auf den Erfolg eines Unternehmens setzen, das andernfalls in ein paar/mehreren Jahren einen Ausstieg in neunstelliger Höhe erzielen könnte, nur um ein paar Hundert zu sparen.)
Außerdem gehe ich davon aus, dass einige der frühen Start-ups, die weniger anspruchsvolle Anforderungen haben, aber bei ihren Pflichten gegenüber Kunden-/Benutzerdaten unbekümmert sind, immer noch nachlässig sind, wenn es um grundlegende Mindestpraktiken geht

Vielleicht eine intuitive Möglichkeit, dies zu würdigen: Stellen Sie sich einen Wirtschaftsnachrichtenbericht über HN vor, in dem einige Startup-Unternehmen den Ball verlieren, mit den Namen der Startup-Gründer, und in der Geschichte heißt es, und es stellt sich heraus, dass sie keine guten Backups hatten. Dann einer von ihnen Mitbegründer, der möglicherweise nicht viel geschlafen hat, während sein Unternehmen um ihn herum zusammenbricht, antwortet: „Kundendaten sind in einem frühen Startup nicht so wichtig; wenn sie es wären, wären wir zu anfällig“ (getippt, bevor der Mitbegründer den Laptop dieser Person wegwerfen konnte quer durch den Raum, um sie am Tippen zu hindern). Es würde nicht gut aussehen

Ich werde darauf am Ende eingehen

>Stellen Sie sich einen Business-News-Artikel über HN vor, in dem es um einige Start-up-Unternehmen geht, die aus dem Ruder laufen, mit den Namen der Start-up-Gründer, und in der Story heißt es, und es stellt sich heraus, dass sie keine guten Backups hatten

ITYM und es stellte sich heraus, dass sie die letzte Stunde nicht gesichert hatten
Ich kann mir alles in Ihrem Szenario vorstellen, sogar die unbearbeiteten Teile, und es scheint alles normal zu sein, es sei denn, Sie lesen: „Unsere Startup-Kunden, die uns seit einem Monat nutzen, sind alle sofort gegangen, als wir die letzte Stunde ihrer Daten verloren haben.“

Ich kann mir dieses Szenario wirklich nicht vorstellen

Zugegebenermaßen gibt es einige Unternehmen, bei denen der Vorteil darin besteht, dass nicht einmal eine Stunde Daten verloren geht
IOW, Kunden nutzen es, weil es keine Daten verliert: Online-Zusammenarbeit an Dokumenten[1] zum Beispiel[2]. Wenn es zu einem Zusammenbruch kommt, bei dem eine Stunde der zuletzt eingegebenen Daten verloren geht, müssen Sie natürlich damit rechnen, dass alle betroffenen aktuellen Benutzer sofort fliehen

[1] Obwohl ich persönlich das Risiko mindern würde, indem ich das aktuelle Dokument während der Bearbeitung im lokalen Speicher dupliziere

[2] Vielleicht benötigt die Börse auch das System, um die Daten der letzten Stunde aufzubewahren? Was sonst?
Ich denke, auch für größere Teams kann es sinnvoll sein, Datenbanken selbst zu verwalten, vorausgesetzt, Sie verfügen über die entsprechende Kompetenz. Es gibt so viele Dinge, die bei verwalteten Diensten schief gehen können, und sie verbergen die zugrunde liegende Implementierung nicht so, wie es bei Dingen wie Blockspeicher oder Objektspeicher der Fall ist

Die Spitzenleistung ist sicherlich schlechter – aber es stört mich sowieso nicht, wenn etwas länger dauert, bis es läuft. Sie haben sicher recht, wenn Sie sagen, dass die Bereitstellung eines Servers genauso automatisiert ist, was ich bei einem physischen Server nicht getan habe

Früher hatte ich einen Root-Server für meine Lieblingsprojekte, aber ehrlich gesagt macht das keinen Sinn. Ich betreibe auf meinen Rechnern kein SaaS mit hohem Datenverkehr und hoher Rechenleistung. Es ist nur eine statische Website und einige Projekte. Ich habe nur noch monatliche Kosten von 24, einschließlich einer Speicherbox mit 1 TB zum Speichern aller meiner Daten

Das Hauptproblem in jedem Szenario mit echter Hardware besteht darin, dass Sie Mitarbeiter benötigen, die sich sowohl mit Hardware als auch mit Linux/UNIX-Systemen auskennen. Viele behaupten, dass sie in ihren Lebensläufen stehen und dann nicht einmal im Job auftreten können (zumindest meiner Erfahrung nach). Meiner Meinung nach war einer der Hauptgründe für die Explosion der Cloud-Welt genau die Schwierigkeit beim Aufbau und die finanziellen Kosten für den Aufbau solcher Teams. Darüber hinaus gibt es eine gewisse natürliche (und notwendige) Reibung zwischen Anwendungsentwicklern und Systemleuten. Die Systemleute sollten sich immer zurückhalten und für mehr Sicherheit, mehr Prozesse und weniger Bereitstellungen plädieren. Das Entwicklerteam sollte immer für mehr Flexibilität, mehr Releases und weniger Prozesse plädieren. Ein gutes Management sollte dann den Mittelweg zwischen beiden finden. Leider haben inkompetente Manager oft einfach beschlossen, Systemleute loszuwerden und Dinge in den AWS-Bereich zu verlagern

Abschließend möchte ich nur anmerken, dass die Cloud-Architektur schädlich für den Planeten ist, da sie eine übermäßige Bereitstellung durch Cloud-Anbieter erfordert und aufgrund der vielen Abstraktionsebenen insgesamt mehr Computerleistung erfordert. Während jedes Projekt für wenig dieser Verschwendung verantwortlich ist, ist die gesamte globale Cloud als Aggregat sehr verschwenderisch. Das stört mich und ist in meinen Ansichten wahrscheinlich eine emotionale Voreingenommenheit (so viel Salz bei all dem oben Genannten).
Es könnte argumentiert werden, dass Sie eine Möglichkeit entwickeln können, physische Server vor dem Einkommen zu mieten, und dann, wenn es sinnvoll ist, entweder die Standardabschreibung anwenden können – oder – Abschnitt 179 bei Direktkäufen und/oder Abschnitt 179-Leasing

Beispielsweise können Sie aus Redundanzgründen eine unglaublich leistungsfähige Gruppe von beispielsweise vier völlig überdimensionierten physischen 1U-Maschinen im Wert von 100.000 US-Dollar in unterschiedlichen Cola-Einrichtungen bereitstellen. Hier gibt es alle möglichen Tricks für Lastausgleich und Failover mit XYZ-Cloud-Dienst, DNS, Anycast, was auch immer Sie wollen. Sie können sich an verschiedene Colo-Einrichtungen wenden, die Rechenzentren auf der ganzen Welt betreiben, die Hardware vom Anbieter an diese liefern und sie dann mit Ansible oder was auch immer Sie sich interessieren, bereitstellen, ohne die Einrichtung jemals zu sehen oder Hardware zu berühren

Jetzt verfügen Sie also über redundante physische Hardware, die die meisten Cloud-Anbieter (insbesondere für I/O) absolut übertreffen wird, Fixkosten wie alles, was Sie können, Bandbreite (die nicht den 800-Prozent-Aufschlag von Cloud-Diensten usw. hat) – kein Warten mehr für die unvermeidliche Cloud-Rechnung von 50.000 US-Dollar oder für den Versuch (in Panik) herauszufinden, was dazu geführt hat, dass Sie Ihr konfiguriertes Cloud-Budget an einem Tag statt in einem Monat überschritten haben. Übrigens sperren Sie sich nicht auf die albernen proprietären APIs ein, um andere Dienste als die von $BIGCLOUD angebotenen virtuellen Maschinen bereitzustellen und sogar zu nutzen

Wenn Sie ML betreiben, können Sie auf Ihrer eigenen Hardware oder (oder gelegentlich in der Cloud) trainieren und die Inferenz rund um die Uhr mit Dingen wie dem NVIDIA A10 ausführen. Die kontinuierliche Cloud-Miete für GPU-Instanzen ist unglaublich teuer und der ROI beim Kauf der Hardware liegt typischerweise im Bereich einiger weniger Monate (oder mit Abschnitt 179 fast sofort weit darüber hinaus). Beispielsweise habe ich kürzlich einen Benchmark mit dem Nvidia A10 für ein Modell durchgeführt, das wir bedienen, und es kann über 700 Inferenzanfragen/s in FP32 mit einer Latenz von weniger als 10 ms ausführen. Bei einem einzelnen A10 pro Gehäuse über vier fehlerfreie Instanzen sind das 2800 Anforderungen/s (und könnten wahrscheinlich noch weiter optimiert werden).

Wenn Sie dann WIRKLICH groß werden, können Sie mit der Anschaffung von Schränken und mehr beginnen. Was die bereits erwähnten Hardwareausfälle angeht, kann ich nur sagen, dass Dual-PS-RAID-Ausgänge usw. Hardware (meiner Erfahrung nach) äußerst zuverlässig ist. Da ich in der Vergangenheit mehrere vollständige Hardware-Schränke hatte, kam es selten zu Hardwareausfällen Anbieter bieten unglaubliche SLAs für den Ersatz an. Sie benachrichtigen sie über den Fehler, sie schicken einen Techniker herein< Acht Stunden direkt zur Colo-Anlage und tauschen Sie die Festplatte, PS usw. gegen das Blinklicht aus

Ich habe die Erfahrung gemacht, dass eine (gute) FTE-Ressource dies problemlos bis hin zu mehreren Schränken bewältigen kann. Was Sie auf den Punkt bringen, das aktuelle Problem besteht darin, dass viele dieser Leute von den großen Cloud-Anbietern geschnappt und (auf dem Markt) durch Ressourcen ersetzt wurden, die die grenzwertige Lächerlichkeit überwinden können, Dutzende (wenn nicht mehr) Produkte/Dienstleistungen von $ zu nutzen BIGCLOUD

Ich habe auch festgestellt, dass diese Konfiguration tatsächlich VIEL zuverlässiger ist als die meisten $BIGCLOUD. Sie müssen sich nicht mehr fragen, was mit einem $BIGCLOUD-Ausfall los ist, den sie nicht einmal zur Kenntnis nehmen (und über den Sie absolut keine Kontrolle haben). Da ich aus der Telekommunikations- und Gesundheitsbranche komme, ist es für mich völlig verblüffend, dass die Betriebszeit bei Cloud-Anbietern tatsächlich viel schlechter geworden ist. Normalerweise kann man den Kunden einfach sagen: „Oh, das Internet hat heute Probleme“, weil sie wahrscheinlich Schlagzeilen darüber sehen werden, aber für viele Anwendungen ist das einfach völlig inakzeptabel – und wir sollten etwas Besseres erwarten

[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
Wenn ich ein neues Projekt starten oder etwas Neues hosten möchte, dauert es ein paar Minuten und ich habe die Skripte. Die Bereitstellung erfolgt schnell, der Wartungsaufwand ist gering und ich habe viel mehr für mein Geld

Für alle, die interessiert sind, ist dies der grobe Überblick über das, was ich verwende:
* Ansible, um alles zu verwalten
* Ein kleines bisschen Terraform für einige DNS-Einträge, die ich vielleicht eines Tages ersetzen werde
* Restic für Backups, wiederum gesteuert von Ansible
* Tailscale für VPN (Ich habe einige Pis zu Hause, nichts Großes, aber Tailscale macht es einfach und sicher)
* Docker-Compose für so ziemlich alles andere
Die Hauptanwendung ist Clojure, daher betreibe ich eine native JVM. Die Datenbank ist vollständig verteilt, RethinkDB arbeitet derzeit an der Umstellung auf FoundationDB

Wichtig ist, dass Sie nichts manuell verwalten, z.B. Behandeln Sie physische Server wie jeden anderen Cloud-Server. Es sollte keine Rolle spielen, ob es physisch oder virtualisiert ist

Ich habe viele weniger erfahrene Leute gesehen, die zu viel für Hetzner und ähnliches bezahlt haben, obwohl ein VPS von 5–10 US-Dollar funktioniert hätte

Ja, Sie unterstützen zu diesem Zeitpunkt Ihre eigene Hardware. Nein, es sind keine großen Kopfschmerzen

Der größte zusätzliche Kostenfaktor hierfür ist die Anmietung weiterer IPv4-Adressen, die Hetzner derzeit, da nur wenige verfügbar sind, beträchtlich in Rechnung stellt

Was auch immer Sie erstellen, es beginnt mit 0 Benutzern, und eine ganze reale Maschine ist für die 0 Last, die Sie erhalten, völlig übertrieben. Sie rüsten Ihren VPS in ein Paar realer Maschinen auf, dann in einen kleinen gemieteten Cluster und dann in ein Rechenzentrum (falls das nicht jemand unterbietet). Alle haben vorhersehbare Rechnungen und eine Top-Leistung für ihren Preis

Alles, was Sie in einer Colo besitzen, kostet auch mehr pro Monat. Wenn ich Verbindungen hatte, bei denen ich für eine statische IP bezahlen konnte, kostete das normalerweise 5 $/Monat
Ich miete jetzt einen ziemlich günstigen Server, aber der kostet 30 $/Monat. Viel mehr als alles, was ich brauche, aber es ist schön. Und sie haben den Support für mein Betriebssystem nicht eingestellt und gleichzeitig die Preise erhöht, um den Support zu verbessern oder so. (Obwohl ich anfänglich fehlerhafte Hardware hatte, die ausgetauscht werden musste)
Wie Sie bereits betont haben, ist Bare-Metal der richtige Weg. Das ist das Gegenteil von Cloud – etwas mehr Arbeit am Anfang, aber viel weniger Kosten am Ende

Weitere Informationen: httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..

Das Einrichten und Verwalten von Postgres ist allerdings mühsam. Es wäre schön, wenn es eine einfachere Möglichkeit gäbe, dies in Ordnung zu bringen

1. Erzwingt, dass die Konfiguration reproduzierbar ist, da VMs ausfallen

2. Sie können bei AWS hohe Rabatte erhalten, die den Aufwand lindern

3. Die anderen Dinge, auf die Sie über die VMs zugreifen können, sind günstiger/schneller, sobald sich Ihre Dinge bereits in der Cloud befinden
4. Es ist einfacher, eine dokumentierte Systemkonfiguration (z. B. AWS-Dokumente) zu haben, als Mitarbeiter zu schulen/zu dokumentieren, welche speziellen Dinge Sie intern haben. Besonders nützlich bei der Einstellung neuer Leute

5. Sie benötigen keinen Platz oder redundante Stromversorgung/Internet usw. vor Ort. Gerade genug, um den Leuten die Möglichkeit zu geben, ihre Laptops zu betreiben

Davor habe ich einen VPS verwendet, habe dann aber aufgehört und auf einen physischen umgestiegen, weil das ein besseres Angebot war und wir nicht auf CPU-Limit(s) stießen

Die Festplattenüberwachung ist jedoch nicht allzu schwierig. Führen Sie bei Festplatten einmal pro Stunde smartctl aus und lassen Sie sich warnen, wenn neu zugewiesene oder ausstehende Sektoren schnell ansteigen oder 100 erreichen. Bei SSDs drücken Sie die Daumen; Nach meiner Erfahrung mit ein paar Tausend funktionieren sie meist großartig, bis sie aus dem Bus verschwinden und nie wieder gesehen werden. Verfügen Sie über einen Datenwiederherstellungsplan, der keine Speicherung der Daten auf Geräten desselben Modells mit sehr ähnlichen Betriebsstunden vorsieht. Firmware-Fehler, die mit Betriebsstunden korrelieren, sind real

Hetzner verfügt schließlich über eine API zum Bestellen dedizierter Server und eine API zum Installieren eines Betriebssystems (oder zum Neustarten, um das gewünschte Image zu retten und zu flashen).
Ich schätze, wenn ich kommerzielle Optionen prüfen würde, würde ich den „Trunk“ im Büro mit einer kommerziellen ISP-Lösung, einer statischen IP-Adresse und vielleicht guter IT-Hardware sortieren lassen, aber soweit ich genau jetzt weiß, wenn ein Kunde Hosting benötigt, muss ich Ich würde immer sofort einen VPS mieten

Ich war damals eher ein Junior-Entwickler, vielleicht war ich es also, aber ich vermisse es überhaupt nicht. Theoretisch stimme ich mit dem überein, was Sie sagen, aber die Bereitstellung einer Docker-Datei für etwas wie Google Cloud Run ist viel einfacher. Ja, ich bezahle mehr, als ich für die Verwaltung meines eigenen VPS zahlen würde, aber ich denke, dass dies durch die eingesparten Entwicklerstunden mehr als ausgeglichen wird

- Die physische Hardware hat Probleme, z. B. Lüfterausfall ->meine VM wird live auf einen anderen Host migriert, das ist mir egal und es ist mir egal
- Physische Hardware explodiert ->meine VM startet auf einem anderen Host neu, das merke ich vielleicht, ist mir aber egal
Katastrophenplanung ist mit VMs viel einfacher (auch bei Haustieren, nicht bei Rindern)

Für einen Anfänger erledigen die billigsten die Arbeit

Ich bin mir sicher, dass diese Angebote mit der Weiterentwicklung des Cloud Computing immer häufiger vorkommen

Es gibt noch einen weiteren Aspekt des Cloud Computing. Die mittleren bis großen Unternehmen berücksichtigen Cloud Computing als einstellige Prozentsätze in ihren Kostenkalkulationen. Das bedeutet, dass die Entscheidungen von Managern und Teams häufig auf Zuverlässigkeit und Skalierbarkeit (die in ihren Präsentationen enthalten sein sollen) und nicht auf der Frage „Ist mein Setup teuer oder billig“ ausgerichtet sind?

Mein Arbeitgeber hat die Cloud aus geschäftlichen/finanziellen Gründen eingeführt, nicht aus religiösen Gründen. Oftmals landen wir neue Builds in der Cloud und migrieren später gegebenenfalls in ein Rechenzentrum

Die On-Prem-Apps kosten etwa 40 % weniger. Apps, die in der Cloud kostengünstiger sind, bleiben dort

Ich denke, es ist so, dass AWS/GCP/Azure in Europa keine sehr wettbewerbsfähigen Angebote sind. Was ich nicht sehe, ist ein Beweis dafür für die USA

für die gleiche Spezifikation, sicher. Ich denke, dass virtuelle Systeme an beiden Enden Sinn machen – entweder ist dynamische Skalierbarkeit für große N wichtig, oder man benötigt eigentlich nur einen kleinen Bruchteil einer physischen Box. Es ist auch nicht sinnvoll, 45/Monat für etwas zu bezahlen, das find mit 5/Monat ausführt, und gibt Ihnen mehr Flexibilität, da Sie nicht alles zusammenlegen müssen, nur um Ihren Server zu nutzen

Bewahren Sie auf jeden Fall Backups auf. Am besten bei einem anderen Anbieter oder zumindest an einem anderen physischen Standort. Und natürlich testen Sie sie

Und wenn Sie ein gutes Backup-System verwalten und Ihre Daten/App ohnehin überwachen, stellt die Überwachung von Laufwerken dann eine erhebliche zusätzliche Belastung dar?
--
[1] Wenn Sie tatsächlich den Wiederherstellungsprozess an einem anderen Ort automatisieren, was ich für einige meiner Bits tue, können Sie einfach auf diese Schaltfläche klicken und DNS aktualisieren, wenn der Vorgang abgeschlossen ist, und möglicherweise etwas mehr RAM + Kerne zuweisen (mein Test). Spiegel sind kleiner als die Live-VMs, da sie keine echten Nutzungsmuster bedienen müssen)

Genau das, was ich für mich und meine Kunden tue. Spart jede Menge Dosh

Selbst wenn ich ein Update durchführen wollte, muss ich nur die neueste Version in die Docker-Compose-Vorlage ziehen und das Ansible-Playbook erneut ausführen. Wenn das Upgrade mehr erfordert, dann ist das natürlich auch so, aber es unterscheidet sich in Bezug auf die Arbeit nicht von anderen Setups

Wahrscheinlich ist das Einzige, was ich manuell tun muss, das Testen meiner Backups. Aber ich habe für jedes Projekt ein Skript, das das erledigt, also schalte ich einfach SSH ein, führe den Einzeiler aus, überprüfe das Ergebnis und schon ist es erledigt. Ich mache das ungefähr einmal im Monat, aber ich bekomme auch E-Mails, wenn ein Backup fehlschlägt
Es kann also überhaupt keine Zeit sein. Normalerweise sind es wahrscheinlich 1-2 Stunden pro Monat, wenn ich regelmäßig Updates nehme. Aber das wird sich skalieren, je mehr Dinge Sie hosten und verwalten

Mit anderen Worten: Der einzige Unterschied besteht darin, woher die Ansible-Inventardatei stammt. Entweder handelt es sich um eine statische Liste von IPs, oder sie stammt von Terraform

Wenn Sie ECC-RAM wünschen, sind das scheinbar 60/Monat, und es geht auch um eine leistungsstärkere 8-Kern-CPU

Unabhängig davon, ob es sich um eine „vollständige Produktionsumgebung und eine doppelte Staging-/Standby-Umgebung“ handelt (um die Person zu zitieren, der Sie geantwortet haben), sind 60/Monat * (2 oder 3) im Vergleich zu AWS eines Startups immer noch spottbillig Rechnung, die ich gesehen habe

Die Anwendungsfälle variieren, aber ich stimme eher zu, dass AWS/GCP/Azure nicht die Antwort auf jedes Problem ist

Für jemanden, der seine Anwendung auf einem 4-Dollar-VPS unterbringen kann, ist das natürlich billiger als alles Bare-Metal-System, aber die Skalierung der Cloud ist in vielen Fällen sehr teuer. Auch Bare-Metal ist nicht die Lösung für jedes Problem, aber viele Leute in der Branche scheinen nicht zu erkennen, wann es die richtige Antwort sein kann.