クラウド意思決定の十戒のうち、どれに従いましたか?

過去数年間、私は多くの企業がクラウドサービスを完璧で安全かつ信頼できるものにできるよう支援してきました。これらの企業が抱える問題はそれぞれ異なりますが、問題の種類は基本的に分類することができます。これらがこの記事で紹介する十戒です。

私は長年の実践から学んだこの10 の戒律を、ビジネス上の意思決定者 (経営者) 向けと技術上の意思決定者 (技術チームのエンジニアやマネージャー) 向けの 2 つのタイプに分けました。

タイプ1 : ビジネス意思決定者向け

1. クラウドを単なる技術の問題として考えない

アジャイルまたは DevOps 変革には、ある程度のトップダウンの組織変更が伴うと広く考えられています。これには、新しい責任、新しい働き方、チーム間の新しいコミュニケーション方法が含まれます。「DevOps Box」を購入するだけでは成功は期待できません。

クラウドコンピューティングの導入も同様です。クラウドコンピューティングを、従来と同じテクノロジーと作業方法を提供する単なる別の方法として考えないでください。「リフトアンドシフト」の考え方は、最終的にはコストがかさみ、肥大化したクラウド導入の失敗につながります。

クラウドコンピューティングを優先的に導入することに成功した企業では、開発、運用、セキュリティ、さらには財務のあらゆる側面で新しいアーキテクチャが採用されています。どうか時間をかけて、必要な根本的な変化を理解し、受け入れてください。

写真

2. 最初からトレーニングする

クラウドコンピューティングを導入するというトップダウンの組織的命令を出しただけで、あとは放っておいて良いことが起こることを期待することはできません。

クラウドコンピューティングは、技術スキルとチームの責任に大きな変化をもたらします。クラウドコンピューティングテクノロジーを深く理解している人材は珍しく、市場で見つけるのは容易ではありません。パートナーは協力できますが、最終的にはこの専門知識を社内で育成する計画が必要です。

大企業では、クラウドセンターオブエクセレンスを確立することは良いスタートですが、こうした取り組みが別の情報サイロに細分化されてしまうことも見てきました。単に「クラウドチーム」を作成するだけでは不十分です。文化をより広範囲に推進する必要があります。つまり、数か月、あるいは数年かけて組織全体にクラウドコンピューティングスキルを慎重に広める必要があります。

確かに、トレーニングには多額の費用がかかりますが、クラウドコンピューティングの本質は、同じ人員でより高い価値を実現できることです。したがって、採用予算の一部をチームのトレーニングに振り向けてください。クラウドサービスプロバイダーが管理するサービスの使い方をチームが理解すれば、驚くほどの成果が得られるでしょう。

適切な優先順位を設定し、適切なインセンティブを提供すれば、従業員は変革し始めます。

写真

3. クラウドコンピューティングを価値の中心として捉える

以前に比べると数は減ったものの、コスト削減を主な目的としてクラウドコンピューティングを選択する企業はまだいくつかあります。そして、それには十分な理由があります。クラウドコンピューティングを選択するのは、コストを削減するためではなく、より大きな価値を生み出すためです。

だからこそ、私はクラウドコンピューティングが「IT のキラーアプリ」と表現されるという考え方に賛成です。スプレッドシートが初期のパーソナルコンピューターを魅力的なものにしたのと同じように、クラウドコンピューティングだけでも IT 投資のコストを上回る可能性があります。

組織がクラウドコンピューティングを最大限に活用できれば、市場投入までの時間、イノベーション、俊敏性を向上させることができます。

企業によっては、クラウド導入に関連して目に見える唯一の指標であり理解できる指標であるクラウド料金にこだわりがちですが、それは苦痛を伴うものです。価値実現速度などの成功指標は測定不可能ではありませんが、確立して評価するには意識的な努力が必要です。

実験を優先し、成功の基準を把握すれば、クラウドコンピューティングの価値がコストをはるかに上回ることがわかります。

4. 小さく始めようが、準備不足にならないように

クラウドコンピューティングの待機期間が数か月、あるいは数年に及ぶことはよくあります。 Andy Jassy 氏は最近の re:Invent 基調講演で、クラウドコンピューティングを誇示しながらも、実際には小規模なパイロットしか展開していない組織を指摘しました。このアプローチは技術チームの履歴書には良いかもしれませんが、ビジネスにとっては何の価値もありません。

クラウドコンピューティングを初めて導入するときには、うまくいかないでしょう。しかし、その心配で最初の一歩を踏み出すのを止めないでください。適度なワークロードを選択し、それをクラウド上で実際に実行してみて、問題点を見つけ出し、改善し、それを繰り返して、クラウドコンピューティングに関する知識を広げ続けます。

クラウドコンピューティングを真剣に受け止めれば、大きな成果が得られます。

写真

5. パートナーを信頼する

企業がクラウドコンピューティングの入り口で何ヶ月、あるいは何年も立ち往生してしまう理由は何でしょうか?彼らは、変化は複雑になる可能性があることを認識しており、間違った変化を望んでいません。

このため、クラウドコンピューティングへの移行には、信頼できるパートナー、つまり、以前に同じ道を歩んだ経験があり、落とし穴と近道の両方を知っている人々を加えることが理にかなっています。

(ちなみに、これはパブリッククラウドを支持する良い議論でもあります。AWS よりも優れたデータセンターを管理したり、Microsoft よりも優れた開発者ツールを構築したりできると本当に思っていますか? ロックインに関する懸念は歴史的に正当化されており、その存在意義もありますが、最終的にはリスクを適切に活用できるベンダーと協力する必要があります。)

信頼できるクラウドコンピューティングおよびコンサルティングパートナーを見つけ、永続的で前向きな変化の実現を自由に支援してもらいましょう。

写真

タイプ2 : 技術意思決定者向け

6. 個人的な好みに基づいてテクノロジースタックを選択しない

テクノロジーに関する決定には、よくあるアドバイスがあります。それは、ほとんどの問題に対して、時の試練に耐える長年の解決策を採用すべきだ、ということです。別の Rails アプリを書いたとか、そういう理由で解雇された人はいません。

このアドバイスは、大きな破壊的な飛躍が起こらない世界では意味をなします。しかし、クラウドコンピューティングでは、新しいテクノロジによって、管理する必要があるコンテンツの量が大幅に削減され、提供するインフラストラクチャの規模と機能が向上するため、状況は変わります。

たとえば、AWS の Amplify サービスは、モバイルとバックエンドのリアルタイム開発において大きな進歩を遂げました。 API 開発に対するローコードでパターン重視のアプローチは間違いなく優れています。クラウドネイティブデータストアとの緊密な統合がさらに強化されました。また、AppSync バックエンドはクラウドサービスであるため、ユーザーが何もしなくても時間の経過とともに改善され続けます。完全に慣れるまでには数週間かかるかもしれません。しかし、この場合、学習に時間を投資することの報酬は永続的です。

重要なのは、あなたの感情があなたを裏切る可能性があるということです。どのツールやサービスが最大のメリットをもたらすかを冷静に評価する必要があります。

写真

7. 時間は最も貴重な資源です。最適化する

毎日触れる最も高価なリソースは、運用データベースクラスター、アプリケーションサーバーファーム、またはログ記録フレームワークではありません。それはあなたのスケジュールです。

あなたとあなたのチームには、テクノロジーを構築し、維持するための時間枠が限られています。車輪の再発明に時間を無駄にしないでください。

残念な個人的な例として、私は以前の仕事でフルスタックのデプロイメントフレームワークとパイプラインツールをゼロから構築するのに多くの時間を費やしました。最終的に、このデプロイメントパイプラインはビジネスに一定の価値をもたらしましたが、それには何千時間ものエンジニアリング時間の犠牲が伴いました。

私と私のチームが既存のクラウドサービスにもっと依存していれば、同じ機能を短時間で完了し、経営陣に自分たちの作業内容を常に説明する必要なく、より価値の高いプロジェクトに取り組むことができたでしょう。

クラウドネイティブ開発では既製のサービスを使用することに重点が置かれているため、スケジュール内で貴重な時間がさらに確保されます。

写真

8. クラウド上での構築を早めに開始します。いいえ、それより少し早いです。

私は「ローカルでコードをテストし、クラウドでサービスをテストする」という考え方を推奨してきました。サーバーレス開発がテクノロジースタックの上位に進むにつれて、クラウドから独立したローカル開発環境を維持する価値は低下します。

必要な場合は、ローカルでコードを反復処理します。リモートスタック (当然ながら本番スタックではありません) にデプロイされたロールとリソースでテストします。開発ライフサイクルの早い段階でこれを行うほど、権限や構成の問題が早く発見され、運用中に予期せぬ問題が発生する可能性が低くなります。

これを最もよく理解しているベンダーは Stackery だと思います。「クラウドローカル」開発という彼らのコンセプトは本当に気に入っていますが、その名前が流行りそうにない気がします。彼らのコマンドラインツールは、現在 AWS Lambda 関数をローカルで実行し、クラウドにデプロイされたバージョンに関連付けられたロールを使用することをサポートしている唯一のツールです。 (ローカル関数を呼び出すと、そのロールに信頼が注入されます。) AWS SAM や Serverless Framework などの他の主要なサーバーレスデプロイメントフレームワークも、まもなくこれに対するより優れたサポートを提供すると予想しています。これが今後の発展の傾向です。

写真

9. 偽の質問は無視する

偽りの問題をでっち上げなくても、職場には現実の問題が十分あると考えるかもしれません。残念なことに、ソフトウェアエンジニアは、実際には重要ではない問題の解決策を見つけるのが非常に得意です。

たとえば、アプリケーションは本当に複数の領域にまたがる必要があるでしょうか? AWS 米国東部リージョン全体がダウンした場合でも、アプリケーションは利用可能な状態を維持する必要がありますか?複数のリージョン間でトランザクションの一貫性を維持するためにどれくらいの時間を費やすでしょうか。また、時々短時間正常にシャットダウンする代わりに、データの複製にどれくらいの時間を費やすでしょうか。

移植性は大きな誤った問題です。誰かが言ったように、Kubernetes を使用する場合は賢くなければなりません。これは要件であり、褒め言葉ではありません。サービスネットワーク、サービスプロキシ、イングレスルーティングなどを調整するのは非常に複雑なタスクです。

別のクラウドプロバイダーを選択する必要がある場合にテクノロジーを即座に切り替えられるように、サーバーレスアプリケーションで複雑な抽象化レイヤーを設計している人も見かけます。

本当に賢明なテクノロジーの意思決定者は、自分が得意とできる分野の範囲が非常に狭いことを理解しています。クラウドサービスを活用して、すぐに運用に耐えるアーキテクチャを導入し、その上に独自の機能を構築します。

Kubernetes を使用する必要がある場合は、面倒な詳細の多くを隠してくれる (そして非常に安価なスポットインスタンスでコンテナをスケジュールできる) Fargate 上の EKS や SpotInst Ocean などのマネージドサービスの使用を検討してください。

言うまでもなく、クラウドサービスプロバイダーとより緊密に統合することで、多くの利点が得られます。クラウドサービスプロバイダーが略奪的な価格設定を固定することを示すまでは (今のところそのようなことは起きていません)、機能の提供に時間を費やしたほうがよいかもしれません。

私の意思決定プロセスはシンプルでした。コードだけに焦点を当ててクラウドを無視しないことです。

写真