Ubie は Go と Node.js の会社になります

Ubie では、創業当初から Server-Side Kotlin を推進してきましたが、全社的な技術選定を再度行い、これからは Go と Node.js を中心とすることにしました。 本記事では、Go と Node.js を選定した理由や、それを普及させる取り組み、そして選定の流れを紹介します。 経緯 これまで Ubie では技術スタックを発散させてきていて、現在は Kotlin、Go、Node.js、Ruby、Python のバックエンドサービスが動いています。以前は新規開発が多く、それぞれに携わるメンバーが技術選定をすることにより、最大瞬間風速を出せるなどのメリットがありました。しかし、現在では弊害が目立ってきています。 まず、事業成長に伴って運用の重要性が増しています。人材が潤沢とは言えないスタートアップにおいて、様々な技術スタックを安定運用することはコストが高すぎると感じています

[joker1007]

本当にそういう選択理由なのだろうか？所属メンバーの技術スタックにおける親和性の問題の方が大きそうに見える。JVMでスケールとパフォーマンスに問題あるなら、行く先は現状C++かRustぐらいしかないと思う。

[ebo-c]

私の知見だと確かにJVM on k8sはめんどくさい点があって、k8s上でJVM起動引数でメモリとかパーセンテージで指定すると、ホストマシンのリソースに対する比率でリソースをモグモグするのよ。k8sなのにノードのVMを知る必要が

[ed_v3]

JS/TSしか書けないとかでなくGo書ける人いるならNode.jsはやめた方が良いんじゃないかなぁ。JSのエコシステムの辛さがバックエンドにも全部来るのは長期的には結構大変だよ。セキュリティ、型の弱さ、移り変わりの速さ等

[Pasta-K]

こういうのバーンと出てくるの良いな

[snowcrush]

他社の選択によくここまで上から目線で言えるなーと言いたくなるブコメの数々。記事の内容は外向けの表明としては充分だと思う。

[rgfx]

このツリーと合わせて読んでいる　https://twitter.com/joker1007/status/1603002036890763270

[gfx]

Ubie、Kotlinやめるってよ。

[yfa02050]

こういうことを繰り返して、社内の技術スタックはとっ散らかっていく。

[tsimo]

JVMでパフォーマンスが問題になるんだったらC++とかRustとかになりそうな。

[nunulk]

"JVM の運用はやはり難しいです。実際に、スケーラビリティやパフォーマンスが問題になることは何度かありました。"

[diveintounlimit]

うーん他にいろいろ検討したのかも知れないが、ここに記載されている理由がすごい薄っぺらいので、甚だ不安になるな。。。

[non_117]

医療ドメインが複雑なのにKotlinをやめるのはよくわからなかった。複雑なドメインはそれこそJavaとか……。

[noseld]

Kotlinのビルドに時間かかってDX悪いのは毎回思う。体感GoエンジニアってJVM系より希少種だけど採用課題解決するのかな？

[strawberryhunter]

最近のJVMはコンテナを検出して正しく振舞うと思うが詳細は知らない。JVMが難しいのではなくてJVM自体の知識とk8sと組み合わせたりする時のノウハウの問題ではないか。

[taguch1]

みんな言葉強くなってて笑うw

[delphinus35]

やはり「採用できねぇ！」ってのが本音では。この人材難では。

[ssig33]

「私達は馬鹿です」って言ってるようなもんだしこんなの自信満々に書くことではない

[zgmf-x20a]

やぐさんの記事だとばかり…

[akymrk]

“JVM の運用知見を持ちつつ、Ubie の人材要件にマッチする候補者はかなりレアで、採用できていません”

[chimerast]

Kotlinエコシステムの調査不足+Springのせいに見えて、Kotlinそのものは起動も速いしJVMも全然悪くないのになんだか誤解を与えそう。Kotlin書いていて楽しい(=生産性が高い)なら使い続けた方がいいのに。GraphQLにも突っ込みたい

[katzchang]

JVM、ゆーてもメモリ管理に気をつければ大抵は何とかなると思ってるけど、どうなんだろ。

[hateshinaiz]

JVMの下りがなければ炎上することはなかっただろう というエントリ

[queeuq]

ServerSideKotlinは悪くないけど微妙。JVMから離れられないなら仕方ないけど積極的に選ぶ必要性は無いなーって印象/JVMとGoがGCあるから同じってGraalVMとかゴリゴリ使ってるような環境の人なんかな。

[yarumato]

“ Server-Side Kotlinは、静的解析やフォーマッタが IntelliJ IDEA にインテグレートされていて扱いにくい。ビルドが遅い。最近の開発がKotlin/JSやKotlin/Native向きで方向性が違う。JVM の運用は難しい。”

[remonoil]

"事業成長に伴って運用の重要性が増しています。人材が潤沢とは言えないスタートアップにおいて、様々な技術スタックを安定運用することはコストが高すぎると感じています。" あるある

[habarhaba]

がんばってください。どこの会社も大体やりきらないで中途半端になる。

[peketamin]

rustを外したのはWebサービスよりもシステムプログラミングに向いてるからとかの判断したのかな

[clubman023]

わかる

[katsyoshi]

“一方で、静的解析やフォーマッタが IntelliJ IDEA にインテグレートされていて扱いにくかったり、” ほんまか？今どきCIでもできるように外部からも叩けるようになっていないのか。

[Keisuke69]

Kotlinやめる理由が書かれてるくらいだとそれほど大きな問題に思えなかったんだが実際のところどうだったんだろ

[mizdra]

選定の根拠なるほど。サービステンプレートやガイドライン用意してるの丁寧だなー。

[door-s-dev]

JVMでパフォーマンス問題ってなんだろ。goもgcはあるよな/少し書き換わったね。まあ社内にgoには詳しい人がいてJVMには詳しい人がいなかったなら分かる

[Shisama]

UbieさんはKotlinのイメージが強かったけど、Goへ行くのかー。弊チームとスタック似ているけど、うちはconnect-web使ってフロントエンドからgRPCでやりとりしてますが快適です！（モック以外）そしてガイドラインすばら