こんにちは、記事作成を1か月くらいサボタージュした、むっそでございます。
とかく資本主義社会は誘惑が多すぎて1つのことに集中するの激ムズです
(意志よわよわな自分を反省しています)
先日大学の友人(営業職)と久しぶりに会ったのですが、「クラウド技術の良さがさっぱりわからん」 みたいなことを言っておりました。
確かに開発者じゃないといまいちクラウドの凄さは分からないかもなぁと思って記事を書こうと思いました。この題材自体はN番煎じすぎてネットに記事はあふれかえってますが、開発者視点で話せればなぁと思います。
一応、出身大学は経済学部なので「IT分からなすぎてマジ卍」という気持ちも通ってきておりますし、すこしばかりお悩み解決的なことはできるのではないかなと思います。
はじめに
非エンジニア視点でクラウドの良さが伝わるように書きたいと思うのですが、非常に残念なことに 知識の呪いみたいなやつはどうしてもあって、初心者時代はあんなに悩みまくっていたのに、慣れのせいでその気持ちを忘れてしまいものすごくわかりにくい説明をする可能性がありますので、コメントとかいただければ修正したいと思います。
まず プログラマー/システムエンジニアも一応人間なんですよ？ っていうところのアプローチから始めて、彼らの生態や特徴、そしてどんな仕事をしていてどんな問題を抱えているフレンズなのかを見ていくことにしましょう。
ちょっと寄り道しているように見えますが、最終的には クラウドをうまく使えばみんなハッピーになれます というところにつながります
(新興宗教じゃないです、シャ〇漬けもしません)
プログラマー/システムエンジニアのとくちょう
プログラマのイメージとして陰キャでドゥフフフって笑いながら独り言言ってそうなイメージがあるかもしれないですが大体以下のようなとくちょうを持っているのかなと思っています。
プログラマー三大美徳
プログラマーの美徳としてよく言及される怠慢、短気、傲慢ってやつですね。
怠慢：全体の労力を減らすために手間を惜しまない気質。この気質の持ち主は、役立つプログラムを書いてみんなの苦労を減らしたり、同じ質問に何度も答えなくてもいいように文書を書いたりする。
短気：今ある問題に対応するプログラムにとどまらず、今後起こりうる問題を想定したプログラムを書く。
傲慢：神罰が下るほどの過剰な自尊心。または人様に対して恥ずかしくないプログラムを書き、また保守しようとする気質。
引用：
どの性質が色濃く出るのかは人によるかと思いますが、私なんかは「突然の障害対応がだるすぎるのでプログラミングのロジックはシンプルにして怠慢な自分が理解しやすいようにコメントアウト(注意書き)をめちゃくちゃ残す」みたいな怠慢属性が強めかも...
90対90の法則
この法則は要は機能追加などの工数見積もりって途方もなく間違えるよね..ってことです。結果的に簡単と思っていた仕事でも締め切り前に余裕がなくなって焦る...
コードの90%が、開発時間の最初の90%を占めている。残りの10%のコードが、他の90%の開発時間を占めている。
引用：
まぁプログラマに限らない話かもですが、なにか資料を作っていて60%くらいの出来栄えにするのは結構速くできるが、90%→91%に改善していく段階になるとめちゃくちゃ時間がかかるなぁって日頃思います。この記事作成に関してもそうです...
ちょっと脱線しますが、品質を下げればスピードは上がるのか？ という議論もあります。そこらへんの詳しい話は和田さんの記事を読んでみると良いかと思います。
https://codezine.jp/article/detail/12245
あとIT界隈の法則の話は、私の前の記事にもすこし書いてます。
お時間あればぜひご覧ください。
エンジニア病みやすい職業説
エンジニアって基本的にPCの画面でじっと論路的整合性とか実装方法とかを考えるのが仕事なのでその思考力が良くない方向に向かっていき、鬱っぽくなったりするのかもしれないですね。
私の人生このままで良いのか...あの人はなぜあんなことをしたのか...私のせいなのか？みたいな論理的に導けない問題で思考が無限ループするという時代は私にもありました。(今も迷走してます)
年代で多いのが30代のビジネスマン。性格的にはまじめで几帳面、責任感の強いタイプ。職種で目立つのはIT業界など技術職の方です。精神障害による労災認定件数も急増しているのですが、その60％が専門技術職です。私は外資系大手通信企業や技術系ベンチャーで多くのエンジニアと接してきて、日米を問わずエンジニアにはうつ病予備軍が多いと感じています。
引用：
最近知った言葉で、クオーターライフクライシス、ミドルエイジクライシスという言葉があるみたいですね。
病みやすいというのは職業病的な要因もありますが、年齢的な要因もあったりするみたいですね。
とかく生きるのは難しいでござるなぁ
上記をまとめると
エンジニアのとくちょうをすごく主観的にまとめると
- 基本的には怠慢/短気/傲慢で効率良く余裕をもって働きたい
- 工数見積もりは90対90の法則で途方もなく失敗するので余裕なく時間に追われる(営業が変な工数見積を出して疲弊する場合もある)
- 職業柄考えまくったり凝り性な性格によって、場合によっては病む
- 人間関係がわずらわしいので良い感じに内輪でわちゃわちゃできるチームで仕事をしたい
- できるなら仕事をやめて50兆円ほしい
ということです。(異論は認めます)
エンジニアのとくちょうと言いつつ、社会人としてみんなが持っている要素なんじゃないかなと思いますね。エンジニアもちゃんと人間なんですね。
あんま責任負いたくないんよ
上記のまとめでわかってもらえるかと思いますが、エンジニアも人間なんだなぁっていう側面がありますし「システムがちゃんと24時間365日稼働できているか」という心配をずっとしてるのは正直辛いわけですね。システムは眠りません笑
「この重すぎる責任、だれか一緒に持ってくれないか」という気持ちとか「私の担当範囲はここまでだからあとはよろしく！」って言いたい想いが気持ちのどこかにはあるわけですね。
そこで出てくるのが「責任共有モデル」ってやつです。
責任共有モデルとはなんぞ
たとえば日頃からGoogleさんにはお世話になっておりますが、Gmailというサービスを使うときに私たちはGmailさんと下記のような責任を共有しているはずです。
私たち：使用するメールアドレス、メール内容に対する責任
コンプラ的にアウトな内容を送受信してもそれはGmailさんの責任にはなりませんね
Gmailさん：ユーザーに対してGmailの画面やアプリケーションを提供、メールを送受信するためのサーバーやネットワーク、ストレージ、セキュリティに対する責任
上の例だとほとんどがGmailさんの責任になるので、Gmailさんを使用している私たちの責任はだいぶ軽いですよね。これを全部自前でそろえようとしたら、サーバーとかストレージなどを買って、さらにメールシステムを構築するのでめちゃくちゃ時間がかかるわけです。
このようにサービスがどこまで責任を持ってくれるかを見ていくことで、IaaS/PaaS/SaaSという分類ができます。
図は下記のリンクからみていただいたほうが良さそうです。
IaaS(Infrastructure as a Service/イアース/アイアース)：
電源/ネットワーク～サーバー(ハイパーバイザー)まではクラウド側で責任を持つ
PaaS(Platform as a Service/パース)：
電源/ネットワーク～ミドルウェアまではクラウド側で責任を持つ
SaaS(Software as a Service/サース)：
電源/ネットワーク～アプリケーションまではクラウド側で責任を持つ
さきほどのGmailさんの例ではアプリケーションまで責任を持っているので、GmailさんはSaaSに分類できます。
※ミドルウェアとかサーバーとはなんぞやという話は下記で説明します。
そういうことでスタートアップとかが大企業様などへDXという文脈でSaaSを提供して金儲けするでぇという感じになっているのが最近な気がします。
大企業様もIT人材不足のため自前でサービスを作るよりかは、金を払ってSaaSとして各種サービスを使えるほうが効率的だし、技術力の高いスタートアップの製品を使ってみようっていう感じはあるのかもしれないですね。
より具体的に責任共有モデルを理解するには
責任共有モデルに書かれているネットワークとかミドルウェアなどの各階層がそもそもよくわからないという方がいれば、何もない状態から簡単なウェブサイトの作成までやってみるというのをおススメしてます。(時間があればで良いです)
実際にアプリケーションを作ることで結構開発者のつまづきポイントなども知れて、エンジニアの気持ちが分かるようになるはずです。もし知っていればこの章は飛ばして読んでもらっても大丈夫です。
たとえば簡単なウェブサイトの作成といえばWordPressが有名です。
WordPressでウェブサイトを構築してみたい場合は、具体的な手順についてはネットの世界にいろいろ転がっているので、詳細はそういったサイトをみていただければと思います。(怠惰)
今の時代は物理サーバーを購入せずともクラウドサービスやQiita等を使えばブログなどのウェブサイトはさくっと作れますが、あえて0からウェブサイトを構築する流れを簡易的に書いてみました。
1.ネットワーク/電源を用意する
自宅にすでにインターネット環境が用意されてればここは省略できます。環境がない場合は、インターネットプロバイダーと契約していただいて固定回線を家につないでいただくと良いでしょう。
wi-fiでも良いですが通信が不安定になりがちなので、提供するウェブサイトのサービスの可用性に影響を与えてしまうでしょう。
2.物理スペース/ラック/空調/物理筐体(サーバー)を用意する
24時間365日ウェブサイトを運用するためにはワークステーションやラックマウントサーバーを購入したほうが良いでしょう。
またPCは熱を持ちすぎると壊れるので空調設備が整っている寒い部屋を用意しましょう。
一応サーバーの意味を書いておきます。
サーバーとは、英語で書くと「Server」となり、提供する側という意味を持つ言葉です。利用者の要求（リクエスト）に対して、それに応答したデータを提供するコンピュータやプログラムのことを“サーバー”と呼んでいます。
3.ハイパーバイザー(仮想化技術)を構築する
詳しくは下記のリンクに書いてありますが、要は一台の物理的なコンピュータを複数の仮想的なコンピュータに分割してくれる技術やソフトウェアのことをハイパーバイザーと呼びます。
ESXi、Hyper-V、Xenといったソフトウェアが代表的です。
まぁあんまり厳密な説明はできないですが、たとえば1つのサーバー上で複数のOSを使いたいという場合には、ハイパーバイザー上でゲストOS(windowsやらLinuxなど)を複数構築できます。
あとは実験的にゲストOSを作って、使い終わったらゲストOSを捨てたいみたいなときにもこの仮想化技術はとても良いですね。
ハイパーバイザーを使わずともウェブサイトは構築できますが、仮想化技術を使わずにOSなどをインストールしてしまうと上記のゲストOSのように使い捨てができないので、やり直しが効きにくく、最悪ごちゃごちゃインストールしてサーバー自体を壊してしまうという危険性もありそうです。
ここまで時間やお金をサーバー構築までに浪費してるので、ハードを壊したくないです。やはり使い捨てられる環境というのは最大の利点ですね。
ちょっと脱線しますが、最近の開発者の中では上記のハイパーバイザー型の仮想化ではなくコンテナ型仮想化(おもにDocker)が流行してますね。
軽量で容易に捨てられる、環境構築をすべてコード化してアプリケーションを作れるといった利点があるため、いまはもう主流になっているといっても過言ではないかと思います。
4.OSをインストールする
Windows/Mac/LinuxなどOSのインストールします。
OSの脆弱性が発見されたときにパッチ(Windows updateみたいなやつ)を当てる作業も必要になります。
5.ミドルウェア(MW)/ランタイムをインストールする
ミドルウェアっていう単語、理解しずらい問題ありますよね
(IT初心者時代にマジなんやこいつって何度も思ってました)
ミドルウェアの代表例としてはウェブサーバー、アプリケーションサーバー、データベースサーバーです。ミドルウェア自体はC++やPythonなどのランタイムで実装されているため、そういう開発言語環境をPCにインストールしたあとで、ミドルウェアをインストールするという手順を踏む必要があります。
詳細は下記のリンクなどで書かれていると思いますが、ウェブサーバー、アプリケーションサーバー、データベースサーバーについて簡単に説明します。
ウェブサーバーとは
クライアント(google検索などでウェブサイトをクリックしたユーザー)からのウェブサイト閲覧リクエストに対して 「ほいよ！」って感じでHTML/CSSをクライアントに返すサーバー。
イメージとしては仕事をさばくのがうまい現場マネージャーって感じです。大量のクライアントから同時に閲覧リクエストが来てもマネージャーの部下に「この仕事やっといて！」って投げて、マネージャー自身はクライアントからのリクエスト要求が漏れないようにひたすら仕事をさばいてるみたいなやつ
アプリケーションサーバーとは
ウェブサーバーは単純にHTML/CSSを返してるだけですが、アプリケーションサーバーはウェブサーバーからの問い合わせ(複雑な計算処理など)に対して計算して処理結果をウェブサーバーに返したり、データを検索してくれるデータベースサーバーに問い合わせて、ほしいデータを取りに行ったりしています。
イメージとしては全体を回してる参謀って感じです。
データベースサーバーとは
データの検索や更新などに特化しているのがデータベースサーバーです。
データベースはまさにコンピューターサイエンスのデータ構造とアルゴリズムの宝庫だと私は思っています。ちゃんと勉強したい...
たとえばトランプ52枚からハートの1を探すという仕事があったときに、単純に52枚のカードをひたすら探すと最悪52回の探索回数が必要になります。
しかしトランプを絵柄と数字でソートした状態でハートの1を探した場合
ということで大体4回の探索回数でハートの1が見つかるわけです。アルゴリズムの力はやはりすごいですね(あくまで一例です)1.ハートの絵柄で絞り込む(1回目のの探索：52枚→13枚に絞り込み)
2.6以下かどうかで絞り込む(2回目のの探索：13枚→6枚に絞り込み)
3.3以下かどうかで絞り込む(3回目のの探索：6枚→3枚に絞り込み)
4.1以下かどうかで絞り込む(4回目のの探索：3枚→1枚に絞り込み)
データベースはこんな感じでデータの格納や探索を最適化する機能を持っています
この例だとたった52枚ですが、現実世界のデータ量は万単位のデータ量から探索することだってあります。なのでデータベースを理解してうまくチューニングできれば 提供しているサービスのパフォーマンスが爆上がりすることもあるわけですね。
データベースサーバーのイメージとしては知識量の引き出しがえげつないオタクって感じです。
6.アプリケーションをインストールする
簡単なブログサイトを作りたいのであればWordPressをインストールして、あとはWordPressの初期登録などを済ませます。
7.コンテンツを入れる
ウェブサイトにいれるコンテンツをアプリケーションに入れてあげます。
技術ブログのウェブサイトならば、技術に関する記事をアプリケーションにアップロードすることで、記事として閲覧できるようになります。
これでウェブサイトの構築は完了となります。
上記の流れについての感想
最初の段階でサーバーやネットワーク環境の作成の段階でめちゃくちゃ時間かかります。私のDELLのノートパソコンでさえポチってから家に届くまで1か月くらいかかってます笑
そしてお値段もお高いです。サービスの収益化も見込めない段階でサーバー代60万円くらいをいきなり初期投資するのは怖いですよね
購入後もOSなどもろもろインストールしてますが、この環境構築手順も割とつまづきポイントが多いです。どのバージョンのプログラム言語やデータベースを入れるか、どのような手順でインストールするかといったところは時間を経るに応じて変化していくので、仕組みを理解しながら臨機応変にインストールする根気強さやリサーチ力が問われます。
半年前のドキュメントの記事を参考にして手順通りインストールしても、エラーが出まくって正常にインストールできないみたいなことも起こります。正直環境構築はめんどいです
なのでIaaSでごちゃごちゃ環境構築などでつまづくよりかは、ささっとSaaSを導入してサービスを利用するというやり方のほうがはるかに人も時間も浪費しないわけですね。
また上記の流れは理論的にはOSI参照モデルぽい話ですが、興味あればOSI参照モデルも合わせて調べてみると良いと思います。
IaaS?PaaS?SaaS?クイズ
「例を見ないといまいちわからん」のが多分普通だと思うので、IaaS/PaaS/SaaS分類クイズを出してみます。時と場合によっては責任の境目が微妙なラインがありそうですが、まぁ大体のケースでこっち側の責任範囲だろうということで書いてます。
あと基本的にクラウドベンダーであるGCP/Azure/AWSは自分たちのデータセンターで電源/ネットワーク/サーバーを責任をもって管理しているので、どのクラウドベンダーの、どのサービスにしろ基本的にIaaS以上のサービスを提供しているということになります。
(なにかしら例外はあるかもしれないですが)
AWS EC2
AWS EC2っていうのはAWSのサービスの1つで、AWS上に仮想サーバーを構築して自由に利用できるサービスです。
実際にAWSのアカウントを作ってコンソールで画面を見てみるだけでだいぶ分類しやすくなると思います。
アカウント作るだけなら無料ですし無料枠内で使用すれば課金の恐れはないです。
まずAWS EC2のコンソールをみるとこんな感じです。
新たにインスタンスを作る画面を見てみるとOSの選択ができそうですね。EC2はセキュリティパッチをどのように当てるかをコントロールできるのでOSの管理責任はユーザー側にもありそうですね。
つまり電源/ネットワーク～サーバー(ハイパーバイザー)まではクラウド側で責任を持ちそうなので、EC2はIaaSに分類できそうです。
AWS RDS
AWS RDSとはAWSクラウドで使用できるリレーショナルデータベースです。ミドルウェアのデータベースサーバーに属するやつです。
まずAWS RDSのコンソールをみるとこんな感じです。
新たにインスタンスを作る画面を見てみるとデータベースの種類(MySQL/PostgreSQLなど)を選べそうですね。どのOSを使うかは選べないのでOSの管理はAWS側で責任を持ってくれそうです。
つまり電源/ネットワーク～ミドルウェアまではクラウド側で責任を持ちそうなので、RDSはPaaSに分類できそうです。
AWS Lambda
AWS Lambdaとはクラウド上にプログラムを定義しておき、インターネットを通じて実行できるサービスです。つまり、利用者側はプログラムコードを用意して、Lambda側に設定するだけで、プログラムを実行することができます。
まずAWS Lambdaのコンソールをみるとこんな感じです。
新たにLambdaを作る画面を見てみると言語(Python/NodeJSなど)を選択できそうです。使用する言語やその実装はユーザー側の責任になりますが、ほかのAWSサービス(API Gateway/SQSなど)と連携させたり並列処理実行などはAWS側の責任になるので、アプリケーションの階層でユーザー側の責任範囲だったり、クラウド側の責任範囲だったりしてます。
ちょっと難しいですがLambdaはPaaSとSaaSの間くらいに分類できそうです。
もっと正確に言うと FaaS(Function as a service) と呼ぶらしいです。
手ごろなPythonアプリをAWSでサクッと作りたいというような需要は数多くあるので、Lambdaはめちゃくちゃ便利です。
エンジニア向けな内容になりますが、最近だとAWS Lambdaのストレージ容量が最大10GBまで拡張可能になりましたし、正直なにか新しいアプリケーションを開発する場合、最初からLambdaで実装することを検討してダメそうなら他のEC2/ECSなどでの実装を検討するっていうのがワールドスタンダードになって良いと思うくらいにLambdaは色んな場面で使えると思います。
最近のスタートアップでもEC2もECSもEKSも使わないで、アプリケーションは全部Lambdaで実行っていう会社も見かけたりします。私はEC2大好きおじさんばかりの部署にいる時代もあったので、全Lambdaスタートアップとかまじ卍って感じで怖いです。若さは恐ろしいです。
すいません、脱線しました。
DeepL
まずDeepLのコンソールをみるとこんな感じです。
文字データを入力するだけで翻訳してくれるので、ユーザー側はデータさえもってればサービスを使えますね。
つまり電源/ネットワーク～アプリケーションまではクラウド側で責任を持ちそうなので、DeepLはSaaSに分類できそうです。
結論：クラウドはなにが良いのか？
責任共有モデルの話から導けるクラウドのメリットとしては、責任をクラウド側にもっていけるってことです。責任共有って言ってるんだからそりゃそうだろって話なんですが笑
ただクラウド技術を利用していたとしても、IaaS相当のサービスだとユーザー側の責任がまだ大きいので、クラウド側に責任をもってもらう効果が薄いです。
しかしPaaS/SaaS相当のクラウド技術を利用していればある程度クラウド側に責任をもってもらえているので、ユーザーやクラウド技術を利用する側の開発者の負担がものすごく軽くなるので、クラウドの利点をちゃんと生かすことができるわけですね。
あとはクラウドの良さについていろんな観点から主観も混じってますが説明していきます。AWSしかほとんど触ってないのでAWS系の内容多めです。すいません。
1.クラウドの良さ(エンジニア心理の観点)
上記で説明したようなエンジニアのとくちょうがあるため、少しでもエンジニアの責任や負担が軽くなるようなスタイルにしていくためにクラウドの存在が必要になってきている。
エンジニアのとくちょう
- 基本的には怠慢/短気/傲慢で効率良く余裕をもって働きたい
- 工数見積もりは90対90の法則で途方もなく失敗するので余裕なく時間に追われる(営業が変な工数見積を出して疲弊する場合もある)
- 職業柄考えまくったり凝り性な性格によって、場合によっては病む
開発者の心理的には24時間365日稼働し続けるシステム全部の責任を持つのは精神的に結構厳しいですね。その負担をクラウド側が軽減してくれるのはありがたいです。
あとはシステムの運用責任をある程度クラウド側に寄せているのであれば、チーム全体の心理的安全性が良くなっていくのかなと思います。日頃から障害対応ばっかりしてギスギスしてるような職場とかつらいですからね。風通しの良い働きやすい職場ですってテンプレートを嘘をつかずに言いたいものです。
2.クラウドの良さ(ストレージの観点)
昨今ではビッグデータ/AIなどの話は尽きないですが、機械学習などを用いて分析するためには過去データ何年分も持たなければいけなかったりしてデータ容量がえげつなくて困っている企業は多いと思います。
オンプレミス(クラウドの対義語で自社運用という意味)でストレージを構築する場合、 とりあえずRAIDで冗長化する！ っていうのが基本的な動きかと思いますが、ペタバイト級になってくるとRAIDではデータロスが増加すると言われております。
データ多すぎてRAID壊れる問題はめちゃくちゃ怖いです。直せる自信もありゃしませんわ。
RAIDベースのアーキテクチャはペタバイト級のデータ管理には向かないのです。
引用：
長期的なストレージ戦略を考えるとRAIDで冗長化するという方向性よりかはAWS S3のようなクラウドのオブジェクトストレージに格納してさらにバックアップや暗号化を施すことで、オンプレミスでのストレージ構築よりはるかに安全で障害がほとんどないストレージを使用することができます。
私自身、データ基盤を作っていた時代もあるので思うこととしては 「データがないとそこで試合終了」 ということです。
いくら優秀なデータベースやアプリケーションを開発できていても、データが欠損していたり安全性が高くないと利用者は不信感をもってしまい徐々に利用者がいなくなるということです。
ストレージ、マジ大事です。
3.クラウドの良さ(ネットワークの観点)
昨今ではBCP(事業継続計画)という観点でビジネスを運用することが求められています。たとえばデータセンターが東京にあって、東京で大地震が起こって1週間サービスが止まってしまうなどして、サービスの可用性が損なわれると SLA(サービス品質保証)99%で契約している場合、アウトー!! となるわけです。
クラウドで構築していればマルチリージョン、マルチAZでのアーキテクチャを採用できるので、東京で大地震が起こっても大阪リージョンにメインを切り替えるみたいにすれば、SLA99%は守れるようになるということですね。
というかクラウドがない時代にSLAってどうやって結んでたの？っていうのが疑問ですね。99%とかのレベルだとオンプレミスだと厳しいと思いますけどねぇ。
4.クラウドの良さ(セキュリティの観点)
昨今だとゼロトラストという考え方でセキュリティを構築していくことが求められています。基本的に社内ユーザーだとしても必要最小権限しか与えないとか、フロントエンド側で認証したからバックエンド側は認証を入れなくてもよいみたいな考え方はせずに全部を疑い性悪説的に考えようって感じかと理解してます。
社内外のネットワーク環境における、従来の「境界」の概念を捨て去り、守るべき情報資産にアクセスするものはすべて信用せずにその安全性を検証することで、情報資産への脅威を防ぐという、セキュリティの新しい考え方。
ちょっと字が多すぎて理解するの厳しいですが、AWSからもこんな記事が出てますね。
クラウドのセキュリティ心配やなぁ という声はオンプレミス派からよく出る話題ですが、
AWSではゼロトラストに基づいて、各種サービスを構築できます。
またcloudtrailのようなAWS環境で発生するアクティビティを追跡/記録するサービスがあるので何かインシデントが起こった時に証跡を追うということもできますね。
セキュリティという分野自体がハード的なものからソフトウェア的な分野まで幅広く含んでいるので、セキュリティ関連のサービスがAWSにあるのは普通にありがたいですね。
オンプレミスでこのクオリティのセキュリティサービスを実装するのは無理ゲーなのではって思います。
5.クラウドの良さ(コストの観点)
オンプレミスとクラウドでのコスト比較でうなっている方は多いと思います。
本当にどういうアーキテクチャを採用するかでクラウドの値段は全然変わります。
AWS EC2で構築するとユーザーが全然使っていない時間帯でも常時起動しているので、コストがかさみます。
AWS Lambdaのようなサーバーレスと言われるサービスは、イベントが発生した時だけ起動してイベントが終了したら終了する仕組みなので、使用分のコストが安くなります。
たとえばAM1:00 - AM7:00まで利用者が0であればコストも0です。サーバーレスは神！
6.クラウドの良さ(エンジニア人事戦略の観点)
クラウド技術を使って開発を回しているということ自体が最近の開発者の魅力ポイントであります。
企業独自の自作データベースでオンプレミスでシステムを構築しているみたいな職場も私は体験しておりますが、その企業でしか使えない技術をやっていても転職がしづらくなるので多分開発者にとってはあまり良くない状況かと思います。その企業独自技術は社内公式ドキュメントが整備されてなかったり、詳しい人に聞かないと学べないという状況が生まれがちなので不自由ですね。
公式リファレンスがインターネット上にあるようなアプリケーションであれば、自分で勝手に勉強して技術力をあげることができます。
またクラウド上で環境を作っているとはすなわち、フルリモートでも開発をすることができるということです。フルリモート勤務できるのはやはり魅力的ですね。
(オンプレミスでサーバーが壊れたら出勤せざるを得ないはず)
7.クラウドの良さ(ビジネスサイドの観点)
不確実性が高まっている時代でさらにプロトタイプの高速開発やとんでもなく高い品質要求をされたりするので、可用性や耐障害性を高めていくためにはクラウドの存在が欠かせなくなっていますね。
また新機能の開発もクラウドだとやりやすいです。
たとえば日本語の検索機能を追加しなければいけないとなった場合は、AWS OpenSearchというデータベースを構築して日本語の全文検索機能を追加できます。
またユーザーログ情報からユーザーログ分析をしたい場合AWS Athenaというデータベースを構築してユーザーログ分析ができます。ユーザーログ分析結果からレコメンド機能を提案するといった展開もできますね。
ビジネスサイドの要求に応じて色んなデータベースを活用したり多種多様なアーキテクチャを選択できるという自由度の高さはクラウドならではの良さかと思います。
あとがき
もうすこし早く記事が完成すると思ってましたが、lambdaの機能の話もしたいなぁとかコンテナ仮想化の話もしたいなぁってなって、めちゃくちゃ記事作成に時間かかってしまった。途方もなく見積もりは間違えてしまう...
開発者として働いているとあまりIaaSかPaaSかSaaSかというのは意識してないなと思います。そもそも若いスタートアップで働いていると、クラウドが前提でアプリケーションが作られてるので、クラウドの良さを論じなくてもみんなわかってる みたいな環境だったりします。
ただちゃんと言語化していく必要はあると思いますし、なにかの拍子でオンプレ派が復権？した場合にクラウドの良さを説明できるという状態は望ましいですよね。
あとはクラウド推進委員会などで苦心されている方もいらっしゃると思うので、稟議を通すための参考資料程度くらいにはなれれば良いな(おこがましい) と思います。
人生は短いですから楽しいことに時間を費やしたいですよね。
そう、クラウドならできますよ、多分
ということで日本がもっとクラウド先進国になってくれることを祈っております。