マイクロサービス向けのデザイン パターン (Design patterns for microservices)
Azure Blog > Design patterns for microservices (2017/07/06) https://azure.microsoft.com/en-us/blog/design-patterns-for-microservices/ AzureCAT patterns & practicesチームは、Azureアーキテクチャ センターで9つの新しいデザイン パターンを公開しました。これら9つのパターンは、マイクロサービスの設計、実装時に特に有益です。業界内のマイクロサービスへの興味の高まりが、これらのパターンを文書化する動機でした。 次の図は、マイクロサービス アーキテクチャでこれらのパターンをどのように使えるかを示しています。 それぞれのパターンに対して、問題、解決策、いつそのパターンを使うか、実装の考慮事項を説明しています。 新しいパターンは、次の通り
アーキテクチャ 【まとめ】 -マイクロサービス、ミニサービス、モジュラーモノリス、モノリシックアーキテクチャを並べて比べてみました- - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。 ラクスでは有り難いことにサービスが順調に成長しています。今後の成長に対応できるようにするために、継続的な検討課題としてより拡大可能なアーキテクチャの検討を行っています。 拡大成長可能なウェブアプリケーション（のバックエンド）アーキテクチャとしてすぐに挙がるのが「マイクロサービスアーキテクチャ」だと思いますが、マイクロサービスアーキテクチャが一般的に議論されるようになったのが2015年頃からだったと思います。それ以来いろいろと考え続け、従来のモノリシックアーキテクチャ群との間にあるアーキテクチャとイメージがつながってきたのでまとめてみたいと思います。 この記事でそれぞれのバックエンドアーキテクチャを俯瞰的に比較する
Software Architecture Guide
Martin is the host of martinfowler.com, the author of Refactoring, and the Chief Scientist at Thoughtworks. 1 Aug 2019 What is architecture? People in the software world have long argued about a definition of architecture. For some it's something like the fundamental organization of a system, or the way the highest level components are wired together. My thinking on this was shaped by an email exc
Microservices Patterns を読んで(1) - kencharosの日記
Chris Richardson 氏の Microservices Patterns を読んだ。 Microservices Patterns: With examples in Java 作者: Chris Richardson出版社/メーカー: Manning Publications発売日: 2018/11/19メディア: ペーパーバックこの商品を含むブログを見る マイクロサービスという言葉が出て来て数年経ちます。 私もマイクロサービス的な複数のサービス間でデータのやり取りを頻繁にするようなシステムを構築したことがあります。 その際にデータの整合性は最重要ではなかったのでトランザクション的なものは使いませんでしが、 お金を扱うようなシステムをマイクロサービスにした場合ちゃんとしたトランザクションはどうするのかは気になっていました。 本書にはその疑問に対する現実的な回答が載っています。
Chaos Engineeringの概要とPumba入門 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は リクルートライフスタイル Advent Calendar 2017 4日目の記事です。 はじめに こんにちは！データエンジニアリンググループでエンジニアをやっている @shotat です。 最近は CETというプロジェクトでDataflowを書いたりGoを書いたり無限にSQLを書いたりしています。 先月サンフランシスコで行われた QCon2017 に参加してきました。 QConではArchitecture, DevOps, Microservices, AI, CS, Culture, Web…と幅広いトラックがあり、全体と
Google Spanner のアーキテクチャを知る - Yuichi Murata's Engineering Blog
最近 Cloud Spanner のベータ公開によって話題の Spanner。 気になっていたので論文を読んだり勉強会などで情報収集していました。日本語のリソースもそこまで多くないので、調べてわかったことを纏めておきます。 簡単にまとめると特徴は以下のとおりです。 Bigtable / Datastore と類似したアーキテクチャをとっており Tablet 群にデータを分散保存している ↑の仕組みであるの上に Lock Table を実装して同期処理のためのロックを処理している さらに↑の仕組みの上に分散トランザクションマネジャーを実装し、グループ横断のトランザクションを管理する 以下で、細かい説明を続けていきます。 Spanner の全体構成 Universe と Zone Zone と Spanserver Spanserver の構成 Spanserver と Replica Rep
逆コーンウェイ戦略とDevOps, Microservices, Agile
コーンウェイの法則 「コーンウェイの法則」というのを知ってますか？Jim Conplien の組織プロセスパターンにも登場しますが、”組織の構造がソフトウェアの構造に反映する“あるいはその逆、“ソフトウェアの構造が組織の構造に反映する”というものです。Wikipedia によると、 Conway’s law is an adage named after computer programmer Melvin Conway, … “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”
DHHはどのようにRailsのコントローラを書くのか | POSTD
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
マイクロサービスのデザインパターン
第1版 2015年9月21日 第2版 2015年12月24日 Bluemixでは，たくさんのサービスやAPIが提供されており，それらを組み合わせることでアプリケーションを開発することができます．単一のプログラム言語を使って，多数のライブラリやクラスファイルを結合して作る大きなアプリケーションにももちろん利点がありますが，新しい機能やUXを継続的に提供したい時や，目的に合わせてプログラミング言語やデータベースを選択したい場合には，それぞれが独立したサービスを組み合わせるやり方が有利です．この考え方の根底にあるのが，James LewisとMartin Fowlerが提唱しているマイクロサービスです．彼らのブログ記事にあるマイクロサービスの定義にあたる部分を訳してみました． マイクロサービス(Microservices)アーキテクチャスタイルは、それぞれが独立のプロセスで実行され，HTTPリソ
マイクロサービスアーキテクチャの設計 - JUG2015
2015/8/28に開催された「Spring in Summer ~ 夏なのにSpring 」での講演「R1-2 マイクロサービスアーキテクチャの設計」の講演資料です。
大規模分散システムの現在 -- Twitter
Monadic Programmingのススメ - Functional Reactive Programmingへのアプローチ
Railsアプリが大きくなっていくにつれてうまく機能しなくなっていくパターンというものがあり、それに関してReverb.comが簡単に5つの... - Sooey
Railsアプリが大きくなっていくにつれてうまく機能しなくなっていくパターンというものがあり、それに関してReverb.comが簡単に5つのアーキテクチャアンチパターンとしてブログにまとめていました。 Reverb.com Dev Blog | 5 architecture anti-patterns and solutions for large Rails apps Reverb.comはミュージシャンのためのマーケットプレイスサービスです。 紹介されている内容は、ドメインレイヤーのコードがRailsの想定する枠組みの外に配置されている構造を前提としいます。具体的には、ドメインレイヤーのクラスをActionControllerやActiveRecordといったRailsのアーキテクチャの範疇からは独立したものとして構築している形を指しているようです。 (1) 責務を抱えすぎたサービスオ
技術選択とアーキテクトの役割
特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。
Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
@@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう？ + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思
Martin Fowler氏の語る“犠牲的アーキテクチャ"
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
理想的なマイクロサービスアーキテクチャを目指す継続的改善 / Re-architecturing of Microservices #CNDT2019
似非サービスクラスの殺し方 / #ginzarb
サービスに寄り添うログ基盤/pepabo_log_infrastructure_bigfoot
これからの Microservices
Microservices in Action
