“2019年, LAMP之后是JACDAG ~我心目中的最强默认标准~”
作为LAMP之后,我想提出一个名为JACDAG的方案。欢迎提出异议,但请温和表达。
この話のターゲット
WEBサービスを構築するために必要な技術要素っていわゆるLAMPだよ…ね…?と思っているゆるふわ職業エンジニア(希望)向け
LAMP指的是- Linux、Apache、MySQL和PHP,它们是一组广泛用于搭建动态网站和应用程序的开源软件。
很久以前,在WEB工程师人才市场上,有一个叫做LAMP的词语非常流行。
Wikipediaの記事では、以下のように定義されています。
LAMP(ランプ)とは、OSであるLinux、WebサーバであるApache HTTP Server、データベースであるMySQL、スクリプト言語であるPerl、PHP、Pythonを総称した頭文字から成る造語である。動的(ダイナミック)なウェブコンテンツを含むウェブサイトの構築に適した、オープンソースのソフトウェア群である。
然而,遗憾的是,从职业工程师的角度来看,LAMP已经不再适应时代了。
与其说是LAMP发生了巨大变化,不如说是仅仅依靠LAMP已经不够了。
JACDAGとは
所以,在目前WEB界中,LAMP已经过时,我想到的最强标准是JACDAG。将其命名为JACDAG,取各个元素的首字母。
-
- J: Javascript framework
-
- A: API
-
- C: Cloud Services Platform or Container
-
- D: Data Store
-
- A: AI
- G: Github
我将在下面逐一解释各个内容。
需要注意的一点是,与LAMP不同的是,并非所有内容都是开源的。但总体而言,与LAMP相比,在引入方面的轻松性和低成本感方面并没有变化,反而更加轻松、简单。
J: JavaScript 框架
リッチなフロントエンドの構築を想定したリッチな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: 云服务平台或容器 huò
云服务或容器虚拟化,或者两者兼而有之。
在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: 数据存储
各种数据存储。
オンラインのサービス構築において、RDBが引き続き便利であることに変わりはありません。
LAMPで名指しされているMySQLも、機能面や情報収集の容易性等、引き続き申し分ないと思います。
しかしいっぽうで、大量トランザクションをさばくにはRDBだけでは限界があったり、複数台のWEBサーバ感に渡るSession情報を維持するなどの目的から、随分前から企業系のWEBサービスにはキャッシュサーバが当然につきものとなっています。
職業エンジニアとしてWEBサービスを考えるのなら、データベースとキャッシュサーバの知識技術は同じくらい重要です。
また、データ分析などのために、データベースのデータやログなどを、データウェアハウス(以下、DWH)に複製・収集して活用するケースなども増えているようです。年を経たサービスならだいたい背負っているようになってきているので、選択肢として選べるよう知識経験は持っておいたほうがいいと思われます。
サービスのローンチ時点においては必ずしも必要とは言い切れませんが、データベースにすべての過去ログが残っていることを前提としていたり、MySQLやサーバログなどについて、直接参照する以外の手段をとれないようなサービスは、うまくサービスが軌道にのった後に技術的負債に悩むことになりやすいです。はじめからデータ運用のためにDWHの活用なども視野に入れたシステム構成を考えておいたほうがいいでしょう。
具体的技术实例
-
- データベース(ex. MySQL)
-
- キャッシュサーバ(ex. Redis)
- データウェアハウス(ex. RedShift、BigQuery)
补充
DWH 虽然不是很熟悉,但以前常听说 RedShift,但最近似乎 BigQuery 的采用率更高随着GCP的兴起。在这个领域中,我总觉得 ElasticSearch、Kibana 和 logstash 这些 Elastic 公司的家族一定在某处都会帮得上忙……。
据说,在LAMP中的M不仅指的是MySQL,还包括MongoDB,但是如果连MongoDB都能安装的话,为什么不至少安装一下memcache呢?我想追问个把小时。
A: AI
因为它很引人注目,所以我故意使用了AI这个词,但从技术角度来看,更接近于机器学习(Machine Learning)。
実のところ、機械学習技術がWEBサービスの前提として当然に含まれるということは自分としてもまだ経験はないのですが、大手サービスの動きを見ていると、先々必須になってくるだろうと予想しています。
基本は外部サービスを使うことになると思いますが、関連技術の知識があるに越したことはありません。
我举了一个具体的例子,即ElasticSearch,但是在在线用户数据搜索需求和推荐功能方面,相比于从头开始构建,现在几乎可以说是使用ElasticSearch已经成为常态了。
尽管不需要对机器学习有深入的了解,但获得关于机器学习可以做什么、不能做什么以及需要具备哪些条件方面的知识,并能做出一定程度的判断是很有必要的。否则,将有可能在未来面临重新发明轮子的困境,浪费宝贵的预算。
如果要从零开始开发一些东西,并且对知识一无所知,那么目前来看,选择Python似乎是最安全可靠的选择。
具体的技术示例
-
- 画像処理
-
- 言語処理
-
- 自動翻訳
-
- ElasticSearch
- Python
補足
我最初写这篇文章的可能性是想要表达 AI 是未来必不可少的。
由于有更好的相关服务链接,我没有过多解释。就这样吧。(我也在学习中,请谅解)
Github:一个流行的在线代码托管平台。
你知道版本控制系统吗?
かつてはSubversionなどというものもありましたし、gitで管理しているコードを集中的に管理するためにはgitlabなどというものもありますが、機能の充実さ、利便性などから、なにか特別の事情がない限り、現在はgit + githubほぼ一択だと思います。
CircleCIやChatOps対応など開発者にとってありがたい機能が満載のgithubですが、各種機能を把握し使いこなしている人は意外とまれな印象です。(なお自分も使いこなせてないほうの人です)
gitやgithubを使いこなしている人といない人とでは、ドムが赤いか赤くないかぐらいの歴然とした差があります。
最低限、ブランチとプルリクくらいは理解していないといわゆるモダンな開発現場についていけません。下手すると迷惑な人になります。実際、コードは書けるのにそういうところについていけず開発の主流から外れてしまったエンジニアをみかけると、もったいないなあと思います。
一个具体的技术示例
- git + github
填補缺漏
或许有人会说,与网络服务没有关系吧,但只有了解从”LGTM”这个词问世开始的人,才可以向我投掷斧头。
这就是全部了。
您觉得如何?
只是随便想了一下,想给这个模糊的想法起一个类似的名字而已,所以如果这个名字是不足够的,太多了,或者解释不适当,请多多谅解。
余談ですが、要素は同じながら並び順について、JAGDAC(ジャグダック)とJACDAG(ジャクダッグ)で悩んだ結果、より音楽著作権に厳しくなさそうな後者を採用しましたが、語呂がいいのは前者だなあとも思います。
如果以上提供的信息能够对您有所帮助,我将感到幸福。