Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スタートアップは Rails を使うべきか / Should Startups Ride on...
Search
Yuya Takeyama
December 08, 2018
Programming
7
2.6k
スタートアップは Rails を使うべきか / Should Startups Ride on Rails?
Yuya Takeyama
December 08, 2018
Tweet
Share
More Decks by Yuya Takeyama
See All by Yuya Takeyama
Terraformで実現するHR Driven Provisioningとアクセス制御の自動化 / HR Driven Provisioning and automation of access control using Terraform
yuyatakeyama
1
170
GitHub Actions/Docker/Terraform/Renovate で最小限の Monorepo CD パイプラインを作る / Minimalistic Monorepo CD Pipeline with GitHub Actions, Docker, Terraform and Renovate
yuyatakeyama
4
400
コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as Codeパイプラインを考える / Scalable and Secure Infrastructure as Code Pipeline for a Compound Startup
yuyatakeyama
5
5.9k
スタディサプリ小中高のオブザーバビリティ / Observability in StudySapuri
yuyatakeyama
1
2.7k
How Quipper Works with CircleCI
yuyatakeyama
4
3k
Quipper のマイクロサービス化への道のり / Quipper's Road to Microservices
yuyatakeyama
5
2.1k
Quipper における SRE チームの紹介 ~僕が SRE になった理由~ / Why I Became an SRE at Quipper
yuyatakeyama
3
2.9k
Other Decks in Programming
See All in Programming
C++でシェーダを書く
fadis
6
4.1k
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
190
Flutterを言い訳にしない!アプリの使い心地改善テクニック5選🔥
kno3a87
1
160
聞き手から登壇者へ: RubyKaigi2024 LTでの初挑戦が 教えてくれた、可能性の星
mikik0
1
130
ヤプリ新卒SREの オンボーディング
masaki12
0
130
Better Code Design in PHP
afilina
PRO
0
120
NSOutlineView何もわからん:( 前編 / I Don't Understand About NSOutlineView :( Pt. 1
usagimaru
0
330
RubyLSPのマルチバイト文字対応
notfounds
0
120
みんなでプロポーザルを書いてみた
yuriko1211
0
260
Tauriでネイティブアプリを作りたい
tsucchinoko
0
370
Macとオーディオ再生 2024/11/02
yusukeito
0
370
TypeScript Graph でコードレビューの心理的障壁を乗り越える
ysk8hori
2
1.1k
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Designing for humans not robots
tammielis
250
25k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Into the Great Unknown - MozCon
thekraken
32
1.5k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
Six Lessons from altMBA
skipperchong
27
3.5k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
Navigating Team Friction
lara
183
14k
Being A Developer After 40
akosma
86
590k
Why Our Code Smells
bkeepers
PRO
334
57k
Docker and Python
trallard
40
3.1k
Transcript
スタートアップは Rails を使うべきか @yuya-takeyama SRE at Quipper
今日話すこと • スタートアップ期をとっくに終えた今も Rails を 使い続ける会社にいて感じていること • 副業含めてスタートアップやベンチャーの人から の相談に対して話してきたこと •
そういった中から感じた「魅力的な会社」と「働 き方」について
自己紹介 • @yuya-takeyama • 2015 年 9 月 ~ Web
Developer at Quipper ◦ Rails, React, React Native など • 2018 年 4 月 ~ SRE at Quipper ◦ Kubernetes を使ったプラットフォームの構 築、移行
自己紹介 • 副業 at 株式会社オクタウェル ◦ ヘルスケア系スタートアップ ◦ PHP, Laravel,
AWS Lambda (TypeScript), CircleCI 等
スタートアップは Rails を使うべきか
結論
好きなフレームワークを 使えばいいと思う
2018 年における Web アプリケーション • フロントエンドも含めて作り込まれていて当たり 前 ◦ SPA, SSR,
PWA... • フレームワークにはフロントエンドの開発も含め た機能セットが求められる • 一方でサーバサイドでは API だけで十分、とい う領域も増えてきた
そんな時代における Rails • 時代に合わせて進化を重ねている ◦ Asset Pipeline (Rails 3.1~) ◦
Webpacker (Rails 5.1~) ◦ API モード (Rails 5~) • 基本的にはフロントエンド・サーバサイドともに いい感じのデフォルトが提供されている ◦ Rails is omakasae (2012)
Rails is omakase の逆の側面 • Rails のやり方が気に入らなければ Rails を使わ なければ良い
◦ フロントエンドは Babel, Webpack, TypeScript のビルド環境を自分で整えて ◦ サーバサイドは Go の net/http で手書きの Middleware と共に • 自分で選んで自分で作っていく (大変ですね...)
2018 年における Rails • 相対的には Rails を使い続ける理由は減ってきて いると言える ◦ 単純にその他の選択肢が増えて、意味を持っ
てきた、という意味で • でも絶対的に Rails の価値が下がったとは言えな い (たぶん)
Quipper と Rails • 2012 には Rails を使い始めている (今年で 7
年 目) • MongoDB (というか MongoMapper) が足かせと なって 4.2 で止まっている... • Heroku, Deis を経て Kubernetes に • マイクロサービス化がまさに始まろうとしている ところ
Web アプリケーションの構成要素と寿命 • アプリケーションコード • インフラ・クラウド • 言語・フレームワーク・ライブラリ • データ
Web アプリケーションの構成要素と寿命 • アプリケーションコード • インフラ・クラウド • 言語・フレームワーク・ライブラリ • データ
<- たぶんこれが一番長生き
データさえちゃんとしていればなんとかなる • 枯れたデータストアをちゃんと選んで使う • ちゃんとメンテされる ORM を選ぶ ◦ または ORM
を使わず抽象化を必要最小限にと どめる • データのモデリングはしっかり考える
データさえちゃんとしていればなんとかなる • という前提を踏まえれば、極論好きなフレーム ワークを使えばいいと思う • 特に好みや技術的に特殊な条件がなければ Rails 自体は決して悪い選択肢ではない ◦ 本当にダメそうならその時方向転換すれば良
い
スタートアップが 選ぶべきインフラとは
Heroku はいいぞ
複数のスタートアップの人と話して感じたこと • AWS 利用率の高さ ◦ EC2 を手動で立てて git pull でデプロイしてい
たり ◦ ECS でデプロイの仕組みをめっちゃ頑張って 構築しようとしていたり • イケてなかった選定理由「投資家に言われたか ら」「知り合いの起業家が使っていたから」
複数のスタートアップの人と話して感じたこと • Heroku 利用率の低さ ◦ AWS に比べると Heroku を偉い人に通しづら い?
◦ ここを通せる腕力、または会社側に柔軟性が あると色々と良くなる • レイテンシをネックとしてあげるケースもある • プロダクトの構築・改善を最優先にすべきでは?
Heroku の良いところ • とにかくアプリケーションを立ち上げるまでが早 い! • 金でスケールできる • インフラとかコンテナのことを意識しなくて良い ◦
コンテナの偏りを直したりとか... • Review Apps, Add-on
Heroku の良いところ • 12 Factor App! ◦ サーバサイドアプリケーションにおけるアー キテクチャの養成ギプス ◦
これだけ守れてれば将来的にコンテナ化した り Kubernetes に載せること自体は全然難しく ない
おまけ: Heroku のレイテンシに関して • CDN を利用すればある程度改善できる (キャッ シュしない動的コンテンツでも) ◦ Edge
TLS Termination, Route Optimization, Dynamic Site Acceleration… ◦ Sinatra で 800 msec 程度が 500 msec 程度に ◦ 速くはないがそんなに悪くもない? (B2B サー ビスなら特に)
まとめ
スタートアップ期の会社にオススメしたいこと • フレームワークに何を使うかは些細な問題 ◦ データやモデルにこそ目を向けるべき • プロダクトの開発に集中するためにコストを使う ◦ Heroku はいいぞ,
Kubernetes は多分まだいい ◦ 他の PaaS でも楽できるならなんでもよし • 何をやる・やらないにしても理由づけを明確に ◦ 枯れた技術でもプロダクトをしっかり作れている会 社はそれだけで十分魅力的
エンジニアとスタートアップの関係性 • 働くならプロダクトに向き合えている企業 ◦ その分技術的負債を抱えていたとしても、自 分の知見で一気にレバレッジがかけられるか も ◦ 短期間・高単価で働けるチャンスもあるかも •
そういったことがあちこちで起これば業界全体の レベルアップにも繋がりそう