ちなみにいつも説明してますが、一般的なパブリッククラウドサービス間でのポータビリティと、旧来のオンプレミスやプライベートクラウドともポータビリティを担保するのでは、システムの作りによって、難度が違うと思います。

例えば、Lambdaは1度の実行可能時間は15分です。今まで60分以上のバッチ処理があれば、分割して実行する仕組みが必要です。これが従来とのポータビリティに差が出る部分です。

でもこれはEC2で実装していれば、従来とのポータビリティは最小化できる。これがいわゆる仮想マシンやコンテナで抽象化するという理屈ですね。

そして、この15分という縛りがAzureやGoogle Cloudでは異なるというのがパブリッククラウド間でのポータビリティに影響する部分です。このタイムアウトのお陰で、Lambda上でいう関数を細分化する必要があり、大規模なシステムであればこの膨大な数の関数の管理に苦労することになります。

また、AWSで言えば、S3イベントトリガーを使ったりしていると、他の環境に移行する際に、独自で実装しないといけないです（他のパブリッククラウドでも同様のものがある場合は置き換えしやすくなると思いますが）

パブリッククラウドを使うといっても、使い方でポータビリティの難易度が変わるのがコードを書いたりしてないと理解しづらいところだと思います。
・パブリッククラウドでモダン化していると、他の環境に移行するにはコードの修正が必要
・パブリッククラウドを使うけど抽象化レイヤーが入っているとシステムポータビリティが高い

システムとしての在り方だけでなくて、IAMなどの認証系も大きな縛りだと思います。IAMで作り込んだ権限管理を他のクラウドに持っていくのは本当に骨が折れるはず。今まではActive Directoryなどで、ネットワークさえ繋がっていれば認証できるという世界だったものの、IAMとなると基本的にはクラウド内に特化した権限管理になるので。

他にも色々要素がありますが、1つのことにフォーカスするとこんな感じでしょうか。 December 12, 2025

@JnFurukawa クラウド(Azure)ですね
教えていただき、ありがとうございます December 12, 2025

必要な時だけサーバー増やして、
いらなくなったら減らす。

ゲームの運営視点で見たら、一気に腑に落ちた🎮️

#Azure学習 December 12, 2025