新しい技術は楽にならないし基礎知識の範囲は広がる一方
- オンプレでサーバ管理していた時代から、EC2 が出てきました！仮想マシンで管理が楽に！
- EC2 の設定を手動でやるのはアレなので、Ansible とか何とか使います！コレが IaC だ！もっと管理が楽に！
- どんな環境でもアプリケーションが安定して動くように、コンテナ化技術でラップしましょう！アプリの運用が楽に！
- コンテナが沢山あると管理が大変ですよね、Kubernetes でオーケストレーションしてコンテナ管理を楽に！
- Kubernetes の裏にいる VM の管理が大変ですよね、Worker Node をクラウド側でマネージするので K8s の運用が楽に！
- つーか Node が登場するとダルいっすよね、Functions でもっとアプリの提供を楽に！
ココ数年のウェブアプリ界隈って大体こういう流行を感じていると思うけど、こうした新しい技術って「何も管理しなくて良くなる」とか「スゲー楽になる」ってことは、あんまないんだよね。
なんでかっていうと、どんな技術が登場しようと、根幹では世界のどこかにあるサーバ (コンピューティング資源) が動いているし、ネットワーク通信の仕組みは今も昔も変わっていないからだ。
確かに、一度 Kubernetes の仕組みや使い方を覚えてしまえば、自分達で物理的にサーバをいじくるよりは、格段に開発・運用が楽になるし、「オンプレ時代に戻りたい」とは思わないのだが、「一度覚えてしまえば」のハードルがメチャクチャ高いってところが忘れられがちだ。
さっき挙げた項目別にいうと…
- 「仮想マシン」にもリソースの割り当てが必要だし、ネットワーク接続にはホスト環境との疎通も必要。今まで直でやれてたところに緩衝層が1つ挟まる
- 「仮想マシン」の構築・設定を自動化するための IaC ツールの作法を覚えないといけない。今まで直で設定できてたところに「コード化」という緩衝層が1つ挟まる
- 「コンテナ内」と、それを実行する環境との間で、また「仮想マシン」的なものが出来ている。「仮想マシン」上の「コンテナ」となると緩衝層がもう1つ挟まる
- 「コンテナ」を取り扱う基盤として挟まってくる Kubernetes の作法を覚えないといけない。「仮想マシン」と「コンテナ」をさらに抽象化する緩衝層がもう1つ挟まる
- クラウドマネージドされる「Worker Node」の取り扱い方を覚えないといけない。純粋な Kubernetes の知識だけでなく、そのクラウドサービス固有の「マネージド Kubernetes」の学習コストがかさむ
- Functions もリソース割り当てが必要だし、アプリの作り方はこれまでのようにはいかない。「関数化」するための作法を学び直し、既存のコードとの違いを抑えておかないと効果を得られない
ほとんどの場合、根幹にある技術を抽象化して取り回しをよくしたい、というのが狙いなのだが、「何をどのように抽象化しているのか」を学び、そこから逆算して「結果的にメモリを 4GB 分は確保したいから、マニフェストファイルにこう書いて…」ということが把握出来ないと、何も出来ない。
「サーバには何 GB のメモリを積めばいいんですか」「ロードバランサの帯域幅はどれくらいあればいいんですか」といった問が、「対象のシステムや想定環境による」としか言えないように、Docker を使おうが Kubernetes を使おうが、オンプレでやろうがクラウドサービスを使おうが、設計して計測して調整しないといけない内容の根幹は同じなのだ。
最終的にやろうとしていることは同じなのに、やれ EC2 や ECS や EKS やっていう緩衝層の知識が必要で、クラウド都合で NLB じゃなくて ALB じゃないといけないところがあったりして、アプリをデプロイしたいだけなのに Docker のことは知らないといけないし Kubernetes の YAML も書けないといけない。LB の設定をしたいんだけど Ingress のマニフェストを書かないといけないだとか、最近はさらに HTTPS 化のために SSL 証明書はほぼ必須で、ドメインが登場するのであれ DNS もいじらないといけないですね、ってな感じで、全然簡単じゃない。
リリース後も、運用コストはオンプレ時代と同じようにかかると思った方が良い。それぞれの緩衝層が脆弱性を持つし、アップデートは必要になるし。もちろんそれも、物理サーバを自分達でいじくるよりは格段に手間がかからないのだが、それがどういう技術で、何が抽象化されていて、どう作用しているのかを把握していないと、必要なメンテナンスも出来ないので、そういう意味では「動作が重たくなったからメモリを増設しましょう」なんて対処で何とかなっていた時代の方が、直感的で、自分達の知能で何とかかんとか出来ていた時代なのかもしれない。今 Docker も Kubernetes も知らないような人が、マネージド K8s を採用している案件にブチ込まれて保守しろって言われたら、数ヶ月は何も分からないって人が出てきても仕方ないぐらい、学習コストがかかると思う。
かつて SOAP で苦しんだ人達が、イマドキ XML じゃなくて JSON でしょ、認証も JWT でやろうよ、なんつって RESTful な設計に飛びついたけど、「REST 原則」がカバーする範囲に対して、自分達が設計しようとしているシステムを自動的に当てはめる技術は存在しない。
URL やメソッドの設計に、広く知られる規約やプラクティスが出来た、という点では有用だが、「リソース」の定義はテーブル定義のように自分達でモデリングが必要だ。命名がちゃんと出来ないと URL 設計も失敗するし、中途半端に REST 風の考えを取り入れていて、中途半端に「自分で考えたところ」が混じっていると、逆に可読性の悪い、保守しにくいシステムになる。前提知識として RESTful な原則事項が通用したり通用しなかったりするのは、全く最初から独自路線を歩んでるプログラムよりも厄介になりやすい。
なんでも手続き的に書くとつらみが出るので、MVC って構造で別けましょう、それだけではビジネスロジック側の扱いが足りないので、DDD でモデルをガチガチに決めましょう、クラス間の依存関係や責任範囲をハッキリさせたいのでクリーン・アーキテクチャにしましょう。
どういうプログラミング言語や設計手法を使おうと、結局は「入力」「処理」「出力」を綺麗に別けた方が分かりやすいよねって話でしかないのだが、なまじ「提唱された有名な手法」が存在していると、それに従わないといけないと思って学習コストがかさんだり、うまく従いきれなくて MVC よりもイビツなだけの分かりにくいコードになったりする。
コレで金もらってるプロだったら、どれもこれも知らないまま生きてんじゃねえよ勉強ぐらいしとけ、って思うと同時に、年々「基礎知識」として知っておかないといけないモノが増えているよなぁ、その割に根幹でやってること変わらないけど、って思いも湧く。かつての新卒は「ローカルマシン上で Struts が動かせましたねースゴーイ」で済んでいたはずなのに、1年目から「GCP で GKE に Docker コンテナをデプロイして LB 設定を Terraform で書きましょう」なんてやらされたら、そりゃ逆に薄っぺらくなるよなーと思う。
まぁ、SE って欧米だと大学出てないと就職できないようなガチの専門職だし、そういう欧米圏で登場してきた技術を、未経験新卒がすんなり入社できるような日本の企業で同じように扱おうぜっていう目標がそもそも厚かましいってところはある。俺ら程度のニホンノエスイーはどれだけ頑張っても Kubernetes の効果的な運用なんか出来るはずがないし、何年経ってもクリーン・アーキテクチャが浸透するような働き方してないし、IT を導入する企業側もリテラシー低いままだからそんなモン求めてないんだわ。
俺らみたいなハナクソ連中がいきなり背伸びして K8s だ DDD だスクラムだ、なんつって、年収が数倍高い欧米人の真似しても無駄なんだ。ウォーターフォールで MVC アプリを作って EC2 に載せるのが関の山だわ。
こう考えると、これから先の生存戦略って、「学生時代から実践的かつ高度な専門スキルを学習してきたような人」が、継続して欧米の技術レベルに追従していけないといけないんだろうな。
今既に SE としてやっている人も、「自分は Android アプリが作れます、SSL とか何とかネットワーク系はよく分かりません」なんてレベルじゃ全然話にならなくて、幅広い基礎知識を正確に有したうえで、「スマホアプリの開発と CI/CD 基盤構築、運用整備まで出来ます」と言えて、初めて「Android アプリエンジニア」と呼べる、みたいなところまで来てると思う。Java や Kotlin が書ける程度のレベルは誰だってすぐ行けるんだわ。
昔はそんなレベルでも良かったのに、何が変わったんだろうね？っていうと、まぁ単純に今求められる IT の質が高度化してきたことも多いとは思う。一部の人間がローカルマシンにバイナリをインストールして動かせば良いようなアプリケーションの時代ではなくなった。誰もがスマホで閲覧するサービスを作って売っていくとなると、安定性はもちろん、UI/UX をメチャクチャ気にしないといけなくなった。Twitter や Facebook 並に「オシャレ」にまとまったアプリじゃないと誰も使わないし、2秒以上待たせるようなアプリは作れないワケだ。
サービスに求められる内容が、既に「欧米の超一流企業が提供するサービス」の質になってきていて辛いところなのに、それを実際実現するにあたって、抽象化層・緩衝層が格段に増えているワケだ。クラウドが何となく上手くやってくれるんでしょ？なんて思っているとファイアウォール全開けしててすぐ乗っ取られるし、オートスケール機能があるんでしょーよく知らんけどーなんて思ってると青天井でサーバが増やされて課金死するので、どの技術も「知らない」では済まされない、「基礎知識」扱いなのが現状だ。
開発言語やフレームワークを、個人の好みで選んでるような時代は終わったんだ。ありとあらゆる技術を正確に知っていて、使いこなせている上で、適材適所に選定できないとダメなんだ。新しい技術なら楽になるとか、古い技術だからダメだとか、そういう考え方してる時点で間違ってる。そういう奴は何を使ってもまともなモンは作れないよ。昔はそれで許されたかもしれないけど、今は許されなくなってる。
今も昔も根幹の原始的な技術の部分は変わらないから、普遍的な基礎知識として覚えておかないといけないし、新しい技術はさほど楽にならない割に学習コストがかかり、それでいてどういうワケか必修科目になっているから、マジで SE のみんな頑張れ。覚えきれないぐらい沢山のことを当たり前のように知っておけ。じゃないと迷惑。
↑ ましてや非 IT 企業が DX なんて絶対無理。「DX」を目指そうと思うな。改善したいと思ってやってきた取り組みが結果的に「DX」と呼ばれるモノだった、みたいな働き方じゃないと到底辿り着けんから。