servicemesh.es
What is a Service Mesh? A service mesh is a dedicated infrastructure layer that adds features to a network between services. It allows to control traffic and gain insights throughout the system. Observability, traffic shifting (for canary releasing), resiliency features (such as circuit breaking and retry/timeout) and automatic mutual TLS can be configured once and enforced in a decentralized fash
サービスメッシュは本当に必要なのか、何を解決するのか | AWS Summit Tokyo 2019
原 康紘 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト AWS 上でのマネージド・サービスメッシュを実現する AWS App Mesh や、Kubernetes ワークロードとの親和性が高い Istio など、サービスメッシュの世界には数々のプロダクトやソリューション、アイデアが生まれつつあります。本セッションでは、マイクロサービスにおけるベストプラクティスの集大成とも言えるサービスメッシュについて、その解決すべき課題と人々が熱狂する理由、サービスメッシュそのものの必要性について掘り下げます。同時に、サービスメッシュを実現する上で最も重要なコンポーネントの一つとも言える Envoy の詳細にも触れながら、皆さまがサービスメッシュを活用する手助けとなるヒントを紹介します。 AWS の詳細については http://aws.amazon.com/jp
マイクロサービスとメッセージングのなぜ [疑問編] - 赤帽エンジニアブログ
「マイクロサービスとメッセージングのなぜ [概要編]」はこちらです。 レッドハットでインテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 概要編ではメッセージングの良い面ばかりに焦点を当ててきましたが、今回の疑問編ではメッセージングを検討し始めたときに疑問に思ったり困りがちなことを説明したいと思います。概要編とは異なり、細かな技術的内容も含まれますので、その時々で必要な部分や興味ある部分だけ読んでいただければと思います。 (ところで、当初は前回を前編、そして今回を後編にして終わらせようと思っていたのですが、今回もあまりに長くなってしまったので、構成を変えたのでした。 このため当初の前編は概要編と名前を変更しています。) ではまず主に疑問とされることを確認して、その後に対処法を見ていきましょう。 メッセージングを利用することによる主な疑問 対処方法 Q1:
![マイクロサービスとメッセージングのなぜ [疑問編] - 赤帽エンジニアブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/f80853750b1c5f85bbe4ae4c26691362ff89c530/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Ft%2Ftyamashi-oss%2F20191208%2F20191208182318.jpg)
アプリケーションにおけるデータ不整合との戦い - blog.syfm
これは Aizu Advent Calendar 2019 の 15 日目の記事です。14 日目は uzimaru0000 さん、16 日目は kacky__917 さんです。 はじめに 世の中には日々たくさんの価値ある Web サービスが生まれていますが、その価値を正しく提供するにはアプリケーションが正しく動かなければなりません。 たとえばアプリケーションは適切なユーザに適切なリソースを提供しなければならず、エラーを返す際は十分に定義された仕様に沿って返し、UI 側ではユーザに適切なメッセージを表示しなければなりません。 実際のところ、これらを厳密に実現するのは非常に困難ですが、アプリケーションにはこれら以上に複雑な問題が常につきまといます。 現在の Web アプリケーションはほとんどが分散システムの一形態です。例えばクライアントとサーバや、サーバとデータベースがネットワークを介して接続
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
メルペイのマイクロサービスアーキテクチャの裏側と、不整合を防ぐための工夫
2019年7月24日、ヤフー株式会社が主催するサーバーサイドエンジニア向けの勉強会「Bonfire Backend #3」が開催されました。第3回となる今回のテーマは「モバイル決済の裏側」。急速に成長するモバイル決済分野でサービスを展開する企業が一堂に会し、自社サービスの仕組みや技術スタックなど、知られざる裏側を語ります。プレゼンテーション「静的MPM決済を支える技術 」に登壇したのは、株式会社メルペイのsusho氏。今年の6月にサービスが開始したばかりのメルペイのサーバーサイドの特徴と工夫について語ります。 静的MPM決済を支える技術 susho氏：こんばんは。「静的MPM決済を支える技術」ということでsushoが発表させていただきます。 最初に自己紹介です。 社内ではsushoと呼ばれているので、ここでもそうさせていただいております。Twitterは@susho0220でやっています。
マイクロサービスにおける内部通信の認証について
"Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~"の発表資料です。 https://connpass.com/event/142624/
クックパッドにおける最近のMicroservices事例 - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 最近ではMicroservicesという言葉もかなり浸透し、そのテクニックも体系化されつつあります。 一方でMicroservicesについての話は概論や抽象的な話が多く、具体像が見えないという方もいらっしゃるのではないでしょうか。 当ブログでは1年半ほど前にMicroservicesへのとりくみについてご紹介しました。 当時社内ライブラリだったGarageはその後オープンソースとして公開され、また社内のシステムも当時と比べ飛躍的な進化を遂げています。 そういったクックパッドにおける最近のMicroservices事例を先日Microservices Casual Talksで紹介しました。 Microservicesの抽象的な話は一切割愛し、具体的な事例に終始した内容となっています。 Microservicesの基本となる考え方はわかったものの、実践方法で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
