見出し画像

マネージドサービス最大のリスクと技術的負債の貸し剥がし

一応サーバつながりですが、アイキャッチ画像と本文と関係ありません。とてもかわいいから使いました。

技術的負債の返済計画とそれを妨げる外部要因

今は「技術的負債」をただ減らせばよいものではなく、資本政策の負債と同様、事業の段階によって借り入れと返済を行なっていきましょうという流れになってきました。(たぶん)

しかし、今は負債を返済しない時期だと思っても許されないことがあります。いくつか要因はあると思いますが、一つがマネージドサービスのサポート打ち切りです。

去年AWSのRDSでMySQL 5.6のサポート終了と、5.7への強制バージョンアップ計画が発表されました。

Amazon RDS for MySQL バージョン 5.6 のサポート終了のお知らせ | Amazon Web Services

当初のアナウンスでは2021年9月から実施予定でしたが、結局2022年3月に延期されました。MySQL5.7移行が困難な利用者が多かったのは想像に難くありません。

Amazon RDS for MySQL バージョン 5.6 サポート延長のお知らせ | Amazon Web Services

自分たちでMySQLサーバを運用しているなら、このままMySQL5.6を使い続けられます。EOLを過ぎたソフトウェアを使い続けるのは技術的負債ではありますが、「今は時期が悪い」と思うならいつまでも引き延ばせます。(それがいいとは思いませんが)自前運用なら未だにMySQL5.1(それ未満でも)を稼働させ続けられるでしょうし、実際そうなっている環境もありそうです。

一方RDSのようなマネージドサービスでは認められません。サービス提供業者が提供を打ち切るなら、嫌でもバージョンアップが発生します。RDSを例に挙げましたが、Lambdaでも古い実行環境のサポートが打ち切られています。打ち切られた言語バージョンは、新規作成どころかコードの修正すらできなくなります。(さすがにリリース済みのアプリは動き続けますが)
ランタイムサポートポリシー

したがって、今は機能開発に注力したいと思っても強制的に技術的負債の返済を求められるケースが出てくるわけです。いわば「技術的負債の貸し剥がし」と言えるでしょう。技術的負債の貸し剥がしなる言葉があるかどうかはわかりません。最近思いついていい感じの表現に思えたので使ってます。

ただ実際の貸し剥がしとは違って必ず予告があります。言語やソフトウェアのEOLはあらかじめ公開されており、それを過ぎたら開発や修正が打ち切られると発表されています。にも関わらず機能開発やバグ改修に追われていると、EOLなどなかったかのように錯覚することがあります。EOLを認識していても、引き続き利用できると勘違いするケースも多いでしょう。

マネージドサービスの本当のリスク

マネージドサービスのリスクとして、ベンダーロックインが指摘されることが多いと思います。ですが、移行コスト(とても高いかもしれない)を払えば抜け出せるでしょう。あくまでその決定は利用者が行えます。

一方EOLによるサポート打ち切りは利用者の意向とは何の関係もなく、外部要因だけで決められます。そのため利用者にはバージョンアップ時期の決定権がありません。マネージドサービスを使う場合、バージョンアップ時期の決定権をサービス提供業者に渡してしまっていると認識すべきでしょう。

このことから、マネージドサービスを使う最大のリスクはベンダーロックインではなく、技術的負債の返済スケジュールを必ずしも自分で決められない点にあると考えています。

逆に捉えると、技術的負債返済のペースメーカーにもなります。自分たちで運用すると、いつまでも動かせてしまうがゆえに、バージョンアップのモチベーションが出ないのはよくある話です。バージョンアップしなくてもいちおう動くので、開発者以外にとってはメリットが見えない可能性があります。そのため、経営層に合理的な説明ができないケースも出てくるでしょう。それが強制的にバージョンアップされるとなると、誰もが喫緊の事業リスクと認識できるので、対応工数を使う合理的な説明になります。

マネージドサービスとの付き合い方

マネージドサービスでは、使っているバージョンをずっと使い続けられないことから、EOLへのアンテナを高く張る必要があるでしょう。その上で上記RDSやLambdaのような例を挙げて、「EOLを過ぎたら利用できなくなる」と常に説明しつづけないといけません。かといってマネージドサービスを使わない運用も難しいでしょう。ソフトウェアバージョンアップに工数をかけられない組織が、アンマネージドなサーバをきちんと運用できる可能性は低いと思います。なので特性を理解した上で技術的負債返済のペースメーカーにするのが健全な開発ではないでしょうか。


この記事が気に入ったらサポートをしてみませんか?