コスパ最強アーキテクチャT3-Turboを紹介する
はじめに 個人開発ほど零細規模でもなく、モジュラモノリスやマイクロサービスを使うほど大規模でもないが、小〜中規模な開発の際にT3-Turboアーキテクチャを使うことでコスパよくシステム構築できます。名前の由来はT3-StackとTurborepoになります。個人開発としては素晴らしいT3-Stackですが、T3-Stackではデメリットとなった密結合や拡張性の問題を、monorepoツールやサーバサイドを採用することで解消し、より大きなチーム開発でも対応可能になっています。 技術要素 2023年5月に行われたVercel Shipの中で、Vercel社がフルスタックな開発環境を目指していることがわかりました。このT3-Turboアーキテクチャでは、Vercel社が出している技術を中心に、それらと相性の良い技術を組み合わせて採用しています。 Turborepo Vercel社によって開発され
ログラスのバックエンド技術スタック2023
はじめに こんにちは、ログラスの小林(@mako-makok)です！ 昨日は@asa_kossyさんの「ログラスのプロダクトマネージャーチームが今年取り組んだこと、いま苦労していること 2023」でした。 ログラス社はありがたいことに、 CTO 協会主催の「開発者体験が良い」イメージのある企業で 25 位にランクインさせていただいております。 この結果は非常に光栄だと思っており、自分が想像する要因としては DDD、スクラム、技術的投資の 3 点だと思っています。 これらは継続的に活動しています。 ライブラリバージョンアップは欠かさずやりますし、DDD に関しては社内で DDD という言葉はもうほぼ使われていないレベルで浸透しており、機能追加の際はドメインエキスパートと会話つつ、モデルと実装を行き来して開発しております。 この認知は非常に嬉しい結果ではありますが、実際は開発者体験に課題を感じ
こんにちは。バックエンドエンジニアとしてアソビュー！の開発を担当しているけんすーです。 2022年5月にアソビューに入社してから半年以上が経過し、日々業務に励んでいます。 今回は私の転職経緯や実際に半年間アソビューで働いてみての振り返りを書きたいと思います。 テックブログの記事ではありつつ技術の話はほとんどありませんが、弊社に興味を持っている皆さまの参考になれば幸いです。 経歴について 私は2020年に都内で受託開発やSESをやっているIT企業に新卒入社しました。主にJava/Spring BootでのWebアプリケーション開発や官公庁系の大規模なシステム開発まで経験を積むことができました。 しかしながら現場での開発を続けていくうちに、誰に向けてプロダクトを開発しているのか見えにくい環境に不満を感じるようになりました。お客様と携わりながらプロダクトを成長させていきたいという思いが募り、契約
マイクロサービスはアンチパターン
マイクロサービスの矛盾先日、「マイクロサービス？モノリス？SaaSアーキテクチャのPros/Cons | SaaS.tech #1」(youtube)(togetter)というイベントを観ました。これは、マイクロサービスのイベントだったのですが、新規のシステム開発において積極的にマイクロサービス化をすすめる方が少なかったのが意外でした。 マイクロサービスの開発経験のある優秀なエンジニアであっても、まずはモノリスからはじめてプロダクト境界を意識して設計していき、functionベースで切り出せるもの(認証や通知、メール送信、バッチ等)は切り出しつつ、必要であればモジュラーモノリスかマイクロサービス化を慎重に検討するということでした。素晴らしい冷静な判断です。 というのは、ドメインの専門知識がないうちにマイクロサービスの複雑なシステムを設計するのは、多くのソフトウェアプロジェクトが陥りやすいリ
モノリポとマルチリポの比較が浮き彫りにする開発能力を高めるための課題とトレードオフ - mtx2s’s blog
ソフトウェアプロダクトに対して求められ、日々繰り返される機能追加は、コードベースを肥大化・複雑化させ続ける。成長する組織では、開発者の増員がそれを更に加速させるだろう。そして、認知負荷の軽減を目的に、いずれはコードベースの分割について考えるようになる。その目指すアーキテクチャがマイクロサービスにせよ、モジュラモノリスにせよ、コンポーネントやモジュール単位でリポジトリを分けるというのが、コードベースのもっとも一般的な管理方法ではないだろうか。 しかし、ここにはもう1つの選択肢がある。「モノリポ（モノレポ）」だ。すべてのコンポーネント、モジュールを1つのリポジトリで管理する。それどころか、社内のあらゆるソフトウェアプロダクトを1つのリポジトリで管理することさえあり得る。 モノリポにはどのような利点や欠点があるのだろうか。私自身、小規模のマルチプロジェクトリポジトリを複数組み合わせて扱うことが多
問題を抱えるソフトウェア開発組織を観察すると、その根本原因が組織設計にあると気付くことも多い。組織の構造的な歪みがまるで力場を形成するかのように、そこに配置された様々な要素に作用し、悪影響を及ぼしている。 組織設計のまずさから生じる問題というものはとらえ難く、理解し難い。その問題に気付かないから、真っ先に矛先がソフトウェアエンジニアリング領域へ向いてしまい、開発プロセスやソフトウェアアーキテクチャの改善を繰り返すが大きな効果が得られない。効果があったとしてもそれは一時的で、気付けば元に戻っている。 コンウェイの法則を思い出せばその従属関係に頷けるはずだが、多くの現場ではこういったソフトウェアエンジニアリング領域に閉じた施策に終始しがちではないだろうか。 以下に挙げる3タイプの組織問題は、ソフトウェアエンジニアやマネージャーとして私が実際に経験したいくつかの事例をタイプ別に集約したストーリー
本記事はRettyマイクロサービス強化月間の四つ目の記事です. engineer.retty.me RettyのtoB開発チームでエンジニアをしています鈴木です. 社会人エンジニアも早いことに１年が経ってしまい, “ピチピチエンジニア” の称号と権利を失ってしまいました. 今年は “深みと勢いのエンジニア” として活動しています. ピチピチエンジニアとして投稿した以前の記事では, その時おすすめの焼き芋を紹介したので今回も最近おすすめのお店としてMEARIを載せます. retty.me 今まで実家の焼き鳥が一番美味しいと思っていた自分に衝撃を与えたお店です. 早速本題に入りますが, RettyのtoB開発チームではtoC開発チームと同様にPHPで作られた大きいモノリスからGoで書かれたマイクロサービスへの移行が進んでいます. 現在, Rettyにおけるとても重要なシステムである予約APIの
Monorepoとは？ Monorepoとは一言でいうと、そのプロダクトに関するコードをすべて単一のリポジトリで管理する方法です。 なぜ Google は全てのコードをシングルレポジトリを管理しているのかを見ればわかる通りGoogleをはじめ、facebook、Twitterなどの世界の名だたるテックカンパニーでも採用されている手法です。日本ではメルカリグループのソウゾウが導入していますね。 流行り出した背景 マイクロサービス アーキテクチャの普及につれて、それぞれのサービスは解決すべき課題にあったツールや言語を使用し、それらを書く開発チームが独立したリポジトリで管理していくことがスタンダードとなってきました。（いわゆる Polyrepo） これによりマイクロサービスを迅速に実装し、担当者が別々にデプロイを行なうことで、各サービスや開発チームの独立性を保ったまま、ソフトウェア開発のスピード
2023/01/31で株式会社カルテットコミュニケーションズを退職し、2023/02/01から株式会社リンケージに入社します - 77webの新しいブログ
2023/01/31で8年11ヶ月勤務した株式会社カルテットコミュニケーションズを退職し、2023/02/01から株式会社リンケージに入社します。 引き続きPHPを書いていくのでよろしくお願いします！ カルテットでやってきたこと Web広告の運用支援SaaS Lisket の開発・運営 https://lisket.jp いまコアとなっている機能のバックエンド開発にメインで携わりました 一回モノリスとして開発したものがうまく機能しないケースに直面し、マイクロサービス化を実施して運用まで担当しました 必要に迫られて、PHPだけでなくJavaのマイクロサービスが生まれたため、勉強して保守・機能追加しました リニューアルプロジェクトのバックエンドプロジェクトリーダーをやりきりました ユーザーサポートやプロダクトマネジメント・マーケティング等、開発だけにとどまらず運営についても幅広く関わりました
mtx2s’s blog
デプロイ頻度とリードタイムは、開発チームが自らのパフォーマンスをモニタリングするうえで欠かせないメトリクスである。それらが、収益性や市場占有率といった組織パフォーマンスに影響を与えるからだ。その調査結果は、DevOps Research and Assessment（DORA）が特定した4つのキーメトリクス、いわゆる「DORAメトリクス」の要素として浸透した（後述するが、DORAメトリクスで扱うのは、リードタイムではなく「変更のリードタイム」である）。 その重要性ゆえに、チームや組織はこれらのメトリクスの計測と可視化に努める。可能な範囲で正確な値が欲しい。そうして、チケット管理ツールやバージョン管理システムからテレメトリを収集、集計し、チームのモニタリングダッシュボードにその実績値を可視化するのだ。 しかし、しばらくメトリクスを運用してみると、その扱いづらさに気づく。計測値や集計値のばらつ
2021年にブックマークした記事まとめ - ぷらすのブログ
2021年にPocketに保存した記事をマークダウン形式で出力するツール. Contribute to p1ass/list-pocket-saved-items development by creating an account on GitHub. 注意: タグはかなり適当 バックエンド Go Nintendo Switch™ ネイティブバイナリへの Go コンパイルを成功させた話 Go の入力バリデーションパッケージ ozzo-validation を試した。 k0kubun/pp: Colored pretty printer for Go language OpenTelemetry in Go Go のロギングライブラリ 2021 年冬 GraphQL の静的解析基盤を作った Go のリリースプロセスとブランチ戦略 Go 1.16 の signal.NotifyContext
PHPerKaigi 2022 スライドまとめ
2022/04/09から2022/04/11で行われているPHPerKaigi 2022に参加できなかったのであとから見るようにスライドを集めてきました。 2022/04/09（土） PHPのエラーを理解して適切なエラーハンドリングを学ぼう by 並里 Datadog APM で始める Laravel アプリケーションのパフォーマンスチューニング by 小黒 陽弘 サムザップにおけるNotionの活用事例とPHPでのNotionAPIを利用した仕組み構築の紹介 by 若田部 誠 エラー監視とテスト体制への改善作戦 by ヒエイカザト サイト制作をぐるっと一周して分かった、WordPress が人類に提供しているもの by 株式会社あつまる 三井 翔吾 未発見 2022/04/10（日） 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント by 和田卓人 PHP で NFC リーダ
アソビュー Advent Calendar 2021の5日目です🎄 アソビューでVPoEとTech Lead時々SREをしているdisc99🐼です！ 🐣はじめに アソビューではサービス立ち上げから9年が経過しましたが、コロナなどの逆風化においても、創業以来、右肩上がりの成長を続けています。 この記事では、これまでのサービスの歴史と、その中で起こった問題から、どのような取り組みを行っているかを紹介しようと思います。 尚、今回の取り組みに関しては、主に技術的取り組みにフォーカスしています。 また、文中ではマイクロサービスに関わる話が出てくるため、各用語は以下の意味を指しています。 アソビュー：アソビュー株式会社（サービス名と会社名が同じため） サービス：アソビューが運営しているEC、SaaSなどのプロダクト アプリケーション：JavaやPythonなどで作られた1つのシステム 🌱サイロ
巨大なモノリシック Rails アプリケーションの マイクロサービス化戦略 / 2019 microservices in cookpad
「価値提供スピードを上げるための技術的負債への向き合い方」は、DMMオンラインサロン事業部がこれまで向き合ってきた技術的負債とその解決策について、深く掘り下げるイベントです。ここでアーキテクトチームの塚原氏が登壇。現在取り組んでいるマイクロサービス・モジュラモノリス化プロジェクトについて話します。 塚原氏の自己紹介 塚原諒氏：こんばんは。今日は「マイクロサービス・モジュラモノリス化によるシステム負債の解消プロジェクト」というタイトルで発表します。 （スライドを示して）まずは自己紹介をさせてください。名前は塚原諒といいます。2022年の4月に中途でDMMに入社して、オンラインサロン事業部のアーキテクトチームに所属しています。 ふだんは本日紹介するマイクロサービス、モジュラモノリスでのリプレイス業務を主にやっています。（スライドには）書いていないんですが、好きなテキストエディタは「Vim」です
はじめに みなさまこんにちは！ 株式会社プラハでエンジニアをしていますAwataです。 早いもので、プラハに入社して1年が経過しました。 そして直近の案件からリーダーを務めることになり、つい先日無事にリリースまで完了しました！ とても学びの多い機会だったので、振り返ってみたいと思います。 また、会社のPodcastでもリーダーとしての振り返り会を行っていますので、興味がある方はぜひそちらも聞いてみてください！ TL;DR かなり長い記事になるので、リーダーをやってみて感じたことを最初にまとめておきます。 実際のスプリントが始まる前に、そのプロジェクトの成功の定義と失敗の定義を決めておきましょう。 そしてなるべく早く、失敗の要因になりえる懸念は取り除けるようにリーダーとして必要なことをやりましょう。 全体での振り返り以外にも、個別の1on1は必ずやりましょう。 どうして？何を話すの？という疑
各社がアーキテクチャを語る「Engineering Team Presentation」を開催しました - Sansan Tech Blog
こんにちは、プロダクト戦略開発室の相場です。 今回は先日開催した「Engineering Team Presentation 〜各社の事業を支えるアーキテクチャ〜」のイベントレポートをお届けしたいと思います。 sansan.connpass.com これまで開催したイベントのアンケートで「各社のアーキテクチャ」に関連するイベントに参加したいと多くの声をいただいており、弊社が運営する「Builders Box」のサポーター企業である日本経済新聞社さん、メルカリさんに加え、 DeNAさん、freeeさんにも協力をお願いし、今回の企画が実現しました。 最終的には700名以上の方にお申し込みいただき、「アーキテクチャ」は関心の高いトピックであると改めて感じるとともに、予想を超える申込者数に運営メンバーは少しドキドキしながら、当日を迎えました。 発表1：『日経電子版のキャッシュ戦略』 株式会社日本経
2022/10/21~10/22にKaigi on Rails 2022が開催されていました。まず最初に自分はただのいち視聴者でしかなかったですが、運営・スピーカーの方々へはお疲れ様でした&ありがとうございましたという気持ちです。 さて連日様々な発表が行われていましたが発表スライドが一箇所にまとまってる場所がまだ中々見つからなかったのでここへリストにしておきます。一部スライドを見つけられなかったセッションもありますが、もし見つけたら更新する予定です。何か間違い等あれば@razokuloverへご連絡ください。 1日目 あなたとRails お隣さんの API のデータを Rails らしく、しなやかに扱う RBSとSteepで始める型のあるRails開発とその運用 システム開発を支えるメタプログラミングの技術 / kaigionrails-2022 7つの入金外部サービスと連携して分かった実
Laravelをモジュラモノリスで開発する
中小規模のLaravelは、初期はモジュラモノリスで運用し、サービスが複雑/大規模になって行く過程で、モジュールをマイクロサービス化していく運用が初期開発が抑えられ、かつクリーンなコードも実現できて良いのではないのでしょうか？ モジュラモノリスとは モノリスアプリケーション内で、ドメインモデル等を単位としてモジュールに分解し、モノリスのように1つのデプロイパイプラインだけを持ちつつも、マイクロサービスのようにシステムのモジュール化・独立性を両立したモノリスアプリケーション。 モジュラモノリスの長所 モジュラモノリスの長所として、以下のようなものが挙げられるかと思います。 モノリスであるため、開発がマイクロサービスと比較し容易である コンテキストの境界がモジュール毎に明白になる モジュール毎にマイクロサービス化を進める事が可能である モジュラモノリスの短所 モジュラモノリスの短所として、以下
改善か？刷新か？──Safie・freee・SmartHR 3社の事例から学ぶ「技術負債」との向き合い方 - TECH PLAY Magazine
開発にはつきものと言える「技術的負債」。長く開発を続ければ、続けるほど溜まっていくため、事業の拡大を図る企業にとって、深刻なネックとなっています。開発スピードが鈍化するといった懸念から、いつ、どのような手法で改善に取り組めばよいのか、判断することが難しい技術負債との向き合い方について、Safie・freee・SmartHRの事例から学びます。 登壇者プロフィール 森本 数馬氏 セーフィー株式会社 取締役 開発本部本部長 兼 CTO 2001年東京大学工学部を卒業後、ソニーに入社。営業職から開発職にキャリアチェンジし、Walkman、カメラなどのシステムLSI開発からTVなどメディア系プロダクトのソフトウェア開発を経験する。2012年 GREE CTO室勤務を経て、2013年にソニーからスピンアウトしたモーションポートレートに入社。顔認証技術を利用したライブラリ開発に携わる。2014年10月
アルプの開発チームがどのように開発手法を試行錯誤しているかを残しておく。振り返ることでこれまでどのようなことを、どのようなチームで、どのようなアイデアで解決してきた*1のかを整理できる。 改めて振り返ってみると「開発手法に銀の弾丸などない」という一言に尽きるくらい、変化が激しい。それでもやってこれたのは、より良い開発にこだわり続ける情熱を持ちつつ、変化に寛容なチームだからだろう。 なお、これは古いドキュメントを辿った断片的な情報の集約であり正確ではないため、チームからのレビューなどでアップデートされる可能性が高い。 「誰かのために〜」とは考えていないが、あえて言うならば、これから入る未来の仲間へ向けていると言えるかもしれない。歴史は文化として残るか、文章になる。文化は僕らが行動で示していくが、理由を知りたい人もいると思う。そんな人はこのブログを読むのをお勧めする。 これを読まなくても困らな
マイクロサービスがその進歩する方向を見出したのは、DevOpsの導入に伴うものとしてでした。当時、チームによるシステム構築方法としてのDevOpsは、特に継続的にデプロイされるシステムにおいて人気を集めるようになってきていました。 ただしそこには、コストという問題があります。今回の記事ではこのコストと、マイクロサービスにトレードオフの価値があるか、という点に注目していきます。 Wes Reisz: マイクロサービスの定義として私が気に入っているのは、Adrian Cockcroft氏の"コンテキスト境界内の細分化されたサービス指向アーキテクチャ"というものです。みなさんはマイクロサービスをどのように定義しますか？ Wrighson: この問題には何年も頭を悩ませてきたような気がします。それというのも、マイクロサービスを始めた当初の3年間は、DDDとの関係が十分に理解できていなかったからです
2022/03/24 15:05 - 15:35 AWS で実践！Analytics Modernization ～事例祭り編～ 面白法人カヤック 池田将士 @mashiike Amazon Redshiftを 1年運用して感じた教訓とその対策方針 アジェンダ ● 自己紹介・会社紹介・事業紹介 ● Redshift導入背景と採用理由 ● 1年運用して感じた教訓とその対策 ○ Ep1: 開発環境に関して (教訓1) ○ Ep2: Redshiftの新機能を試したい (教訓2) ○ Ep3: Clusterのお引越し (教訓3 ~ 5) ● まとめ 自己紹介 池田 将士 (@mashiike) 技術部 SREチーム所属 データにまつわる技術を担当 好きなAWSサービス Amazon S3 Amazon Kinesis Data Firehose Amazon Redshift 2016年末に新
マイクロサービスではなくモジュラモノリスを採用した理由
はじめに 皆様こんにちは、株式会社プラハのAwataです。 今回は、直近の開発において、マイクロサービスを検討をしたがモジュラモノリスを採用した経緯を書いていこうと思います。 案件の詳細に興味がある方は、以前書いたリーダーの振り返り記事を読んで頂ければと思います。 ※マイクロサービスやモジュラモノリスが何なのか？というそれぞれの詳細にはこの記事では触れませんのでご注意ください。 TL;DR マイクロサービスは思ったよりも難しい 組織的な問題がないならマイクロサービスはきっとまだ早い 将来的にマイクロサービスにするかもしれないなら、モジュラモノリスがいいかもしれない なぜマイクロサービスを検討したか 今回の案件では、既存システムとの連携が必須でしたが、既存システムのコードがかなり汚く、手を入れることが難しい状態でした。 そのため、既存システムのコードは極力触らずに新規サービスを開発したいと考
初めまして、株式会社スマートラウンドCTOの小山（@doyaaaaaken）です。 昨年末Startup CTO of the year 2022というイベントに出場して優勝し、その際のピッチ内容について解説する連続記事をこれまで書いてきました。 今回の記事はその4本目の記事となります。 もうじき今年のStartup CTO of the yearが開催されようとしている中、このシリーズが3本で止まっていた事実を思い出し、 「今年中にしか出せないネタなので書かねば！」 という気持ちになり急遽駆け込みで書きました。 拙い部分があればご容赦ください。 なお優勝ピッチ解説シリーズの他の記事は以下リンク先で公開しています。👇 🔗【優勝ピッチ解説(1)】スマートラウンドの開発体制ではスクラムをどう改変したか？ 🔗【優勝ピッチ解説(2)】スマートラウンドでISMS認証を取得した背景および得た知見
Spring Fest 2023での登壇資料
ScalaMatsuri 2020は、2020年10月17日～18日にオンラインで開催されたアジア最大級の国際Scalaカンファレンスです。ここで、アルプ株式会社の竹尾氏が、「モジュラモノリスで表現する複雑なドメイン領域と境界」というテーマで登壇。前半は「Scalebase」の概要と創業当初の環境について話をしました。 アルプ株式会社の取締役 竹尾正馬氏（以下、竹尾）：それでは始めます。アルプ株式会社の竹尾です。本日は「モジュラモノリスで表現する複雑なドメイン領域と境界」について発表します。よろしくお願いします。質問は発表終了後や、Discode内でまとめて回答したいと思います。 まず私、竹尾は、アルプ株式会社で取締役をしています。2018年に会社を共同創業して、エンジニアリング全般を担当しています。新卒の時には、サイバーエージェントのアドテクスタジオという部署でScalaをやっていました
背景 著者が開発に携わるサービスは拡大期にあり、リアーキしてモノリスからモジュラーモノリス化しようと計画している。 著者はモジュラーモノリス化することで著書・チームトポロジーで描かれるようなストリームアラインドチームができていく、という理想を抱いていたのだが、どうもそれにはハードルがあるように感じたので、課題感を言語化し、それにどう対処していくかを考えた。 チームトポロジー的理想と、それに対する課題 ▼理想 逆コンウェイ戦略によりモジュール分割され、そこに必要な職能のメンバーが集まってストリームアラインドチームができる。エンジニアの認知負荷は減少し、コミュニケーションや意思決定はチーム内で完結し、アウトカムが最大化される。 ▼課題 「PMによる日々の施策立案は、現在想定しているモジュールに閉じた形ではなされていない」という現実がある。このままでは、モジュール分割を達成しても、各プロジェクト
ScalaMatsuri 2020は、2020年10月17日～18日にオンラインで開催されたアジア最大級の国際Scalaカンファレンスです。ここで、アルプ株式会社の竹尾氏が、「モジュラモノリスで表現する複雑なドメイン領域と境界」というテーマで登壇。後半はモジュラモノリスの構築方法について話をしました。前回の記事はこちら。 実際のモジュラモノリス構築方法 竹尾正馬氏（以下、竹尾）：実際どうやって構築していったかを「How Did We Design It？」で説明していきます。まずScalebaseのアプリケーションは、こんなイメージです。依存性逆転の原則を適用して、上位レイヤーから下位レイヤーのみの参照を可能にしています。それぞれのレイヤーについて説明します。 Primary AdapterとSecondary Adapterは後々説明しますが、外部通信の役割を果たすものだと思ってください
株式会社SODAで運営するSNKRDUNKでは、サービス、リポジトリ、組織の急激な拡大に伴い、開発スピード、品質を落とさないようにGo+gRPCを利用し、将来的にマイクロサービスも視野にいれながらモジュラモノリスへのリプレイスを進めています。 社内で実践しているGo+gRPCでのモジュラモノリスでの実装方法や、現状抱えている課題などをお話できればと思っています。
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社タイミーの須貝氏が登壇。続いて、タイミーがどうやってモジュラモノリス化を進めているかについて話します。前回はこちらから。 タイミーが抱えていた課題 須貝俊 氏：続いて、タイミーがどうやってモジュラモノリス化を進めているかというところをより具体的に話していきたいと思います。 （スライドを示して）課題としてはスライドに示したようなものがあって、コード上で何が何に依存しているのか把握しきれない状態になっていました。上記に伴う変更による影響範囲がわからない。また、エンジニアの増加に伴ってチームも増えていくため、チームの責任範囲を明確にしていく必要が
こんにちは、CTOの松本です。最近はモノレポ構成にハマってます、アーキテクチャ設計が柔らかくなる感覚が好きです。 さて、今回は2022年3月15日にSaaS.techの第一回を開催させていただいたのでそのご報告をさせていただこうかと思います。 saas-tech.connpass.com ちなみにアーカイブ動画はこちらに。 www.youtube.com SaaS.techとは？ そもそもSaaS.techとはという話なのですが、本イベントはLayerXのイベントというよりも、SaaSに関わるすべてのエンジニアに向けたコミュニティイベントを目指して企画した勉強会となります。 ですので、レギュレーションとして会社紹介や採用宣伝は抑えるように設定しつつ、純粋に技術の話でワイワイできる場づくりを目指しました。個人的に、一企業で会社紹介たっぷりの構成でオンライン勉強会を開くフォーマットについてちょ
🎧 Railsのモジュラモノリス化とNext.jsの分割を実行中 #notetechtalk｜noteエンジニアチームの技術記事
noteのサーバサイドとフロントエンドのリアーキテクチャについて サーバサイドはPackwerkを利用してモジュラモノリス化 フロントエンドはNext.jsによるリアーキテクチャ それぞれの実施理由や進捗具合 ▼Podcastをもっと聴く
「マイクロサービス？モノリス？2社のアーキテクチャから見るPros/Cons」 記念すべき SaaS.Tech 第 1 回は「マイクロサービス？モノリス？2 社のアーキテクチャから見るPros/Cons」と題して、SmartHR、LayerX のアーキテクチャをそれぞれお話します。 本編ではテーマに沿った LT を、後半には参加者の皆さまからの質問に答えるパネルディスカッションも実施します！ https://saas-tech.connpass.com/event/239175/ ＜目次＞ 00:00:00 会場オープン 00:05:08 オープニングトーク 00:12:30 アプリケーションが大きくてつらい...ってコト！？ | SmartHR プロダクトエンジニア すがわらまさのり 00:34:45 絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ
2023 JSConf JP 資料まとめ
はじめに JSConf JPに参加してきました。 後で見返せるように資料をまとめておきます。 Youtube Track A: https://www.youtube.com/watch?v=yxMJaXke9Hc Track B: https://www.youtube.com/watch?v=N1lhkH33fwY Track C: https://www.youtube.com/watch?v=pdgB0Y5ZQGk- Track D: https://www.youtube.com/watch?v=rDfPXDEot_A 資料リンク There and Back Again: A Proposal's Tale Web Internals: Mastering the JavaScript Engine Deep dive into Biome LLM全盛時代の開発プラクティス M
第一線で活躍するCTOに日々の業務や未来をインタビューする「Voicy公式 厳選！CTO百景」チャンネル。ここで株式会社カオナビの松下氏が登壇。ここからは、カオナビに入社してからCTOに就任するまでのことを話します。前回はこちらから。 カオナビ入社時の状況 やまげん氏（以下、やまげん）：ここから（の）経歴の流れですが、カオナビさんでの実際の活躍や、やってきたことも話してもらえたらなと思います。 当初（カオナビに）入った時はCTOではないというお話でしたが、実際はどういったロール・役割で入られた感じなんですか？ 松下雅和氏（以下、松下）：開発の本部にプロダクト本部があって、プロダクト本部長の直下で自由に動きながらカオナビで働いて見えてきた課題や今後の方向性など（の判断）に対応してほしいとのことだったので。 けっこう自由度高く「このあたりちょっと危なそうだから、こう対応しておきますね」とか、「
Railsでサービスを開発 / 運用をしていると、コードの肥大化に伴うモノリシック化に悩まされることも多いはず。2014年のサービス開始からRailsで進めてきたnoteも今まさにその壁に立ち向かっている最中です。 Railsアプリケーションを分割しようと考えたときに、マイクロサービス化や別言語でのフルリプレイスなどを検討することもあるはずです。 様々な選択肢がある中で、弊社ではPackwerkの導入とRailsエンジン化による分割を進めることにしました。（※ packwerk：Shopifyが作成したgem。依存関係をパッケージによって整理することができる） Railsエンジンを採用した大きな理由としては以下が挙げられます。 すばやく小さく問題を切り分けることを優先 マイクロサービス化はアーキテクチャから考慮する必要があり時間がかかる 将来的なマイクロサービス化の下準備として進めることが
Object-Oriented Conference概要 ※イベント及びセッションの概要は公式HPから引用しました。 2020.02.16 SUN 10:00 - 17:00 お茶の水女子大学 #ooc_2020 Object-Oriented Conference はオブジェクト指向をテーマに、あれこれ共有したり、セッションを聴講することで、みなさんの知見を深めるためのイベントです。 オブジェクト指向といっても、分析設計から、現場で活かすためのプラクティスなど様々なテーマがあります。セッションやラウンドテーブルなどを通じて、参加者の皆様が新たな発見を持ち帰っていただけるようなイベントを目指しています。 オブジェクト指向についてまったく知らない方やオブジェクト指向を完全に理解した方、そして普段オブジェクト指向以外のパラダイムを利用している方もお気軽にご参加ください！ 開会の挨拶 オブジェク
packwerkに入門してみた
はじめに packwerkは、Shopifyがオープンソースで提供しているモジュラモノリスを支援するgemです。 Shpifyがモジュラモノリスに移行した理由やpackwerkが作成された背景については、下記の記事で紹介されています。 packwerkのUSAGE.mdを読むだけでは中々理解が進まなかったのですが、下記の「Gradual Modularization for Ruby and Rails」という本が非常に参考になりました。 この記事では、packwerkの基本的な使い方について確認します。 簡易なサンプルアプリケーションをモジュール化する、という流れでイメージを掴んでいきたいと思います。 この記事で作成したコードは下記のリポジトリで確認することができます。 事前準備 scaffoldを用いて、簡易なサンプルアプリケーションを作成します。 rails new sample_p
モノリシックRailsアプリケーションをモジュラモノリスへ移行しているnoteの事例 by Hiroya Shimamoto - Kaigi on Rails 2022
私たちのサービス(note)のバックエンドは、Model 数が 800 以上と比較的大規模なモノリシックRailsアプリケーションで構成されています。 また関わるエンジニアの人数も40名程度のため、開発効率の低下、バグの増加といった課題が顕在化してきました。 このような課題に対しマイクロサービスアーキテクチャを検討しましたが、アーキテクチャ検討の前にまずはドメイン分割を進める必要があると考えました。 そこで Packwerk という Shopify が開発した gem を導入することにしました。 Packwerk は、モジュラーモノリス化を支援してくれる gem です。 設定したディレクトリをモジュールとみなし、モジュール間の依存関係を静的解析で検出してくれます。 モジュール化は基本的にはファイル移動だけなので、ドメイン分割を段階的に進めることができ、やり直しも容易にできます。 これらの特
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
入社6ヶ月レポート - asoview! Tech Blog
組織設計の失敗に見るソフトウェア開発への悪影響 - mtx2s’s blog
予約APIのマイクロサービス化とgRPCゲートウェイの置き方 - Retty Tech Blog
Monorepoって何なのか？と関連アーキテクチャとの関係をまとめてみた
マイクロサービスによって起こったサイロ化に対する取り組み - asoview! Tech Blog
Kotlin製のGraphQLサーバーをNode.jsでモジュラモノリス化している話
分散モノリスを解消して、モジュラモノリスとして扱うために リプレイスの専任チーム発足から今まで取り組んできたこと
初めてのリーダー案件がめちゃめちゃ学びだったので振り返っていく
#KaigiOnRails 2022の発表スライドのリスト
Alp開発日誌 Day10 「開発手法史2020」 - 道産子エンジニア
マイクロサービスアーキテクチャを再評価する - 影響、運用面での複雑性、代替案
Amazon Redshiftを 1年運用して感じた教訓とその対策方針
【優勝ピッチ解説(4)】smartroundでモジュラモノリスを採用した背景とその詳細
Spring Modulithで始めるモジュラモノリス開発
小さいチームでもフレキシブルに方針変更 スタートアップがマイクロサービスではなくモジュラモノリスを選択した理由
拡大期のサービスのモジュラモノリス移行を考えたらチーム編成の難しさにぶつかりそうな話
Scala使いに相性ピッタリ sbtとScalaPBによるモジュラモノリス構築方法
SNKRDUNKでGo+gRPCで すすめるモジュラモノリス
タイミーはどのようにしてモジュラモノリス化を進めたか packwerkの導入と、悩んだ2つのポイント
SaaS.tech #1を開催しました - LayerX エンジニアブログ
マイクロサービス？モノリス？SaaSアーキテクチャのPros/Cons | SaaS.tech #1
「現場の信頼を勝ちとる」意識がCTO就任につながった 広い視野で課題を解決していけば、権限は自ずとついてくる
RailsエンジンとPackwerkによるコード分割を進行中｜noteエンジニアチームの技術記事
Object-Oriented Conference参加メモ - Qiita