クラウドとベンダーロックインの問題
クラウドに関する記事が出ているようなので一語り。専門ですからね。
ベンダーロックインは「Lock in(固定)」という言葉から、一度はまってしまうとベンダーを一切変更できないように考えてしまいがちですが、これは単にスイッチングコストの問題でしかないと、Vacation Trackerは指摘。Amazon Web Service(AWS)のエンタープライズストラテジストであるマーク・シュワルツ氏も「Switching Costs and Lock-In」という記事の中で、「『ロックイン』という用語は誤解を招くと考えています。本当に議論しているのはスイッチングコストについてです」「スイッチングコストはこれまでのITの歴史上でも存在しました。プラットフォームやベンダーを後から変更しようとすると、スイッチングコストが発生します。例えば、Javaを選んでからNode.jsに移行するとコストがかかります」と述べています。
本当にこの世の中は議論のすり替えが大好き。私の全細胞が総反論したい。ベンダーロックインは誤解でスイッチングコストなのだ、とは言いますがこれは表現がおかしい。スイッチングコストそのものがベンダーロックインなのです。
そして、別にクラウドサービスだけではなくオンプレミスでもベンダーロックインはあったよねということも、これもYesです。
ただし、クラウドサービスはそのクラウドでしか使えないPaaSを宣伝しがちなので、ロックインされがちであることは覚えておくべきでしょう。
ロックインされない思考
まず大前提として、どんなにPaaSを駆使しようが、インフラ（クラウドならIaaS）の上で動いているということをしっかり頭に刻みましょう。
インフラに依存しないコーディングを。アプリケーション開発者はいつもこの話題を夢見るのですが、これはおかしいです。地球に依存しないで生活するって言っているのと同じです。どこにいっても地面があり、空気があり、空や海があるのです。インフラを抽象化したってインフラのことを忘れてはいけません。
都会に済んで、土や地下水のことを忘れても、自然災害はやってくるのです。
昨日、Classmethod社の技術ブログで、サーバーレス開発部が推奨した技術書が記事になっていたのですが感心しました。
先日、サーバーレス開発部のSlackチャンネルで、おすすめの技術書を紹介してくれという雑なポストをしたところ、すごい勢いで技術書が流れてきたので、保存する意味も込めてブログにまとめてみました。
おすすめ理由については、サーバーレス開発部の方々に直接聞いたものを載せています。
サーバーレス開発なのに、インフラのことを知っておかなければいけない。ここが非常に重要なポイントです。インフラを抽象化したはずなのにインフラを知る必要があるということの理由はどこにあるのかを次に説明します。
まずは、冒頭の「ベンダーロックイン」「スイッチングコスト」への対応です。AWSでサーバーレスに開発できることはとても便利ですが、だからと言ってAWSがないと使えない技術にはしてはいけないということです。必要であれば別のクラウドサービスでもオンプレミスでも動作させることができることを意識することにより、盲目的な設計をしなくなります。もし、AWSじゃなかったらどうする？、これを意識することにより、なぜAWSを使うかという理由もはっきりします。これは他のクラウドサービスでも重要な視点です。さまざまなクラウドサービスがあります。そして同じような機能を各社リリースしています。最後に何が差別化されるかというと開発のしやすさとともにサービスレベルが関係してきます。サービスレベルはインフラの話無しには成り立たないのです。マルチゾーンに対応しているか、冗長性が担保されているか、スケールアウトの対応は。どんどんインフラの話に突っ込んでいきます。結局、建物の話をしようとしても地面の話は必ず出てくるのです。だから、ロックインするのは「クラウド」ではなく、利用する人の「心」です。心がロックインされないために、インフラの話が重要となってきます。
次に、本番運用を前提として、障害対応や異常動作解析のために重要であるという点です。教科書通りに作っても教科書通りにならないことがよくあります。その理由がインフラにある可能性は絶対に捨てられません。そうした場合インフラをマネージドするクラウドサービスに問い合わせや相談をする必要がありますが、インフラの知識がないと理解がおぼつかないのです。サーバーレスで作ったシステムで想定外の動作が発生したとき、エンドユーザーに理由を説明しなければいけませんよね。クラウドサービスの不具合、とだけしか言えないサービス提供者になってしまいます。そして理由もわからず不満だけを持ち、別のクラウドサービスに移るジプシー開発者になってしまいます。きっと安住の地は見つからないでしょう。土地を知り空を知り海を知り気候を知る。そうすればロックインされない思考ができるようになり、スイッチングコストが低いサービス提供者になれます。その土地に合わせた実装ができるようになるのです。おなじ都市であっても、東京に家を建てるのと、ドバイに家を建てるのは違うのです。
DockerとArmの提携の話で、AWSが出てきた件
クラウドサービスではどんどん革新的なサービスが開発されるのですが、例えばこういうニュースも気を付けて読む必要があります。
Dockerの戦略的提携担当エグゼクティブバイスプレジデントであるDavid Messina氏は米ZDNetに対し、次のように説明した。「x86チップ搭載のノートPCでも、コンテナの作成や共有、実行などに関して、開発者がDockerについて知っているすべてのコマンドがArmで利用できるようになった」
また、アプリケーションをプロダクション環境に持っていく準備が整ったら、開発者はArmベースの「Amazon EC2 A1」インスタンス向けのセキュアな「Docker Enterprise Engine」を利用できるようになる。これにより、企業はArmでクラウドネイティブのアプリケーションを実行する際に、コードを書き直す必要なく、x86ベースのアーキテクチャと比べて最大45％の費用を節約できる。また、開発者はDockerから商用サポートを受けられる。
ArmはCPUの話で、Dockerはミドルウェア（ただしOSのような機能も持つ）の話です。そこにAmazon EC2が割り込んでくるのですが、Armが動くIaaSはまだAWSしかありません。
もし、45%安くなるぜ、アプリの作り直しいらないでコンテナがそのまま動くぜ、ということで安易に使ったとします。
そしたら、Arm独特の問題が仮に発生したとします。もしくはArm基盤のDockerでは動くがx86に持っていくと動きが変わってしまうことが想定外にありえたとします。
これが真のロックインです。例えばArmの仮想サーバーが他のクラウド環境にも広まっていくとしたらこれはそちらに動かせるでしょう。もしくはオンプレにもArmのサーバーの波が来るかもしれない。
この辺りの状況を何にも考えず、45%安いしAWSだし大丈夫だろうという思考をしようなら、たちまちロックインされてしまうと思います。そうやってクラウドサービスを付き合っていくことこそ、「ロックインされない思考」だと思います。
まとめ
私はAWSの領域では生活していないですが、だからと言ってAWSも使えるようにする準備もしていますし情報も入手しています。オンプレミス然りです。インフラでもアプリケーション開発でも、この「ロックインされない思考」こそ重要です。
