JavaとNode.jsとエンタープライズIT

http://dejanglozic.com/2014/03/24/node-js-and-enterprise-why-not/

3 comments | 1 point | by WazanovaNews 3年以上前 edited


Jshiike 3年以上前 edited | ▲upvoteする | link

IBMのDejan GlozicはかつてJavaがデビューして間もない時期に、後にEclipseに進化するJFaceを書いた人物。Node.jsとエンタープライズIT市場の関係について、

自分が(IBMのミドルウェアツールとの連携という)問題を解決するように頼まれたのはJavaがまだ2年しか経ってないとき、そして、Eclipseプラットフォームをつくる膨大な作業もJavaベースで、それはJavaが生まれて4年たったとき。…当時の人々はJavaに対して懐疑的であったけど、それでも、Javaを進化させ、疑念を解消するために直すべきことは何でも直すという勢いが止まることはなかった。エンタープライズITの世界には、やんちゃであった子供時代を忘れてしまい、口うるさく注意するようになった親のような人たちがいるようだけど、...かつて恐れを抱かず前に進んだように、今回も恐れを抱かずに進むことはできる。また5年たてば、次の新しいものがでてきて、またこの議論は繰り返されるのだから。

と冷静にコメントしています。そして、Node.jsが取り組むべき課題は、多言語化 / セキュリティ / スケーラビリティ / 大きなチームにおけるマイクロサービスの進化 / サービス間のメッセージング / クラスタリング / 継続的インテグレーションとダウンタイムのない本番アップなどであるとし、

子供が音楽をに取り組むように、気持ちをオープンにして、固定観念にとらわれることなく、メリットだけを考えて課題を解決していこう。

とまとめています。

少し話しが変わって今度はBoxのエンジニアブログでの話題。

Boxにおいて外部の依存関係管理にnpmを利用しはじめたタイミングで、運悪くパブリックのnpmレジストリが落ちる障害を経験。そこで、自分たちがコントロールできないところでサービスの不具合をだすわけにはいかないので、まず要件を整理。

  • パブリックnpmレジストリが利用できるかどうかにかかわらずデプロイできること。
  • パブリックのnpmレジストリにパブリッシュすることなく、内部でモジュールをつくってシェアできること。
  • 依存しているパブリックのモジュールにアクセスできること。

プライベートnpmレジストリが、

問題を解決してくれるかもしれないが、セットアップやメンテの手間がかかり、新しいテクノロジーを採用するたびにどう運用するのか議論しなくてはいけないかも。npmレジストリがどういう仕組みになっていて、ボトルネックが何で、データをロスするパターンはどういうものかを理解しなくてはいけなくなる。そこに手をつけなくてはいけないのは頭が痛い。

であるとし、プライベートnpmレポジトリの採用を断念。ひとまずは、GitHubエンタープライズをプライベートモジュールのソースとして利用することにしたとのこと。

外部リソースへの依存については、パブリックのnpmモジュール以外もJQueryのドキュメントやGoogleの検索機能など様々で、メリットとして現に生産性のアップを享受できてるゆえに、依存関係を全て解消できるわけではないとし、ポイントは、どれだけリスクを下げられるかだとしています。そこで、一番重要なのは、パブリックのnpmレジストリに依存せずにデプロイすることであるとし、プライベートnpmを採用しなかったゆえに、残りの選択肢は、node_modulesディレクトリにチェックインすること。対応策を決めるのに、BoxにおけるNode.jsのプロジェクトのタイプを分析しています。

1) ライブラリ: プライベートnpmのモジュールとして作成し、他のプロジェクトで依存先として利用される。ライブラリはプロジェクトの一部というかたちでのみデプロイされ、単独でデプロイされることはない。一度作成されたら、最初はかなりの頻度で更新され、安定してきたら、バグか新機能追加がない限りはアップデートされない。

2) コマンドラインユーティリティ: 開発環境にインストールされる前に、プライベートとパブリックのコマンドラインユーティリティがRPMにバンドルされる。デプロイした初期の更新を過ぎれば、主要なアップデート以外では変更はない。

3) webアプリ: 本番環境に投入し、顧客に提供するプロダクト。webアプリのための開発は継続的で頻度が高く、担当者ベースでなくチームを巻き込むことになる。

ディペンデンシーにチェックインすることは、コミットも肥大化するので極力避けたいとし、方針としては、

1) ライブラリは、それ自身だけがデプロイされることはないし、ライフサイクルも短いので、ディペンデンシーに必ずしもチェックインすることはない。Boxのメンバがコマンドラインユーティリティかwebアプリを扱っていて、ライブラリをnpmからインストールするということは、ライブラリのディペンデンシーは最終的にはレポジトリにある。パブリックnpmレジストリがダウンしたら、ライブラリのアップデートができないが、これはパブリッシュされたモジュールと問題は同じ。

2) コマンドラインユーティリティのディペンデンシーもチェックインしない。ユーティリティをRPMにパッケージするときは、依存関係は全てダウンロードされて最終的にはRPMに含まれることになる。そしてRPMをオフラインでデプロイできる。パブリックのNnpmレジストリが落ちれば、RPMの作成ができなくなるが、新しいNode.js RPMをつくる頻度を考えると、リスクは低いと見ている。

3) Webアプリがディペンデンシーをチェックインする唯一のNode.jsプロジェクトとなる。どのような時であれ、チェックインされたソースコードは本番環境にデプロイできる状態にしている。対象は、内製のライブラリもパブリックなライブラリも両方含む。もしパブリックのnpmレジストリが落ちれば、簡単にアップデートするのが難しくはなる。

また可能性としては低いが、「ディペンデンシーを緊急で更新しなくてはいけない事態になったら、内部のライブラリもパブリックのモジュールもソースコードを確認して手動でアップデートすることで、出血を止める。」としてます。

Boxとしては、現時点でのやり方を参考のためにシェアしているが、Node.jsの依存関係を管理するガイドとして皆に勧めているわけではないとしてます。法人化して資金調達したnpmも「プライベート関連のソリューションで将来はマネタイズしたい。」と発表してますが、このあたりもDejan Glozicが期待しているように段階的に改善されていくのでしょうか。


広告でサポートいただけるスポンサー企業様の募集をしてます!


#node.js #npm

Jshiike 3年以上前 | ▲upvoteする | link

@yosuke_furukawaさんのgitnpm: npm wrapper for libraries not published to npm, but uploaded on git

https://github.com/yosuke-furukawa/gitnpm

Jshiike 3年以上前 | ▲upvoteする | link

ちなみに、Boxは、DropboxのエンタープライズIT市場向けの製品という立ち位置で比較されることが多かったですが、Dropboxよりも先に上場するようです。上場資料によると、SaaSの他の上場企業を大きくしのぐ勢いで営業コストをかけて、トップライン(売上)のアップに邁進しているようです。利益は無視してとにかく市場シェアを取りにいくというアグレッシブなかたちですね。

Back