ミック on X: "AuroraやRDSからNewSQLへの移行徐々に増えてるわね。マイクロサービス化するとデータベースの運用工数も馬鹿にならない。 https://t.co/5doHZsMrxu"
なぜ「実践マイクロサービスAPI」は退屈だったのか
はじめに 先日実践マイクロサービス APIという書籍を購入しました。 動機としては、マイクロサービスを実装するためにマイクロサービスという手法について学ぶためです。 その目的で上記書籍を読み進めていましたが、マイクロサービス API の実装という面では中々読むのがしんどかったです。 今回はなぜしんどかったについて、言及していきたいと思います。 本題に入る前の注意書 ここでは本題に入る前に、あらかじめ言っておきたいことについて二点ほど記載します。 まず一点目についてですが、書籍自体を退屈と言いたいわけではないということです。 今回紹介する実践マイクロサービス APIという書籍をタイトルではあまり良くない本のように捉えていますが、この本自体は確実にとても非常に素晴らしい本です。 マイクロサービスの概要から始まり、マイクロサービスを設計する際に意識することや、API 実装幅広く扱っています。 ま
急にマイクロサービスやってと言われた時に読む本 - Qiita
急にそんなこと言われたら手段が先行してるので、そんなこと言われたらそもそも〜の話をしましょう。 マイクロサービスや分散アーキテクチャがなんにもわからない状態の時に読みたい本を書いていきます。 はじめに web アプリケーションを作っていると、完全なスタンドアローンな状態は珍しく、大抵は何かしらの外部 API （決済など）をコールしていることが多いと思います。それは広義の意味では分散システムであると言えます。ここでいうマイクロサービスはモノリスを分解する過程や思想の先にあるものを指していますが、web アプリケーションであれば分散システムについてインプットしておくのは有意義だと思います。 概念編 マイクロサービスアーキテクチャ 第2版 とりあえずこれさえ読んでおけば間違いない一冊。 2022年12月に出版されたもので、2016年に出た第1版から大幅に増改訂（ページ数は約2倍w）があり、マイク
『ソフトウェアアーキテクチャ・ハードパーツ』 - Don't Repeat Yourself
『ソフトウェアアーキテクチャ・ハードパーツ』を訳者の方からご恵贈いただきました。ありがとうございます。献本については基本的にすべて書評を書こうと思っているため、今回も記事にします。発売は10/27のようです。 ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析 作者:Neal Ford,Mark Richards,Pramod Sadalage,Zhamak DehghaniオライリージャパンAmazon おことわり まず指示語についてです。記事中で「本書」「この本」と書く場合は『ソフトウェアアーキテクチャ・ハードパーツ』を指します。また、「著者」は本書を執筆した人を指すものとします。「筆者」といった場合、それは私のことです。 いわゆるスキミングをした状態で一旦書評をするため、本書の細かい議論の見落としや用語の誤認識が含まれる可能性があります。この書評は
インフラエンジニアが学ぶと良さそうなgRPCサーバーについて - じゃあ、おうちで学べる
3-shake にはSreake共有会 という毎週、火曜日と木曜日に担当者が現場で得た知見などを発表する社内勉強会が開催されています。こちらのブログはそれらを変更修正しております。 syu-m-5151.hatenablog.com 元々しようとしていたの話 Go 1.18 の最新情報←Generics の深い話とかはもう既出すぎて気になる人は読んでる Go でのTDD(が実は20周年なので)←書いてる途中で自分が言うべきことなんてないことに気付く 今後、案件で増えるであろう gRPC についてインフラエンジニアが知っておいても良いと思ったという話 ← 今ここ TL;DR protobuf (Protocol Buffers) はデータフォーマットで、JSONの役割を置き換えるものです。一方 gRPC は通信プロトコルで、HTTPの役割を置き換えるものです。 gRPC をライブラリやツール
Data Meshとは何か？
Aboutこの記事は、「Data Mesh」について書かれたものです。参考文献に記載された内容をベースとして、個人的な感想や意見を加えたものです。 事例ではありません。 TL;DRData Mesh はデータ基盤の新しいアーキテクチャ原則であり、現在主流である中央集中型のデータ基盤と、そこから起こる問題への解決策です。Data Mesh はマイクロサービスと DDD から着想を得ており、データの生成・管理・提供を中央ではなくドメインごとに管理します。管理が分散することでスケーラビリティ・自律性を確保しつつ、統一的なガバナンスを保持できるアイデアです。主な想定読者Data Mesh が気になる方データ基盤を開発・保守するデータエンジニアデータマネジメントをより洗練させたいと感じている方Data Mesh の登場した背景 (WHY)詳細に入る前に、Data Mesh が前提に置く現代のデータ基
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://x.com/mpyw/status/1697466966381142485?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
Istio入門
mattn on Twitter: "Go が microservice で使われるのはコア数によってスケールするランタイムを持ってるという点と、コンパイルが速いので CI/CD しやすいという2点の理由であり、言語仕様はあんま関係無いと思っています。 https://t.co/mWq9ZGDM5Q"
さぼ ♻️ System Dynamics on Twitter: "こちらも仮説で、GoでORM使わずにWebAppを書こうとすると, Go自体のプログラムの抽象度が低いのと、ORMを使わずに書いてRDBの関係の管理の煩雑さを抽象化しない事から、認知負荷があがりやすく、それによってサービス分割した… https://t.co/s9uuEoViHO"
songmu on Twitter: "「最初はモノリシックで作りましょう」という志向に僕も近いけど、それって僕ら旧世代がいる中での過渡期の現実解であって、モノリシックと言うよりも寧ろ「サービスが一つのmicroservicesから作り始める」と考えたほうが今は良いんじゃないかと思うこともある"
https://twitter.com/Keisuke69/status/1477800190983938048
なおぱー on Twitter: "他社のエンジニアの方から「マイクロサービスを始めたいんだけど」と相談を受けることが増えてきたんだけど、そのたびに「99.9%のケースではマイクロサービスにしない方がいいですよ」とお伝えしてる。ましてや新規サービスをマイクロサービスで作るのはかなり修羅の道。ソウゾウは極めて特殊"