Almost Every infrastructure decision I endorse or regret after 4 years
10 days ago
- #Infrastructure
- #Kubernetes
- #AWS
- 选择AWS而非Google Cloud，因其提供更优的支持和稳定性。
- 推荐使用EKS，除非成本节约是首要考虑因素。
- 对使用EKS托管插件感到遗憾，因定制受限，已转向Helm charts。
- 关键数据管理推荐使用RDS。
- Redis ElastiCache因其多功能性和高性能受到好评。
- ECR在稳定性和集成优势上优于quay.io。
- AWS VPN因其简洁性及与Okta的集成受到推荐。
- 对AWS高级支持的高成本表示遗憾。
- Control Tower Account Factory for Terraform (AFT)因自动化账户管理受到推荐。
- 推荐通过Slack机器人自动化事后分析流程。
- PagerDuty的事件模板在事件管理中受到推荐。
- 建议定期审查PagerDuty工单以管理警报疲劳。
- 推荐每月召开成本跟踪会议以管理SaaS支出。
- 后悔在DataDog或PagerDuty中管理事后分析，因定制问题。
- 后悔未更多使用函数即服务(FaaS)处理CPU密集型工作负载。
- 尽管存在复杂性，仍推荐GitOps用于基础设施管理。
- 主张优先考虑团队效率而非外部需求。
- 后悔让多个应用共享数据库，导致维护问题。
- 后悔未尽早采用Okta等身份平台。
- 推荐使用Notion进行文档管理。
- 推荐Slack，并建议优化沟通实践。
- 因简洁高效，Linear优于JIRA。
- 对未使用Terraform Cloud无遗憾（因成本问题），改用Atlantis。
- 对GitHub Actions的CI/CD功能表示认可，但对自托管运行器有所保留。
- 后悔使用DataDog，因其对Kubernetes和AI工作负载的高成本。
- 推荐PagerDuty用于事件管理。
- 对通过差异进行模式迁移表示认可，但有所保留。
- 推荐Ubuntu用于开发服务器，因其支持和软件包生态。
- 尽管有局限，仍推荐AppSmith构建内部工具界面。
- Helm v3虽复杂，仍被推荐用于Kubernetes部署。
- 推荐使用ECR（OCI格式）的Helm charts进行生命周期管理。
- 对Bazel在Go服务中的必要性表示不确定。
- 后悔未尽早采用OpenTelemetry实现指标与追踪。
- 尽管复杂，Renovatebot在依赖更新上优于Dependabot。
- 推荐Kubernetes托管服务，但提示其复杂性。
- 推荐自购IP地址以满足白名单需求。
- 对Flux实现Kubernetes GitOps无任何遗憾。
- 强烈推荐Karpenter管理EKS节点。
- 后悔使用SealedSecrets管理Kubernetes密钥。
- 推荐ExternalSecrets同步AWS密钥至Kubernetes。
- 推荐ExternalDNS管理DNS。
- 推荐Cert-manager管理SSL证书。
- 后悔在EKS中使用Bottlerocket，因调试困难。
- 在基础设施即代码领域，Terraform优于CloudFormation。
- 对未采用Pulumi或CDK等代码化IaC方案无遗憾。
- 对未使用Istio或Linkerd等服务网格无遗憾。
- 推荐Nginx作为EKS入口控制器，因其稳定性。
- 推荐用Homebrew分发公司脚本和二进制文件。
- 推荐Go语言开发服务，因其易用性与性能。" 注：部分条目根据技术语境调整了表述方式（如"endorsed"译为"推荐"，"regret"译为"后悔
- 并确保专业术语（如EKS、Helm、OCI等）保留原名。