お疲れ様です！
最近AWSのサービスが終わるの終わらないのがXなどで話題ですね！
Jeff Barrさんは以下のようにおっしゃっています。
このポストから具体的にはこれらのサービスが対象になるようです。
- S3 Select
- CloudSearch
- Cloud9
- SimpleDB
- Forecast
- Data Pipeline
- CodeCommit
特にCloud9はよくハンズオンに使うインタフェースに使うのに便利だったので惜しまれる声をよく耳にしました。
（これは関係ないｗ）
そんななか、なんとなくサービスの終了とどう向き合っていくのかを考えてみたくて今Blogを書いています。
それではいきましょう。
サービスをずっと続けてほしい！
その気持ちは非常によくわかります、先程のCloud9だったりもそうですし、CodeCommitはAWS環境の中で使える唯一のGitのサービスですし、Data Pipelineも意外にあるユースケースだと便利みたいな事があったりしました。
ですが、サービスは今後新規導入を行われないという結論になったようです。
ここででてくるのは「なんでこんな良いサービスがなくなっちゃうの？」とか「いやいや、考え直してほしい」とかだと思います。
ずっと続けることはもちろん可能だと思います。でも自分はサービスは終了したほうが良いと思ってます。それは今までB2Cでサービス運用するなかでも体験してきたことです。
サービスを続けることのデメリット
サービスを続けるということはやらなきゃいけないことがある、ということです。例えばもう新しい機能は追加しない放置しよう！となったサービスがあったとします。放置しましょう。何がおきるでしょうか？
セキュリティホールから侵入される？サービスダウンでユーザからクレームがくる？使ってるAPIの仕様が変わって対応しないといけない？それこそ使っているクラウドサービスがサービス終了するかもしれません。
セキュリティ対応は急に来ます。サービスが落ちたら対応するのも人は張り付かないといけません、クラウドサービスが無くなったら新しいものを検討しないと、、、何より動いている時点で、クラウドリソースの料金も人的コストも掛かっています。
これでは放置ではないですよね？実際サービスが外向けに動いている以上放置するという選択肢は無いわけです。
イノベーションのジレンマ
イノベーションのジレンマとは、ハーバード・ビジネス・スクール（HBS）の教授であるクレイトン・クリステンセン氏によって提唱された理論で、業界トップシェアである企業が、既存事業の拡充や強化に注力するあまりに、新たな技術やビジネスモデルに乗り遅れてしまい、結果的にトップの地位から陥落する現象を言います。
名前だけは聞いたこともあるのではないでしょうか？（ぼくもBlog書くにあたってLLMさんにききましたｗ）
そしてイノベーションのジレンマの一つの理由として選択と集中ができないことだと自分は思います。同じようなサービスをいくつも持って、でもどのサービスも大小ユーザが居るがゆえにやめられない、ユーザは少ないけど少しだけいるからやめられない、それは上記した理由により非常に小回りが利かなくなります。
それを解決するには選択と集中を行う事です。重複しているサービスを減らし、より有用なサービスを残す事をしていかなければならないのです。
実はAWSも色々なサービスを終了したり利用を制限したりしています。以下は一部です。
- Amazon Sumerian
- Amazon Lumberyard
- Amazon SimpleDB
- AWS OpsWorks
- Amazon Honeycode
- AWS CodeStar
- AWS IoT 1-Click
- AWS DeepLens
- Amazon QLDB
これらサービスを終了することでそのリソースを他に向けていく、それは生存戦略として必要なことだと思います。
これはこれからもAWSが強いAWSであるために必要なことなのかなーと思っています。
どんな終わり方がいい？
とはいえ、大事なのはコミュニケーションだと思います。
何も言わずにシュッといなくなる、それはオーナーシップの欠如だし、誠実ではないですよね。ビジネスである以上、何をどういつまでにおこなって最終的にどうなる、みたいなものが出てこないとユーザは何をしたら良いかわからなくなってしまうと思います。
やり方が良かったかはわかりませんが、新規ユーザを制限する、という事をまず行ったタイミングが悪いのと、サービスが愛されていたがゆえに盛り上がってしまったのかなと思います。
多分、AWSの人たちは情報を出さないという話ではなくて、現状もどこに落ち着いたら良いのかを考えていると思っていて、結論がでたらそれを共有してくれるのだと思っています。
早く安心できるアナウンスがあると良いなと思います！
システムアーキテクチャとサービス終了
それではシステムアーキテクチャの中でサービス終了とどう向き合うかですが、考えていても難しいな、、、という印象はあります。
ただ、やはり言えるのは定期的に使っているサービスの将来性については考えるべきなのかなと思いました。
先程までお話した、例えば「重複した機能があり、古くなっているサービス」「あまりアップデートのないサービス」等といったサービスはそうでないサービスに比べてサービスが制限される可能性が高いという事を考える必要があり、定期的にそういうサービスを乗り換えていくような動きをする必要があるのかもしれません。
例として前述のCloudSearchであれば、OpenSearch Serviceへの移行を検討する必要があったのかもしれないですし、Cloud9はCloudShellや、各種Notebookの様なサービスで同じことができるようにしたほうが良かったのかもしれません。
ポータビリティがあげられるものとデータストアのようなポータビリティが上げづらいものはあるかもしれませんが、だからこそそういったことも考えて常日頃から棚卸ししていくことは有用なのかもしれないな、と思った次第です。
そんなこんなで
ここまでサービス終了についてお話ししてきました。明けない夜はない、落ちないサーバもないし、終わらないサービスもありません。その前提で今後のシステム構築をどうして行ったら良いか考えていくのも良いかもしれません。
そんなこんなでちょっとさみしい気分の中終わろうと思います。
ではでは！
256bitのミステリ世界 
コメントを残す