Atlassianが社内PaaSを使って従業員のAWSアクセスを管理する理由

Micros というPaaS上で、1,000を超えるサービスがホスティングされている。

ハッカソンで作られたコードから、実際のフラッグシップ製品まですべてを含む。

非常に重要なサービスだが、実際の構成はシンプル。

• Dockerイメージ: サービスロジック

• サービス説明を含むYAML

== DB、キュー、キャッシュなど必要なリソースの定義

== オートスケーリング特性のような各種設定

残りのすべての作業はMicrosが処理する。

= Log Aggregation、Monitoring、Alert

= マルチAZ、バックアップ/リストア/保持設定 など

自前で開発した部分はそれほど多くなく、ほとんどはAWSの機能を利用している。

** このようにPaaSを構成する理由

• 社内標準ツールやプロセスとの統合により、開発が容易になる

• サービス全体に広く適用すべき変更がシンプルかつ予測可能になる

• 少数のエンジニアの専門技術が何倍にも増幅される (multiplied)

  ( 社内にPostgreSQLの専門家はそれほど多くないが、Microsに適用するだけで会社全体が恩恵を受ける )

• プラットフォーム改善の小さな試みでも会社全体に影響を与えられる

• AWSの新機能も、既存のセキュリティや規程を守りながら段階的に追加できる

もちろんこの方式がすべて優れているわけではなく、新しいAWS機能を試しにくいこともあれば、別のサードパーティーツールがMicrosと連携できない場合もある。そのため、内部ではPaaSの機能追加プロセスを整備している。

このPaaSは、社内エンジニアとAWSの間を遮る壁ではなく、むしろAWSのインフラをより多く見せる役割を果たしている。今後も進化させていく。

[xguru]

記事がかなり長いため、いくつかの部分だけを抜粋して記しました。

少し大きな組織で AWS を運用しているのであれば、じっくり読んでみることをお勧めします。

以前、KTH や Daum もこれと似たように内部クラウド（OpenStack だったと記憶しています）を構成して使っていたと思いますが

このように AWS の上に薄く重ねる方法も良いように思います。