ロックインコスト

最近のクライアントエンゲージメントにおいて、サーバーレスアーキテクチャが最適であると予測しました。しかし、ベンダーロックインへの懸念から、クライアントはサーバーレスアーキテクチャの採用に難色を示しました。小売業界にとって興味深い時期であり、AWSにとどまることは、Amazonという別の小売企業に競争優位性を与える可能性があることを意味します。競合他社を支援しないという考えから、クライアントは私たちが選択するソリューションが他のクラウドベンダーにも完全に移植可能であることを確認することに関心がありました。

技術的な観点から見ると、システムをあるプラットフォームから別のプラットフォームに移行する能力を確保することは間違いなく望ましいことです。コンテナ化の台頭により、特定のプラットフォームにロックインされることに関心を持つ理由は何でしょうか？高いロックインコストは、別のプラットフォームに移行することを決定した場合に、ビジネスに示したいものではありません。したがって、このようなシナリオが発生した場合、移行コストを可能な限り低く抑える必要があります。現在の理解に基づいてロックインコストの簡単な式を作成するならば、次のようになります。

ロックインコスト = 移行コスト (?)

この式は、技術的な観点からのみ見ている場合に正しいです。しかし、ビジネスの観点は見過ごすべきではありません。私たちが提供する技術ソリューションは、常にビジネス上の問題を解決するために設計されていることを忘れないでください。多くの場合、特定のテクノロジーを採用することでビジネスは利益を得ます。重要なメリットの1つは、市場投入時間の短縮です。市場投入時間の短縮は、機会獲得として定式化できます。

ロックインコスト = 移行コスト - 機会獲得

機会獲得は、未知の未知の要素を扱っているため、測定が非常に困難です。移行コストは分析および推論できます。一方、機会獲得は分析が容易ではありません。あるプラットフォームから別のプラットフォームへの移行方法を理論化および分析できますが、競合他社の市場機会を奪取することによる利益をどのように計算しますか？技術的およびビジネスの両方の観点から包括的な視点で意思決定プロセスを検討することにより、下すロックインに関する決定は利益をもたらす可能性があります。

イベント駆動型アーキテクチャの構築例を見てみましょう。アーキテクチャでは分散メッセージングシステムを選択する必要があります。既にAWSをプラットフォームとして選択している場合、Kinesisなどのベンダー固有のサービスを選択できます。これらのサービスは完全に管理されており、すぐに実行できます。そのため、機会獲得が得られます。Kafkaなどのベンダー非依存システムと比較すると、これらのベンダー固有のサービスでは移行コストが高くなります。しかし、独自の分散メッセージングシステムをセットアップするには、特にそのようなプラットフォームの構築経験がない場合は、本番環境で使用できるようになるまで、強化に多くの時間を要します。移行コストだけを見るのではなく、システムをより適応させることで移行コストを削減する方法に焦点を当てましょう。クラウドの使用例では、これがジェネリッククラウドの使用の実践を避けることを推奨する理由と同様です。