スタートアップのためのマイクロサービス入門 | Amazon Web Services
AWS Startup ブログ スタートアップのためのマイクロサービス入門 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 以前「スタートアップのためのコンテナ入門 – Kubernetes 編」を出した際に記事内で、マイクロサービスやサービスメッシュにふれる機会がありました。今回は AWS でデベロッパーアドボケイトをしているトリ氏 (@toricls) にマイクロサービスについて記事を寄稿いただきました。 ※ 本記事は Software Design 2020年7月号 に掲載された「スタートアップのためのAWSテクノロジー講座 – マイクロサービスのあるべき姿と特徴を知る」からの転載、改修版です。 目次 マイクロサービスにはコンテナが必要なのか？ サービスメッシュは本当に必要なのか？ 「マイクロサービス」という言葉の功罪 マイクロサービスが必
Backends For Frontends（BFF）はじめました - ZOZO TECH BLOG
はじめに こんにちは。EC基盤本部SRE部プラットフォームSREの三神です。 2021年3月18日、ZOZOTOWNは大規模なリニューアルをしました。その中でも、コスメ専門モールのZOZOCOSMEと、ラグジュアリー&デザイナーズゾーンのZOZOVILLAを同時にオープンし、多くの反響をいただきました。 今回のリニューアルではBackends For Frontends（以下、BFF）にあたるZOZO Aggregation APIを構築しています。本記事ではZOZOTOWNが抱えていた課題とBFFアーキテクチャを採用した理由、またZOZO Aggregation API構築時に発生した課題と解決法についてご紹介します。 ZOZO Aggregation APIのサービスメッシュについてはこちらの記事でご紹介していますので合わせてご覧ください。 techblog.zozo.com BFFと
業務システムとマイクロサービス（２） - 設計者の発言
マイクロサービス・アーキテクチャ(MSA)を適用する際に頭を悩ます問題のひとつが「複数サービスにわたる更新操作」である。マイクロサービスを成すソフトウエアのまとまりは、個々に独自のデータストアを持っている。ゆえに複数サービスを横断する更新操作の際、トランザクション管理によるACID特性を保証できなくなる。 この問題に対処するために二相コミットや結果整合性等の考え方があるが、どのやり方でも限界があるし、ある種の制約や余分な手間を受け入れざるを得ない。もっとも穏当な設計方針は「複数サービスに渡る更新が起こるような粒度ではサービスを切り出さない」である。個々のサービスを実装する段になって悩む前に、サービス粒度の設計に関して事前に考慮すべきことがあるということだ。 前回記事で説明した「CRUD基準によるサブシステム分割」は、更新制御の面から見たサービス粒度の設計基準として応用できる。ドメイン駆動設
モノリス分割はこうやる！「How to break a Monolith into Microservices」を読んだ - kakakakakku blog
研修中に「マイクロサービス」の解説をしていると，たまに「モノリス分割」に関する質問が出てディスカッションをすることがある．当然ながら万能な分割アプローチはないけど，例えば DDD (Domain-driven design) などのアプローチを選択するなど，選択肢はいろいろある．そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ． 具体的には以下の「計8種類」のアプローチが紹介されている．原著を翻訳するのではなく，あくまで個人的なメモとしてまとめる．なお，日本語も個人的に載せているため，参考程度にしてもらればと！ Warm Up with a Simple and Fairly Decoupled Capability（シンプルかつ分離された機能で準
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
