Notices by まちカドおるみん御嬢様 (orumin@mstdn.maud.io), page 283

既に RoR の人材が多い国内企業とかならそれでもいいだろうけれど、Kubernetes にしろコンテナランタイムにしろ Go が増えているので Go のほうが人材の確保や保守がやりやすい、みたいな事情もあって RoR が別の言語で書き直される、とかになってる気がする

べつに RoR でも scale-out させるのやってやれないことはなさそうだけれど、そこまでして Ruby に固執して Ruby 人材を集める必要があるかという問題が出てくる >>

“今回のプレゼンでは、このRuby on Railsを用いたシステムがAWS上で大規模にスケールアウトして、かつ高速に動作するということをお伝えしようかと思います。”

Ruby on Rails × AWSにおける最適化　レスポンスタイムを200ms→100msにするためにやったこと - ログミーTech https://logmi.jp/tech/articles/304537

人が保守管理するから、というのもあるけれど、それよりも private にしろ public にしろ cloud 的なインフラに載せて on-demand に scale-out させようとしたとき、うまいことボトルネック部分だけ scale して解消する、みたいなのが難しいだけという感じのイメージ

逆に cloud native だからってなんでも micro service に細かく分割するとそれはそれで service call がボトルネックになって普通に終わったりする

適切に scale するなら monolith のほうが良いこともあるので、case-by-case

少なくとも、Ruby on Rails の monolith は大抵の場合 service の拡大に対応できなくて行き詰まって結局どこかで別のものに書き直す、というのがパターンとして多い

ただしなんでもかんでも monolithic にするのをやめて適切なサイズに問題を分割して適切な手法で解決を行なうと適切なパフォーマンスが得られる

べつに monolith を micro にしたからといって高速になるわけじゃないです

“GitHub の有名な Ruby モノリスを解体し、GitHub のすべてのユーザーのためにリポジトリのパフォーマンスを向上させる新しいマイクロサービスを Go で作成しています。”

GitHub における大規模なモノリポのパフォーマンスの向上 - GitHubブログ https://github.blog/jp/2021-03-19-improving-large-monorepo-performance-on-github/

そもそも Linux kernel なんかは tuning nob がたくさん付いてるから動的に設定変えて環境に最適化してより performance の向上ができるわけで

べつに zeroconf であることと performance で劣るかどうかは別軸

まあそれに限らず地図を見るのは一般に面白い

極点を中心にした地図とか見ると面白いよね

@shijin たとえば transfer も xfer とかに略されがち（Linux kernel 内部の API 名とかでもありがち）なので、trans が X なのは英語だとコモンセンスっぽい

@shijin transform が x だよ。

陸軍の近代化で外せないのはナポレオンなんだけど、ナポレオン戦争に参戦したプロイセンがドイツ統一や軍隊の近代化に果たした役割も大きいよね、という話？

メモ板に封印されてしまった……。

消しゴムもアンドゥもない世界久々に体験してるけど修羅やな。

@plinius そういえばロシア長年の悩みだった不凍港を持ちたい、という願いも案外気候変動が解決する可能性もあるのか……。

まず神ではない。