LAMPの次としてJACDAGというものを提唱してみたい。異論は認める。マサカリを投げるときは優しくお願いします。
この話のターゲット
WEBサービスを構築するために必要な技術要素っていわゆるLAMPだよ…ね…？と思っているゆるふわ職業エンジニア（希望）向け
LAMPとは
その昔、WEB系エンジニアの人材市場において、LAMPという言葉がもてはやされた時期がありました。
Wikipediaの記事では、以下のように定義されています。
LAMP（ランプ）とは、OSであるLinux、WebサーバであるApache HTTP Server、データベースであるMySQL、スクリプト言語であるPerl、PHP、Pythonを総称した頭文字から成る造語である。動的（ダイナミック）なウェブコンテンツを含むウェブサイトの構築に適した、オープンソースのソフトウェア群である。
しかし、残念ながら、職業エンジニアという観点で言うと、LAMPは時代にあわなくなってきています。
LAMPから大きく変わったというよりむしろ、LAMPだけでは足りなくなっているのです。
JACDAGとは
というわけで、WEB界隈においてLAMPが古くなった現在、 ぼくのかんがえたさいきょうのデファクトスタンダード。
それを、要素それぞれの頭文字をとって JACDAG と名付けてみました。
- J: Javascript framework
- A: API
- C: Cloud Services Platform or Container
- D: Data Store
- A: AI
- G: Github
個別の内容は以下にて説明していきます。
ひとつ注意点として、LAMPと違い、すべてがオープンソースというわけではありません。ただ、全体として、導入の際の気軽さや低コスト感はLAMPと変わらない、むしろ以前よりもさらに気楽に気軽に簡単になっていると思います。
J: Javascript framework
リッチなフロントエンドの構築を想定したリッチなJavascript framework。
LAMPの時代からWEBサービスには暗黙的にHTML、CSS、Javascriptなどの技術要素が暗黙的に含まれていましたが、昨今のUXに対する要求の高まりには、サーバサイド＋HTML＋追加のJavascriptという旧来の構成ではすでに対応しきれなくなっています。
ぞして、それらの高度な要求に対応するためのフレームワークはすでにいくつも存在しており、個別の技術要素を選別してフルスクラッチで作り上げるよりも、有名どころのフレームワークのお作法を理解して導入するほうが手っ取り早いでしょう。
具体的な技術例
- Vuejs
- React
補足
例としてはわかりやすく２つを挙げましたが、本来リッチであったはずのフレームワークすら、ReactではRedux、Vuejsではvuexやnuxt.jsなど、更に高位にラッピングしたフレームワークを通じて採用される例が増えているように思います。
ユーザにもっとも近いところで非同期に動くjavascriptや、そのフレームワークの独特のアーキテクチャは、開始から終了まで一本道のMVCなサーバサイドプログラムだけに慣れ親しんでいた人が少し二の足を踏ませるケースを散見するのですが、大丈夫、コードは友達、怖くないよ！
A: API
サーバサイドAPI。
フロントエンドのJavascriptリッチ化の動きに対応して、サーバサイド側でやるべき処理は整理統合が可能になり、API化が進んでいます。
言語は最低限WEBサービスに対応しているものであれば基本的にはなんでもよいはずですが、WEB対応のフレームワークの充実やサーバレス環境に対応している言語は採用されやすいように思われます。
そのため、これまでWEBサービス技術界隈では（下にみられがちながらも）覇権を握ってきたPHPや、djangoを擁してWEB対応も十分なうえ機械学習を得意としているPython、またJavascriptの知識が転用できるnodejsなどが比較的採用されやすいように見受けられます。
具体的な技術例
- PHP
- Python
- nodejs
補足
個人的には、API化が進みサーバサイド側の処理が減ったこと、また言語やフレームワークの進化、開発環境の充実、コードレビューの浸透などにより、サーバサイド側の処理実装は以前より易化しているイメージがあります。
とはいえ、どんなプログラムでもスパゲティ化させる、ラーメンマンの生まれ変わりみたいな方もいらっしゃいますが…。
C: Cloud Services Platform or Container
クラウドサービスかコンテナ仮想化、またはその両方。
LAMPでいうところのLinuxとApache、つまり動作環境部分ですね。
ローカルの開発はdokcerコンテナで行い、本番環境はAWSやGCPのサービスを使って構築するようになったことで、LinuxやWEBサーバなどの知識・技術は、以前ほど必要ではなくなり、かわりにdockerや各種プラットフォームを使用するための知識・技術が必要とされるようになっています。
Apacheがnginxに変わってもサーバの設定が必要なことはあったり、OSは引き続きLinux系が主流であるなど、WEBサーバやLinux系OSの知識技術がまったく不要になったわけではありませんが、その前提としてコンテナやクラウドサービスプラットフォームを理解している必要があります。
仮想化環境としてはVirtualBoxなどもありましたが、最近はもうDocker一強状態ですね。
具体的な技術例
- Cloud
- AWS
- GCP
- Container
- Docker
補足
本番環境における各種管理用サービスやミドルウェアの充実、また開発環境のコンテナ化によって開発環境がローカルPCだけで完結できるようになったことにより、一日中ターミナルを開いて華麗なワンライナーとCUIエディタを駆使しコードを書き上げるLinux職人を最近あまりみかけなくなったなあという印象です。
D: Data Store
各種データストア。
オンラインのサービス構築において、RDBが引き続き便利であることに変わりはありません。
LAMPで名指しされているMySQLも、機能面や情報収集の容易性等、引き続き申し分ないと思います。
しかしいっぽうで、大量トランザクションをさばくにはRDBだけでは限界があったり、複数台のWEBサーバ感に渡るSession情報を維持するなどの目的から、随分前から企業系のWEBサービスにはキャッシュサーバが当然につきものとなっています。
職業エンジニアとしてWEBサービスを考えるのなら、データベースとキャッシュサーバの知識技術は同じくらい重要です。
また、データ分析などのために、データベースのデータやログなどを、データウェアハウス（以下、DWH）に複製・収集して活用するケースなども増えているようです。年を経たサービスならだいたい背負っているようになってきているので、選択肢として選べるよう知識経験は持っておいたほうがいいと思われます。
サービスのローンチ時点においては必ずしも必要とは言い切れませんが、データベースにすべての過去ログが残っていることを前提としていたり、MySQLやサーバログなどについて、直接参照する以外の手段をとれないようなサービスは、うまくサービスが軌道にのった後に技術的負債に悩むことになりやすいです。はじめからデータ運用のためにDWHの活用なども視野に入れたシステム構成を考えておいたほうがいいでしょう。
具体的な技術例
- データベース(ex. MySQL)
- キャッシュサーバ(ex. Redis)
- データウェアハウス（ex. RedShift、BigQuery）
補足
DWHはあまり詳しくないのですけれども、昔はRedShiftをよく聞きましたがGCPの隆盛に伴い最近はBigQueryのほうが採用率が高い気がします。そして、この分野では、ElasticSearch、Kibana、logstash擁するElastic社ファミリーに必ずどこかではお世話になるイメージ…。
なおLAMPのMはMySQLだけではなくMongoDBも意味しているそうですが、MongoDBすらも入れるのならなぜせめてmemcacheを入れないのかと小一時間問い詰めたい。
A: AI
キャッチーなのでAIという言葉をあえて使いましたが、技術的には機械学習（Machine Learning）というほうが近いかもしれません。
実のところ、機械学習技術がWEBサービスの前提として当然に含まれるということは自分としてもまだ経験はないのですが、大手サービスの動きを見ていると、先々必須になってくるだろうと予想しています。
基本は外部サービスを使うことになると思いますが、関連技術の知識があるに越したことはありません。
以下にてひとつ具体的な例としてElasticSearchを挙げましたが、たとえばオンラインにおけるユーザへのデータ検索ニーズやレコメンド機能に応じる方法として、フルスクラッチでなにかを構築するよりも、ElasticSearchを導入するのがほぼ当たり前になってきているように見受けられます。
機械学習について深い知識とまではいかなくとも、機械学習でなにができてなにができないか、やるならなにが必要か、という知識を身につけ、ある程度の判断はできるようになっていたほうがいいでしょう。
そうしないと、先々四角い車輪の再発明をする羽目になり、大切な予算をドブに捨てることになりかねません。
もしも知識ゼロからフルスクラッチでなにか開発しようとするなら、現状はPyrhonを選ぶのが一番安全確実と思われます。
具体的な技術例
- 画像処理
- 言語処理
- 自動翻訳
- ElasticSearch
- Python
補足
これ（AIは今後必須、だろう）ということを言いたくてそもそもこの記事書きだした可能性…。
個別の対応サービスについては他にもっといい記事がありまくるので、無理はしませんでした。きりっ。（自分も勉強中なのですみません）
G: Github
ご存知、バージョン管理システム。
かつてはSubversionなどというものもありましたし、gitで管理しているコードを集中的に管理するためにはgitlabなどというものもありますが、機能の充実さ、利便性などから、なにか特別の事情がない限り、現在はgit + githubほぼ一択だと思います。
CircleCIやChatOps対応など開発者にとってありがたい機能が満載のgithubですが、各種機能を把握し使いこなしている人は意外とまれな印象です。（なお自分も使いこなせてないほうの人です）
gitやgithubを使いこなしている人といない人とでは、ドムが赤いか赤くないかぐらいの歴然とした差があります。
最低限、ブランチとプルリクくらいは理解していないといわゆるモダンな開発現場についていけません。下手すると迷惑な人になります。実際、コードは書けるのにそういうところについていけず開発の主流から外れてしまったエンジニアをみかけると、もったいないなあと思います。
具体的な技術例
- git + github
補足
WEBサービス関係ねえじゃねえか、というご意見もありましょうけれども、 LGTM という言葉を生まれた時から知っていたという人だけが、私にマサカリを投げなさい。
以上です
いかがでしょうか？
ぼんやりと考えていたことに便宜上それっぽい名前をつけてみたかっただけなので、これじゃ足りない、多い、説明が不適切などありましたらすみません。
余談ですが、要素は同じながら並び順について、JAGDAC（ジャグダック）とJACDAG（ジャクダッグ）で悩んだ結果、より音楽著作権に厳しくなさそうな後者を採用しましたが、語呂がいいのは前者だなあとも思います。
以上、なにかのご参考になりましたら幸いです。