リー・アチソン は、クラウドコンピューティングで業界の思想的リーダーとして認められており、大規模なクラウドベースのサービス指向のSaaSアプリケーションの設計と構築に豊富な経験を持っています。元NewRelicのクラウドアーキテクチャ担当シニアディレクターであったLeeは、現在、 Atchison Technology LLC, クラウドコンサルティングおよびアドバイス会社。 Leeは、O’ReillyMediaから出版された本「ArchitectingforScale」の著者でもあります。第2版が利用可能になりました ここ.
OpsRamp: の初版を公開しました スケールのための設計それ以来、デジタルアプリケーションの開発と管理に関して最も変化したことは何ですか。
LA: 圧倒的に最大の変化は、クラウドでのサーバーレスの受け入れです。サーバーレスは当時は目新しいものでしたが、今ではもっと受け入れられています。もう1つの変化は、AWS以外のクラウドサービスの成長です。 2016年、クラウドはAWSを意味しました。しかし今、私たちは本当に実行可能な競争相手を持っています。 Azureは非常に実行可能であり、EUでより人気があります。私は特にIBMに興味をそそられます。IBMは、ハイエンドのエンタープライズクラウドのニーズに対応できる可能性があります。彼らはインフラストラクチャとビジネスフレームワークを持っています。彼らは成功するために秘密のソースが必要です。また、2020年には、100％クラウドに移行するという考えがより現実的になりつつあります。クラウドは現在の戦略であり、規制対象の業界でさえこのように動いています。
OpsRamp: ITチームはどのような教訓だと思いますか& エンジニアリングVPは、このクレイジーな時期に今学んでいますか？
LA: 自宅で仕事をすることは容認でき、実際にリモートでビジネスを行うことができるという哲学全体は、認識の大きな変化であると思います。技術グループでは、文化に参加するためにオフィスにいる必要があるという隠されたメッセージがありました。しかし、自宅での作業は予想よりもうまく機能しており、長期的にはリモートワークがより受け入れられるようになるでしょう。これにより、ITのサポートの問題が発生します。危機に瀕しているものがはるかに多いため、協調プロセスをより完全に標準化する必要があります。ワークフローとチームおよび管理プロセスは、より正式で、アドホックではない必要があります。リモート接続を追加すると、人とのやり取りの方法が変わり、より正式なプロセスが必要になります。
ウイルスが4年前に私たちを襲った場合、私たちはリモートワークの準備ができていなかったでしょうが、今では、アプリケーションはクラウドでの分散ワークロードを可能にします。"
過去数年間にクラウド向けにアプリを最新化するために行った作業により、リモート作業のサポートが容易になりました。ロジスティクス業界について考えてみてください。 私たちもその準備ができていました。このパンデミックの間、私たちは大規模な食糧不足はありませんでした。 確かに、トイレットペーパーのようないくつかのジャストインタイムで製造された製品にはいくつかの不足がありました。 しかし、20年前には、システムや構造の変更、輸送や宅配のインフラストラクチャに十分な速さで対応することができなかったでしょう。
OpsRamp: 私はあなたの「可用性の低下の5つの原因」に興味をそそられました 最新のデジタルアプリケーションポッドキャスト. それらは、リソースの枯渇、土壇場での修正、厨房での開発者の多さ、サードパーティの統合、および技術的負債です。どれを防ぐのが最も難しいですか、そしてそこに何かアドバイスはありますか？
LA: 対処しなければならない根本的な要因は次のとおりです。ほとんどのアプリケーションが失敗する理由は、成功のためです。組織は成功する準備ができていません。より多くの顧客を持つことは、より高い期待を生み出します。じゃあ何をすればいいの？ストレステストはある程度しか役に立ちません。顧客が何をしているかを真にシミュレートできることはめったにありません。予期していなかったことが原因で成功しました。答えは、可用性の文化に焦点を当てることです。システムを構築するときは、特定の制限があるシステムを構築しないでください。
すべての作業で可用性とスケーラビリティを常に計画するには、特定の考え方が必要です。もちろん、これを行うとプロジェクトに時間とコストがかかるため、トレードオフがあり、適切なバランスを見つける必要があります。」
しかし、品質、スケーリング、高可用性の文化がある場合、これの多くは自然に発生します
OpsRamp: そのような文化のいくつかの信条は何ですか？
LA: 私は本番環境でのカオステストの大ファンです。カオステストは、Netflixによって最初に普及しました。 カオスモンキー。 本番アプリケーションの実行中は、コードを実行してダウンさせようとします。これは、顧客がサイトを使用しているとき、およびピーク時でもこれを行います。これを継続的に行い、システムを破壊しようとします。これにより、アプリケーションが成熟します。問題が発生した場合、システムはそれ自体で問題を解決できるほど十分に自己回復します。その考え方をアプリケーションに組み込む必要があります。ソフトウェアに問題を引き起こしてそれらを修正すればするほど、ソフトウェアは将来の問題に対して回復力を持つ可能性が高くなります。はい、停止が短い場合がありますが、後で大きな停止が発生する場合に比べて小さいです。大きな問題を防ぐことを目的として簡単に修正できる小さな問題を強制的に発生させることです.
OpsRamp：最近のDevOpsについてどう思いますか？これは全体的に前向きな傾向でしたか？
LA: レーベルDevOpsは悪いラップを得る可能性があります。哲学とプロセスは、カオステスト、サーバーレス、クラウドの成熟度、継続的インテグレーションなど、これまで説明してきたすべてのプロセスと一致しています。私の本では、STOSAについて話します(単一チーム指向のサービスアーキテクチャ), これは、サービスの所有権が組織全体でどのように機能して、より良い所有権を促進するかについてのモデルです。これは、DevOpsの基本原則に基づいています。＆nbsp;そして今、DevOpsが危機の時に本当に役立つことがわかりました。過去により機敏であった企業は、Covid-19の間に、より敏感になることができました。注意すべき重要な点は、DevOpsは上級管理職がアプリについて考える方法を変えることもでき、組織全体をより機敏にすることができるということです。これにより、新しいビジネスモデルを迅速に開発できます。これは、多くの企業がここ数か月で行う必要がありました。私に影響を与えているのは、DevOpsが企業の考え方でアジャイル思考を推進していることです。これは、アプリケーション開発に対するDevOpsの影響よりも全体的に重要です。
OpsRamp: あなたの仕事であなたにとって最もエキサイティングなことは何ですか？それはあなたが困難な時代を通してあなたをやる気にさせ続けることですか？
LA: 私の本を読んだり、私の話を聞いたりした人が戻ってきて、私が話し合ったテクニックが問題を解決するのに役立つと私に言ったとき、私はそれが大好きです。これらは非常に基本的な概念であることが多く、誰もがそれらについて深い知識を持っているわけではないことを忘れることがあります。私が教えていることが組織に良い影響を与えていることを知ってとてもうれしく思います。
次のステップ:
- ゲストインタビュー： Covid-19の次の段階でのITの管理
- デジタルトランスフォーメーションのためのIT運用の成熟度の向上
- Learn どれだけ節約できるか OpsRampで。