Presque toutes les décisions d’infrastructure que j’ai approuvées ou regrettées après 4 ans à gérer l’infrastructure dans une startup

xguru · 2024-02-28T11:16:02+09:00

Chaque choix est indiqué comme Endorse (approbation) ou Regret (regret) Choix d’AWS Choisir AWS plutôt que Google Cloud : j’approuve le choix d’AWS. AWS est centré sur le client. Google Cloud donne l’impression de s’appuyer sur des robots et de l’automatisation. EKS : j’approuve l’usage d’EKS. EKS offre une intégration profonde avec les services AWS, et Kubernetes a aussi rattrapé son retard sur de nombreux points (par exemple l’intégration avec Route53 via externaldns). Add-ons managés EKS : je regrette d’avoir utilisé les add-ons managés EKS. Il a fallu personnaliser l’installation, et l’exploitation s’est mieux passée après le passage à des charts Helm. Base de données et cache RDS : j’approuve l’usage de RDS. Les données sont la partie la plus importante de l’infrastructure, et le coût de RDS en vaut la peine. Redis ElastiCache : j’approuve l’usage de Redis. Redis est très efficace pour le cache et pour des usages plus généraux. ECR : j’approuve la migration de quay.io vers ECR. ECR est plus stable et son intégration des permissions est plus poussée. Réseau et support AWS VPN : j’approuve l’usage d’AWS VPN. Le VPN est très simple à configurer et à comprendre. Nous utilisons Okta pour gérer l’accès VPN, et l’expérience est très bonne. Support premium AWS : je le regrette. Le support premium AWS est très coûteux et n’en vaut pas la peine si l’on ne manque pas de connaissances AWS en interne. Control Tower Account Factory for Terraform : j’approuve l’intégration d’AFT. Cela automatise la création des comptes et aide à standardiser les tags. Automatisation des processus Automatisation des post-mortems via un bot Slack : j’approuve l’automatisation du processus de post-mortem. Cela aide à inciter les gens à rédiger les post-mortems. Utilisation des templates d’incident de PagerDuty : j’approuve l’usage de templates lors des incidents. Cela permet un certain niveau de personnalisation grâce à la flexibilité de Notion. Revue régulière des tickets PagerDuty : j’approuve la révision régulière de la configuration des alertes. Cela permet de faire en sorte que même les alertes moins importantes ne soient pas ignorées. Gérer les post-mortems dans Datadog ou PagerDuty : je regrette l’usage d’un outil de gestion unifié pour les post-mortems. Dans les deux cas, il est difficile de personnaliser le processus. Je pense qu’il vaut mieux utiliser un outil puissant comme Notion. Divers Réunion mensuelle de suivi des coûts : j’approuve une réunion mensuelle pour examiner les coûts SaaS. Cela permet de vérifier si les coûts sont appropriés et de prendre les mesures nécessaires. Dans AWS, les postes sont regroupés par tags et séparés par compte. Je recommande de ne pas s’arrêter à AWS et d’examiner toutes les principales sources de dépenses de l’entreprise. Ne pas avoir davantage utilisé le FaaS : je regrette de ne pas avoir pu utiliser le FaaS de façon plus complète, car il n’existait pas d’option FaaS pour les workloads GPU. Beaucoup de workloads CPU auraient pu être traités via du FaaS. Un autre avantage caché de Lambda est qu’il est très facile d’en suivre le coût avec une grande précision. GitOps : j’approuve l’usage de GitOps. Nous utilisons GitOps pour une grande partie de l’infrastructure, et nous avons investi dans le développement d’outils pour aider à comprendre l’état des déploiements. Priorité à l’efficacité de l’équipe : j’approuve le fait de prioriser l’efficacité de l’équipe. Je n’ai jamais regretté le temps investi dans l’automatisation ou la documentation. Plusieurs applications partageant une seule base de données : je regrette que plusieurs applications partagent une seule base de données. Cela a causé plusieurs problèmes. Adoption de SaaS Adoption tardive d’une plateforme d’identité : nous utilisions Google Workspace pour attribuer les permissions, mais je regrette de ne pas avoir adopté plus tôt une solution d’identité comme Okta. Okta s’intègre bien et aide à résoudre les problèmes de sécurité et de conformité. Notion : j’approuve l’usage de Notion pour la documentation. Notion a été un excellent choix et s’utilise bien plus facilement que ce que nous avons utilisé auparavant (wikis, Google Docs, Confluence, etc.). Le concept de base de données pour organiser les pages est utile. Slack : j’approuve l’usage de Slack. C’est un outil efficace comme moyen principal de communication. Outils et services de développement Passer de JIRA à Linear : j’approuve l’usage de Linear à la place de JIRA. Je trouve JIRA trop complexe et trop lourd. Ne pas utiliser Terraform Cloud : je ne regrette pas de ne pas utiliser Terraform Cloud, car je ne pouvais pas en justifier le coût. Nous sommes passés à Atlantis et avons ajouté l’automatisation nécessaire dans le pipeline CI/CD. GitHub Actions pour le CI/CD : j’approuve dans une certaine mesure l’usage de GitHub Actions. Les actions de la marketplace et la syntaxe sont faciles à utiliser. Je considère comme inconvénient le support limité des workflows auto-hébergés. Choix techniques Datadog : je regrette l’usage de Datadog. C’est très coûteux, et son modèle tarifaire n’est pas adapté aux clusters Kubernetes ni à une entreprise d’IA. PagerDuty : j’approuve l’usage de PagerDuty. Le produit est bon et son prix est raisonnable. Migrations de schéma par diff : j’approuve dans une certaine mesure l’usage d’un outil pour les migrations de schéma. Les données sont importantes, et les migrations de schéma peuvent être risquées. Ubuntu for dev servers : j’approuve l’usage d’Ubuntu pour les serveurs de développement. C’est bien pris en charge et il dispose de la plupart des paquets nécessaires. AppSmith : j’approuve l’usage d’AppSmith pour l’automatisation des processus destinés aux ingénieurs en interne. Nous l’auto-hébergeons et c’est globalement satisfaisant. Au départ, nous avions exploré retool pour des intégrations plus poussées, mais à l’époque nous ne pouvions pas justifier le prix pour seulement quelques intégrations. helm : j’approuve l’usage de Helm v3. Il y a des problèmes autour du déploiement des CRD et de la formation des développeurs, mais c’est suffisamment bon pour empaqueter et déployer des objets Kubernetes. helm charts dans ECR (oci) : j’approuve le stockage des charts Helm dans un registre OCI. Cela pose moins de problèmes que l’ancienne méthode avec S3 et des plugins. bazel : je ne suis pas certain à propos de bazel. Cela semble excessif pour déployer des services Go, et GitHub Actions est plus facile à utiliser pour davantage d’ingénieurs. Ne pas utiliser OpenTelemetry : je regrette d’avoir envoyé les métriques directement via l’API DataDog. Je recommande d’utiliser OpenTelemetry dès le départ. Choisir renovatebot plutôt que dependencyabot : je regrette de ne pas avoir réfléchi plus tôt au maintien à jour des dépendances. Renovatebot est personnalisable, mais sa configuration et son débogage sont complexes. Kubernetes : j’approuve l’usage de Kubernetes. Il faut un moyen d’héberger des services de longue durée, et Kubernetes est populaire et fonctionne bien. Acheter ses propres IP : j’approuve l’achat de son propre bloc d’IP lorsqu’on travaille avec des partenaires externes. Cela aide à fournir aux partenaires externes un bloc CIDR plus large à mettre en whitelist. Choisir Flux pour le GitOps k8s : je ne regrette pas d’avoir choisi Flux comme outil GitOps pour Kubernetes. Il faut développer des outils pour aider à comprendre l’état des déploiements. Karpenter pour la gestion des nœuds : j’approuve l’usage de Karpenter avec EKS. C’est plus fiable et plus rentable que les autres autoscalers. Utiliser SealedSecrets : je regrette l’usage de SealedSecrets. C’est complexe pour les développeurs et cela fait perdre l’automatisation existante d’AWS pour la rotation des secrets. Utiliser ExternalSecrets : j’approuve l’usage d’ExternalSecrets pour synchroniser les secrets AWS -> Kubernetes. C’est facile à comprendre pour les développeurs et cela permet de créer/mettre à jour facilement les secrets dans AWS avec terraform. Utiliser ExternalDNS : j’approuve l’usage d’ExternalDNS. Cela synchronise les entrées DNS Kubernetes -> Route53 et a causé très peu de problèmes au cours des 4 dernières années. Utiliser cert-manager : j’approuve l’usage de cert-manager pour la gestion des certificats SSL. C’est très intuitif pour générer des certificats Let's Encrypt et cela ne pose pas de problème. Bottlerocket pour EKS : je regrette l’exploitation de clusters EKS avec Bottlerocket. Des problèmes de CSI réseau surviennent souvent et sont difficiles à déboguer. Choisir Terraform plutôt que CloudFormation : j’approuve l’usage de Terraform. Il est facile à étendre à d’autres fournisseurs SaaS et sa syntaxe est plus lisible que celle de CloudFormation. Ne pas utiliser une solution IaC basée sur du code : je ne regrette pas. Terraform et CloudFormation utilisent des fichiers de données, tandis que Pulumi ou CDK décrivent l’infrastructure en code. La nature limitée de HCL dans Terraform aide à réduire la complexité. Ne pas utiliser de service mesh réseau : je ne regrette pas. Les service meshes réseau sont intéressants, mais les entreprises ont tendance à sous-estimer leur complexité. Le conseil général en infrastructure est que « moins, c’est mieux ». Nginx load balancer pour l’ingress EKS : je ne regrette pas. J’approuve l’usage de Nginx. C’est ancien, mais stable et éprouvé. homebrew pour les scripts d’entreprise : j’approuve l’usage de homebrew pour distribuer les scripts de l’entreprise. C’est suffisamment bon pour distribuer scripts et binaires aux utilisateurs Linux comme Mac. Go for services : j’approuve l’usage de Go pour les services. C’est facile à apprendre pour les nouveaux ingénieurs et c’est un bon choix dans l’ensemble.

(cep.dev)

87 points par xguru 2024-02-28 | 4 commentaires | Partager sur WhatsApp

Chaque choix est indiqué comme Endorse (approbation) ou Regret (regret)

Choix d’AWS

Choisir AWS plutôt que Google Cloud : j’approuve le choix d’AWS. AWS est centré sur le client. Google Cloud donne l’impression de s’appuyer sur des robots et de l’automatisation.
EKS : j’approuve l’usage d’EKS. EKS offre une intégration profonde avec les services AWS, et Kubernetes a aussi rattrapé son retard sur de nombreux points (par exemple l’intégration avec Route53 via externaldns).
Add-ons managés EKS : je regrette d’avoir utilisé les add-ons managés EKS. Il a fallu personnaliser l’installation, et l’exploitation s’est mieux passée après le passage à des charts Helm.

Base de données et cache

RDS : j’approuve l’usage de RDS. Les données sont la partie la plus importante de l’infrastructure, et le coût de RDS en vaut la peine.
Redis ElastiCache : j’approuve l’usage de Redis. Redis est très efficace pour le cache et pour des usages plus généraux.
ECR : j’approuve la migration de quay.io vers ECR. ECR est plus stable et son intégration des permissions est plus poussée.

Réseau et support

AWS VPN : j’approuve l’usage d’AWS VPN. Le VPN est très simple à configurer et à comprendre. Nous utilisons Okta pour gérer l’accès VPN, et l’expérience est très bonne.
Support premium AWS : je le regrette. Le support premium AWS est très coûteux et n’en vaut pas la peine si l’on ne manque pas de connaissances AWS en interne.
Control Tower Account Factory for Terraform : j’approuve l’intégration d’AFT. Cela automatise la création des comptes et aide à standardiser les tags.

Automatisation des processus

Automatisation des post-mortems via un bot Slack : j’approuve l’automatisation du processus de post-mortem. Cela aide à inciter les gens à rédiger les post-mortems.
Utilisation des templates d’incident de PagerDuty : j’approuve l’usage de templates lors des incidents. Cela permet un certain niveau de personnalisation grâce à la flexibilité de Notion.
Revue régulière des tickets PagerDuty : j’approuve la révision régulière de la configuration des alertes. Cela permet de faire en sorte que même les alertes moins importantes ne soient pas ignorées.
Gérer les post-mortems dans Datadog ou PagerDuty : je regrette l’usage d’un outil de gestion unifié pour les post-mortems. Dans les deux cas, il est difficile de personnaliser le processus. Je pense qu’il vaut mieux utiliser un outil puissant comme Notion.

Divers

Réunion mensuelle de suivi des coûts : j’approuve une réunion mensuelle pour examiner les coûts SaaS. Cela permet de vérifier si les coûts sont appropriés et de prendre les mesures nécessaires. Dans AWS, les postes sont regroupés par tags et séparés par compte. Je recommande de ne pas s’arrêter à AWS et d’examiner toutes les principales sources de dépenses de l’entreprise.
Ne pas avoir davantage utilisé le FaaS : je regrette de ne pas avoir pu utiliser le FaaS de façon plus complète, car il n’existait pas d’option FaaS pour les workloads GPU. Beaucoup de workloads CPU auraient pu être traités via du FaaS. Un autre avantage caché de Lambda est qu’il est très facile d’en suivre le coût avec une grande précision.
GitOps : j’approuve l’usage de GitOps. Nous utilisons GitOps pour une grande partie de l’infrastructure, et nous avons investi dans le développement d’outils pour aider à comprendre l’état des déploiements.
Priorité à l’efficacité de l’équipe : j’approuve le fait de prioriser l’efficacité de l’équipe. Je n’ai jamais regretté le temps investi dans l’automatisation ou la documentation.
Plusieurs applications partageant une seule base de données : je regrette que plusieurs applications partagent une seule base de données. Cela a causé plusieurs problèmes.

Adoption de SaaS

Adoption tardive d’une plateforme d’identité : nous utilisions Google Workspace pour attribuer les permissions, mais je regrette de ne pas avoir adopté plus tôt une solution d’identité comme Okta. Okta s’intègre bien et aide à résoudre les problèmes de sécurité et de conformité.
Notion : j’approuve l’usage de Notion pour la documentation. Notion a été un excellent choix et s’utilise bien plus facilement que ce que nous avons utilisé auparavant (wikis, Google Docs, Confluence, etc.). Le concept de base de données pour organiser les pages est utile.
Slack : j’approuve l’usage de Slack. C’est un outil efficace comme moyen principal de communication.

Outils et services de développement

Passer de JIRA à Linear : j’approuve l’usage de Linear à la place de JIRA. Je trouve JIRA trop complexe et trop lourd.
Ne pas utiliser Terraform Cloud : je ne regrette pas de ne pas utiliser Terraform Cloud, car je ne pouvais pas en justifier le coût. Nous sommes passés à Atlantis et avons ajouté l’automatisation nécessaire dans le pipeline CI/CD.
GitHub Actions pour le CI/CD : j’approuve dans une certaine mesure l’usage de GitHub Actions. Les actions de la marketplace et la syntaxe sont faciles à utiliser. Je considère comme inconvénient le support limité des workflows auto-hébergés.

Choix techniques

Datadog : je regrette l’usage de Datadog. C’est très coûteux, et son modèle tarifaire n’est pas adapté aux clusters Kubernetes ni à une entreprise d’IA.
PagerDuty : j’approuve l’usage de PagerDuty. Le produit est bon et son prix est raisonnable.
Migrations de schéma par diff : j’approuve dans une certaine mesure l’usage d’un outil pour les migrations de schéma. Les données sont importantes, et les migrations de schéma peuvent être risquées.
Ubuntu for dev servers : j’approuve l’usage d’Ubuntu pour les serveurs de développement. C’est bien pris en charge et il dispose de la plupart des paquets nécessaires.
AppSmith : j’approuve l’usage d’AppSmith pour l’automatisation des processus destinés aux ingénieurs en interne. Nous l’auto-hébergeons et c’est globalement satisfaisant. Au départ, nous avions exploré retool pour des intégrations plus poussées, mais à l’époque nous ne pouvions pas justifier le prix pour seulement quelques intégrations.
helm : j’approuve l’usage de Helm v3. Il y a des problèmes autour du déploiement des CRD et de la formation des développeurs, mais c’est suffisamment bon pour empaqueter et déployer des objets Kubernetes.
helm charts dans ECR (oci) : j’approuve le stockage des charts Helm dans un registre OCI. Cela pose moins de problèmes que l’ancienne méthode avec S3 et des plugins.
bazel : je ne suis pas certain à propos de bazel. Cela semble excessif pour déployer des services Go, et GitHub Actions est plus facile à utiliser pour davantage d’ingénieurs.
Ne pas utiliser OpenTelemetry : je regrette d’avoir envoyé les métriques directement via l’API DataDog. Je recommande d’utiliser OpenTelemetry dès le départ.
Choisir renovatebot plutôt que dependencyabot : je regrette de ne pas avoir réfléchi plus tôt au maintien à jour des dépendances. Renovatebot est personnalisable, mais sa configuration et son débogage sont complexes.
Kubernetes : j’approuve l’usage de Kubernetes. Il faut un moyen d’héberger des services de longue durée, et Kubernetes est populaire et fonctionne bien.
Acheter ses propres IP : j’approuve l’achat de son propre bloc d’IP lorsqu’on travaille avec des partenaires externes. Cela aide à fournir aux partenaires externes un bloc CIDR plus large à mettre en whitelist.
Choisir Flux pour le GitOps k8s : je ne regrette pas d’avoir choisi Flux comme outil GitOps pour Kubernetes. Il faut développer des outils pour aider à comprendre l’état des déploiements.
Karpenter pour la gestion des nœuds : j’approuve l’usage de Karpenter avec EKS. C’est plus fiable et plus rentable que les autres autoscalers.
Utiliser SealedSecrets : je regrette l’usage de SealedSecrets. C’est complexe pour les développeurs et cela fait perdre l’automatisation existante d’AWS pour la rotation des secrets.
Utiliser ExternalSecrets : j’approuve l’usage d’ExternalSecrets pour synchroniser les secrets AWS -> Kubernetes. C’est facile à comprendre pour les développeurs et cela permet de créer/mettre à jour facilement les secrets dans AWS avec terraform.
Utiliser ExternalDNS : j’approuve l’usage d’ExternalDNS. Cela synchronise les entrées DNS Kubernetes -> Route53 et a causé très peu de problèmes au cours des 4 dernières années.
Utiliser cert-manager : j’approuve l’usage de cert-manager pour la gestion des certificats SSL. C’est très intuitif pour générer des certificats Let's Encrypt et cela ne pose pas de problème.
Bottlerocket pour EKS : je regrette l’exploitation de clusters EKS avec Bottlerocket. Des problèmes de CSI réseau surviennent souvent et sont difficiles à déboguer.
Choisir Terraform plutôt que CloudFormation : j’approuve l’usage de Terraform. Il est facile à étendre à d’autres fournisseurs SaaS et sa syntaxe est plus lisible que celle de CloudFormation.
Ne pas utiliser une solution IaC basée sur du code : je ne regrette pas. Terraform et CloudFormation utilisent des fichiers de données, tandis que Pulumi ou CDK décrivent l’infrastructure en code. La nature limitée de HCL dans Terraform aide à réduire la complexité.
Ne pas utiliser de service mesh réseau : je ne regrette pas. Les service meshes réseau sont intéressants, mais les entreprises ont tendance à sous-estimer leur complexité. Le conseil général en infrastructure est que « moins, c’est mieux ».
Nginx load balancer pour l’ingress EKS : je ne regrette pas. J’approuve l’usage de Nginx. C’est ancien, mais stable et éprouvé.
homebrew pour les scripts d’entreprise : j’approuve l’usage de homebrew pour distribuer les scripts de l’entreprise. C’est suffisamment bon pour distribuer scripts et binaires aux utilisateurs Linux comme Mac.
Go for services : j’approuve l’usage de Go pour les services. C’est facile à apprendre pour les nouveaux ingénieurs et c’est un bon choix dans l’ensemble.

4 commentaires

xguru 2024-03-03

Quelques anciens articles GeekNews pertinents à consulter

Pour ceux qui gèrent une entreprise en solo en tant que développeur, quelle stack technique utilisez-vous ?
La stack d’architecture d’une startup tech en solo
La stack technique de Healthchecks.io, un SaaS géré par une seule personne
Recommandations d’outils pour les développeurs de SaaS en solo
La stack technique d’une entreprise de hardware fondée et gérée seule par une femme
Exploiter une startup pour 6 $ par an
Stack on a Budget - développement basé sur les free tiers
Exploiter une startup logicielle avec un minimum d’efforts
Comment traiter 80 To de trafic et 5 M de pages vues avec 500 000 wons par mois (400 $)

nicewook 2024-02-28

Le contenu principal comme les commentaires sont tous deux très intéressants.

mhj5730 2024-02-28

Waouh… des informations pratiques qu’il est presque impossible de trouver ailleurs.

xguru 2024-02-28

Avis Hacker News

Le surcoût de l’utilisation de RDS en vaut la peine
- Le coût additionnel de l’utilisation de RDS paraît ridiculement élevé chaque fois qu’on envisage de le remplacer par un cluster SQL en colocation. C’est tellement au-delà de ce que je serais prêt à payer que cela couvrirait une baie en colocation, des AWS Direct Connect, des serveurs, un SAN, des licences SQL Server, des contrats de maintenance, ainsi que le salaire d’un DBA interne à temps plein.
- Coût total sur 12 mois : 547,441.85 USD
- Quand la marge devient assez importante pour payer le salaire d’un ou plusieurs employés à temps plein, il faut envisager d’embaucher à la place plutôt que de continuer à faire grossir RDS aveuglément. Avec RDS, vous payez vraiment très cher, et il faut réévaluer les décisions prises au début de la startup.
Dire que Google Cloud est meilleur qu’AWS est peut-être une opinion impopulaire, mais avec Google Cloud Run, on peut exécuter des conteneurs Docker dans le cloud comme dans un rêve. Les noms des services sont simples, il y a moins de services critiques que dans l’offre complexe d’AWS, et l’interface est plus intuitive. Les inconvénients sont le manque de tutoriels dû à une communauté plus réduite, la difficulté à trouver des personnes expérimentées, et le manque d’outils tiers. Je recommande d’essayer.
Utiliser EC2 + ASG est un vrai plaisir. C’est conceptuellement simple : on lance une image dans un ASG et on configure des politiques d’auto-scaling. Il n’y a presque rien à surveiller. À l’inverse, utiliser k8s est toujours un gros chantier. On monte une équipe entière pour gérer k8s. On introduit des dizaines de concepts propres à k8s ou on investit des années-homme dans la « platform engineering » pour masquer ces concepts. On publie des guidelines, des SDK et toutes sortes de validateurs pour permettre d’utiliser k8s « correctement ». Et malgré cela, on écrit des dizaines de milliers de lignes de YAML et de code pour implémenter des operators. Par moments, je me demande si k8s n’est pas trop intrusif.
Avis sur les produits SaaS
- Je ne comprends pas le passage de JIRA à Linear. Linear est correct, mais je tombe souvent sur des choses qu’il ne peut pas faire, ou dont j’ignore le fonctionnement.
- Je recommande globalement Terraform Cloud. Faire grandir son propre système maison peut être acceptable pendant les premières années, mais cela peut coûter cher à long terme.
- Je soutiens dans une certaine mesure l’usage de GitHub Actions pour le CI/CD. Je suggérerais plutôt d’utiliser GitLab.
- Je ne suis pas du tout d’accord à propos de Datadog. C’est le meilleur outil de monitoring/observabilité du marché. Le coût est la critique la plus fréquente, mais la plupart du temps c’est parce que la configuration de Datadog est mauvaise et que les coûts explosent.
- Je soutiens l’avis sur Pagerduty. Pagerduty coûte environ 10 fois plus cher qu’Opsgenie sans offrir de meilleures fonctionnalités. Lors d’un renouvellement de contrat avec Pagerduty, quand j’ai demandé au commercial quelles fonctionnalités ils avaient qu’Opsgenie n’avait pas, il a répondu qu’ils essayaient de se positionner comme une marque premium sur le marché. Je suis donc très bien avec une marque généraliste pour la gestion des incidents.
J’imagine un développeur des années 90/2000 lire cette liste et être perdu devant la complexité et le jargon.
Lecture intéressante, mais je ne suis pas sûr que l’auteur regrette vraiment assez de choses pour en faire un billet de blog.
Je ressens l’envie d’expérimenter un retour à un énorme serveur à 100k$ pour tout faire tourner dans une seule boîte.
J’ai réussi à apprendre les bases de Kubernetes / EKS, mais j’envisage de passer à ECS. Kubernetes est trop complexe pour nos besoins. C’est difficile à piloter avec quelque chose comme CloudFormation. Les load balancers provisionnés par les add-ons sont difficiles à référencer depuis l’extérieur de Kubernetes. Sur EKS Fargate, le logging vers Cloudwatch semble ne pas fonctionner, même en suivant la documentation. Les métriques CPU/mémoire ne fonctionnent pas comme sur EKS EC2, et il semble qu’ADOT soit nécessaire. Sur ECS, j’ai recréé l’environnement en un dixième du temps et tout a bien fonctionné.
J’aime la manière dont cet article est écrit et son contenu. Je ne suis pas d’accord avec certaines décisions et recommandations, mais même dans ces cas-là, lire les raisons est excellent. J’aimerais voir davantage d’articles de ce genre et un moyen de les comparer. Cela m’inspire à écrire un article similaire.
La base de données « évier de cuisine » utilisée par tout le monde est un problème fréquent, mais il se répète sans cesse. Avec la croissance, cela devient une dette technique importante et un goulot d’étranglement en performance. Utiliser une base de données managée comme RDS permet d’exploiter facilement des clusters de base de données séparés pour chaque application principale.