フロントだけにとどまるな。
目次
フロントだけにとどまるな。転職活動でクラウド知識の必要性を痛感した話
最近、転職活動をしています。
自分はこれまで、フロントエンドやWordPressを中心にWeb開発をしてきました。
なので最初は、転職でも当然そのあたりの経験を中心に見られると思っていました。
もちろん実際に聞かれます。
ただ、自分が見てきた求人や面接では、それと同じくらい気になったことがありました。
クラウドやインフラの話がかなり出てくる。
制作寄りの会社でも、自社開発寄りの会社でも、
AWSなどのクラウド経験
デプロイやCI/CD
Docker
DB
ネットワーク
監視や運用
のような話が普通に出てきます。
自分はそこで、
フロントができれば、その先は知らなくていい、ではないんだな。
とかなり強く感じました。
それをきっかけに、そもそもクラウドとは何なのか、なぜWebエンジニアにもクラウドの知識が求められるのかを改めて整理してみました。
そもそも「クラウド」って何なのか
クラウドという言葉は普通に使いますが、説明しようとすると意外と難しいです。
NISTの定義では、クラウドコンピューティングは、ネットワーク経由でサーバー、ストレージ、アプリケーションなどの共有されたコンピューティング資源へオンデマンドでアクセスでき、必要に応じて素早く用意・解放できるモデルとして整理されています。
参考: https://www.nist.gov/publications/nist-definition-cloud-computing（外部サイト）
かなり簡単に言えば、
サーバーやストレージなどを自分で物理的に用意するのではなく、必要なITリソースをネットワーク越しに必要な分だけ使う。
という考え方です。
AWS、Microsoft Azure、Google Cloudなどが代表的です。
ただ、クラウドは単に「インターネット上にあるサーバー」ではありません。
必要になったら増やせる。
使わなくなったら減らせる。
利用量を計測できる。
サーバーだけではなく、DB、ストレージ、ネットワーク、認証、監視などもサービスとして組み合わせられる。
このあたりが、クラウドを理解するときのポイントだと思います。
VPSとクラウドは何が違うのか
自分は個人開発でVPSを使うことがあります。
VPSは分かりやすいです。
サーバーを1台借りて、Linuxを入れて、Nginxを設定して、アプリを置く。
自分でサーバーを触っている感覚があります。
一方、AWSのようなクラウドでは、仮想サーバーだけを使う必要はありません。
たとえば、
コンピューティング
オブジェクトストレージ
マネージドDB
DNS
CDN
ロードバランサー
監視
権限管理
サーバーレス実行環境
などを別々のサービスとして組み合わせられます。
AWSのIaaSの説明でも、コンピューティング、ストレージ、ネットワークなどのITインフラをインターネット経由で利用するモデルとして説明されています。
参考: https://aws.amazon.com/jp/what-is/iaas/（外部サイト）
ただし、VPSとクラウドが完全に対立するもの、という理解も少し違います。
クラウド上でも仮想マシンを使いますし、VPSサービス側がクラウド基盤を使っていることもあります。
自分の中では、
VPSは「1台の仮想サーバーを借りて自分で面倒を見る」感覚が強い。
クラウドは「必要なインフラ機能をサービスとして組み合わせる」感覚が強い。
くらいに捉えると分かりやすくなりました。
フロントエンドなのに、なぜクラウドを知らないといけないのか
ここが今回一番考えたところです。
フロントエンドの仕事は、画面を作ることです。
HTML、CSS、JavaScript、React、Next.js。
そこだけ見れば、AWSのVPCやDBを知らなくてもコードは書けます。
でも、実際のWebサービスは画面だけでは動きません。
ユーザーがブラウザで開くまでに、
DNS
→ CDN
→ Webサーバーやアプリケーション
→ API
→ データベース
→ ストレージ
のように、いろいろなものがつながっています。
フロント側でNext.jsを書いていても、
どこにデプロイされるのか
APIはどこで動いているのか
環境変数はどう管理されるのか
画像はどこに置くのか
DBへどう接続するのか
本番とステージングをどう分けるのか
障害が起きたらどこを見るのか
は避けて通れません。
つまり、クラウドを知るというのは「インフラ担当になる」というより、
自分が書いたコードが本番でどう動いているかを理解すること
に近いんだと思います。
個人開発をすると、担当範囲という逃げ道がなくなる
仕事では役割分担があります。
フロントエンド担当。
バックエンド担当。
インフラ担当。
それ自体は当然です。
でも個人開発では、全部自分です。
フロントを書いても、それだけでは公開できません。
APIを作る。
DBを用意する。
ドメインをつなぐ。
HTTPSにする。
環境変数を管理する。
バックアップを考える。
ログを見る。
ここまでやって初めて、外から使えるサービスになります。
自分が最近、バックエンドやクラウドまで勉強したいと思っているのもここです。
フルスタックという肩書きが欲しいというより、
自分で作ったものが、どうやって動いているのかを一通り説明できるようになりたい。
その気持ちが強くなっています。
転職活動で「インフラ弱い」がそのまま課題になった
今回の転職活動でも、自分の経験を話すと、
フロントエンドやWordPress、業務改善などについてはかなり話せます。
一方で、クラウドやインフラの話になると、自分でも説明が浅くなるのが分かります。
AWSを本格的に構築・運用してきた経験があるわけではありません。
そこは正直に伝えています。
でも面接を重ねる中で、
ここを避けたまま次のキャリアへ行くのは厳しいな。
と思うようになりました。
これは「AWSのサービス名を100個暗記しないといけない」という話ではありません。
まずは、
Webアプリが本番で動くために、何が必要なのか。
その全体像を理解する必要がある。
自分に足りないのはそこだと思っています。
まず理解したいクラウドの範囲
いきなり全部やろうとすると、AWSだけでもサービスが多すぎます。
なので今の自分なら、Web開発につながるところから入ります。
コンピューティング
アプリケーションをどこで動かすのか。
仮想マシン、コンテナ、サーバーレスなど、それぞれ何が違うのか。
ネットワーク
HTTPリクエストがどこを通ってアプリへ届くのか。
DNS、IP、ポート、ロードバランサー、VPCあたりの基本。
データベース
PostgreSQLなどを自分でサーバーへ入れる場合と、マネージドDBを使う場合の違い。
ストレージ
画像やファイルを、アプリサーバーそのものではなくオブジェクトストレージへ置く理由。
IAM・権限
誰が何を操作できるのか。
APIキーを適当に置かない、という話もここにつながります。
監視・ログ
動いているかどうかだけではなく、壊れたときに原因を追える状態を作る。
このあたりなら、フロントエンドの仕事ともかなりつながっています。
クラウドを知ると、フロントの設計も変わると思う
インフラを勉強する理由は、インフラエンジニアになるためだけではありません。
たとえば画像配信を考えると、
「Next.jsでどう表示するか」だけではなく、
画像をどこに保存するか。
CDNをどう使うか。
キャッシュをどうするか。
までつながります。
APIでも、
「fetchを書く」だけではなく、
そのAPIはどこで動き、どのDBへ接続し、どう認証されているのか。
まで見えるようになります。
そこが分かれば、フロント側の実装で何を気にするべきかも変わるはずです。
自分が目指したいのは、まさにこの状態です。
「フロントだけにとどまるな」は、自分に向けて言っている
タイトルは少し強めですが、これは誰かに「フロントだけではダメ」と言いたい記事ではありません。
フロントエンドを深く極めるキャリアも当然あります。
自分が今回言いたいのは、
自分はフロントだけを見ている状態から、もう一段外側へ出たい。
ということです。
転職活動をして、そこをかなり強く意識するようになりました。
画面を作れる。
WordPressをカスタマイズできる。
Next.jsも勉強している。
その次に、
それがどこで動いて、どう公開され、どう守られ、どう運用されるのか。
まで理解したい。
だから今、自分にとってクラウドを学ぶ意味があります。
次は知識だけで終わらせず、実際にAWSなどで小さな構成を作って、デプロイから監視まで一度自分で通してみたいと思っています。
そこでまた普通にハマると思います。
たぶん、そのハマったところが次の記事になります。
