Πόσο μπορείτε να κερδίσετε από ένα VPS $4;

Οι εικονικές προσφορές αποδίδουν σημαντικά χειρότερα (δείτε τα πειράματά μου του 2019: httpsjan.rychter.com/enblog/cloud-server-cpu-performance και κοστίζουν περισσότερο. Η διαφορά είναι ότι μπορείτε να κάνετε "κλιμάκωση κατά παραγγελία", κάτι που διαπίστωσα ότι δεν είναι απαραίτητο, Τουλάχιστον στην περίπτωσή μου. Και αν χρειαστεί να κάνω κλίμακα, μπορώ ακόμα να το κάνω αυτό, απλώς η λήψη νέων διακομιστών διαρκεί ώρες αντί για δευτερόλεπτα. Λοιπόν, δεν χρειάζεται να κάνω κλίμακα σε δευτερόλεπτα

Στην περίπτωσή μου, ολόκληρος ο μηνιαίος λογαριασμός μου για το πλήρες περιβάλλον παραγωγής και ένα διπλό περιβάλλον σταδιοποίησης/αναμονής είναι σταθερός, απλός, προβλέψιμος, πολύ χαμηλός σε σύγκριση με ό,τι θα χρειαζόμουν να πληρώσω το AWS και έχω ακόμα πολύ περιθώριο απόδοσης

Ένα πράγμα που αξίζει να σημειωθεί είναι ότι αντιμετωπίζω τους φυσικούς διακομιστές ακριβώς όπως τους εικονικούς: τα πάντα διαχειρίζονται μέσω του ansible και μπορώ να αναδημιουργήσω τα πάντα από την αρχή. Στην πραγματικότητα, χρησιμοποιώ ένα άλλο περιβάλλον "devcloud"στο Digital Ocean και αυτό περιστρέφεται χρησιμοποιώντας terraform, πριν μεταφερθεί στο ansible που κάνει την υπόλοιπη εγκατάσταση

Υποψιάζομαι ότι τα VendorOps και πολύπλοκα εργαλεία όπως τα kubernetes ευνοούνται από εμπόρους πολυπλοκότητας που έχουν εμφανιστεί την τελευταία δεκαετία. Φαίνεται υπέροχο στο βιογραφικό και δίνει στους ηγέτες της τεχνολογίας μια ψευδή αίσθηση επιτευγμάτων

Εν τω μεταξύ, το Stackoverflow, το οποίο είναι αναμφισβήτητα πιο σημαντικό από τις περισσότερες νεοσύστατες επιχειρήσεις, προχωρά σε εξειδικευμένα μηχανήματα

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

Φαίνεται ότι η τάση σε αυτόν τον χώρο είναι να πηδάμε απευθείας στο υψηλότερο επίπεδο αφαίρεσης. Παρακάμπτοντας τα βασικά στοιχεία και δείχνετε εργαλεία, βιβλιοθήκες και προϊόντα $buzzword

Βλέπετε αναλαμπές αυτού σε διάφορες μορφές. Το ένα είναι τα θέματα των μέσων κοινωνικής δικτύωσης που ρωτούν πράγματα όπως Πόσα από X πρέπει να μάθω για να μάθω Y Όπου το X είναι μια θεμελιώδης, πιθανώς πολύ σταθερή τεχνολογία ή πεδίο και το Y είναι κάποιο εργαλείο για χρήση ή απευθείας δημιουργία ενός προϊόντος ή μιας υπηρεσίας

Η CORBA ανήκει εκεί. Και ίσως ακόμη και το σημασιολογικό ιστό. Σίγουρα XML!
Η XML είναι υπέροχη - αν δεν το πιστεύετε, τότε μπορεί να σας ενδιαφέρει η ανάλυση του JSON: httpseriot.ch/projects/parsing_json.html
Και μην με κάνετε να ξεκινήσω το YAML..

Το πρόσθετο κόστος του να βρίσκομαι σε ένα σύννεφο αξίζει τον κόπο για μένα να έχω διαχείριση βάσεων δεδομένων, αυτόματα στιγμιότυπα, φιλοξενία εξισορροπητών φορτίου, αποθήκευση μπλοκ plug and play κ.λπ.
Θέλω να ανησυχώ για το αν το προϊόν μας είναι καλό, όχι για τις αστοχίες υλικού στη μέση της νύχτας, για την περιστροφή ενός νέου διακομιστή και τη μη σωστή λειτουργία του, επειδή δεν υπήρχε κίνητρο για τη χρήση της διαχείρισης διαμόρφωσης με ένα μόνο κουτί, για την πραγματοποίηση μίας απλής εργασίας προκαλέσει OOM ή πλήρη δίσκο και σπάσει τα πάντα αντί για αυτό ακριβώς να κάνει εργασίες VM, φόβος επανεκκίνησης ενός μηχανήματος που έχει λειτουργήσει 1000 ημέρες κ.λπ.

Για μένα, η γοητεία του cloud δεν είναι κάποια μόδα κλιμάκωσης FAANG όταν δεν απαιτείται, αλλά η αυτόματη επιδιόρθωση λειτουργικού συστήματος, η αυτόματη εξισορρόπηση φορτίου, οι υπηρεσίες NAT, τα κεντρικά, αναλύσιμα αρχεία καταγραφής, οι υπηρεσίες βάσης δεδομένων που δεν χρειάζεται να διαχειριστώ, εκτός box Rolling αναβαθμίσεις σε υπηρεσίες, διαχείριση κρυπτογραφικών κλειδιών και μυστικών και φυσικά αποθήκευση αντικειμένων. (Αυτά είναι όλα τα πράγματα που χρησιμοποιούμε στην εκκίνηση μας)
Θα έλεγα ότι οι αποκλειστικοί διακομιστές μπορεί να είναι πολύ βιώσιμοι/οικονομικοί όταν φτάσουμε σε μια συγκεκριμένη κλίμακα, αντί για το αντίστροφο. Προς το παρόν, τα έξοδα του cloud αξίζουν τον κόπο για την εκκίνηση μου

Εάν κάνετε τις ρυθμίσεις του περιβάλλοντος σας ως κώδικα, δεν θα πρέπει τελικά να έχει σημασία αν ο στόχος σας είναι ένας αποκλειστικός διακομιστής, ένα vm ή κάποια συγκεκριμένη ρύθμιση του cloud που έχει ρυθμιστεί μέσω ενός api

Δεν έχει σημασία ποιο, το θέμα είναι ότι έχετε ένα που μπορεί να σας δημιουργήσει ένα νέο κουτί ή να επαναφέρει ένα κουτί που δεν συμπεριφέρεται σωστά σε καλή κατάσταση εκτελώντας απλώς μια εντολή

Σίγουρα, ο πραγματικός σωρός του Go(o) που το οδηγεί μπορεί να βελτιωθεί (και πράγματι βελτιώνεται)

Τούτου λεχθέντος, η σκληρή αλήθεια είναι ότι η προσέγγισή σας είναι η σωστή, σχεδόν όλες οι επιχειρήσεις (startups!) υπερκατασκευάζονται αντί να εστιάζουν στην παροχή αξίας, στον εντοπισμό της πραγματικής θέσης κ.λπ. (Ναι, υπάρχει και η πλευρά της ζήτησης, καθώς η Οι νεοφυείς επιχειρήσεις που διογκώνονται με χρήματα VC θέλουν να εξαρτώνται από τρίτα μέρη που μπορούν να πάρουν το φορτίο, να κλιμακωθούν μαζί τους, SLA και οτιδήποτε άλλο πρέπει να διαφημιστεί.)
Το Kubernetes είναι φανταστικό! Κάθε φορά που βλέπω μια δυνητικά ανταγωνιστική επιχείρηση να ξεκινά να χρησιμοποιεί το Kubernetes, ανακουφίζομαι αμέσως, καθώς ξέρω ότι δεν χρειάζεται να ανησυχώ πια γι 'αυτήν. Πρόκειται να εξαφανιστούν μέσα σε ένα σωρό άλυτα τεχνικά προβλήματα, προσπαθώντας να διορθώσουν ζητήματα που δεν μπορούν να εντοπιστούν σε μια στοίβα τεχνολογίας απίστευτης πολυπλοκότητας και προσπαθώντας να ξεπεράσουν τους περιορισμούς που επιβάλλονται από ένα σύστημα σχεδιασμένο για επιχειρήσεις με κίνηση κατά δύο τρία μεγέθη μεγαλύτερη. Επίσης, τα COGS τους θα είναι πολύ υψηλότερα από τα δικά μου, πράγμα που σημαίνει ότι θα χρειαστεί να τιμολογήσουν υψηλότερα το προϊόν τους, εκτός και αν ξοδεύουν χρήματα από VC (στην περίπτωση αυτή είναι αστραπιαία)

Καλά πράγματα τριγύρω

Το Ansible είναι επιτακτικό, μπορεί να λειτουργήσει προς μια στατική κατάσταση, και αυτό είναι όλο. Αν αντιμετωπίσει πρόβλημα, εκτινάσσεται η σύνδεσή του με το SSH, και κλαίει πολλά λάθη python και εγκαταλείπει για πάντα. Ακόμη και με το απόθεμά του απέχει πολύ από το δηλωτικό
Το k8s είναι ένας βρόχος ελέγχου που προσπαθούν να σημειώσουν πρόοδο προς την δηλωμένη τους κατάσταση. Η αποτυχία δεν είναι πρόβλημα, θα προσπαθήσουμε ξανά. Θα ελέγχει συνεχώς την κατάστασή του, έχει ένα ωραίο API για να το αναφέρει και χάρη σε πολλές τροποποιημένες ιδέες είναι πιο δύσκολο να υπάρχουν περίεργες συγκρούσεις μεταξύ αναπτυγμένων στοιχείων. (Ενώ η ενσωμάτωση πολλών βιβλίων με το Ansible δεν είναι ασήμαντη.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
Και ακόμα κι αν το k8s προσφέρει πάρα πολλές κληρονομιές, υπάρχουν επερχόμενες πιο λεπτές εκδηλώσεις των βασικών ιδεών. (Π.χ. httpsgithub.com/aurae-runtime/aurae )
Και τώρα προτείνετε στους ανθρώπους να χρησιμοποιούν μια απλούστερη μη τυπική υλοποίηση;
Έτσι φυσικά μπορείτε να εφαρμόσετε μια λύση ελάχιστης πολυπλοκότητας ή μπορείτε να χρησιμοποιήσετε κάτι "εκτός ραφιού"Το k8s είναι πολύπλοκο και μερικά από αυτά είναι σίγουρα περιττά για την περίπτωσή σας, αλλά είναι επίσης μάλλον γενικό, ευέλικτο, καλά υποστηριζόμενο κ.λπ.

>προτείνετε στους χρήστες να χρησιμοποιούν μια απλούστερη μη τυπική υλοποίηση;
Αυτό που πρότεινα είναι ότι εάν τα k8s το έργο/λογισμικό γίνει πολύ μεγάλο για να αποτύχει, τότε οι άνθρωποι μπορούν να στραφούν σε μια εναλλακτική. Ευτυχώς, οι έννοιες του k8s και το API είναι ανοιχτού κώδικα, επομένως μπορούν να εφαρμοστούν σε άλλα έργα, και έδωσα ένα τέτοιο παράδειγμα για να δείξω ότι η επιλογή k8s δεν είναι ένα κλείδωμα προμηθευτή που μοιάζει με Oracle

Πάντα ακούω για όλα τα υπέροχα πράγματα που λαμβάνετε πρακτικά δωρεάν από παρόχους cloud. Είναι πράγματι τόσο εύκολο να ρυθμιστεί και να χρησιμοποιηθεί αυτό το υλικό; Κάθε φορά που προσπάθησα να εγκαταστήσω τη στοίβα LAMP μου σε μια υπηρεσία cloud, ήταν τόσο συγκεχυμένη και τρομακτική διαδικασία που κατέληγα να τα παρατήσω. Αναρωτιέμαι αν χρειάζεται απλώς να πιέσω λίγο περισσότερο και θα φτάσω στο Cloud Heaven
Το να μπορείτε να πείτε "θέλω μια ομάδα MySQL εδώ με αυτό το είδος προδιαγραφών"είναι πολύ καλύτερο (από άποψη χρόνου) από το να το κάνετε μόνοι σας. Οι ενημερώσεις είναι επίσης όμορφα τυλιγμένες στο σύστημα, επομένως λέω απλώς "εφαρμογή της πιο πρόσφατης ενημέρωσης"αντί να διασφαλίσω χειροκίνητα ότι οι αποτυχίες/επανεκκινήσεις γίνονται με τη σωστή σειρά

Έτσι πληρώνετε για να απλοποιήσετε τα πράγματα, αλλά το κέρδος από αυτή την απλούστευση εμφανίζεται μόνο με μεγαλύτερα έργα. Εάν έχετε κάτι σε έναν διακομιστή που μπορείτε να επανεκκινήσετε ενώ οι χρήστες σας λαμβάνουν μια σελίδα σφάλματος, μπορεί να μην αξίζει τον κόπο

Το σύννεφο δεν είναι εύκολο να προσπαθήσεις να πετύχεις την ψύξη και την ενεργειακή απόδοση ενός μικρού δωματίου διακομιστών οπουδήποτε κοντά στα επίπεδα απόδοσης που δημοσιεύουν τα περισσότερα μεγάλα κέντρα δεδομένων είναι σχεδόν αδύνατη, όπως και η συνδεσιμότητα με πολλούς προμηθευτές στο Διαδίκτυο

Με το σύννεφο όλα αυτά εξαφανίζονται καθώς διαχειρίζεται οποιοσδήποτε χειριστής κέντρου δεδομένων στο οποίο εκτελείται το cloud, αλλά αυτό που οι άνθρωποι ξεχνούν είναι ότι αυτό ισχύει και για τις παλιομοδίτικες υπηρεσίες συντοπισμού που συχνά προσφέρουν καλύτερο κόστος/αξία από το cloud
Και παρόλο που είναι σίγουρα πιο δύσκολο να διαχειριστείτε πράγματα όπως το AWS ή το Azure επειδή αφαιρεί πολλές αφαιρέσεις που αποκρύπτουν οι πάροχοι vpc μικρού scall από εσάς ή που δεν έχετε πραγματικά με έναν μόνο οικιακό διακομιστή, δεν είναι δύσκολο στην κλίμακα να χρειάζεται να εκτελέσετε ένα ζευγάρι rack αξίας διακομιστών vmware με αποθηκευτικό χώρο βάσει SAN  Με τα πράγματα στο Cloud έχετε περισσότερες ρυθμίσεις να κάνετε επειδή πρόκειται για τη διαμόρφωση εικονικών διακομιστών κ.λπ. Αντί να μεταφέρετε τον υπολογιστή σε κουτί στο δωμάτιό σας, πρέπει να τον "ρυθμίσετε"για να τον κάνετε διαθέσιμο  Οι βάσεις δεδομένων DO έχουν αντίγραφα ασφαλείας που μπορείτε να διαμορφώσετε σύμφωνα με τις προτιμήσεις σας, να τα αποθηκεύσετε σε DO Spaces (όπως το S3). Η διαχείριση χρηστών DB είναι εύκολη. Υπάρχουν επίσης διακομιστές κρυφής μνήμης για το Redis  Μπορείτε να προσθέσετε ένα πρόγραμμα εξισορρόπησης φορτίου και να το συνδέσετε με τους διάφορους διακομιστές Ιστού σας  Νομίζω ότι μου πήρε περίπου 30 λεπτά για να ρυθμίσω διακομιστές ιστού 2x, διακομιστή DB, διακομιστή προσωρινής μνήμης, εξισορροπητή φορτίου, διακομιστή αποθήκευσης και να τα συνδέσω όλα όπως απαιτείται χρησιμοποιώντας μερικές απλές φόρμες. Δεν μπορεί πραγματικά να το νικήσει αυτό  Αν έχετε περισσότερες πληροφορίες ή απόψεις, παρακαλώ κοινοποιήστε  Πολλά άρθρα στο διαδίκτυο σχετικά με τη σκλήρυνση ενός διακομιστή Linux, αυτά που έχω δοκιμάσει χρειάζονται λίγο περισσότερο από 30 λεπτά για να ακολουθήσω τα βήματα, πολύ περισσότερο εάν προσπαθώ να μάθω και να καταλάβω τι κάνει κάθε πράγμα, γιατί είναι σημαντικό, ποια είναι η υποκείμενη ευπάθεια και πώς μπορεί να χρειαστεί να προσαρμόσω ορισμένες ρυθμίσεις για τη συγκεκριμένη περίπτωση χρήσης  Είμαι βέβαιος ότι μπορείτε να βρείτε παραδείγματα σεναρίων ρύθμισης στο διαδίκτυο (η ρύθμιση των αυτόματων ενημερώσεων, το τείχος προστασίας, οι εφαρμογές κ.λπ. θα πρέπει να είναι θέμα εκτέλεσης του 'curl $URL'και μετά το 'chmod +x $FILE'και το 'bash $FILE'. Δεν χρειαζόμουν διαχείριση διαμόρφωσης (χρησιμοποιώ την υπηρεσία δημιουργίας αντιγράφων ασφαλείας του παρόχου μου, η οποία είναι σημαντική υποθέτω)  Κάτι σαν αυτό: httpsraw.githubusercontent.com/potts99/Linux-Post-Install..  (βλέπεται στη διεύθυνση httpswww.reddit.com/r/selfhosted/comments/f18xi2/ubuntu_d) Προφανώς το ίδιο μπορεί να ειπωθεί για VM μεγάλης διάρκειας και αυτό μπορεί να λυθεί με την ύπαρξη μιας πειθαρχημένης ομάδας, αλλά νομίζω ότι είναι γενικά πιο πιθανό σε ένα περιβάλλον με ένα μοναδικό μηχάνημα που λειτουργεί πολύ καιρό  Ο Hetzner έχει όλα αυτά εκτός από τις διαχειριζόμενες βάσεις δεδομένων  httpswww.hetzner.com/managed-server Τα πακέτα φιλοξενίας ιστοσελίδων περιλαμβάνουν επίσης 1..απεριόριστα DB (MySQL και PostgreSQL) httpswww.hetzner.com/webhosting/ έχει αυτόματο αντίγραφο ασφαλείας και αποτυγχάνει; >Με την κράτηση ημερήσιας δημιουργίας αντιγράφων ασφαλείας ή το αντίγραφο ασφαλείας που περιλαμβάνεται στον τύπο διακομιστή, δημιουργούνται αντίγραφα ασφαλείας όλων των δεδομένων καθημερινά και διατηρούνται για μέγιστο διάστημα 14 ημερών. Η ανάκτηση αντιγράφων ασφαλείας (Επαναφορά) είναι δυνατή μέσω της διεπαφής διαχείρισης konsoleH  Αλλά έχω την εντύπωση ότι οι βάσεις δεδομένων σε διαχειριζόμενους διακομιστές προορίζονται για χρήση από εφαρμογές που εκτελούνται σε αυτόν τον διακομιστή, επομένως δεν υπάρχει πραγματικά η έννοια του failover  httpswww.hetzner.com/legal/managed-server/ Η αποτυχία μιας μονάδας δίσκου σε έναν μόνο διακομιστή δεν θα πρέπει ποτέ να προκαλεί διακοπή παραγωγής  Πολλά ζητήματα διαμόρφωσης μπορούν να εντοπιστούν σε αυτόνομες αναπτύξεις. Αυτό το αρχείο γραμματοσειράς ή το JRE πρέπει πραγματικά να εγκατασταθεί σε ολόκληρο τον διακομιστή ή μπορείτε να το ομαδοποιήσετε στην ανάπτυξή σας  Οι αναπτύξεις μας χρησιμοποιούν στόχους on-premise και EC2. Το σενάριο ανάπτυξης δεν είναι διαφορετικό, μόνο η IP για τον κεντρικό υπολογιστή  Τώρα, θα πω αν μπορώ να χρησιμοποιήσω το S3 για κάτι που θα το κάνω 100%. Δεν υπάρχει εναλλακτική λύση on-premise για αυτό με το ίδιο σύνολο χαρακτηριστικών  Το θέμα του DevOps είναι "Βοοειδή, όχι κατοικίδια". Βάλτε μια κουκκίδα στον διακομιστή σας μία φορά την εβδομάδα για να βρείτε τα σημεία αποτυχίας σας  Θα μου άρεσε αν μπήκατε στο Discord/Slack μας και αναφέρατε μερικά από τα ζητήματα που βλέπατε, ώστε να μπορούμε τουλάχιστον να βελτιώσουμε την εμπειρία για άλλους που χρησιμοποιούν το Dokku. Μη διστάσετε να με χτυπήσετε εκεί ψηλά (το ψευδώνυμό μου είναι "savant")  Επιτρέψτε μου να προλογίσω και να πω ότι είμαι προγραμματιστής εφαρμογών με γνώση μόνο του Docker.Δεν είμαι εξαιρετικά ικανός στα infra και η εφαρμογή με την οποία δυσκολεύτηκα έχει περίεργες παραμέτρους ανάπτυξης: Είναι μια εφαρμογή Python που κατά το χρόνο δημιουργίας αναλύει αρκετές συναυλίες στατικών ανιχνεύσεων HTML για να συμπληρώσει μια βάση δεδομένων Postgres που είναι στατική μετά την κατασκευή. Στη συνέχεια, μια εφαρμογή Ιστού Flask λειτουργεί σε αυτήν τη βάση δεδομένων. Η ανάλυση HTML εξελίσσεται γρήγορα και έτσι τα συμπληρωμένα δεδομένα ΒΔ θα πρέπει να ομαδοποιούνται ως μέρος των εικόνων της εφαρμογής  IIRC, δυσκολεύτηκα με τη δόμηση των Dockerfiles όταν το DB δεν ήταν επίμονο, αλλά απλώς ένα άλλο παροδικό μέρος της εφαρμογής, αλλά φαινόταν ξεπερασμένο. Το μεγαλύτερο πρόβλημα φαινόταν να είναι πώς να αποφύγετε τη λήψη συναυλιών σπάνια αλλαγμένων δεδομένων από το S3 για κάθε έκδοση, όταν ιδανικά θα αποθηκευόταν στην κρυφή μνήμη, ειδικά με έναν τρόπο που συμπεριφέρονταν λογικά στο DigitalOcean και στο τοπικό μου περιβάλλον. Υποθέτω ότι η σωστή αποθήκευση στο επίπεδο της εικόνας Docker θα αντιμετώπιζε το πρόβλημα, αλλά έφτασα πολύ γρήγορα στο τέλος της γνώσης και της υπομονής μου  Το DX του Dokku φαίνεται εξαιρετικό για άτομα που κάνουν κανονικά πράγματα. :) 0. httpscoolify.io/ Επιπλέον, ποιος δεν θέλει να παίξει με το πιο καινούργιο, πιο κουλ παιχνίδι στα λεφτά του άλλου; Υπάρχει σίγουρα ένα επιχείρημα για να μετακινηθούν (κάποια) πράγματα από το cloud αργότερα στο ταξίδι, όταν η ευελιξία (ή η αντιμετώπιση της ροής/περιστροφής) γίνεται λιγότερο βασικός παράγοντας και η κλίμακα/κόστος αρχίζει να κυριαρχεί  Σίγουρα, μπορείτε να βρείτε κάτι που λειτουργεί στο Hetzner, αλλά να είστε έτοιμοι να απαντήσετε σε πολλές περισσότερες ερωτήσεις  Συμφωνώ στο τελευταίο σημείο της επιχείρησής σας που το ζητάτε, το οποίο και πάλι είναι λυπηρό που αυτές οι επιχειρηματικές "απαιτήσεις"υπαγορεύουν πώς να αρχιτεκτονήσετε και να φιλοξενήσετε το λογισμικό σας όταν ένας άλλος τρόπος μπορεί να είναι ο πολύ καλύτερος Η αποκατάσταση από καταστροφή είναι ένα πολύ πραγματικό πρόβλημα. Γι'αυτό το δοκιμάζω τακτικά. Σε ένα σενάριο καμένης γης, μπορώ να λειτουργήσω σε ένα δευτερεύον σύστημα (σταδιοποίηση) ή ένα σύστημα μορφοποιημένου νέφους σε λιγότερο από μία ώρα. Για την επιχείρησή μου, αυτό είναι αρκετό 
Περάσαμε μια έκρηξη ανάπτυξης, και όπως όλοι πριν, αυτό σήμαινε ότι υπήρχαν πολλοί άπειροι άνθρωποι στους οποίους δόθηκαν πολλά χρήματα και επείγουσες προσδοκίες. Είναι μια συνταγή για καλλιέργειες φορτίου και εκμεταλλευτικό μάρκετινγκ

Αλλά η ανάπτυξη επιβραδύνεται και τα χρήματα γίνονται πιο ακριβά, επομένως επιβραδύνετε και αρχίστε να μαθαίνετε ξανά τα παλιά μαθήματα με νέες συναρπαστικές παραλλαγές. (Όπως εδώ: διαχείριση γυμνών μεταλλικών κλιμακώσεων και με κοντέινερ και ενορχήστρωση)
Και ολόκληρος ο κύκλος θα επαναληφθεί στο επόμενο μπουμ. Αυτή είναι η βιομηχανία μας προς το παρόν

Ένας σταθερός αποκλειστικός διακομιστής είναι κατά 99% πολύ πιο χρήσιμος από ένα κατεστραμμένο VPS σε κοινόχρηστο υλικό, αλλά προφανώς έχει αυξημένο κόστος εάν δεν χρειάζεστε όλους τους πόρους που παρέχουν

Ναι - αλλά η λαχτάρα να "κάνεις αυτό που κάνουν όλα τα κουλ παιδιά"είναι τουλάχιστον εξίσου ισχυρές σε αυτούς που κανονικά θα αποκαλούνταν "διευθυντές", έναντι "υπάλληλοι"αποτέλεσμα Α) τεράστιες δαπάνες μικροϋπηρεσιών/cloud πηγαίνουν στραβά, καλά τουλάχιστον ακολουθούσατε τις βέλτιστες πρακτικές, συμβαίνουν αυτά τα πράγματα, τι μπορείτε να κάνετε

Αποτέλεσμα Β) πήγατε με έναν διακομιστή Hetzner και κάτι πήγε στραβά, καλά είστε και θα έπρεπε να είχατε πάει με microservices, απολαύστε την αναζήτηση νέας εργασίας

Ενθαρρύνοντας έτσι τους διαχειριστές να επιλέξουν microservices/cloud. Μπορεί να μην είναι η σωστή απόφαση για την εταιρεία, αλλά είναι η σωστή απόφαση για τον διευθυντή και είναι ο διευθυντής που παίρνει την απόφαση

(Όπως και το να είσαι σύμβουλος που θέλει μια επέκταση και να γράφει λογισμικό που λειτουργεί, όπως ανακάλυψα με τον δύσκολο τρόπο.)
Υπάρχει μια αποσύνδεση μεταξύ των ιδρυτών και όλων των άλλων

Οι ιδρυτές πιστεύουν ότι θα είναι >10x κάθε χρόνο

Η πραγματικότητα είναι ότι είναι 90% πιθανό να αποτύχουν

Το 90% των περιπτώσεων - μια χαρά αποτυγχάνεις σε οτιδήποτε

Κάποιο % από το 10% των φορών που πετυχαίνεις, είσαι ακόμα καλά χωρίς το σύννεφο - τουλάχιστον για αρκετά χρόνια επιτυχίας, άφθονο χρόνο για να αλλάξεις αν χρειαστεί

Έχω μόνο μία ansible εγκατάσταση και μπορεί να λειτουργήσει τόσο για εικονικούς διακομιστές όσο και για φυσικούς. Καμία διαφορά. Η μόνη διαφορά είναι ότι οι εικονικοποιημένοι διακομιστές πρέπει πρώτα να ρυθμιστούν με terraform και οι φυσικοί πρέπει να παραγγελθούν πρώτα και οι IP τους να εισαχθούν σε ένα αρχείο διαμόρφωσης (απόθεμα)

Φυσικά, προσέχω επίσης να αποφύγω να εξαρτηθώ από πολλές άλλες υπηρεσίες cloud. Για παράδειγμα, χρησιμοποιώ το VpnCloud (httpsgithub.com/dswd/vpncloud) για επικοινωνία μεταξύ των διακομιστών. Ως δευτερεύον πλεονέκτημα, αυτό μου δίνει επίσης την ευελιξία να μεταβώ σε οποιονδήποτε πάροχο υποδομής ανά πάσα στιγμή
Το κύριο σημείο μου ήταν ότι, ενώ οι εικονικοποιημένες προσφορές έχουν τις χρήσεις τους, υπάρχει ένα (τεράστιο) χάσμα μεταξύ ενός χόμπι VPS $10/μήνα και μιας εταιρείας με επιχειρηματική δραστηριότητα B2C με εκρηκτική ανάπτυξη. Οι περισσότερες νέες επιχειρήσεις στην πραγματικότητα πέφτουν σε αυτό το κενό: δεν περιμένετε εκθετική ανάπτυξη με ραβδί χόκεϊ σε ένα κερδοφόρο B2B SaaS. Εκεί θα πρέπει να αμφισβητήσετε τη συνήθη προεπιλεγμένη επιλογή "χρήση AWS". Με νοιάζει το COGS και τα περιθώρια μου, γι'αυτό κοιτάζω αυτή την επιλογή πολύ προσεκτικά

Δεν είστε εταιρεία λογισμικού, ουσιαστικά φτιάχνετε και πουλάτε Sprockets

Οι απόψεις εδώ θα ήταν να προσλάβετε ένα μεγάλο προσωπικό eng/IT για να "αγοράσει και να διατηρήσει διακομιστές"(το PaaS είναι κακό) και στη συνέχεια πιθανότατα "να γράψετε έναν κώδικα μόνοι σας"(το SaaS είναι κακό) ή οτιδήποτε άλλο είναι σήμερα δημοφιλές εδώ (τελευταίο νήμα εδώ ήταν "Πατώντας την PHP μέσω SFTP χωρίς Git, και αν χρειάζεστε περισσότερα"lol)
Πιστεύω όμως ότι οι επιχειρήσεις θα πρέπει να κάνουν ένα πράγμα καλά και να αποφεύγουν να προσπαθούν να ανταγωνιστούν (κάνοντάς το με το χέρι) για πράγματα εκτός της βασικής τους αρμοδιότητας. Σε αυτήν την περίπτωση, σίγουρα θα πίστευα ότι το Sprocket Masters δεν θα πρέπει να προσπαθήσει να διαχειριστεί το δικό του υλικό και θα πρέπει να βασίζεται σε έναν πάροχο για να χειριστεί την κλιμάκωση, την ασφάλεια, το χρόνο λειτουργίας, τη συμμόρφωση και όλες τις μικρές λεπτομέρειες. Πιστεύω επίσης ότι το λογισμικό τους θα πρέπει να είναι τυπικό με όσο το δυνατόν λιγότερα in-house. Δεν είναι κατάστημα λογισμικού και θα πρέπει να γράφουν όσο το δυνατόν λιγότερο κώδικα

Ρεαλιστικά το Widget Masters θα μπορούσε να τρέξει αυτούς τους ιστότοπους με ένα σχετικά μικρό προσωπικό, εκτός εάν αποφασίσουν να τα κάνουν όλα χειροκίνητα, οπότε πιθανότατα θα χρειαζόταν πολύ μεγαλύτερο προσωπικό

Ωστόσο, αυτό που βλέπω και αυτό που νομίζω ότι μιλούσε η προηγούμενη αφίσα είναι επιχειρήσεις όπου η τεχνολογία βρίσκεται στον πυρήνα της επιχείρησης, και εκεί συχνά έχει λιγότερο νόημα και αντί να εξοικονομεί χρόνο φαίνεται να κοστίζει χρόνο. Υπάρχει ένας λόγος που υπάρχουν ειδικοί στο AWS: δεν είναι ασήμαντο. Οι "πραγματικοί"διακομιστές δεν είναι επίσης ασήμαντοι, αλλά δεν είναι απαραίτητα πιο δύσκολοι από τις υπηρεσίες cloud

Αλλά αυτές οι υπηρεσίες δεν θέλουν να έχουν προσωπικό για τη συντήρηση του φυσικού υλικού.

Αλλά η Sprocket Masters πρέπει ακόμα να έχει έναν ακριβό Cloud Consultant στον συγκρατητή απλώς για να ανταποκρίνεται σε καταστάσεις έκτακτης ανάγκης

Εάν πρόκειται να έχετε κάποιον στο προσωπικό για να αντιμετωπίσει τα ζητήματα του cloud, μπορείτε επίσης να νοικιάσετε έναν διακομιστή

Προσωπικά έχω τρέξει Dedicated Servers για την επιχείρησή μας τις προηγούμενες μέρες, αλλά καθώς επεκτανόμασταν και κλιμακώσαμε, έγινε πολύ πιο εύκολο να πάμε με τους παρόχους Cloud για την παροχή διαφόρων υπηρεσιών γρήγορα, παρόλο που το κόστος αυξήθηκε. Για να μην αναφέρουμε ότι είναι πολύ πιο εύκολο να πείτε σε έναν υποψήφιο πελάτη ότι χρησιμοποιείτε "σύννεφο όπως το AWS"παρά "Ωχ, νοικιάζουμε αυτά τα μηχανήματα σε ένα κέντρο δεδομένων που διευθύνεται από κάποια εταιρεία"(κάτι που στην πραγματικότητα μπορεί να είναι καλύτερο, αλλά οι πελάτες συνήθως δεν το καταλαβαίνουν) . Έλεγχος, Συμμόρφωση και άλλα

Για πολλούς ακόμη και πολύ λιγότερο από αυτό. Εκτελώ ένα μικρό δευτερεύον έργο[1] που έγινε viral μερικές φορές (30.000 προβολές σε 24 ώρες περίπου) και εκτελείται σε έναν διακομιστή web CPU ενός πυρήνα και σε έναν διαχειριζόμενο Postgres επίσης σε έναν μόνο πυρήνα CPU. Δεν έχει φτάσει καν στην πλήρη αξιοποίηση
1: httpsaihelperbot.com/ Θα μπορούσα να αλλάξω κάποιες από αυτές σε λειτουργίες λάμδα; Ή να αλλάξω σε ECS; Ή να μεταβείτε σε κάποια άλλη υπηρεσία cloud du jour; Μπορεί. Αλλά ο χρόνος που αφιέρωσα για να γράψω αυτό το σχόλιο είναι ήδη εξοικονόμηση περίπου έξι μηνών για μια τέτοια αλλαγή. Εάν είναι πιο δύσκολο από το "πατήστε κουμπί, λάβετε 100% αξιόπιστη μεταφρασμένη υπηρεσία", είναι δύσκολο να το δικαιολογήσετε  Κάποια από αυτά είναι επίσης επειδή το cloud παρέχει ορισμένες άλλες υπηρεσίες τώρα που επιτρέπουν κάτι τέτοιο. Δεν χρειάζεται να εκτελέσω ένα σύμπλεγμα Kafka για βασικά μηνύματα, όλα συνοδεύονται από ένα λεωφορείο μηνυμάτων. Το χρησιμοποιώ. Χρησιμοποιώ τις φιλοξενούμενες επιλογές DB. Χρησιμοποιώ S3 ή ισοδύναμο, κ.λπ. Θεωρώ ότι ό,τι περισσεύει δεν αξίζει σχεδόν καθόλου την ταλαιπωρία του να προσπαθήσω να μπω σε κάποιο άλλο παράδειγμα όταν πληρώνω μονοψήφια δολάρια το μήνα για να τρέξω απλώς σε μια περίπτωση EC2  Είναι απολύτως αλήθεια ότι δεν μπορούν όλοι ή κάθε έργο να το κάνουν αυτό. Δεν έχω κολλήσει σε αυτό ως τελικό στόχο. Όταν δεν λειτουργεί, κάνω αμέσως την κατάλληλη ενέργεια κλιμάκωσης. Δεν προτείνω να πάτε να ξανααρχιτεκτονήσετε κάτι με βάση αυτό. Απλώς λέω, δεν είναι επιλογή που πρέπει να σε περιφρονούν. Έχει μεγάλη ευελιξία και η χρέωση είναι αρκετά συνεπής (ή, για να το θέσω αλλιώς, το γεγονός ότι αν ξαφνικά έχω 50 φορές την κίνηση, το σύστημά μου αρχίζει να πνίγεται και να εκτοξεύεται αισθητά αντί να μου χρεώνει απλά εκατοντάδες δολάρια περισσότερα είναι ένα χαρακτηριστικό για μένα παρά ένα σφάλμα) και γενικά δεν προσπαθείς να στραφείς σε κάποιο παράδειγμα που είναι βολικό για κάποια υπηρεσία cloud αλλά μπορεί να μην είναι βολικό για σένα  Χρειάστηκε ποτέ να διαχειριστείτε ένα από αυτά τα περιβάλλοντα; Το θέμα είναι ότι, αν θέλετε να αποκτήσετε κάποια βασική επεκτασιμότητα για περισσότερα από ένα άτομα και τα κατάλληλα devop, τότε θα πρέπει να κάνετε υπερβολική παροχή από έναν σημαντικό παράγοντα (πιθανώς ακυρώνοντας τις αποταμιεύσεις σας)  Αναπόφευκτα θα καταλήξετε σε μια προσαρμοσμένη λύση, πράγμα που σημαίνει ότι οι νέοι συνεργάτες θα δυσκολευτούν να κατακτήσουν το σύστημα και σημαντικοί άνθρωποι που εγκαταλείπουν την εταιρεία θα φέρουν μαζί τους τη βαθιά γνώση της υποδομής σας. Επιστρέφετε στα κατοικίδια αντί για τα βοοειδή. Μερικοί διακομιστές είναι ειδικοί, μετά από λίγο αυτοματισμός σημαίνει "πολλά κολλημένα σενάρια κελύφους εδώ και εκεί"και μια αναβάθμιση λειτουργικού συστήματος σημαίνει είτε το μισό infra είναι KO για λίγο είτε δεν κάνετε καθόλου αναβαθμίσεις λειτουργικού συστήματος  Και στην τυχερή περίπτωση θα χρειαστεί να κλιμακώσετε Μπορεί να βρείτε δυσάρεστες εκπλήξεις  Και μην με κάνετε ποτέ να ξεκινήσω από την πλευρά της δικτύωσης. Αν δεν νοικιάσετε ολόκληρο το rack σας και δεν τοποθετήσετε το δικό σας υλικό δικτύωσης, θα λάβετε αυτό που παίρνετε. Το οποίο θα μπορούσε να είναι πολύ φτωχό είτε σε λειτουργίες είτε σε επιδόσεις Αν υποθέσουμε ότι δεν κάνετε τίποτα φανταχτερό  Αν θέλετε 100,0000% χρόνο λειτουργίας, σίγουρα. Αλλά δεν το κάνεις συνήθως. Οι εταιρείες που θέλουν αυτό το είδος χρόνου λειτουργίας έχουν συνήθως ομάδες αφιερωμένες σε αυτό ούτως ή άλλως  Και η κλιμάκωση λειτουργεί καλά και σε γυμνό μέταλλο, εάν κλιμακώνεστε κάθετα - έχετε ιδέα για την ποσότητα ισχύος και απόδοσης που μπορείτε να λάβετε από έναν μόνο διακομιστή; Είναι ανησυχητικό να συνεχίσουμε να ακούμε για "κλιμάκωση"όταν το ηχείο σημαίνει "οριζόντια κλιμάκωση"  Εάν οι απαιτήσεις σας είναι «κλιμάκωση», τότε η κάθετη κλιμάκωση θα σας πάει μακριά  Εάν οι απαιτήσεις σας είναι "οριζόντια κλιμάκωση κατ'απαίτηση", τότε, σίγουρα, οι πάροχοι cloud θα βοηθήσουν εκεί. Όμως, λίγα μέρη χρειάζονται τέτοιου είδους κλιμάκωση  Δεν λέω ότι το 100% uptime σε γυμνό μέταλλο είναι φθηνό, λέω ότι το 100% uptime συχνά δεν χρειάζεται  Επειδή η βιομηχανία είναι γεμάτη από ανθρώπους που κυνηγούν τις τάσεις και τις λέξεις-κλειδιά και στους οποίους το πιο σημαντικό είναι να προσθέσετε αυτές τις λέξεις-κλειδιά στα βιογραφικά  Ο στόχος του IME για επεκτασιμότητα είναι εξαιρετικά λανθασμένος για τις περισσότερες υπηρεσίες / εφαρμογές / οτιδήποτε. Και συνήθως πληρώνετε τόσα πολλά έξοδα για τις "κλιμακούμενες"λύσεις, που στη συνέχεια χρειάζεται να κλιμακώσετε για να το αναπληρώσετε  Πραγματικά αμφιβάλλω για αυτό.Το ένα θέμα που βλέπετε σχεδόν σε κάθε υποστηρικτή του AWS είναι μια μεγάλη ψευδαίσθηση σχετικά με το τι εγγυάται ότι το AWS σας παρέχει πραγματικάΝαι, σίγουρα.Κανείς δεν απολύεται επειδή αγοράζει από την IBMΛοιπόν, αν οι μεγάλες εταιρείες είχαν κάποια αρμοδιότητα στη λήψη αποφάσεων, θα ήταν ασυναγώνιστες και θα ήταν απελπιστικό να δουλέψουμε σε οτιδήποτε άλλο στο όλα.Λοιπόν, ναι, αυτό είναι ένα δημόσιο αγαθόΠηγή: σχεδόν τριάντα χρόνια λειτουργίαςΜέχρι στιγμής δεν έχω παρατηρήσει ότι αν ξοδέψω περισσότερα για την εταιρεία που πληρώνομαι επίσης περισσότεροη απόκτηση της ισοδύναμης αξιοπιστίας με σίδερα είναι πολύ πιο ακριβή από την ενοικίαση "δύο αποκλειστικών διακομιστών"- τώρα μπορεί να είστε εντάξει με έναν διακομιστή και μια εφεδρική λύση , και αυτό είναι δίκαιο. αλλά ένα sysad για τη δημιουργία όλων αυτών, ακόμη και με ένα σύντομο συμβόλαιο για την αρχική εγκατάσταση και χωρίς συντήρηση, θα ξεπεράσει τη διαφορά τιμής στο cloud, ειδικά αν υπάρχει μια βάση δεδομένων στο μείγμα και σας ενδιαφέρει αυτά τα δεδομέναΣήμερα, το cloud είναι παρόμοιο - ο χρόνος για την αγορά είναι πιο γρήγορος καθώς υπάρχουν λιγότερα κινούμενα μέρη.Όταν η οικονομία ανεβαίνει και η ανάπτυξη επιβραδύνεται, οι beancounters έρχονται και κάνουν το δικό τουςΣυμβαίνει κάθε φοράΑυτό κάνει το AWS πλουσιότερο στις εταιρείες theof και στις ομάδες cloudΕίναι ασήμαντο να παρέχει και να καταργεί την παροχή μιας παρουσίας EC2 αυτόματα, μέσα σε δευτερόλεπτα, εάν η ανάπτυξή σας χρειάζεται να αυξηθεί ή να μειωθεί.Αυτό είναι που το κάνει θεμελιωδώς διαφορετικό από έναν διακομιστή γυμνού μετάλλου
Τώρα, δεν αρνούμαι ότι μπορεί να είναι ακόμα πιο αποδοτικό σε σύγκριση με το AWS να παρέχει μερικούς περισσότερους αποκλειστικούς διακομιστές από αυτούς που θα χρειαστείτε, αλλά όταν έχετε πραγματικά απρόβλεπτους φόρτους εργασίας δεν είναι εύκολο να συμβαδίσετε

αν γυρίζετε και κλείνετε VM για να καλύψετε την καμπύλη ζήτησης - κάτι δεν πάει καλά με την αρχιτεκτονική σας

Σκεφτήκατε ποτέ πώς το stackoverflow χρησιμοποιεί ~8 αποκλειστικούς διακομιστές για να εξυπηρετήσει ολόκληρο τον κόσμο και δεν χρειάζεται να κάνει spin up και τερματισμό VM για να καλύψει την παγκόσμια ζήτηση πελατών;
--
Όταν σχεδιάζετε υπολογιστική υποδομή, είναι σημαντικό να επιστρέφετε στα βασικά και να μην υποκύπτετε στην προπαγάνδα των πωλητών cloud
Το είπες μόνος σου. Δεν χρειάζεται όλες οι εφαρμογές να εξυπηρετούν ολόκληρο τον κόσμο, επομένως η ζήτηση θα είναι χαμηλότερη όταν οι άνθρωποι πάνε για ύπνο

Ακόμη και με παγκόσμιες εφαρμογές υπάρχουν κανονισμοί που απαιτούν τη φιλοξενία εφαρμογών και δεδομένων σε συγκεκριμένες περιοχές. Φανταστείτε μια εφαρμογή που χρησιμοποιείται από πελάτες στην Ευρώπη, την Αυστραλία και τις ΗΠΑ. Πρέπει να εξυπηρετούνται από τοπικά κέντρα δεδομένων και το ένα σύμπλεγμα θα κοιμάται κυρίως όταν εκτελείται το άλλο (λόγω ζωνών ώρας). Με αποκλειστικούς διακομιστές θα σπαταλάτε το 60-70% των πόρων σας, ενώ χρησιμοποιώντας κάτι σαν EC2/Fargate μπορείτε να μειώσετε σχεδόν στο 0 όταν η περιοχή σας κοιμάται

Υπάρχει μια μέθοδος για την τρέλα, εδώ ονομάζεται "ανάπτυξη με γνώμονα την ασφάλεια εργασίας"Γιατί είναι απειλή για τις δουλειές τους

Υπάρχει μια ολόκληρη ομάδα ανθρώπων που έχουν τις τεχνικές γνώσεις για να αυτοδιοργανωθούν ή να φιλοξενήσουν μικρές παρουσίες για την οικογένειά τους/τους φίλους/τους συλλόγους τους/το κλαμπ πεζοπορίας. Αυτό το μικρό περιθώριο όπου μπορείτε να ξοδέψετε λίγο επιπλέον επειδή θέλετε να το κάνετε σωστά, αλλά δεν μπορείτε να δικαιολογήσετε το να πληρώνετε τόσα πολλά και να ξοδεύετε χρόνο κάνοντας σκληρή συντήρηση. Ένα μικρό VPS, με ένα κοινόχρηστο Nextcloud ή έναν μικρό ιστότοπο, είναι το μόνο που χρειάζεται σε πολλές περιπτώσεις

Για αυτό χρησιμοποιώ ακόμη και λίγο Raspberry Pi 400 στην κρεβατοκάμαρά μου

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

Ο ίδιος φιλοξενώ τα δικά μου πράγματα για σχεδόν μια δεκαετία τώρα. Κανείς δεν έχει δοκιμάσει το DDoSing μου, γιατί να το κάνει; Τι όφελος θα είχαν ενδεχομένως από αυτό; Θα ήμουν σχεδόν το μόνο άτομο που θα επηρεαζόταν, και μόλις σταματήσουν, δεν θα αργούσε να ανακάμψει

Υπάρχει ελάχιστα έως καθόλου κίνητρα για DDoS ένα προσωπικό κουτί, πόσο μάλλον από ένα τυχαίο διαδίκτυο

Υπερεκτιμάτε δραστικά τις ικανότητες ενός εφήβου

Το να κάνετε ping στην IP ξανά και ξανά δεν θα κάνει πραγματικά πολλά. Ίσως μια επίθεση DoS ανάλογα με το τι έχει το δίκτυο-στόχος όσον αφορά το IPS, αλλά ακόμα και τότε είναι πιο πιθανό να μολύνουν τους υπολογιστές τους με ιούς προτού τους δοθεί η ευκαιρία να σας επιτεθούν.

Προσωπικά έχω δει ένα από αυτά για κάποιον απατεώνα στο GTA 5. Σίγουρα συμβαίνει και δεν είναι διασκεδαστικό
Επεξεργασία: Φαίνεται ότι αυτό μπορεί να είναι αυτόματο. Αυτό είναι κάτι ενδιαφέρον που πρέπει να το ψάξω λίγο. Πιθανώς είναι απλώς επιπλέον πολυπλοκότητα για τον μικρό μου διακομιστή, αλλά έχω κάποιες χρήσεις στο μυαλό μου

Τεχνικά, το homelab μου είναι επίσης σε στατική δημόσια IP - αυτό ήταν περισσότερο μια άσκηση στο "μπορώ να το κάνω αυτό"παρά "στην πραγματικότητα είναι απαραίτητο", αλλά είναι ακόμα ωραίο και είμαι πολύ χαρούμενος

Σχετικά με το μόνο hangup ήταν ότι έπρεπε να διαμορφώσω το Wireguard για να διατηρήσει τη σήραγγα ζωντανή, διαφορετικά μερικές φορές το VPS θα λάμβανε εισερχόμενη κίνηση και αν το εργαστήριό μου δεν είχε επικοινωνήσει για λίγο (που, γιατί;) το τούνελ θα ήταν εκτός λειτουργίας, και η σύνδεση μεσολάβησης θα. Ευτυχώς αυτή είναι ενσωματωμένη λειτουργικότητα

Έτσι, φαίνεται ότι η προσθήκη ροών RSS / Atom σε έναν ιστότοπο σελίδων jekyll ή GitHub είναι αρκετά απλή

1. httpsgithub.com/jekyll/jekyll-feed
2. httpsdocs.github.com/en/pages/setting-up-a-github-pages-s..

3. httpspages.github.com/versions/
atom 2c/4t, 4gb ram, 1tb drive, 100mbit
Μερικά χρόνια λειτουργίας σε αυτό το σημείο
Εάν δεν διακοπεί: ενδέχεται να οφείλεται κάποια αναβάθμιση.
Οι ενημερώσεις ασφαλείας πυρήνα είναι ένα θέμα


Βρήκα τα Atoms να είναι αφόρητα αργά, ακόμα και με Linux. Φυσικά είναι αρκετό για την εξυπηρέτηση ιστότοπων και οτιδήποτε άλλο, αλλά είναι μπερδεμένο το πόση ενέργεια χρησιμοποιούν απλά δεν έχουν απόδοση

Ακριβώς. Αυτές οι περιπτώσεις VPS κάτω των 10 $ είναι ιδανικές για μικρά έργα όπου δεν θέλετε να συνάψετε μακροχρόνιες συμβάσεις ή να ασχοληθείτε με τη διαχείριση των δικών σας διακομιστών

Εάν διαχειρίζεστε μια πραγματική επιχείρηση όπου τα περιθώρια είναι ελάχιστα και έχετε όλο τον ελεύθερο χρόνο στον κόσμο για να χειριστείτε ζητήματα διακομιστή, εάν (όταν) προκύψουν, αυτοί οι αποκλειστικοί διακομιστές των ~ 50 $ θα μπορούσαν να είναι ενδιαφέροντες να εξερευνήσετε

Αλλά αν έχετε μια πραγματική επιχείρηση, ακόμη και ένας λογαριασμός AWS 10.000 $/μήνα είναι φθηνότερος από την πρόσληψη άλλου ειδικευμένου προγραμματιστή για να βοηθήσει στη διαχείριση των αποκλειστικών διακομιστών σας

Αυτό είναι που γενικά χάνεται στις συζητήσεις σχετικά με το κόστος του cloud σε μέρη όπως το HN: Ναι, το cloud είναι ακριβό, αλλά η πρόσληψη ακόμη και ενός επιπλέον sysadmin/προγραμματιστή για να σας βοηθήσει να διαχειριστείτε προσαρμοσμένη υποδομή είναι απίστευτα ακριβή και πολύ λιγότερο ευέλικτη. Αυτός είναι ο λόγος για τον οποίο το να ξοδεύετε υποθετικά 5000 $/μήνα σε μια λύση που φιλοξενείται στο cloud που θα μπορούσε, θεωρητικά, να κατασκευαστεί προσαρμοσμένα σε διακομιστή 50 $/μήνα με αρκετό χρόνο επένδυσης, μπορεί να είναι πολύ μεγάλη. Οι μηχανικοί είναι ακριβοί και ο χρόνος περιορισμένος

Ωχ, με συγχωρείτε, αλλά πόσα πληρώνετε αυτόν τον τύπο DevOps; Αυτό φαίνεται σαν μια πολύ αμερικανική προοπτική, ακόμη και η περιοχή της κοιλάδας. Στην Ευρώπη, η πρόσληψη ενός άντρα θα ήταν φθηνότερη

Το πλήρως φορτωμένο κόστος απασχόλησης είναι σημαντικά υψηλότερο από αυτό που παίρνετε στο σπίτι στο μισθό σας. Στην Ευρώπη είναι χειρότερα. Ρίξτε μια ματιά σε αυτά τα γραφήματα: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Εάν πληρώσετε κάποιον 1000 EUR στο Ηνωμένο Βασίλειο, κοστίζει στην εταιρεία συνολικά 1245 EUR

Εάν πληρώσετε κάποιον 1000 EUR στη Ρουμανία, κοστίζει στην εταιρεία 1747 EUR συνολικά

Έτσι, ένα πλήρως φορτωμένο κόστος 120.000 $ μπορεί να σας εξαγοράσει μόνο με μισθό $68.000 USD για ένα άτομο που ασχολείται με την ΕΕ

Αλλά δεν μπορείς να έχεις μόνο ένα άτομο που αναπτύσσει. Χρειάζεστε τουλάχιστον 2 αν θέλετε να επιτρέψετε σε έναν από αυτούς να κάνει ένα διάλειμμα, πάρε διακοπές

Μπορώ να σε συνδέσω σε περίπου 3 ώρες

Το AWS είναι πολύ οικονομικό για άλλες υπηρεσίες (S3, SES, SQS, κ.λπ.), αλλά οι εικονικές μηχανές δεν είναι καλή συμφωνία. Παίρνετε λιγότερη RAM& CPU, με την επιβάρυνση της εικονικοποίησης, και πληρώνουν πολύ περισσότερα χρήματα

Ειδικά για την Postgres αν εκτελέσεις κάποιες δοκιμές με το pgbench μπορείς να δεις πραγματικά το πρόστιμο που πληρώνεις για το virtualization

Ίσως η ικανότητα του sysadmin να μπορείς να φτιάξεις τη δική σου υποδομή γίνεται μια χαμένη τέχνη, διαφορετικά δεν μπορώ να εξηγήσω γιατί οι άνθρωποι είναι τόσο ερωτευμένοι να πληρώνουν 5 φορές για λιγότερη απόδοση

Το Hetzner είναι φθηνό και αξιόπιστο στην Ευρώπη, αν βρίσκεστε στη Βόρεια Αμερική ρίξτε μια ματιά στο OVH. Ειδικά η εναλλακτική λύση εξοικονόμησης κόστους που ονομάζεται SoYouStart. Μπορείτε να πάρετε 4/8 4,5 ghz, 64 RAM και μονάδα NVME για 65 $

(Δεν έχω καμία σχέση με την OVH, είμαι απλώς πελάτης με σχεδόν 100 διακομιστές και μου βγήκε τέλεια)
Θα σημειώσω επίσης ότι είμαι γέρος hehe, και μια από τις πρώτες μου δουλειές είχαμε ένα κέντρο δεδομένων αξιοπρεπούς μεγέθους στην τοποθεσία. Η ενασχόληση με SAN, οδηγούς ταινίας (αυτόματοι περιστροφείς ταινίας εκείνη την εποχή ήταν διακομιστές, κ.λπ. ήταν μια τεράστια PITA. Το να συσκευάζω τις ταινίες και να τις στέλνω σε άλλο γραφείο για πλεονασμό τοποθεσίας ήταν πάντα διασκεδαστικό

Η συγκεκριμένη εφαρμογή που διαχειρίζομαι πάσχει πραγματικά από χαμηλά GHz και να μην έχει όλα τα δεδομένα στη μνήμη. Έχοντας τρέξει τα σημεία αναφοράς στο EC2, ορισμένες αναφορές που τελειώνουν σε ~5 δευτερόλεπτα μπορεί να διαρκέσουν περισσότερο από ένα λεπτό σε μια παρόμοια παρουσία EC2 που κοστίζει περίπου 10 φορές περισσότερο. Αυτή η εφαρμογή χρειάζεται πραγματικά την ακατέργαστη CPU. και ναι, έχουμε μια αρκετά μεγάλη ομάδα μηχανικών που έχει βελτιστοποιήσει όλα τα ερωτήματα, τους δείκτες κ.λπ

Όσον αφορά την αναπαραγωγή, τα αντίγραφα ασφαλείας κ.λπ. Τα έστησα όλα αυτά, και ειλικρινά δεν ήταν μεγάλη υπόθεση. Είναι μερικά σύντομα κεφάλαια στο βιβλίο της Postgres που τα εξηγούν όλα πολύ απλά, πώς να ρυθμίσετε τις παραμέτρους, τη συνεχή (και αυτόματη) δοκιμή κ.λπ.

Συμφωνώ ότι τα SAN είναι ένας εφιάλτης. Αυτός είναι ο λόγος που στέλνω όλα τα WAL μου (αρχεία αντιγράφων ασφαλείας PG) στο S3 (και τελικά στο Glacier). Με αυτόν τον τρόπο δεν χρειάζεται να σκέφτομαι να χάσω αυτά τα αρχεία και είναι φτηνό

Νομίζω ότι υπάρχει μια εσφαλμένη αντίληψη ότι αυτού του είδους οι διαμορφώσεις είναι πολύ περίπλοκες για να τις ρυθμίσει ένας μόνο μηχανικός, χωρίς να απαιτείται ατελείωτη συντήρηση. Στην πραγματικότητα, μπορείτε να τα ρυθμίσετε όλα σε λιγότερο από μία εβδομάδα και χρειάζεται πραγματικά συντήρηση μόνο όταν θέλετε να αναβαθμίσετε το Postgres (κάποιες ρυθμίσεις μπορεί να έχουν αλλάξει). Υπολογίζω ότι χρειάζονται περίπου 5 ώρες το χρόνο συντήρηση

Η υποδομή αυτοεξυπηρέτησης φαίνεται πιθανό να γίνεται όλο και πιο βιώσιμη καθώς συνεχίζουμε να βελτιώνουμε την παράδοση του τελευταίου μιλίου και να επεκτείνουμε την πρόσβαση σε οπτικές ίνες. Θα γίνει το σύννεφο αυτο-κανιβαλιστικό; Σίγουρα ίσως

Αυτό που σας προσφέρει το cloud είναι η δυνατότητα να βάλετε τα δεδομένα/τον φόρτο εργασίας σας στον πυρήνα χωρίς να χρειάζεται να κάνετε ειδικές συμφωνίες με τον τοπικό πάροχο υπηρεσιών διαδικτύου σας, και με πολύ μεγαλύτερη ανθεκτικότητα που θα μπορούσατε να αντέξετε οικονομικά, εκτός και αν έχετε τουλάχιστον το κοντέινερ 20 ποδιών γεμάτο κλίμακας υπολογιστικών αναγκών διακομιστών

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

Επεξεργασία: Αν κάποιος ενδιαφέρεται για αυτο-φιλοξενία, είναι απλό με το cloudflared. Έχω ένα Google Pixelbook 2017 που τρέχει το Ubuntu σε προσαρμοσμένο υλικολογισμικό που εξυπηρετεί έναν ιστότοπο που βασίζεται σε Flask. Η φόρτιση του γραφείου μου είναι συνδεδεμένη σε δίκτυο Wi-Fi επισκεπτών. Λαμβάνει βαθμολογία 100/100 Mobile PageSpeed ​​και χρειάζεται 0,8 δευτερόλεπτα για να φορτώσει πλήρως

Από το DO παίρνω όλα τα οφέλη μιας αξιόπιστης εταιρείας, επεκτασιμότητα, αυτοματοποιημένα αντίγραφα ασφαλείας κ.λπ. Δεν υπάρχει περίπτωση να αλλάξω

Το σύννεφο Hetzner έχει τώρα δύο τοποθεσίες στις Η.Π.Α. Ωστόσο, δεν υπάρχουν αποκλειστικοί διακομιστές στις ΗΠΑ - αυτοί θα ήταν αληθινοί. Ακόμα κι αν οι ίδιες οι τρέχουσες προσφορές cloud είναι ήδη ~30% της τιμής των κύριων ισοδύναμων cloud..

Όπως εσείς, έτσι και εγώ εκτελώ τις υπηρεσίες μου από έναν ενοικιασμένο φυσικό διακομιστή. Χρησιμοποιούσα το Versaweb, αλλά τα μηχανήματα τους είναι πολύ παλιά. Δεν μου άρεσε προηγουμένως ο Hetzner επειδή είχα ακούσει άσχημα πράγματα για αυτούς που παρεμβαίνουν σε αυτό που τρέχεις

Ωστόσο, μετακόμισα σε αυτούς τον Δεκέμβριο όταν μόλις πέθανε η παρουσία μου στο Versaweb, πιθανότατα SSD από μεγάλη ηλικία. Τώρα πληρώνω το 50% από όσα πλήρωσα στο Versaweb και μπορώ να εκτελέσω 6 τέτοιες περιπτώσεις Postgres

Στη συνέχεια, αναρωτιέται κανείς εάν αξίζει να πληρώσετε 700 $ από 800 $ για μια διαχειριζόμενη υπηρεσία με φανταχτερό περιβάλλον εργασίας στο cloud, αυτόματες αναβαθμίσεις και αντίγραφα ασφαλείας κ.λπ.

Για μια παράσταση 1 ατόμου ή μικρή εκκίνηση, νομίζω ότι όχι. Φθηνότερο στη χρήση μιας διαθέσιμης υπηρεσίας και απόθεση αντιγράφων ασφαλείας στο S3 ή κάτι φθηνότερο

Η εταιρεία Δούλευα για την αισίως αμειβόμενη εταιρεία Α τέσσερις φορές μεγαλύτερη από ό,τι η εταιρεία Β χρέωνε για την ίδια ακριβώς υπηρεσία, μόνο και μόνο επειδή η εταιρεία Α ήταν πρόθυμη να στείλει τριμηνιαία τιμολόγια με τρόπο που έπαιζε καλά με το σύστημα τιμολόγησης μας. Για τις εταιρείες, η εξοικονόμηση μερικών εκατοντάδων δολαρίων εδώ και εκεί συχνά δεν αξίζει την ταλαιπωρία της εισαγωγής επιπλέον τριβής

Υπάρχει ένα έμμεσο κόστος εκεί. Εάν είναι μόνο ένα ή δύο από αυτά τα πράγματα, απλώς χρησιμοποιήστε τις διαχειριζόμενες υπηρεσίες

Εάν αρχίσετε να κλιμακώνετε, πάρτε έναν τύπο υπαλλήλου διαχειριστή για εξοικονόμηση σε αυτό
Διαφορετικά, θα έπρεπε να προσλάβω/να συμβόλαια με κάποιον πολύ έμπειρο ή να αφιερώσω έναν σταθερό μήνα ή περισσότερο από τον χρόνο μου (ο οποίος δεν ήταν διαθέσιμος), απλώς για να είμαι 100% σίγουρος ότι θα μπορούσαμε πάντα να επαναφέρουμε τα ημερολογιακά αντίγραφα ασφαλείας PITR γρήγορα

Μπορώ να εξοικονομήσω το μέγεθος του κόστους στο cloud σε άλλα μέρη, αλλά η αξιόπιστη διαχείριση PostgreSQL ήταν μια αρκετά εύκολη κλήση (ακόμα κι αν η τιμή εισόδου ήταν μεγαλύτερη από ό,τι θα περίμενες)

Μια πρώιμη startup που δεν έχει την πολυτέλεια να χάσει μια ώρα δεδομένων παραγωγής είναι πιθανώς πολύ εύθραυστη για να επιβιώσει ούτως ή άλλως

Είναι μια πρώιμη εκκίνηση - θα υπάρξουν μεγαλύτερες διακοπές από αυτήν στην υπηρεσία και όσοι πελάτες φεύγουν μετά από μια ώρα απώλεια δεδομένων παραγωγής απλώς δεν εκτιμούσαν αρκετά το προϊόν ούτως ή άλλως

(Στη συγκεκριμένη εκκίνηση που σκεφτόμουν, είχα ήδη μερικές ωραίες αυτοματοποιημένες συχνές απορρίψεις DB-online στο S3 με επιβολή διατήρησης, αλλά δεν πίστευα ότι ήταν αρκετά καλό για αυτό το συγκεκριμένο σενάριο. Αλλά χωρίς να είμαι σίγουρος ότι θα μπορούσαμε να ανακτήσουμε Το PITR/journaling θα προσθέσει ένα νέο μεμονωμένο στοίχημα αποτυχίας στην επιτυχία μιας επιχείρησης που διαφορετικά θα μπορούσε να έχει 9+ νούμερα έξοδο σε λίγα/αρκετά χρόνια, μόνο για να εξοικονομήσει μερικές εκατοντάδες.)
Επίσης, υποθέτω ότι ορισμένες από τις πρώιμες νεοφυείς επιχειρήσεις που έχουν λιγότερο απαιτητικές ανάγκες, αλλά είναι πιο καμαρωτές όσον αφορά τις υποχρεώσεις τους έναντι των δεδομένων των πελατών/χρηστών, εξακολουθούν να αμελούν τις ελάχιστες βασικές πρακτικές

Ίσως ένας διαισθητικός τρόπος για να εκτιμήσετε: Φανταστείτε μια ιστορία ειδήσεων στο HN, σχετικά με ορισμένες επιχειρήσεις εκκίνησης που έριξαν την μπάλα, με τα ονόματα των ιδρυτών startup, και η ιστορία λέει και αποδεικνύεται ότι δεν είχαν καλά αντίγραφα ασφαλείας Στη συνέχεια, ένα από τα οι συνιδρυτές, που ίσως δεν κοιμούνται πολύ καθώς η εταιρεία τους καταρρέει γύρω τους, απαντούν "Τα δεδομένα των πελατών δεν είναι τόσο σημαντικά σε μια πρώιμη εκκίνηση, αν ήταν, θα ήμασταν πολύ εύθραυστοι"(πληκτρολογήθηκε πριν ο συνιδρυτής προλάβει να πετάξει το φορητό υπολογιστή αυτού του ατόμου σε όλη την αίθουσα για να σταματήσουν να πληκτρολογούν). Δεν θα ήταν καλή εμφάνιση

Θα αναφερθώ σε αυτό στο τέλος

>Φανταστείτε μια ιστορία ειδήσεων στο HN, σχετικά με ορισμένες επιχειρήσεις εκκίνησης που έριξαν την μπάλα, με τα ονόματα των ιδρυτών startup, και η ιστορία λέει και αποδεικνύεται ότι δεν είχαν καλά αντίγραφα ασφαλείας

ITYM και αποδεικνύεται ότι δεν είχαν αντίγραφο ασφαλείας για την τελευταία ώρα
Μπορώ να φανταστώ τα πάντα στο σενάριο σας, ακόμα και τα μη αποκομμένα κομμάτια, και όλα φαίνονται φυσιολογικά, εκτός και αν διαβάσετε "Οι πελάτες μας startup, που μας χρησιμοποιούν εδώ και ένα μήνα, έφυγαν αμέσως μόλις χάσαμε την τελευταία ώρα των δεδομένων τους"Πραγματικά δεν μπορώ να φανταστώ αυτό το σενάριο

Τώρα, φυσικά, υπάρχουν ορισμένες επιχειρήσεις όπου το όφελος από τη χρήση του είναι ότι δεν υπάρχει ούτε μια ώρα χαμένων δεδομένων
IOW, οι πελάτες το χρησιμοποιούν επειδή δεν θα χάσουν δεδομένα: για παράδειγμα, διαδικτυακή συνεργασία εγγράφων[1][2]. Εάν έχετε μια κατάρρευση που χάνει μια ώρα από τα τελευταία δεδομένα που εισήχθησαν, τότε βεβαίως, περιμένετε από όλους τους επηρεαζόμενους τρέχοντες χρήστες να φύγουν αμέσως

[1] Αν και, προσωπικά, θα μετριάζω τον κίνδυνο αντιγράφοντας το τρέχον έγγραφο στην τοπική αποθήκευση κατά την επεξεργασία του

[2] Ίσως το χρηματιστήριο χρειάζεται επίσης το σύστημα για να διατηρεί την τελευταία ώρα δεδομένων; Τι άλλο?
Νομίζω ότι ακόμη και για μεγαλύτερες ομάδες μπορεί να έχει νόημα να διαχειρίζεστε μόνοι σας τις βάσεις δεδομένων, υποθέτοντας ότι έχετε την ικανότητα να το κάνετε καλά. Υπάρχουν τόσα πολλά πράγματα που μπορεί να πάνε στραβά με τις διαχειριζόμενες υπηρεσίες και δεν κρύβουν την υποκείμενη υλοποίηση με τον τρόπο που κάνουν πράγματα όπως ο αποκλεισμός αποθήκευσης ή η αποθήκευση αντικειμένων

Οι κορυφαίες επιδόσεις είναι σίγουρα χειρότερες - αλλά δεν με ενοχλεί πολύ αν κάτι χρειάζεται περισσότερο για να τρέξει ούτως ή άλλως. Σίγουρα έχετε δίκιο στο ότι έχετε τόση αυτοματοποίηση στην παροχή ενός διακομιστή, κάτι που δεν έκανα με έναν φυσικό διακομιστή

Είχα έναν διακομιστή root για τα έργα μου για κατοικίδια, αλλά ειλικρινά, αυτό δεν έχει νόημα. Δεν τρέχω μεγάλη επισκεψιμότητα, υπολογίζω έντονο SaaS στα μηχανήματα μου. Είναι απλώς ένας στατικός ιστότοπος και μερικά έργα. Μειώνω το μηνιαίο κόστος των 24, το οποίο περιλαμβάνει ένα κουτί αποθήκευσης 1 TB για την αποθήκευση όλων των δεδομένων μου

Το κύριο ζήτημα σε κάθε σενάριο που αφορά πραγματικό υλικό είναι ότι χρειάζεστε προσωπικό ικανό τόσο σε υλικό όσο και σε συστήματα Linux/UNIX. Πολλοί ισχυρίζονται ότι είναι στα βιογραφικά τους και μετά δεν μπορούν να αποδώσουν μία φορά στη δουλειά (ούτως ή άλλως από την εμπειρία μου). Κατά τη γνώμη μου, ένας από τους σημαντικότερους λόγους για την έκρηξη του κόσμου του cloud ήταν ακριβώς η δυσκολία στη δημιουργία και το οικονομικό κόστος της δημιουργίας τέτοιων ομάδων. Επιπλέον, υπάρχει μια κάπως φυσική (και απαραίτητη) τριβή μεταξύ των προγραμματιστών εφαρμογών και των ανθρώπων συστημάτων. Οι άνθρωποι των συστημάτων θα πρέπει πάντα να πιέζουν και να επιχειρηματολογούν για περισσότερη ασφάλεια, περισσότερες διαδικασίες και λιγότερες αναπτύξεις. Η ομάδα προγραμματιστών θα πρέπει πάντα να επιχειρηματολογεί για περισσότερη ευελιξία, περισσότερες εκδόσεις και λιγότερη διαδικασία. Η καλή διαχείριση θα πρέπει στη συνέχεια να φτάσει στη μέση διαδρομή μεταξύ των δύο. Δυστυχώς, οι ανίκανοι διευθυντές συχνά μόλις αποφάσισαν να απαλλαγούν από τους ανθρώπους των συστημάτων και να μεταφέρουν πράγματα στη γη του AWS

Τέλος, θα ήθελα απλώς να σημειώσω ότι η αρχιτεκτονική του cloud είναι κακή για τον πλανήτη, καθώς απαιτεί υπερβολική παροχή από τους παρόχους cloud και απαιτεί περισσότερη ισχύ υπολογιστή συνολικά λόγω των πολλών επιπέδων αφαίρεσης. Ενώ οποιοδήποτε έργο είναι υπεύθυνο για λίγα από αυτά τα απόβλητα, ολόκληρο το παγκόσμιο σύννεφο ως σύνολο είναι πολύ σπάταλο. Αυτό με ενοχλεί και προφανώς πιθανόν παράγοντες ως συναισθηματική προκατάληψη στις απόψεις μου (τόσο μεγάλες ποσότητες αλατιού για όλα τα παραπάνω)
Το επιχείρημα θα μπορούσε να προβληθεί ότι μπορείτε να αναπτύξετε ένα μέσο για την ενοικίαση φυσικών διακομιστών προ-εισοδήματος, στη συνέχεια, όταν είναι λογικό, μπορείτε είτε να χρησιμοποιήσετε την τυπική απόσβεση -ή- την ενότητα 179 για οριστικές αγορές ή/και μισθώσεις Ενότητας 179

Για παράδειγμα, μπορείτε να αναπτύξετε μια απίστευτα ικανή ομάδα ας πούμε τεσσάρων φυσικών μηχανών 1U με απολύτως υπερπαροχή 100.000 $ σε διαφορετικές εγκαταστάσεις colo για πλεονασμό. Υπάρχουν όλων των ειδών τα κόλπα εδώ για εξισορρόπηση φορτίου και failover με την υπηρεσία cloud XYZ, DNS, anycast, ό,τι θέλετε. Μπορείτε να πάτε με διάφορες εγκαταστάσεις colo που λειτουργούν κέντρα δεδομένων σε όλο τον κόσμο, να στείλετε το υλικό από τον πωλητή σε αυτούς και, στη συνέχεια, να τους παρέχετε Ansible ή οτιδήποτε άλλο σας ενδιαφέρει χωρίς να δείτε ποτέ την εγκατάσταση ή να αγγίξετε το υλικό

Έτσι, τώρα έχετε περιττό φυσικό υλικό που θα κάνει κύκλους γύρω από τους περισσότερους παρόχους cloud (ειδικά για I/O), σταθερό κόστος όπως όλα όσα μπορείτε εύρος ζώνης (που δεν έχει τη σήμανση 800% των υπηρεσιών cloud, κ.λπ.) - όχι άλλη αναμονή για τον αναπόφευκτο λογαριασμό των 50.000 $ στο cloud ή την προσπάθεια εντοπισμού (πανικόβλητος) τι σας έκανε να υπερβείτε τον διαμορφωμένο προϋπολογισμό σας στο cloud σε μια ημέρα αντί για ένα μήνα. Oh btw, δεν κλείνεστε στα ανόητα ιδιόκτητα API για να παρέχετε και να χρησιμοποιείτε ακόμη και υπηρεσίες εκτός από εικονικές μηχανές που προσφέρονται από το $BIGCLOUD

Εάν κάνετε οποιοδήποτε ML, μπορείτε να εκπαιδεύσετε με το δικό σας υλικό ή (ή το περιστασιακό cloud) και να εκτελέσετε τα συμπεράσματα 24/7 με πράγματα όπως το NVIDIA A10. Η συνεχής ενοικίαση cloud για παρουσίες GPU είναι απίστευτα ακριβή και η απόδοση επένδυσης (ROI) για την αγορά του υλικού είναι συνήθως στην περιοχή μερικών μηνών (ή πολύ μπροστά σχεδόν αμέσως με την Ενότητα 179). Για παράδειγμα, έκανα πρόσφατα ένα σημείο αναφοράς με το Nvidia A10 για ένα μοντέλο που εξυπηρετούμε και μπορεί να κάνει πάνω από 700 αιτήματα συμπερασμάτων στο FP32 με καθυστέρηση κάτω από 10 ms. Με ένα μόνο A10 ανά σασί σε τέσσερις υγιείς περιπτώσεις που είναι 2800 req/s (και πιθανότατα θα μπορούσε να ρυθμιστεί περαιτέρω)

Στη συνέχεια, αν γίνετε ΠΡΑΓΜΑΤΙΚΑ μεγάλοι, μπορείτε να αρχίσετε να αποκτάτε ντουλάπια και όχι μόνο. Όσον αφορά τις αστοχίες υλικού, όπως αναφέρθηκε, το μόνο που μπορώ να πω είναι διπλό PS RAID, κ.λπ., το υλικό είναι (από την εμπειρία μου) εξαιρετικά αξιόπιστο. Έχοντας στο παρελθόν πολλά πλήρη ερμάρια υλικού, οι αστοχίες υλικού ήταν λίγες και πολύ μεταξύ τους και το υλικό Οι πωλητές θα περιλαμβάνουν απίστευτα SLA για αντικατάσταση. Τους ειδοποιείς για την αποτυχία, στέλνουν έναν τεχνικό< οκτώ ώρες απευθείας στην εγκατάσταση colo και αντικαταστήστε το δίσκο, το PS, κ.λπ. με το φως που αναβοσβήνει

Η εμπειρία μου είναι ότι ένας (καλός) πόρος FTE μπορεί να το διαχειριστεί εύκολα σε κλίμακα πολλαπλών γραφείων. Για την άποψή σας, το τρέχον ζήτημα είναι ότι πολλοί από αυτούς τους ανθρώπους έχουν αρπαχθεί από τους μεγάλους παρόχους cloud και έχουν αντικατασταθεί (στην αγορά) με πόρους που μπορούν να περιηγηθούν στην οριακή γελοιότητα που χρησιμοποιεί δεκάδες (αν όχι περισσότερα) προϊόντα/υπηρεσίες από $ ΜΕΓΑΛΟ ΣΥΝΝΕΦΟ

Βρήκα επίσης ότι αυτή η διαμόρφωση είναι στην πραγματικότητα ΠΟΛΥ πιο αξιόπιστη από τα περισσότερα $BIGCLOUD. Μην αναρωτιέστε πια τι συμβαίνει με μια διακοπή λειτουργίας του $BIGCLOUD που δεν θα αναγνωρίσουν καν (και δεν έχετε κανέναν απολύτως έλεγχο). Προερχόμενος από ένα υπόβαθρο στις τηλεπικοινωνίες και την υγειονομική περίθαλψη, μου φαίνεται εντελώς παράξενο πώς ο χρόνος λειτουργίας έχει πράγματι χειροτερέψει πολύ με τους παρόχους cloud. Συνήθως, μπορείτε απλώς να πείτε στους πελάτες "ωχ, το Διαδίκτυο έχει προβλήματα σήμερα", επειδή πιθανότατα θα βλέπουν τίτλους σχετικά με αυτό, αλλά για πολλές εφαρμογές αυτό είναι εντελώς απαράδεκτο - και θα πρέπει να περιμένουμε καλύτερα

[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
Αν θέλω να δημιουργήσω ένα νέο έργο ή να δοκιμάσω να φιλοξενήσω κάτι νέο, χρειάζονται μερικά λεπτά και έχω τα σενάρια. Οι αναπτύξεις είναι γρήγορες, η συντήρηση είναι χαμηλή και έχω πολύ περισσότερα για τα χρήματά μου

Για όποιον ενδιαφέρεται, αυτή είναι η γενική περιγραφή αυτού που χρησιμοποιώ:
* Ανίκανος να διαχειριστεί τα πάντα
* Ένα μικρό κομμάτι εδάφους για ορισμένες καταχωρήσεις DNS τις οποίες μπορεί να αντικαταστήσω μια μέρα
* restic για αντίγραφα ασφαλείας, πάλι ελεγχόμενο από ansible
* tailscale για vpn (έχω μερικά pi's που τρέχουν στο σπίτι, τίποτα σημαντικό αλλά το tailscale το κάνει εύκολο και ασφαλές)
* docker-compose για σχεδόν οτιδήποτε άλλο
Η κύρια εφαρμογή είναι το Clojure, επομένως τρέχω ένα εγγενές JVM. Η βάση δεδομένων είναι πλήρως διανεμημένη, το RethinkDB, τώρα εργάζεται για τη μετάβαση στο FoundationDB

Το σημαντικό είναι να μην διαχειρίζεσαι τίποτα χειροκίνητα, π.χ. αντιμετωπίζετε τους φυσικούς διακομιστές όπως οποιονδήποτε άλλο διακομιστή cloud. Δεν θα πρέπει να έχει σημασία αν είναι φυσικό ή εικονικό

Έχω δει πολλούς λιγότερο έμπειρους ανθρώπους να πληρώνουν υπερβολικά για hetzner και παρόμοια όταν ένα vps $5-10 θα είχε λειτουργήσει

Ναι, υποστηρίζετε το δικό σας υλικό σε εκείνο το σημείο. Όχι, δεν είναι μεγάλος πονοκέφαλος

Το μεγαλύτερο πρόσθετο κόστος σε αυτό είναι η ενοικίαση περισσότερων διευθύνσεων IPv4, τις οποίες η Hetzner χρεώνει αδρά προς το παρόν που υπάρχουν τόσο λίγες διαθέσιμες

Ό,τι και να δημιουργήσετε, θα ξεκινήσει με 0 χρήστες και ένα ολόκληρο πραγματικό μηχάνημα είναι εντελώς υπερβολικό για αυτό το 0 φορτίο που θα λάβετε. Αναβαθμίζετε το VPS σας σε ένα ζεύγος πραγματικών μηχανημάτων, μετά σε ένα μικρό νοικιασμένο σύμπλεγμα και μετά σε ένα κέντρο δεδομένων (αν κάποιος δεν το υποβαθμίσει). Όλα αυτά έχουν προβλέψιμους λογαριασμούς και κορυφαία απόδοση για την τιμή τους

Οτιδήποτε διαθέτετε σε ένα colo θα είναι περισσότερο ανά μήνα. Όταν είχα συνδέσεις όπου μπορούσα να πληρώσω για μια στατική IP, συνήθως ήταν 5 $/μήνα
Τώρα νοικιάζω έναν αρκετά χαμηλό διακομιστή, αλλά είναι 30 $/μήνα. Πολύ περισσότερο ό,τι χρειάζομαι, αλλά είναι ωραίο. Και δεν μείωσαν την υποστήριξη για το λειτουργικό μου σύστημα ενώ αύξαναν τις τιμές για να βελτιώσουν την υποστήριξη ή κάτι τέτοιο. (Αν και είχα κάποιο αρχικά ξεφλουδισμένο υλικό που έπρεπε να αντικατασταθεί)
όπως επισήμανες, το γυμνό μέταλ είναι ο δρόμος. λειτουργεί το αντίθετο από το cloud - λίγο περισσότερη δουλειά στην αρχή αλλά πολύ λιγότερα έξοδα στο τέλος

Περισσότερες πληροφορίες httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..

Η εγκατάσταση και η διαχείριση της Postgres είναι ένας πόνος. Θα ήταν ωραίο να υπάρχει ένας απλούστερος τρόπος για να το πετύχετε αυτό

1. Αναγκάζει τη διαμόρφωση να είναι αναπαραγώγιμη, καθώς τα VM θα μειωθούν

2. Μπορείτε να λάβετε μεγάλες εκπτώσεις στο AWS που μειώνουν τον πόνο

3. Τα άλλα πράγματα στα οποία έχετε πρόσβαση πάνω από τα VM είναι φθηνότερα/γρηγορότερα όταν τα πράγματά σας είναι ήδη στο cloud
4. Πιο εύκολο να έχετε μια τεκμηριωμένη διαμόρφωση συστήματος (π.χ. έγγραφα AWS) παρά να εκπαιδεύσετε τους ανθρώπους/τεκμηριώστε τα ειδικά πράγματα που έχετε στο εσωτερικό σας. Ιδιαίτερα χρήσιμο στην πρόσληψη νέων ανθρώπων

5. Δεν χρειάζεστε χώρο ή πλεονάζουσα τροφοδοσία/διαδίκτυο/κτλ. on premesis. Ακριβώς αρκετά για να αφήσουμε τους ανθρώπους να τρέχουν τους φορητούς υπολογιστές τους

Χρησιμοποίησα ένα VPS πριν από αυτό, αλλά σταμάτησα και άλλαξα σε ένα φυσικό επειδή ήταν καλύτερη συμφωνία και δεν αντιμετωπίσαμε όρια CPU

Ωστόσο, η παρακολούθηση του δίσκου δεν είναι πολύ δύσκολη. Για σκληρούς δίσκους, εκτελέστε το smartctl μία φορά την ώρα, ειδοποίηση όταν οι τομείς ανακατανομής ή εκκρεμότητας αυξάνονται γρήγορα ή φτάνει το 100. Για SSD, σταυρώστε τα δάχτυλά σας. από την εμπειρία μου με μερικές χιλιάδες, τείνουν να λειτουργούν τέλεια μέχρι να εξαφανιστούν από το λεωφορείο, για να μην τους ξαναδούν ποτέ. Έχετε ένα σχέδιο ανάκτησης δεδομένων που δεν περιλαμβάνει αποθήκευση των δεδομένων σε συσκευές του ίδιου μοντέλου με πολύ παρόμοια ισχύ σε ωριαία ισχύ σε ώρες Τα σφάλματα υλικολογισμικού που σχετίζονται με την ώρα είναι πραγματικά

Το Hetzner έχει τελικά ένα API για την παραγγελία αποκλειστικών διακομιστών και ένα API για την εγκατάσταση ενός λειτουργικού συστήματος (ή για επανεκκίνηση για διάσωση και αναβοσβήνει όποια εικόνα θέλετε)
Υποθέτω ότι αν ερευνούσα εμπορικές επιλογές, θα είχα ταξινομήσει τον "κορμό"στο γραφείο με μια εμπορική λύση isp, στατική IP, καλό υλικό πληροφορικής ίσως, αλλά από ό,τι ξέρω αυτήν ακριβώς τη στιγμή, αν ένας πελάτης χρειαζόταν φιλοξενία"d πηγαίνετε πάντα κατευθείαν στην ενοικίαση ενός vps

Ήμουν περισσότερο ένας junior προγραμματιστής εκείνη την εποχή, οπότε ίσως ήμουν, αλλά δεν μου λείπει καθόλου. Θεωρητικά συμφωνώ με αυτό που λέτε, αλλά η ανάπτυξη ενός Dockerfile σε κάτι σαν το Google Cloud Run είναι πολύ πιο εύκολη. Ναι, πληρώνω περισσότερα από όσα θα διαχειριζόμουν το δικό μου VPS, αλλά νομίζω ότι αυτό αντισταθμίζεται περισσότερο από τις ώρες προγραμματισμού που έχουν αποθηκευτεί

- το φυσικό υλικό έχει πρόβλημα, π.χ. αποτυχία ανεμιστήρα ->το VM μου μεταφέρεται ζωντανά σε διαφορετικό κεντρικό υπολογιστή, δεν το παρατηρώ ούτε με ενδιαφέρει
- το φυσικό υλικό εκρήγνυται ->το VM μου επανεκκινείται σε διαφορετικό κεντρικό υπολογιστή, μπορεί να παρατηρήσω αλλά δεν με νοιάζει
 Ο σχεδιασμός καταστροφών είναι πολύ πιο εύκολος με τα VM (ακόμη και με κατοικίδια ζώα και όχι βοοειδή)

Για έναν αρχάριο, τα φθηνότερα κάνουν τη δουλειά

Είμαι βέβαιος ότι καθώς το cloud computing εξελίσσεται, αυτές οι προσφορές γίνονται πιο κοινές

Υπάρχει μια άλλη πτυχή του cloud computing. Οι μεσαίες έως μεγάλες εταιρείες υπολογίζουν το cloud computing ως μονοψήφια ποσοστά στους υπολογισμούς κόστους. Αυτό σημαίνει ότι οι αποφάσεις που παίρνουν οι μάνατζερ και οι ομάδες, συχνά αναζητούν αξιοπιστία και επεκτασιμότητα (που θα τεθούν στις παρουσιάσεις τους) και όχι «η εγκατάσταση μου είναι δαπανηρή ή φθηνή»

Ο εργοδότης μου υιοθέτησε το cloud ως επιχειρηματικό/οικονομικό παιχνίδι, όχι ως θρησκευτικό. Συχνά προσγειώνουμε νέες κατασκευές στο cloud και μεταφέρουμε αργότερα σε ένα κέντρο δεδομένων, εάν χρειάζεται

Οι εφαρμογές on-prem κοστίζουν περίπου 40% λιγότερο. Οι εφαρμογές που είναι πιο αποδοτικές στο cloud παραμένουν εκεί

Νομίζω ότι ισχύει ότι τα AWS/GCP/Azure δεν είναι πολύ ανταγωνιστικές προσφορές κόστους στην Ευρώπη. Αυτό που δεν βλέπω είναι απόδειξη αυτού για τις ΗΠΑ

για την ίδια προδιαγραφή, σίγουρα. Νομίζω ότι τα εικονικά έχουν νόημα και στα δύο άκρα - είτε η δυναμική επεκτασιμότητα για μεγάλο N είναι σημαντική, είτε χρειάζεστε μόνο ένα μικρό κλάσμα ενός φυσικού πλαισίου. Το να πληρώνετε 45/μήνα για κάτι που εκτελείται find στις 5/μήνα δεν είναι επίσης λογικό και σας δίνει μεγαλύτερη ευελιξία για να μην συνδυάζετε πράγματα μαζί μόνο και μόνο για να χρησιμοποιήσετε τον διακομιστή σας

Κρατήστε αντίγραφα ασφαλείας σε κάθε περίπτωση. Κατά προτίμηση σε άλλο πάροχο ή τουλάχιστον σε διαφορετική φυσική τοποθεσία. Και, φυσικά, δοκιμάστε τα

Και αν διαχειρίζεστε ένα καλό καθεστώς δημιουργίας αντιγράφων ασφαλείας και παρακολουθείτε τα δεδομένα/την εφαρμογή σας ούτως ή άλλως, είναι σημαντική επιπλέον δυσκολία η παρακολούθηση μονάδων δίσκου;
--
[1] στην πραγματικότητα, εάν αυτοματοποιήσετε τη διαδικασία επαναφοράς σε άλλη τοποθεσία, κάτι που κάνω για μερικά από τα bit μου, τότε μπορείτε απλώς να πατήσετε αυτό το κουμπί και να ενημερώσετε το DNS όταν ολοκληρωθεί, και ίσως να εκχωρήσετε λίγο περισσότερους πυρήνες RAM+ (η δοκιμή μου οι καθρέφτες είναι μικρότεροι από τα ζωντανά εικονικά μηχανήματα, καθώς δεν χρειάζεται να εξυπηρετούν μοτίβα πραγματικής χρήσης)

Ακριβώς αυτό που κάνω για τον εαυτό μου και τους πελάτες μου. Εξοικονομεί τόνους dosh

Ακόμα κι αν ήθελα να ενημερώσω, είναι απλώς μια περίπτωση να τραβήξω την πιο πρόσφατη έκδοση στο πρότυπο docker-compose και να εκτελέσω ξανά το ansible playbook. Προφανώς, αν η αναβάθμιση απαιτεί περισσότερα, ας είναι, αλλά δεν διαφέρει από οποιαδήποτε άλλη εγκατάσταση

Πιθανώς το μόνο πράγμα που _χρειάζεται_ να κάνω και το κάνω χειροκίνητα είναι να δοκιμάσω τα αντίγραφα ασφαλείας μου. Αλλά έχω ένα σενάριο για κάθε έργο που το κάνει, έτσι απλά ενεργοποιώ το SSH, τρέχω το one-liner, ελέγχω το αποτέλεσμα και είναι έτοιμο. Αυτό το κάνω περίπου μία φορά το μήνα περίπου, αλλά λαμβάνω επίσης email αν αποτύχει ένα αντίγραφο ασφαλείας
Άρα δεν μπορεί να είναι καθόλου χρόνος. Συνήθως είναι πιθανώς 1-2 ώρες το μήνα αν κάνω ενημερώσεις σε ημι-τακτική βάση. Αλλά αυτό θα κλιμακωθεί με τα περισσότερα πράγματα που φιλοξενείτε και διαχειρίζεστε

Με άλλα λόγια, η μόνη διαφορά είναι από πού προέρχεται το αρχείο αποθέματος ansible. Είτε είναι μια στατική λίστα IP, είτε προέρχεται από το terraform

Εάν θέλετε ECC RAM, αυτό φαίνεται να είναι 60/μήνα, και ανεβάζει επίσης μια πιο ισχυρή CPU 8 πυρήνων

Ανεξάρτητα, αν μιλάμε για ένα "περιβάλλον πλήρους παραγωγής και ένα διπλό περιβάλλον εγκατάστασης/αναμονής"(για να αναφέρω το άτομο στο οποίο απαντήσατε), τότε το 60/μήνα * (2 ή 3) εξακολουθεί να είναι φθηνό σε σύγκριση με το AWS κάθε startup λογαριασμός που έχω δει

Οι περιπτώσεις χρήσης ποικίλλουν, αλλά τείνω να συμφωνώ ότι το AWS/GCP/Azure δεν είναι η απάντηση σε κάθε πρόβλημα

Για κάποιον που μπορεί να προσαρμόσει την εφαρμογή του σε ένα VPS $4, αυτό θα είναι προφανώς φθηνότερο από οτιδήποτε γυμνό μέταλλο, αλλά το cloud κλιμακώνεται πολύ ακριβά σε πολλές περιπτώσεις. Το γυμνό μέταλλο δεν είναι επίσης η απάντηση σε κάθε πρόβλημα, αλλά πολλοί άνθρωποι στη βιομηχανία δεν φαίνεται να εκτιμούν πότε μπορεί να είναι η σωστή απάντηση.