- 主にスタートアップ環境での経験に基づきます。
- 個人の感想です。
- すべての選択について支持と後悔で表示します。
AWS
支持
- AWS：支持する。AWSは顧客に焦点を当てている。Google Cloudはロボットとオートメーションに依存する感じ。
- EKS：支持する。EKSはAWSサービスと緊密な統合を提供していて、Kubernetesを幅広く追いついている。
後悔
- EKSマネージドアドオン：後悔する。インストールをカスタマイズする必要があり、helmチャートに切り替えてからより良い操作を経験。
データベースとキャッシュ
支持
- RDS：支持する。データはインフラの最も大事な部分で、RDSを使用する価値がある。
- Redis ElastiCache：支持する。Redisはキャッシュと一般的な使用に非常に効果的。
- ECR：支持する。 ECRはより信頼性が高く、権限統合がより密接。
ネットワークとサポート
支持
- AWS VPN: 支持する。設定が非常にシンプル。VPNアクセスを管理するためにOktaを使用したら、非常に良い経験ができる。
- Control Tower Account Factory for Terraform: 支持する。アカウントの作成を自動化し、タグの標準化に役立つ。
後悔
- AWSプレミアムサポート：後悔。非常に高価で、作業者がAWSの知識が不足していたら価値がない。
プロセス自動化
支持
- Slackボットを使用した事後分析の自動化：支持する。事後分析を作成するように誘導するのに役に立つ。
- Pager Dutyの事故テンプレート使用：支持する。Notionの柔軟性を活かし、多少のカスタマイズが可能。
- Pager Dutyチケット定期レビュー：支持する。重要でないアラームも無視しないように管理。
後悔
- DatadogまたはPager Dutyでの事後分析の管理：後悔する。どちらも事後プロセスをカスタマイズすることが困難。Notionなどの強力なツールを使用する方が良い。
その他
支持
- 毎月のコスト追跡会議：支持する。毎月のSaas費用が適切かを確認し、必要な措置を講じる。AWSではアイテムをタグ別にグループ化し、アカウント別に区切る。AWSにとどまらず、会社が持っているすべての主要支出源を把握することをお勧め。
- GitOps：支持する。インフラの多くにGitOpsを使用しており、ツール開発に投資して展開状況を理解するのに役立つ。
- チーム効率性優先：支持する。自動化や文書化に時間を費やしたことを後悔したことはない。
後悔
- FaaSを使用しない：後悔する。GPU操作にFaaSオプションがないため、FaaSが完全に使用できなかった。大量のCPU作業ならFaaSで処理できたはず。
- 複数のアプリケーションが1つのデータベースを共有する：後悔する。複数のアプリケーションが1つのデータベースを共有すると何らか問題が発生する。
SaaSの導入
支持
- Notion：支持する。Notionは素晴らしい選択であり、過去に使用したもの（Wikis、Google Docs、Confluenceなど）よりも簡単に動作する。ページのデータベース概念が役に立つ。
- Slack: 支持する。コミュニケーションのための基本ツールとして効果的。
後悔
- アイデンティティプラットフォームの後半導入：後悔する。Google Workspaceを使用して権限を割り当てるために使用したが、Oktaなどのアイデンティティソリューションをより早く導入する必要があった。
開発ツールとサービス
支持
- JIRAからLinearに移動：支持する。JIRAは複雑で重い。
- GitHub Actions for CI/CD: 支持する。マーケットプレイスのアクションと文法が使いやすい。独自ホスティングワークフローのサポートが制限されていることは短所。
技術の選択
支持
- Pager Duty：支持する。良い製品で価格が適切。
- Schema Migration by Diff: 支持する。データが大事なので、スキーマの移行・統合は危険。
- Ubuntu for dev servers：支持する。開発に必要なほとんどのパッケージが常備。
- AppSmith：支持する。内部エンジニアのためのプロセス自動化に十分で満足。最初はretoolを使ってより深い統合を試したが、価格の正当化ができなかった。
- helm：支持する。CRDのデプロイと開発者のトレーニングが難しいが、Kubernetesオブジェクトをパッケージ化して配布するのに十分。
- helm チャート in ECR(oci)：支持する。S3とプラグインを使用した以前の方法より安全。
- 自己IP購入：支持する。外部パートナー向けに大きなブロックをホワイトリストとして提供するのに役立つ。
- Kubernetes：支持する。長期実行サービスをホストする手段が必要なので、Kubernetesは人気で、機能の信頼性が高い。
- Flux for kas GitOps選択：支持する。Deploy状態を理解するためにツールの開発が必要。
- Karpenter for node management: 支持する。EKS使用時Karpenterを使用したら、他のオートスケーラよりも信頼性が高く費用対効果が高い。
- ExternalSecretsの使用：支持する。ExternalSecretsを使用してAWSからKubernetesパスワードを同期したら開発者にとって理解しやすい。terraformを使用してAWS内でパスワードを簡単に作成/更新。
- ExternalDNS18：支持する。KubernetesからRoute53DNSエントリを同期し、過去問題はほとんどなかった。
- cert-managerの使用：支持する。SSL証明書を管理にcert-managerの使用する。Lets Encrypt証明書の生成が非常に直感的。
- TerraformとCloudformationの選択：支持する。他のSaaSプロバイダーに拡張しやすく、CloudFormationより文法がわかりやすい。
- ネットワークメッシュを無効にする：支持する。ネットワークメッシュは素晴らしいが、会社が複雑さを過小評価する傾向がある。
- Nginx ロードバランサー for EKS ingress: 支持する。Nginxは古いが安定的。
- homebrew for company scripts：支持する。LinuxユーザーとMacユーザーの両方にスクリプトとバイナリをデプロイできる。
- Go for services: 支持する。初心者が学びやすく、全体的に良い選択。
後悔
- Datadog：後悔する。非常に高価で、KubernetesクラスターとAI企業のコストモデルが不適切。
- bazel：後悔まではないが、再考が必要。Goの展開には過度で、GitHub Actionsの方がエンジニアには使いやすいかも。
- オープンテレメトリを無効にする：後悔する。最初からDataDog APIを直接使用してメトリックを送信することを推奨。
- dependencyabotの代わりにrenovatebotを選択する：後悔する。依存関係を最新の状態に保つことをより早く考えなかった。Renovatebotはカスタマイズ可能だが、設定とデバッグは複雑。
- SealedSecretsの使用：後悔する。開発者にとって複雑で、AWSの既存パスワードの交換で自動化を失う。
- Bottlerocket for EKS: 後悔する。ネットワーキングCSIの問題が頻繁に発生し、デバッグが困難。