Do modern cloud applications lock you in?

Pulisher : Mass Migration & DR Center キル・ジュンボム
Description : 最新のクラウドアプリケーションの長所と短所についての紹介セッション

はじめに

最新のクラウドテクノロジを使うことがなぜ良いのか、そしてこれを必要なときにアプリケーションを他の側に移すのは難しいのかについてお話したいと思います。

セッションの概要紹介

最新のアプリケーションの近代化をVM > Container > Serverlessの順に考えています。 2つの領域で間違った主張ですが、第一に、コンテナとサーバーレスは別の技術であり、個別に活用することができます。二つ目は、自動化、CICD、観察可能な項目、管理型サービスなどを提供しないかもしれないので、現代的と呼ぶことができません。 再び、正しく言えば、アプリケーションのモダン化はクラウドを最大限に活用しているアプリケーションと言えます。クラウドの本来の目的に合わせて使用し、機能を最大限に使用/活用することです。 個人的にはこれをクラウドネイティブと呼びたいと思います。

しかし、今、モダンなクラウドアプリケーションは再定義されています。障害隔離のような機能を提供したり、機能ごとに細分化され、独立して動作し、スケーラビリティを可能にし、緩やかな接続で依存性を下げ、変更をシステム全体でテストすることなく変更することができます。イベント駆動され、運営上の変化に柔軟に対応して拡張/進化することができます。このような良いものを自由に適用する場合、欠点があるのか？という疑問が生じます。どのような代償を払うことになるのか、それがLock-inなのかという質問です。

‘心配しないでください、それは事実ではありません’と済ませられる質問ではありません。

このような質問は、善と悪を区別し、これが正しいか間違っているかを答えることはできません。 アーキテクチャとしてこれを見る方法は、決定を下し、結果の長所と短所を理解することです。 この状態で私たちができる強力な行動は、問題を様々な多くの次元に分けて分析することと、使用可能なソリューションの範囲を拡大することです。 これと合わせて、Lock-inコストおよび移行コストについて議論してみましょう。

一次元的な比較グラフでは、前述のモダンクラウドアプリケーションの定義によると、3つの領域が緑色でポジティブです。しかし、Lock-inが発生します。 どちらを選択しても最善の選択になるわけではありません。 一次元ではなく、多次元の分析が必要な理由です。

アーキテクチャは様々な次元で選択肢を分析し、決定を下す必要があります。白と黒、善と悪のような二項対立的な視点から離れ、より多くの次元のニュアンスを見て、長所と短所を見なければなりません。Y軸であるLock-inにも種類が多く、これをもっと詳しく見る必要があります。

通常、Lock-inというと、特定のベンダーにロックインされることだけを認識します。しかし、それは多くの次元のうちの1つに過ぎません。Lock-inというのは、切り替えにコストがかかるということです。製品にも転換コストがかかります。たとえ自分が作った製品であっても、それを離れようとするとお金がかかります。バージョンアップグレードも同じです。Kubernetesなどオープンソースのバージョンサポートが中止される場合、新しいバージョンにアップグレードする必要があり、設計、テストなど多くの努力が必要です。このような状況をサポートするためにAWSではExtended Supportというサービスを作りました。 とにかくお金がかかります。作業者のスキルセットも転換するには費用がかかります。いつも使っていた技術が慣れていて速いですが、新しい技術を習得するのに時間とコストがかかるものです。IT人は1と0で考えるのが好きですが、スペクトルはグレーゾーンが多く、バランス、Trade-offなど他の次元を一緒に考えなければならない問題です。

上記で見たコンバージョンコストを効用と比較して2×2で区分してみると、少し分かりやすくなります。効用性が高く、転換が容易な場合はSNSや携帯電話のような場合と言えます。このような場合は長期契約を締結し、契約が終わったら簡単に他の契約を探す戦略を使います。効用も転換費用も高い場合はAccepted Lock-inと呼ばれ、特定の転換費用がある場合、これを管理する方法についても議論が必要です。この位置は、コストを使いながら効用を得ることになるので、バランスが取れていると感じられます。許容されたLock-in状態は、利益が潜在的な転換コストより大きい場合があります。

このような二次元の分析は問題を財政的な側面でマッピングすることができ、様々な側面があることを知ることができるので、アーキテクチャが持つべき最初の戦略です。二つ目は、ソリューションの範囲を見て選ぶ段階で広いスペクトルを持って検討しなければならないということです。

従来のITは、開発チームがコードを渡すと、インフラストラクチャや運用チームがそれを引き受け、責任が完全に移るという感じでした。 このような方法は、クラウドに優しいものではありませんでした。 現代のプラットフォーム開発者、プラットフォームエンジニアは、アプリケーションチームをサポートし、より生産的にします。このようなマインドセットの変更が全体的な生産性を向上させます。伝統的に異なるレイヤーに分かれていたからといって、インフラ領域だけでアプリケーションの問題を解決しようとしないでください。

私たちが使っているクラウドプロバイダーのサービスを簡単に比較してみましょう。 ほとんどの領域で似たようなサービスを確認することができます。もう少し拡大してみると、同じではないことが分かりますが、各企業ごとに哲学と戦略、方向性が違うからです。 クラウドがコピーのように同じサービスを提供しないことは、ユーザーの立場でメリットがあります。選択肢が増えるからです。

クラウドプロバイダを選択する際に行うサービスマッピングは、クラウドサービスとプラットフォーム統合の重要な特性を無視するため、危険なアプローチです。

ソフトウェア空港で確認できる他のAPI Layerの下にある様々な言語をHarmonizationを通じてまとめて全ての言語を使うように、クラウドプラットフォームもAbstractionしてアプリケーションを上げて使うことができそうですが、実際はそうではありません。 他のことを追加で学ばなければならないし、これを広く使わなければならないので、時間と費用がかかります。他のプラットフォームで提供する似たようなサービスを一緒に使うことになると、全てのサービスがサポートする機能だけを制限的に使う必要があり、これはサービスの効用性が落ちる結果をもたらします。 このような妥協案を選択するのが正しいかどうか考えなければなりません。

決定のためのモデルはこうです。 転換しなければならない可能性と転換費用は0になることはできません。 そして、責任を減らす費用があるので、その努力は意味がありません。 そのため、投資した費用と責任費用二つの費用を合わせて中間領域を選択しなければなりません。 二つの領域を一緒に見る理由は、保険に加入するのと似ています。すべてを保障しすぎて高価な商品や保障項目がほとんどない安い商品を加入せず、中間領域の商品を買うというアプローチと同じです。

小さな反復イテレーションを作り、小さな部分でうまく機能することを確認する必要があります。 これは私たちがよく知っている概念に似ています。摩擦を減らすこと、在庫を減らすこと、敏捷性に関する価値のために製品を構築します。これは、ソリューションスペースがコンバージョンコストとスピードに影響を与えるためです。 コンバージョンコストは、使用するサービスの機能だけではありません。 それは、働き方に大きく依存します。

ロックインを恐れず、この種の問題を考え続け、再構築し、理解する必要があります。 実際はお金に関わることです。 何かが起こることに対する予測であり、鋭く考えなければならず、様々な側面からの分析を継続する必要があります。

わかりやすいアプローチは機能しません。 サービスをマッピングしたり、抽象化階層を使って進めること、分散システムを利用することなど、レガシーなアプローチは有効ではありません。

オープンソースを活用し、スピードを上げ、移行コストを大幅に削減することができます。精神的にロックインされることなく、デザインの意図を維持して意思決定を行う必要があります。

セッションを終えて

Rock-inを避けるためには、基本的にソフトウェア開発をよくしなければなりません。 速度も速く、パターンも使用し、アーキテクチャも良いものでなければなりません。 開発の原則があり、デザインの意図とパターン、自動化のレベルが高ければ、移行コストが最も大きな問題ではないでしょう。このようなすべてのオプションがよく検討されれば、Rock-inは分析可能で対応可能な脅威に過ぎません。