Les offres virtualisées fonctionnent bien moins bien (voir mes expériences de 2019 : httpsjan.rychter.com/enblog/cloud-server-cpu-performance et coûtent plus cher. La différence est que vous pouvez « évoluer à la demande », ce que je n'ai pas trouvé nécessaire, du moins dans mon cas. Et si j'ai besoin d'évoluer, je peux toujours le faire, c'est juste que l'obtention de nouveaux serveurs prend des heures au lieu de quelques secondes. Eh bien, je n'ai pas besoin d'évoluer en quelques secondes
Dans mon cas, la totalité de ma facture mensuelle pour l'environnement de production complet et un environnement de préparation/de secours en double est constante, simple, prévisible, très faible par rapport à ce que j'aurais besoin de payer à AWS, et j'ai encore beaucoup de marge de performance pour
Une chose à noter est que je traite les serveurs physiques comme des serveurs virtuels : tout est géré via ansible et je peux tout recréer à partir de zéro. En fait, j'utilise un autre environnement "devcloud"chez Digital Ocean, et celui-ci est lancé à l'aide de terraform, avant d'être transmis à ansible qui fait le reste de la configuration
Je soupçonne que VendorOps et des outils complexes comme kubernetes sont favorisés par les marchands de complexité qui sont apparus au cours de la dernière décennie. Il a fière allure sur le CV et donne aux dirigeants de la technologie un faux sentiment d'accomplissement
Pendant ce temps, Stackoverflow, qui est sans doute plus important que la plupart des startups, avance sur des machines dédiées
1 : httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..
Il semble que la tendance dans cet espace soit de sauter directement à la plus haute couche d'abstraction. Ignorer les fondamentaux et pointer vers les outils, bibliothèques et produits $buzzword
Vous en voyez des aperçus sous différentes formes. L'un est des fils de discussion sur les réseaux sociaux qui demandent des choses comme Combien de X dois-je connaître pour apprendre Y Où X est une technologie ou un domaine fondamental, peut-être très stable et Y est un outil du jour ou directement un produit ou un service
CORBA y appartient. Et peut-être même les trucs du web sémantique. Certainement XML !
XML est génial - si vous n'y croyez pas, alors vous pourriez être intéressé par la difficulté d'analyser JSON : httpseriot.ch/projects/parsing_json.html
Et ne me lancez pas sur YAML..
Le coût supplémentaire d'être sur un cloud en vaut vraiment la peine pour moi d'avoir des bases de données gérées, des instantanés automatiques, des équilibreurs de charge hébergés, un stockage de blocs plug and play, etc.
Je veux m'inquiéter de savoir si notre produit est bon, pas de pannes matérielles au milieu de la nuit, de faire tourner un nouveau serveur et de ne pas le faire fonctionner correctement car il n'y avait aucune incitation à utiliser la gestion de la configuration avec un seul boîtier, ayant une seule tâche d'emballement provoquer un OOM ou un disque plein et casser tout au lieu de se contenter de ces tâches VM, peur de redémarrer une machine qui a fonctionné 1000 jours, etc.
Pour moi, l'attrait du cloud n'est pas une mode d'évolutivité FAANG quand ce n'est pas nécessaire, mais le correctif automatique du système d'exploitation, l'équilibrage de charge automatique, les services NAT, les journaux centralisés et analysables, les services de base de données que je n'ai pas à gérer, hors du box roulant les mises à niveau des services, la gestion des clés de chiffrement et des secrets, et bien sûr, le stockage d'objets. (Ce sont toutes les choses que nous utilisons dans notre startup)
J'irais sur une branche et dirais que les serveurs dédiés peuvent être très viables/rentables lorsque nous atteignons une certaine échelle, au lieu de l'inverse. Pour le moment, les dépenses cloud en valent la peine pour ma startup
Si vous configurez votre environnement en tant que code, cela ne devrait finalement pas avoir d'importance si votre cible est un serveur dédié, une machine virtuelle ou une configuration spécifique au cloud configurée via une api
Peu importe lequel, le fait est que vous en avez un qui peut vous construire une nouvelle boîte ou ramener une boîte qui se comporte mal à un état connu en exécutant simplement une commande
Bien sûr, la pile réelle de Go (o) qui l'anime peut être améliorée (et elle s'améliore effectivement)
Cela dit, la dure vérité est que votre approche est la bonne, presque toutes les entreprises (startups !) surconstruisent au lieu de se concentrer sur la création de valeur, l'identification de la niche réelle, etc. (Oui, il y a aussi le côté demande, car le Les startups gonflées par l'argent VC surconstruisent qu'elles veulent dépendre de tiers qui peuvent prendre la charge, évoluer avec eux, les SLA et ainsi de suite doivent être annoncés.)
Kubernetes est fantastique ! Chaque fois que je vois une entreprise potentiellement concurrente commencer à utiliser Kubernetes, je suis immédiatement soulagé, car je sais que je n'ai plus à m'en soucier. Ils sont sur le point de disparaître dans une pile de problèmes techniques insolubles, essayant de résoudre des problèmes introuvables dans une pile technologique d'une complexité incroyable et contournant les limites imposées par un système conçu pour les entreprises dont le trafic est deux à trois fois plus important. De plus, leur COGS sera bien plus élevé que le mien, ce qui signifie qu'ils devront fixer un prix plus élevé pour leur produit, à moins qu'ils ne fassent que brûler de l'argent VC (auquel cas ils sont un flash dans la casserole)
De bonnes choses tout autour
Ansible est impératif, il peut fonctionner vers un état statique, et c'est tout. S'il rencontre un problème, il lève sa connexion SSH, crie des tonnes d'erreurs python et abandonne pour toujours. Même avec son inventaire c'est loin d'être déclaratif
k8s est une des boucles de contrôle qui tentent de progresser vers leur état déclaré. L'échec n'est pas un problème, il va réessayer. Il vérifiera constamment son propre état, il a une belle API pour le signaler, et grâce à de nombreux concepts réifiés, il est plus difficile d'avoir des conflits étranges entre les composants déployés. (Alors que l'intégration de plusieurs playbooks avec Ansible n'est pas triviale.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
Et même si k8s met trop d'héritage, il y a des manifestations à venir plus minces des idées de base. (Par exemple, httpsgithub.com/aurae-runtime/aurae )
Et maintenant, vous suggérez que les gens utilisent une implémentation non standard plus simple ?
Alors bien sûr, vous pouvez implémenter une solution de complexité minimale ou vous pouvez utiliser quelque chose "sur étagère"k8s est complexe et certains d'entre eux sont définitivement inutiles pour votre situation, mais c'est aussi plutôt général, flexible, bien pris en charge, etc.
>vous suggérez que les gens utilisent une implémentation non standard plus simple ?
Ce que j'ai suggéré, c'est que si k8s le projet/logiciel devient trop gros pour échouer, alors les gens peuvent passer à une alternative. Heureusement, les concepts et l'API de k8s sont open source, ils peuvent donc être implémentés dans d'autres projets, et j'ai donné un tel exemple pour illustrer que choisir k8s n'est pas un verrouillage du fournisseur de type Oracle
J'entends toujours parler de toutes les bonnes choses que vous obtenez pratiquement gratuitement des fournisseurs de cloud. Est-ce vraiment si facile à configurer et à utiliser ? Chaque fois que j'ai essayé de configurer ma pile LAMP sur un service cloud, c'était un processus tellement déroutant et effrayant que j'ai fini par abandonner. Je me demande si j'ai juste besoin de pousser un peu plus fort et j'arriverai à Cloud Heaven
Être capable de dire "Je veux un MySQL en cluster ici avec ce genre de spécifications"est bien mieux (en termes de temps) que de le faire par vous-même. Les mises à jour sont également bien intégrées dans le système, donc je dis simplement "appliquer la dernière mise à jour"plutôt que de s'assurer manuellement que les basculements/redémarrages se produisent dans le bon ordre
Vous payez donc pour simplifier les choses, mais le gain de cette simplification n'intervient qu'avec des projets plus importants. Si vous avez quelque chose sur un seul serveur que vous pouvez redémarrer pendant que vos utilisateurs reçoivent une page d'erreur, cela n'en vaut peut-être pas la peine
Le cloud n'est pas facile, mais essayer d'obtenir le refroidissement et l'efficacité énergétique d'une petite salle de serveurs n'importe où près des niveaux d'efficacité que la plupart des grands centres de données publient est presque impossible, tout comme la connectivité Internet multi-fournisseurs
Avec le cloud, tout cela disparaît car il est géré par l'opérateur de centre de données sur lequel le cloud s'exécute, mais ce que les gens oublient, c'est que cela est également vrai pour les services de colocation à l'ancienne qui offrent souvent un meilleur rapport coût/valeur que le cloud.
Et bien qu'il soit définitivement plus difficile de gérer des choses comme AWS ou Azure parce qu'il saigne beaucoup d'abstractions que les petits fournisseurs de vpc scall vous cachent ou que vous n'obtenez pas vraiment avec un seul serveur domestique, ce n'est pas difficile à l'échelle d'avoir à exécuter un couple de racks de serveurs vmware avec stockage basé sur SANAvec le Cloud, vous avez plus de configuration à faire car il s'agit de configurer des serveurs virtuels, etc.Au lieu de transporter le PC dans un box à votre pièce, vous devez "la configurer"pour la rendre disponibleLes bases de données DO ont des sauvegardes que vous pouvez configurer à votre guise, stockez-les sur DO Spaces (comme S3).La gestion des utilisateurs de la base de données est simple.Il y a aussi des serveurs de cache pour RedisVous pouvez ajouter un load balancer et le connecter à vos différents serveurs webJe pense que ça m'a pris environ 30 minutes pour configurer 2 serveurs Web, un serveur de base de données, un serveur de cache, un équilibreur de charge, un serveur de stockage et les connecter tous au besoin à l'aide de quelques formulaires simples.Je ne peux pas vraiment battre çaSi vous avez plus d'informations ou d'opinions, n'hésitez pas à partagerDe nombreux articles sur Internet à propos de durcir un serveur Linux, ceux que j'ai essayés prennent un peu plus de 30 minutes pour suivre les étapes, beaucoup plus longtemps si j'essaie d'apprendre et de comprendre ce que fait chaque chose, pourquoi c'est important, quelle est la vulnérabilité sous-jacente est, et comment je pourrais avoir besoin de personnaliser certains paramètres pour mon cas d'utilisation particulierJe suis sûr que vous pouvez trouver des exemples de scripts de configuration en ligne (configurer les mises à jour automatiques, le pare-feu, les applications, etc. devrait être une question d'exécuter 'curl $URL'puis 'chmod +x $FILE'et 'bash $FILE'.Je n'ai pas eu besoin de la gestion de la configuration (j'utilise le service de sauvegarde de mon fournisseur, ce qui est important je suppose)Quelque chose comme ceci : httpsraw.githubusercontent.com/potts99/Linux-Post-Install..(vu sur httpswww.reddit.com/r/selfhosted /commentaires/f18xi2/ubuntu_d )Évidemment, la même chose peut être dite pour les machines virtuelles de longue durée, et cela peut être résolu en ayant une équipe disciplinée, mais je pense que c'est généralement plus probable dans un environnement avec une seule longue exécution dédiée machineHetzner a tout cela sauf les bases de données géréeshttpswww.hetzner.com/managed-serverLes packages d'hébergement Web incluent également 1. .bases de données illimitées (MySQL et PostgreSQL)httpswww.hetzner.com/webhosting/dispose-t-il d'une sauvegarde automatique et d'un basculement ?>Avec la sauvegarde journalière réservée ou la sauvegarde incluse dans le type de serveur, toutes les données sont sauvegardées quotidiennement et conservées pendant 14 jours maximum.La récupération des sauvegardes (restauration) est possible via l'interface d'administration konsoleHMais j'ai l'impression que les bases de données sur les serveurs gérés sont destinées à être utilisées par des applications exécutées sur ce serveur, il n'y a donc pas vraiment de concept de basculementhttpswww.hetzner.com/legal/managed-server/Un seul disque sur un seul serveur défaillant ne devrait jamais provoquer une production outageDe nombreux problèmes de configuration peuvent être attribués à des déploiements autonomes.Ce fichier de police ou JRE doit-il vraiment être installé sur l'ensemble du serveur ou pouvez-vous le regrouper dans votre déploiementNos déploiements utilisent des cibles sur site et EC2.Le script de déploiement n'est pas différent, seule l'adresse IP de l'hôte estMaintenant, je vais dire si je peux utiliser S3 pour quelque chose que je ferai à 100 %.Il n'y a pas d'alternative sur site avec le même ensemble de fonctionnalitésLe but de DevOps est "le bétail, pas les animaux de compagnie". Mettez une balle dans votre serveur une fois par semaine pour trouver vos points d'échecJ'aimerais que vous sautiez dans notre Discord/Slack et souleviez certains des problèmes que vous voyiez afin que nous puissions à améliorez au moins l'expérience des autres utilisateurs de Dokku.N'hésitez pas à me contacter (mon surnom est `savant`)Permettez-moi de préfacer et de dire que je suis un développeur d'applications avec seulement une connaissance pratique de Docker.Je ne suis pas super doué pour l'infra et l'application avec laquelle j'ai lutté a des paramètres de déploiement particuliers : c'est une application Python qui, au moment de la construction, analyse plusieurs gigs d'analyses HTML statiques pour remplir une base de données Postgres qui est statique après avoir été construite.Une application Web Flask sert ensuite cette base de données.L'analyse HTML évolue rapidement et les données de base de données remplies doivent donc être regroupées dans le cadre de l'image ou des images de l'applicationIIRC, j'ai eu du mal à structurer Dockerfiles lorsque la base de données n'était pas persistante mais simplement une autre partie transitoire de l'application, mais cela semblait surmontable.Le plus gros problème semblait être de savoir comment éviter d'extraire des concerts de données rarement modifiées de S3 pour chaque version alors qu'idéalement elles seraient mises en cache, en particulier d'une manière qui se comporte de manière saine dans DigitalOcean et dans mon environnement local.Je suppose que la bonne mise en cache de la couche d'image Docker résoudrait le problème, mais j'ai assez rapidement atteint la fin de mes connaissances et de ma patienceLe DX de Dokku semble idéal pour les personnes faisant des choses normales.:)0. httpscoolify.io/De plus, qui ne veut pas jouer avec le jouet le plus récent et le plus cool aux frais d'un autre ?Il y a certainement un argument pour déplacer (certaines) choses hors du cloud plus tard dans le voyage lorsque la flexibilité (ou la gestion des flux/pivots) devient moins un moteur principal et que l'échelle/le coût commencent à dominerBien sûr, vous pouvez faire fonctionner quelque chose sur Hetzner mais soyez prêt à répondre à beaucoup plus de questionsD'accord sur votre dernier point d'entreprise demandant ce qui est encore une fois triste que ces "exigences"commerciales dictent comment concevoir et héberger votre logiciel alors qu'une autre manière pourrait être la bien meilleureLa reprise après sinistre est un problème très réel.C'est pourquoi je le teste régulièrement.Dans un scénario de terre brûlée, je peux être opérationnel sur un système secondaire (de mise en scène) ou sur un système de cloud terraformé en moins d'une heure.Pour mon entreprise, cela suffit
Nous avons traversé un boom de croissance et, comme tous les précédents, cela signifiait que de nombreuses personnes inexpérimentées recevaient beaucoup d'argent et des attentes urgentes. C'est une recette pour le culte du fret et le marketing d'exploitation
Mais la croissance ralentit et l'argent devient plus cher, alors ralentissez et commencez à réapprendre les anciennes leçons avec de nouvelles variations passionnantes. (Comme ici : gestion de la mise à l'échelle sans système d'exploitation et avec les conteneurs et l'orchestration)
Et tout le cycle se répétera au prochain boom. C'est notre industrie pour l'instant
Un serveur dédié solide est 99% du temps beaucoup plus utile qu'un VPS paralysé sur du matériel partagé, mais cela a évidemment un coût accru si vous n'avez pas besoin de toutes les ressources qu'ils fournissent
Oui - mais le désir de "faire ce que tous les enfants cool font maintenant"est au moins aussi fort chez ceux qui seraient normalement appelés "managers"que chez les "employés"résultat A) d'énormes dépenses en microservices / cloud tournent mal, eh bien au moins vous suiviez les meilleures pratiques, ces choses arrivent, que pouvez-vous faire
résultat B) vous êtes allé avec un serveur Hetzner et quelque chose s'est mal passé, eh bien vous êtes et auriez dû opter pour des microservices, profitez de la recherche d'un nouvel emploi
Encourageant ainsi les managers à choisir les microservices/cloud. Ce n'est peut-être pas la bonne décision pour l'entreprise, mais c'est la bonne décision pour le manager, et c'est le manager qui prend la décision
(Tout comme le fait d'être consultant à la recherche d'une extension et d'un logiciel d'écriture qui fonctionne, comme je l'ai découvert à mes dépens.)
Il y a une déconnexion entre les fondateurs et tout le monde
Les fondateurs pensent qu'ils vont >10x chaque année
La réalité est qu'ils ont 90 % de chances d'échouer
90% du temps - vous êtes bien d'échouer sur n'importe quoi
Quelques % des 10 % du temps où vous réussissez, vous vous débrouillez toujours sans le cloud - au moins pendant plusieurs années de succès, beaucoup de temps pour changer si nécessaire
Je n'ai qu'une seule configuration ansible, et cela peut fonctionner à la fois pour les serveurs virtualisés et physiques. Aucune différence. La seule différence est que les serveurs virtualisés doivent d'abord être configurés avec terraform, et les serveurs physiques doivent d'abord être commandés et leurs adresses IP entrées dans un fichier de configuration (inventaire)
Bien sûr, je veille également à ne pas devenir dépendant de nombreux autres services cloud. Par exemple, j'utilise VpnCloud (httpsgithub.com/dswd/vpncloud) pour la communication entre les serveurs. En tant qu'avantage secondaire, cela me donne également la possibilité de passer à tout moment à n'importe quel fournisseur d'infrastructure
Mon point principal était que même si les offres virtualisées ont leur utilité, il existe un (énorme) écart entre un VPS de loisir à 10 $/mois et une entreprise dont les activités B2C explosent. La plupart des nouvelles entreprises se situent en fait dans cet écart : vous ne vous attendez pas à une croissance exponentielle en bâton de hockey dans un SaaS B2B rentable. C'est là que vous devriez remettre en question le choix par défaut habituel de "utiliser AWS". Je me soucie de mon COGS et de mes marges, donc je regarde ce choix très attentivement
Vous n'êtes pas une entreprise de logiciels, fondamentalement, vous fabriquez et vendez des pignons
Les opinions ici seraient d'embaucher un grand personnel d'ingénierie / informatique pour "acheter et entretenir des serveurs"(PaaS est mauvais) et ensuite probablement "écrire un code vous-même"(SaaS est mauvais) ou tout ce qui est actuellement populaire ici (dernier fil ici c'était "Poussez PHP sur SFTP sans Git, et vous êtes si vous avez besoin de plus"lol)
Mais je crois que les entreprises devraient bien faire une chose et éviter d'essayer de rivaliser (en le faisant manuellement) pour des choses en dehors de leur compétence principale. Dans ce cas, je pense certainement que Sprocket Masters ne devrait pas tenter de gérer son propre matériel et devrait s'appuyer sur un fournisseur pour gérer la mise à l'échelle, la sécurité, la disponibilité, la conformité et tous les petits détails. Je pense aussi que leur logiciel devrait être standard avec le moins possible en interne. Ils ne sont pas un magasin de logiciels et devraient écrire le moins de code possible
De manière réaliste, Widget Masters pourrait gérer ces sites avec un personnel plutôt restreint, à moins qu'ils ne décident de tout faire manuellement, auquel cas ils auraient probablement besoin d'un personnel beaucoup plus important.
Cependant, ce que je vois aussi et ce dont je pense que l'affiche précédente parlait, ce sont des entreprises où la technologie est au cœur de l'entreprise, et là, cela a souvent moins de sens, et au lieu de gagner du temps, cela semble coûter du temps. Il y a une raison pour laquelle il y a des experts AWS : ce n'est pas anodin. Les "vrais"serveurs ne sont pas non plus triviaux, mais pas nécessairement plus difficiles que les services cloud
Mais ces agences ne veulent pas non plus avoir à faire appel à du personnel pour entretenir le matériel physique.
Mais Sprocket Masters doit toujours avoir un consultant cloud coûteux simplement pour répondre aux urgences
Si vous allez avoir quelqu'un dans le personnel pour gérer les problèmes de cloud, vous pouvez aussi bien louer un serveur à la place
J'ai personnellement géré des serveurs dédiés pour notre entreprise dans les premiers jours, mais à mesure que nous nous développions et évoluions, il est devenu beaucoup plus facile d'aller avec les fournisseurs de cloud pour fournir rapidement divers services même si les coûts ont augmenté. Sans oublier qu'il est beaucoup plus facile de dire à un client potentiel que vous utilisez "un cloud comme AWS"que "Oh, nous louons ces machines dans un centre de données géré par une entreprise"(ce qui peut en fait être mieux mais les clients n'obtiendront généralement pas cela) . Audit, Conformité et autres
Pour beaucoup, même beaucoup moins que cela. J'exécute un petit projet parallèle [1] qui est devenu viral à quelques reprises (30 000 vues en 24 heures environ) et il s'exécute sur un serveur Web à processeur unique et un Postgres géré également sur un seul cœur de processeur. Il n'a même pas été proche de la pleine utilisation
1 : httpsaihelperbot.com/ Pourrais-je en basculer certaines vers des fonctions lambda ? Ou passer à ECS ? Ou passer à un autre service cloud du jour ? Peut être. Mais le temps que j'ai passé à écrire ce commentaire représente déjà environ six mois d'économies pour un tel changement. Si c'est plus difficile que "appuyez sur un bouton, recevez un service traduit à 100% de manière fiable", c'est difficile à justifier Cela s'explique en partie par le fait que le cloud fournit désormais d'autres services qui permettent ce genre de choses. Je n'ai pas besoin d'exécuter un cluster Kafka pour la messagerie de base, ils sont tous livrés avec un bus de messages. J'utilise ça. J'utilise les options de base de données hébergées. J'utilise S3 ou équivalent, etc. Je trouve que ce qui reste ne vaut presque pas la peine d'essayer de me coincer dans un autre paradigme lorsque je paie des dollars à un chiffre par mois pour simplement fonctionner sur une instance EC2 Il est absolument vrai que tout le monde ou tous les projets ne peuvent pas le faire. Je ne suis pas collé à cela comme objectif final. Lorsque cela ne fonctionne pas, je prends immédiatement les mesures de mise à l'échelle appropriées. Je ne suggère pas que vous réorganisiez quoi que ce soit sur cette base. Je dis juste que ce n'est pas une option à mépriser. Il a beaucoup de flexibilité et la facturation est assez cohérente (ou, pour le dire autrement, le fait que si j'ai soudainement 50 fois plus de trafic, mon système commence à s'étouffer et à crachoter plutôt que de simplement me facturer des centaines de dollars plus est une fonctionnalité pour moi plutôt qu'un bogue), et vous ne vous étirez généralement pas pour vous contorsionner dans un paradigme qui convient à certains services cloud mais peut ne pas vous convenir Avez-vous déjà eu à gérer un de ces environnements ? Le fait est que si vous souhaitez obtenir une évolutivité de base pour plus d'une personne et des développements appropriés, vous devez surprovisionner d'un facteur important (ce qui peut annuler vos économies) Vous allez inévitablement vous retrouver avec une solution sur mesure, ce qui signifie que les nouveaux entrants auront plus de mal à maîtriser le système et que les personnes importantes qui quittent l'entreprise apporteront avec elles leur connaissance intime de votre infrastructure. Vous êtes de retour aux animaux de compagnie au lieu des bovins. Certains serveurs sont spéciaux, après un certain temps, l'automatisation signifie "beaucoup de scripts de shell de colle ici et là"et une mise à niveau du système d'exploitation signifie que la moitié de l'infra est KO pendant un certain temps ou que vous ne faites pas du tout de mises à niveau du système d'exploitation Et dans le cas fortuné, vous devez passer à l'échelle Vous pourriez avoir des surprises désagréables Et ne me lancez jamais du côté du réseautage. À moins que vous ne louiez tout votre rack et que vous ne placiez votre propre matériel réseau, vous obtenez ce que vous obtenez. Ce qui pourrait être très pauvre en fonctionnalités ou en performances En supposant que vous ne fassiez rien d'extraordinaire Si vous voulez une disponibilité de 100,0000 %, bien sûr. Mais vous ne le faites pas habituellement. Les entreprises qui souhaitent ce type de disponibilité ont normalement des équipes qui s'y consacrent de toute façon Et la mise à l'échelle fonctionne également bien sur le métal nu si vous évoluez verticalement - avez-vous une idée de la quantité de puissance et du débit que vous pouvez obtenir à partir d'un seul serveur ? Il est préoccupant de continuer à entendre parler de "mise à l'échelle"lorsque l'orateur signifie "mise à l'échelle horizontale" Si vos exigences sont "mises à l'échelle", alors la mise à l'échelle verticale vous mènera loin Si vos exigences sont "la mise à l'échelle horizontale à la demande", alors, bien sûr, les fournisseurs de cloud vous aideront. Mais, peu d'endroits ont besoin de ce genre de mise à l'échelle Je ne dis pas qu'une disponibilité à 100 % sur le métal nu est bon marché, je dis qu'une disponibilité à 100 % n'est souvent pas nécessaire Parce que l'industrie est pleine de gens qui chassent les tendances et les mots-clés et pour qui le plus important est d'ajouter ces mots-clés aux CV IME visant l'évolutivité est extrêmement faux pour la plupart des services/applications/peu importe. Et généralement, vous payez tellement de frais généraux pour les solutions "évolutives", que vous devez ensuite évoluer pour compenser cela J'en doute vraiment.Le seul thème que vous voyez sur presque tous les promoteurs d'AWS est une grande quantité d'illusions sur les garanties qu'AWS vous fournit réellementOui, bien sûr.Personne n'est licencié pour avoir acheté chez IBMEh bien, si les grandes entreprises avaient la moindre compétence en matière de prise de décision, elles seraient imbattables et il serait vain de travailler sur quoi que ce soit d'autre chez tous.Donc, ouais, c'est un bien publicSource : près de trente ans d'opérationsJusqu'à présent, je n'ai pas remarqué que si je dépensais plus pour l'entreprise que je reçois également plus payéobtenir la fiabilité équivalente avec des fers est beaucoup plus cher que de louer "deux serveurs dédiés"- maintenant vous pourriez être d'accord avec un serveur et une solution de sauvegarde , et c'est juste. mais un sysad pour créer tout cela, même sur un court contrat pour la configuration initiale et sans maintenance, ira bien au-delà de la différence de prix du cloud, surtout s'il y a une base de données dans le mélange et que vous vous souciez de ces donnéesAujourd'hui, le cloud est similaire - le délai de mise sur le marché est plus rapide car il y a moins de pièces mobiles.Lorsque l'économie s'effondre et que la croissance ralentit, les beancounters entrent et font leur travailCela arrive à chaque foisCela ne fait que rendre AWS plus riche au nom des entreprises et des équipes cloudIl est simple de provisionner et de déprovisionner une instance EC2 automatiquement, en quelques secondes si votre déploiement doit évoluer à la hausse ou à la baisse.C'est ce qui le rend fondamentalement différent d'un serveur bare metal
Maintenant, je ne nie pas qu'il pourrait encore être plus rentable par rapport à AWS de provisionner quelques serveurs dédiés de plus que ce dont vous aurez besoin, mais lorsque vous avez des charges de travail vraiment imprévisibles, il n'est pas facile de suivre
si vous lancez et arrêtez des machines virtuelles pour répondre à la courbe de la demande - quelque chose ne va vraiment pas avec votre architecture
Vous est-il déjà venu à l'esprit, comment se fait-il que stackoverflow utilise environ 8 serveurs dédiés pour servir le monde entier et n'a pas besoin de faire tourner et d'arrêter les machines virtuelles pour répondre à la demande mondiale des clients ?
--
Lors de la planification d'une infrastructure de calcul, il est important de revenir à l'essentiel et de ne pas tomber dans la propagande des fournisseurs de cloud
Vous l'avez dit vous-même. Toutes les applications n'ont pas besoin de desservir le monde entier, donc la demande sera plus faible lorsque les gens s'endormiront
Même avec des applications mondiales, il existe des réglementations qui vous obligent à héberger des applications et des données dans des régions spécifiques. Imaginez une application utilisée par des clients en Europe, en Australie et aux États-Unis. Ils doivent être servis à partir de centres de données régionaux, et un cluster dormira principalement lorsque l'autre fonctionnera (en raison des fuseaux horaires). Avec des serveurs dédiés, vous gaspillerez 60 à 70 % de vos ressources, tout en utilisant quelque chose comme EC2/Fargate, vous pouvez réduire à presque 0 lorsque votre région est en veille.
Il y a une méthode à la folie, ici ça s'appelle "développement axé sur la sécurité de l'emploi"Parce que c'est une menace pour leur travail
Il y a tout un groupe de personnes qui ont les capacités techniques pour s'auto-héberger, ou héberger de petites instances pour leur famille/amis/association/club de randonnée. Cette petite marge où vous êtes autorisé à dépenser un peu plus parce que vous voulez que tout soit correct, mais vous ne pouvez pas justifier de payer autant et de passer du temps à faire un entretien difficile. Un petit VPS, avec un Nextcloud partagé ou un petit site web, suffit dans bien des cas
Pour cela j'utilise même un petit Raspberry Pi 400 dans ma chambre
httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..
J'ai moi-même hébergé mes propres trucs pendant près d'une décennie maintenant. Personne n'a essayé DDoSing ma configuration, car pourquoi le feraient-ils ? Quel bénéfice pourraient-ils en retirer ? Je serais à peu près la seule personne affectée, et une fois qu'ils s'arrêteraient, il ne faudrait pas longtemps pour récupérer
Il y a peu ou pas d'incitation à DDoS sur une box personnelle, encore moins par une rando Internet
Vous surestimez considérablement les capacités d'un adolescent
Le simple fait de cingler l'adresse IP encore et encore ne va pas vraiment faire grand-chose. Peut-être une attaque DoS en fonction de ce que le réseau cible a en termes d'IPS, mais même dans ce cas, il est plus probable qu'ils infectent leurs ordinateurs avec des virus avant d'avoir la chance de vous attaquer réellement
J'ai personnellement été victime de l'un d'entre eux pour un tricheur dans GTA 5. Cela arrive définitivement et ce n'est pas amusant
Edit : Il semble que cela soit automatique. C'est quelque chose d'intéressant que je devrais étudier un peu. C'est probablement juste une complexité supplémentaire pour mon petit serveur, mais j'ai quelques utilisations en tête
Techniquement, mon homelab est également sur une adresse IP publique statique - c'était plus un exercice de "pourrais-je faire cela"que "réellement nécessaire", mais c'est toujours cool et je suis très heureux
Le seul problème était que je devais configurer Wireguard pour maintenir le tunnel en vie, sinon parfois le VPS recevait du trafic entrant et si mon laboratoire n'avait pas tendu la main depuis un moment (ce qui, pourquoi le ferait-il ?), le tunnel serait en panne, et la connexion proxy serait. Heureusement, c'est une fonctionnalité intégrée
Donc, il semble que l'ajout de flux RSS / Atom sur un site de pages jekyll ou GitHub soit assez simple
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 Go de RAM, 1 To de lecteur, 100 Mbits
Quelques années de disponibilité à ce stade
Si ininterrompu : une mise à niveau peut être nécessaire.
Les mises à jour de sécurité du noyau sont une chose
J'ai trouvé qu'Atoms était insupportablement lent, même avec Linux. Bien sûr, c'est suffisant pour servir des sites Web et ainsi de suite, mais c'est déconcertant de voir combien d'énergie ils utilisent tout simplement pas performants
Exactement. Ces instances VPS à moins de 10 $ sont idéales pour les petits projets où vous ne souhaitez pas conclure de longs contrats ou vous occuper de la gestion de vos propres serveurs
Si vous dirigez une entreprise réelle où les marges sont très minces et que vous avez tout le temps libre dans le monde pour gérer les problèmes de serveur si (quand) ils surviennent, ces serveurs dédiés d'environ 50 $ pourraient être intéressants à explorer
Mais si vous dirigez une entreprise réelle, même une facture AWS de 10 000 $/mois est moins chère que d'embaucher un autre développeur qualifié pour vous aider à gérer vos serveurs dédiés.
C'est ce qui manque généralement dans les discussions sur les coûts du cloud sur des sites comme HN : oui, le cloud coûte cher, mais embaucher ne serait-ce qu'un seul administrateur système/développeur supplémentaire pour vous aider à gérer une infrastructure personnalisée est incroyablement coûteux et beaucoup moins flexible. C'est pourquoi dépenser 5 000 $/mois pour une solution hébergée dans le cloud qui pourrait, en théorie, être personnalisée sur un serveur à 50 $/mois avec un investissement en temps suffisant peut encore être une bonne affaire. Les ingénieurs coûtent cher et le temps est limité
Euh, excusez-moi, mais combien payez-vous ce gars DevOps ? Cela semble être une perspective très américaine, même dans la vallée. En Europe, embaucher un mec serait moins cher
Les coûts de l'emploi à pleine charge sont nettement plus élevés que ce que vous rapportez chez vous sur votre salaire. C'est même pire en Europe. Jetez un œil à ces graphiques : httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Si vous payez quelqu'un 1000 EUR au Royaume-Uni, cela coûte à l'entreprise un total de 1245 EUR
Si vous payez quelqu'un 1000 EUR en Roumanie, cela coûte à l'entreprise 1747 EUR au total
Ainsi, un coût complet de 120 000 $ ne vous rapportera peut-être qu'un salaire de 68 000 $ US pour une personne devops de l'UE
Mais vous ne pouvez pas avoir qu'une seule personne devops. Vous en avez besoin d'au moins 2 si vous voulez permettre à l'un d'entre eux de faire une pause, de partir en vacances ou de partir en vacances.
Je peux te brancher dans environ 3 heures
AWS est très rentable pour les autres services (S3, SES, SQS, etc.), mais les machines virtuelles ne sont pas une bonne affaire. Vous obtenez moins de RAM& CPU, avec la surcharge de virtualisation, et payer beaucoup plus d'argent
Surtout pour Postgres, si vous exécutez des tests avec pgbench, vous pouvez vraiment voir la pénalité que vous payez pour la virtualisation
Peut-être que la compétence sysadmin de pouvoir construire sa propre infrastructure devient un art perdu, sinon je ne peux pas expliquer pourquoi les gens aiment tant payer 5x pour moins de performances
Hetzner est bon marché et fiable en Europe, si vous êtes en Amérique du Nord, jetez un œil à OVH. Surtout leur alternative économique appelée SoYouStart. Vous pouvez obtenir 4/8 4,5 GHz, 64 RAM et un lecteur NVME pour 65 $
(Je n'ai aucune affiliation avec OVH, je suis juste un client avec presque 100 serveurs, et ça a très bien fonctionné pour moi)
Je noterai également que je suis vieux hehe, et l'un de mes premiers emplois, nous avions un centre de données de taille décente sur place. Traiter avec des SAN, des lecteurs de bande (les rotateurs de bande automatiques à l'époque étaient des serveurs, etc. était un énorme PITA. Emballer des bandes et les expédier à un autre bureau pour la redondance des emplacements était toujours amusant
L'application particulière que je gère souffre vraiment d'un faible GHz et n'a pas toutes les données en mémoire. J'ai exécuté les benchmarks sur EC2, certains rapports qui se terminent en ~5 secondes peuvent prendre plus d'une minute sur une instance EC2 comparable qui coûte environ 10 fois plus. Cette application a vraiment besoin du processeur brut. et oui, nous avons une assez grande équipe d'ingénieurs qui a optimisé toutes les requêtes, indices, etc.
En ce qui concerne la réplication, les sauvegardes, etc., j'ai configuré tout cela, et honnêtement, ce n'était pas grave. Il s'agit de quelques courts chapitres dans le livre Postgres qui expliquent tout très simplement, comment configurer, tester en continu (et automatiquement), etc.
Je suis d'accord que les SAN sont un cauchemar. C'est pourquoi j'expédie tous mes WAL (fichiers de sauvegarde PG) vers S3 (et éventuellement Glacier). De cette façon, je n'ai pas à penser à perdre ces fichiers et c'est très bon marché
Je pense qu'il y a une idée fausse selon laquelle ces types de configurations sont trop compliqués à configurer pour un seul ingénieur, avec une maintenance sans fin requise. En réalité, vous pouvez tout configurer en moins d'une semaine et il ne nécessite vraiment de maintenance que lorsque vous souhaitez mettre à niveau Postgres (certains paramètres peuvent avoir changé). J'estimerais qu'il faut environ 5 heures par an d'entretien
L'infrastructure libre-service semble susceptible de devenir de plus en plus viable à mesure que nous continuons d'améliorer la livraison du dernier kilomètre et d'étendre l'accès à la fibre. Le cloud va-t-il devenir auto-cannibalisant ? Définitivement peut-être
Ce que le cloud vous offre, c'est la possibilité de placer vos données/charge de travail au cœur sans avoir à conclure d'accords spéciaux avec votre FAI local, et avec beaucoup plus de résilience que vous ne le feriez probablement à moins que vous n'ayez au moins le conteneur multiple de 20 pieds plein des serveurs échelle des besoins de calcul
https://www.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..
Edit : Si quelqu'un est intéressé par l'auto-hébergement, c'est simple avec cloudflared. J'ai un Google Pixelbook 2017 exécutant Ubuntu sur un micrologiciel personnalisé qui dessert un site Web basé sur Flask. Je charge sur mon bureau tout en étant connecté à un réseau wifi invité. Il reçoit un score Mobile PageSpeed de 100/100 et prend 0,8 seconde pour se charger complètement
De DO, je reçois tous les avantages d'une entreprise fiable, l'évolutivité, les sauvegardes automatisées, etc. Il n'y a aucun moyen que je change
Le cloud Hetzner a maintenant deux emplacements aux États-Unis. Toujours pas de serveurs dédiés aux États-Unis - ceux-ci donneraient un coup de pied réel. Même si leurs offres cloud actuelles elles-mêmes représentent déjà environ 30 % du prix des principaux équivalents cloud.
Comme vous, j'exécute également mes services à partir d'un serveur physique loué. J'utilisais Versaweb, mais leurs machines sont trop vieilles. Je n'aimais pas Hetzner auparavant parce que j'avais entendu de mauvaises choses à leur sujet interférant avec ce que vous exécutez
Cependant, je suis passé chez eux en décembre lorsque mon instance Versaweb vient de mourir, probablement un SSD de vieillesse. Je paie maintenant 50 % de ce que j'ai payé Versaweb, et je peux exécuter 6 instances Postgres de ce type
Ensuite, on se demande s'il vaut la peine de payer 700 $ ou 800 $ pour un service géré avec une interface utilisateur cloud sophistiquée, des mises à niveau et des sauvegardes automatiques, etc.
Pour un show 1 personne ou une petite startup, je pense que non. Moins cher d'utiliser un service disponible et de vider les sauvegardes sur S3 ou quelque chose de moins cher
L'entreprise pour laquelle je travaillais travaillait pour l'entreprise A, bien rémunérée, quatre fois plus que l'entreprise B facturait exactement le même service, simplement parce que l'entreprise A était disposée à envoyer des factures trimestrielles d'une manière qui convenait parfaitement à notre système de facturation. Pour les entreprises, économiser quelques centaines de dollars ici et là ne vaut souvent pas la peine d'introduire des frictions supplémentaires
Il y a là un coût implicite. S'il ne s'agit que d'une ou deux de ces choses, prenez simplement les services gérés
Si vous commencez à évoluer, obtenez un employé de type administrateur pour économiser sur ce
Sinon, je devrais embaucher / contracter quelqu'un de très expérimenté, ou consacrer un mois solide ou plus de mon temps (qui n'était pas disponible), juste pour être sûr à 100% que nous pourrions toujours restaurer rapidement les sauvegardes PITR journalisées
Je peux économiser de l'ampleur sur les coûts du cloud ailleurs, mais PostgreSQL géré crédible était un appel assez facile (même si le prix d'entrée de gamme était supérieur à ce à quoi vous vous attendiez)
Une start-up précoce qui ne peut pas se permettre de perdre une heure de données de production est probablement trop fragile pour survivre de toute façon
C'est un démarrage précoce - il y aura des interruptions plus importantes que cela du service et tous les clients qui fuient après une heure de perte de données de production n'apprécient tout simplement pas assez le produit de toute façon
(Dans le démarrage spécifique auquel je pensais, j'avais déjà de jolis vidages DB-online fréquents et automatisés vers S3 avec rétention appliquée, mais je ne pensais pas que c'était assez bon pour ce scénario particulier. Mais n'étant pas sûr que nous pourrions récupérer avec PITR/journalisation ajouterait un nouveau pari unique sur le succès d'une entreprise qui, autrement, pourrait avoir une sortie à plus de 9 chiffres dans quelques/plusieurs années, juste pour en économiser quelques centaines.)
De plus, je suppose que certaines des premières startups qui ont des besoins moins exigeants, mais qui sont cavalières quant à leurs obligations envers les données des clients/utilisateurs, font toujours preuve de négligence vis-à-vis des pratiques de base minimales
Peut-être une façon intuitive d'apprécier : Imaginez un article d'actualité sur HN, sur certaines opérations de démarrage qui lâchent la balle, avec les noms des fondateurs de démarrage attachés, et l'histoire dit et il s'avère qu'ils n'avaient pas de bonnes sauvegardes Puis l'un des cofondateurs, qui n'ont peut-être pas beaucoup dormi pendant que leur entreprise s'effondre autour d'eux, répondent "Les données des clients ne sont pas si importantes dans un démarrage précoce ; si c'était le cas, nous serions trop fragiles"(tapé avant que le cofondateur ne puisse jeter l'ordinateur portable de cette personne à travers la pièce pour les empêcher de taper). Ce ne serait pas beau
J'aborderai cela à la fin
>Imaginez une histoire d'actualité sur HN, sur certaines opérations de démarrage laissant tomber la balle, avec les noms des fondateurs de démarrage attachés, et l'histoire dit et il s'avère qu'ils n'avaient pas de bonnes sauvegardes
ITYM et il s'avère qu'ils n'ont pas sauvegardé la dernière heure
Je peux tout imaginer dans votre scénario, même les bits non coupés, et tout semble normal, à moins que vous ne lisiez "Nos clients startups, qui nous utilisent depuis un mois, sont tous partis immédiatement lorsque nous avons perdu la dernière heure de leurs données"Je ne peux vraiment pas imaginer ce scénario
Maintenant, d'accord, il y a certaines entreprises où l'avantage de l'utiliser est qu'il n'y a même pas une heure de données perdues
IOW, les clients l'utilisent car il ne perdra aucune donnée : la collaboration documentaire en ligne[1], par exemple[2]. Si vous avez un effondrement qui perd une heure des dernières données saisies, alors bien sûr, attendez-vous à ce que tous les utilisateurs actuels concernés fuient immédiatement
[1] Bien que, personnellement, j'atténuerais le risque en dupliquant le document actuel dans le stockage local pendant qu'il est en cours d'édition
[2] Peut-être que la bourse a également besoin du système pour conserver la dernière heure de données ? Quoi d'autre?
Je pense que même pour les grandes équipes, il peut être judicieux de gérer vous-même les bases de données, en supposant que vous ayez les compétences pour bien le faire. Il y a tellement de choses qui peuvent mal tourner avec les services gérés et ils ne cachent pas l'implémentation sous-jacente comme le font des choses comme le stockage de blocs ou le stockage d'objets
Les performances de pointe sont certainement pires - mais je ne suis pas trop dérangé si quelque chose prend plus de temps à fonctionner de toute façon. Vous avez certainement raison d'avoir autant d'automatisation dans le provisionnement d'un serveur, ce que je n'ai pas fait avec un serveur physique
J'avais l'habitude d'avoir un serveur racine pour mes projets favoris, mais honnêtement, cela n'a aucun sens. Je n'exécute pas un trafic élevé, calcule un SaaS intense sur mes machines. C'est juste un site Web statique et quelques projets. Je suis descendu à des charges mensuelles de 24 qui comprend un boitier de stockage de 1 To pour stocker toutes mes données
Le principal problème dans tout scénario impliquant du matériel réel est que vous avez besoin de personnel compétent à la fois dans le matériel et les systèmes Linux/UNIX. Beaucoup prétendent être sur leur CV et ne peuvent ensuite pas effectuer une fois sur le tas (d'après mon expérience en tout cas). À mon avis, l'une des raisons majeures de l'explosion du monde du cloud était précisément la difficulté à constituer et le coût financier de la constitution de telles équipes. De plus, il existe une friction quelque peu naturelle (et nécessaire) entre les développeurs d'applications et les systèmes. Les responsables des systèmes devraient toujours repousser et plaider pour plus de sécurité, plus de processus et moins de déploiements. L'équipe de développement doit toujours plaider pour plus de flexibilité, plus de versions et moins de processus. Une bonne gestion devrait alors trouver le juste milieu entre les deux. Malheureusement, les gestionnaires incompétents ont souvent simplement décidé de se débarrasser des personnes chargées des systèmes et de déplacer les choses vers AWS.
Enfin, je voudrais juste noter que l'architecture cloud est mauvaise pour la planète car elle nécessite un sur-approvisionnement par les fournisseurs de cloud, et elle nécessite globalement plus de puissance informatique en raison des nombreuses couches d'abstraction. Alors que n'importe quel projet est responsable d'une petite partie de ce gaspillage, l'ensemble du cloud mondial en tant qu'agrégat est très coûteux. Cela me dérange et est évidemment probablement un biais émotionnel dans mes opinions (si de grandes quantités de sel pour tout ce qui précède)
L'argument pourrait être que vous pouvez développer un moyen de louer des serveurs physiques avant le revenu, puis, lorsque cela a du sens, vous pouvez soit utiliser l'amortissement standard -ou- l'article 179 sur les achats purs et/ou l'article 179.
À titre d'exemple, vous pouvez déployer un groupe incroyablement capable de, disons, quatre machines physiques 1U absolument complètement sur-approvisionnées à 100 000 $ dans différentes installations de colo pour la redondance. Il existe toutes sortes d'astuces ici pour l'équilibrage de charge et le basculement avec le service cloud XYZ, DNS, anycast, tout ce que vous voulez. Vous pouvez utiliser diverses installations de colo qui exploitent des centres de données dans le monde entier, leur expédier le matériel du fournisseur, puis les provisionner avec Ansible ou tout ce que vous voulez sans jamais voir l'installation ou toucher au matériel.
Alors maintenant, vous avez du matériel physique redondant qui va absolument tourner en rond autour de la plupart des fournisseurs de cloud (en particulier pour les E/S), des coûts fixes comme tout ce que vous pouvez bande passante (qui n'a pas le balisage de 800 % des services cloud, etc.) - plus besoin d'attendre pour l'inévitable facture cloud de 50 000 $ ou en essayant de retrouver (dans la panique) ce qui vous a fait dépasser votre budget cloud configuré en un jour au lieu d'un mois. Oh btw, vous ne vous enfermez pas dans les API propriétaires maladroites pour provisionner et même utiliser des services autres que les machines virtuelles offertes par $ BIGCLOUD
Si vous faites du ML, vous pouvez vous entraîner sur votre propre matériel ou (ou sur le cloud occasionnel) et exécuter l'inférence 24h/24 et 7j/7 avec des choses comme le NVIDIA A10. La location continue dans le cloud pour les instances GPU est incroyablement chère et le retour sur investissement sur l'achat du matériel est généralement de l'ordre de quelques mois (ou bien en avance presque immédiatement avec la section 179). À titre d'exemple, j'ai récemment fait un benchmark avec le Nvidia A10 pour un modèle que nous servons et il peut faire plus de 700 requêtes d'inférence/s en FP32 avec une latence inférieure à 10 ms. Avec un seul A10 par châssis sur quatre instances saines, c'est 2800 req/s (et pourrait probablement être réglé davantage)
Ensuite, si vous devenez VRAIMENT grand, vous pouvez commencer à obtenir des armoires et au-delà. En termes de pannes matérielles, comme mentionné, tout ce que je peux dire, c'est que la sortie RAID double PS, etc., le matériel est (selon mon expérience) extrêmement fiable. Ayant eu plusieurs armoires complètes de matériel dans le passé, les pannes matérielles étaient rares et espacées et les fournisseurs incluront des SLA incroyables pour le remplacement. Vous les informez de l'échec, ils envoient un technicien< huit heures directement à l'installation de colo et remplacez le disque, le PS, etc. par la lumière clignotante
Mon expérience est qu'une (bonne) ressource ETP peut facilement gérer cela jusqu'à l'échelle de plusieurs cabinets. Pour vous, le problème actuel est que beaucoup de ces personnes ont été récupérées par les grands fournisseurs de cloud et remplacées (sur le marché) par des ressources capables de naviguer dans le ridicule limite qui utilise des dizaines (sinon plus) de produits/services de $ GROS NUAGE
J'ai également trouvé que cette configuration est en fait BEAUCOUP plus fiable que la plupart des $ BIGCLOUD. Plus besoin de se demander ce qui se passe avec une panne de $BIGCLOUD qu'ils ne reconnaîtront même pas (et sur laquelle vous n'avez absolument aucun contrôle). Venant d'une formation dans les télécommunications et la santé, je suis complètement dingue de voir à quel point le temps de disponibilité s'est aggravé avec les fournisseurs de cloud. Habituellement, vous pouvez simplement dire aux clients "oh, Internet a des problèmes aujourd'hui"car ils verront probablement les gros titres à ce sujet, mais pour de nombreuses applications, c'est tout simplement inacceptable - et nous devrions nous attendre à mieux
[0] - https://www.section179.org/section_179_deduction/
[1] = https://www.section179.org/section_179_leases/
Si je veux lancer un nouveau projet ou essayer d'héberger quelque chose de nouveau, cela prend quelques minutes et j'ai les scripts. Les déploiements sont rapides, la maintenance est faible et j'en ai bien plus pour mon argent
Pour ceux que ça intéresse, voici le montage approximatif de ce que j'utilise :
* Ansible pour tout gérer
* Un tout petit peu de terraform pour certaines entrées DNS que je remplacerai peut-être un jour
* restic pour les sauvegardes, à nouveau contrôlé par ansible
* tailscale pour vpn (j'ai quelques pi en cours d'exécution à la maison, rien de majeur mais tailscale le rend facile et sécurisé)
* docker-compose pour à peu près tout le reste
L'application principale est Clojure, donc j'exécute une JVM native. La base de données est entièrement distribuée, RethinkDB, travaille actuellement sur le passage à FoundationDB
L'important est de ne rien gérer manuellement, par ex. traitez les serveurs physiques comme n'importe quel autre serveur cloud. Peu importe qu'il soit physique ou virtualisé
J'ai vu beaucoup de personnes moins expérimentées surpayer pour hetzner et similaires alors qu'un vps de 5 à 10 $ aurait fonctionné
Oui, vous prenez en charge votre propre matériel à ce stade. Non, ce n'est pas un énorme mal de tête
Le coût supplémentaire le plus important est la location de plus d'adresses IPv4, que Hetzner facture généreusement pour le moment où il y en a si peu de disponibles
Tout ce que vous créez commencera avec 0 utilisateurs, et une vraie machine entière est complètement exagérée pour cette charge 0 que vous obtiendrez. Vous mettez à niveau votre VPS dans une paire de machines réelles, puis dans un petit cluster loué, puis dans un centre de données (si quelqu'un ne sape pas celui-là). Tous ceux-ci ont des factures prévisibles et des performances optimales pour leur prix
Tout ce que vous possédez dans une colo sera également plus cher par mois. Quand j'avais des connexions où je pouvais payer pour une adresse IP statique, c'était généralement 5 $/mois
Je loue maintenant un serveur assez bas de gamme, mais c'est 30 $/mois. Bien plus de tout ce dont j'ai besoin, mais c'est bien. Et ils n'ont pas abandonné le support de mon système d'exploitation tout en augmentant les prix pour améliorer le support ou quelque chose du genre. (Bien que j'avais initialement du matériel floconneux qui devait être échangé)
comme vous l'avez souligné, le métal nu est la voie à suivre. Cela fonctionne à l'opposé du cloud - un peu plus de travail au début mais beaucoup moins de dépenses à la fin
Plus d'infos httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..
La configuration et la gestion de Postgres sont pénibles. Ce serait bien d'avoir un moyen plus simple de tout arranger
1. Force la config à être reproductible, car les machines virtuelles tomberont en panne
2. Vous pouvez obtenir de fortes remises sur AWS qui réduisent la douleur
3. Les autres choses auxquelles vous avez accès au sommet des machines virtuelles qui sont moins chères/plus rapides une fois que vos affaires sont déjà dans le cloud
4. Il est plus facile d'avoir une configuration système documentée (par exemple, les documents AWS) que de former les gens/de documenter les éléments spéciaux que vous avez en interne. Particulièrement utile pour embaucher de nouvelles personnes
5. Vous n'avez pas besoin d'espace ou d'alimentation redondante/internet/etc sur place. Juste assez pour permettre aux gens de faire fonctionner leurs ordinateurs portables
J'utilisais un VPS avant cela, mais je me suis arrêté et je suis passé à un VPS physique car c'était une meilleure affaire et nous n'avons pas rencontré de limite(s) de CPU
La surveillance du disque n'est cependant pas trop difficile. Pour les disques durs, exécutez smartctl une fois par heure, alertez lorsque les secteurs réaffectés ou en attente augmentent rapidement ou atteignent 100. Pour les SSD, croisez les doigts ; d'après mon expérience avec quelques milliers, ils ont tendance à bien fonctionner jusqu'à ce qu'ils disparaissent du bus, pour ne plus jamais être revus. Avoir un plan de récupération de données qui n'implique pas le stockage des données sur les mêmes modèles d'appareils avec des heures d'alimentation très similaires, les erreurs de micrologiciel corrélées à l'heure sont réelles
Hetzner a une API pour commander des serveurs dédiés après tout, et une API pour installer un système d'exploitation (ou pour redémarrer pour sauver et flasher l'image que vous voulez)
Je suppose que si j'étudiais les options commerciales, j'aurais le "tronc"trié au bureau avec une solution de FAI commercial, une adresse IP statique, un bon matériel informatique peut-être, mais d'après ce que je sais à ce moment précis, si un client avait besoin d'hébergement, je 'd aller toujours directement à la location d'un vps
J'étais plutôt un développeur junior à l'époque, donc peut-être que j'étais un mais ça ne me manque pas du tout. En théorie, je suis d'accord avec ce que vous dites, mais déployer un Dockerfile sur quelque chose comme Google Cloud Run est beaucoup plus facile. Oui, je paie plus que ce que je gérerais pour mon propre VPS, mais je pense que cela est plus que compensé par les heures de développement économisées
- le matériel physique a des problèmes, par ex. échec du ventilateur ->ma VM est migrée en direct vers un autre hôte, je ne le remarque pas ou ne m'en soucie pas
- le matériel physique explose ->ma machine virtuelle redémarre sur un autre hôte, je le remarquerai peut-être mais je m'en fiche
La planification des catastrophes est beaucoup plus facile avec les machines virtuelles (même avec des animaux de compagnie et non du bétail)
Pour un débutant, les moins chers font le travail
Je suis sûr qu'à mesure que le cloud computing évolue, ces offres deviennent plus courantes
Il y a un autre aspect du cloud computing. Les moyennes et grandes entreprises comptent le cloud computing comme des pourcentages à un chiffre dans leurs calculs de coûts. Cela signifie que les décisions prises par les managers et les équipes, recherchent souvent la fiabilité et l'évolutivité (à mettre sur leurs présentations) plutôt que "est-ce que ma configuration est coûteuse ou bon marché"Mon employeur a adopté le cloud comme un jeu commercial/financier, et non religieux. Nous débarquons souvent de nouvelles versions dans le cloud et migrons vers un centre de données si nécessaire plus tard
Les applications sur site coûtent environ 40 % de moins. Les applications qui sont plus rentables dans le cloud y restent
Je pense qu'il est vrai qu'AWS/GCP/Azure ne sont pas des offres très compétitives en Europe. Ce que je ne vois pas en est la preuve pour les États-Unis
pour la même spécification, bien sûr. Je pense que les virtuels ont du sens aux deux extrémités - soit l'évolutivité dynamique pour un grand N est importante, soit vous n'avez réellement besoin que d'une petite fraction d'une boîte physique. Payer 45/mois pour quelque chose qui fonctionne sur 5/mois n'est pas sensé non plus, et vous donne plus de flexibilité pour ne pas regrouper les choses juste pour utiliser votre serveur
Gardez des sauvegardes dans tous les cas. De préférence sur un autre fournisseur ou au moins dans un lieu physique différent. Et, bien sûr, testez-les
Et si vous gérez un bon régime de sauvegarde et que vous surveillez quand même vos données/applications, la surveillance des disques représente-t-elle une difficulté supplémentaire importante ?
--
[1] en fait, si vous automatisez le processus de restauration vers un autre emplacement, ce que je fais pour quelques-uns de mes morceaux, vous pouvez simplement appuyer sur ce bouton et mettre à jour le DNS une fois terminé, et peut-être allouer un peu plus de RAM + cœurs (mon test les miroirs sont plus petits que les machines virtuelles en direct car ils n'ont pas besoin de servir des modèles d'utilisation réels)
Exactement ce que je fais pour moi et mes clients. Économise des tonnes de dosh
Même si je voulais mettre à jour, il s'agit simplement d'extraire la dernière version dans le modèle docker-compose et de relancer le playbook ansible. Évidemment, si la mise à niveau nécessite plus, qu'il en soit ainsi, mais ce n'est pas différent de toute autre configuration.
Probablement la seule chose que j'ai _besoin_ de faire manuellement est de tester mes sauvegardes. Mais j'ai un script pour chaque projet qui le fait donc je me contente de SSH, lance le one-liner, vérifie le résultat et c'est fait. Je le fais environ une fois par mois environ, mais je reçois également des e-mails si une sauvegarde échoue
Il ne peut donc pas y avoir de temps du tout. Habituellement, c'est probablement 1 à 2 heures par mois si je prends des mises à jour sur une base semi-régulière. Mais cela évoluera avec le nombre de choses que vous hébergez et gérez
En d'autres termes, la seule différence est l'origine du fichier d'inventaire ansible. Soit c'est une liste statique d'IP, soit ça vient de terraform
Si vous voulez de la RAM ECC, cela semble être 60/mois, et cela passe également à un processeur 8 cœurs plus puissant
Quoi qu'il en soit, si nous parlons d'un "environnement de production complet et d'un environnement de staging/standby en double"(pour citer la personne à qui vous avez répondu), alors 60/mois * (2 ou 3) est toujours très bon marché par rapport à l'AWS de n'importe quelle startup facture que j'ai vue
Les cas d'utilisation varient, mais j'ai tendance à convenir qu'AWS/GCP/Azure n'est pas la réponse à tous les problèmes
Pour quelqu'un qui peut installer son application sur un VPS à 4 $, cela coûtera évidemment moins cher que tout ce qui est nu, mais le cloud évolue très cher dans de nombreux cas. Le métal nu n'est pas non plus la réponse à tous les problèmes, mais beaucoup de gens dans l'industrie ne semblent pas apprécier quand cela peut être la bonne réponse.
SERVEURS PRIVÉS VIRTUELS#120
