Kubeshark — Deep Network Observability for KubernetesInspect all internal and external cluster communications, API transactions, and data in transit with cluster-wide network visibility, monitoring all traffic going in, out, and across containers, pods, namespaces, nodes, and clusters.
The OpenTracing project
# Start Jaeger locally $ docker run -d -p 6831:6831/udp -p 16686:16686 jaegertracing/all-in-one:latest $ export DOCKER_IP=`docker-machine ip $(docker-machine active)` $ cd $GOPATH/src # Grab a simple, self-contained OpenTracing example $ go get github.com/opentracing-contrib/examples/go $ cd github.com/opentracing-contrib/examples/go $ go run ./trivial.go $DOCKER_IP # Visualize the tracing instrum
モノリス分割はこうやる！「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（シンプルかつ分離された機能で準
Mercari Microservices Platform における Terraform 0.12 対応 | メルカリエンジニアリング
Platform Group, Platform Infra Team の @dtan4 です。 現在メルカリ/メルペイのマイクロサービス基盤 (Microservices Platform) では、様々なクラウドリソース・SaaS を開発者に提供しています。これらのリソースを宣言的に管理するための手段として HashiCorp Terraform を利用しており、数百のマイクロサービスのインフラが Terraform によって管理されています。 1年以上前の話ですが、Terraform 0.12 がリリースされました。昨年後半に、我々が管理している Terraform リポジトリにおいて Terraform 0.12 対応作業を行いました。本記事では、我々の環境においてどのように Terraform 0.12 対応作業を行ったかについて説明します。 Terraform 0.12 対応の動
理解して拡げる分散システムの基礎知識
20200725の #JTF2020 セッションスライド。 （資料内で説明した資料へのリンク） ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kuber…
Istio as an Example of When Not to Do Microservices
I’ve been pretty invested in helping organizations with their cloud-native journeys for the last five years. Modernizing and improving a team (and eventually an organization’s) velocity to deliver software-based technology is heavily influenced by its people, process and eventual technology decisions. A microservices approach may be appropriate when the culmination of an application’s architecture
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
Microservicesでなぜ作るのか - An Epicurean
「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流
Service meshとは何か
Microservicesの世界においてService meshは大きなキーワードになった．KubeCon 2017やKubeCon 2018 EUにおいても多くのセッションをService mesh（もしくはその代表格であるIstio）が占めており注目の高さも伺える．もちろんMicroservicesを進めるMercariにおいても導入を検討しており今後重要なコンポーネントの1つになると考えている．本記事ではそもそもなぜService meshという考え方が登場したのか，なぜ重要なのか? その実装としてのIstioとは何で何ができるのか? について簡単にまとめてみる． 参考文献 Service meshを一番理想的な形でサービスに使い始めその考え方を広めたのはLyftだ（と思う）．LyftはIstioのコアのコンポーネントであるEnvoyを開発しそれを用いてService meshを構築
Tales of Modern Systems: Distributed / Containerized Systems
4. Today's Session is ... 1. Patterns of Modern Systems 1. Containerized Systems 2. Distributed Systems 2. Tales of Distribution/Containerization 3. Storing Data in Modern Systems 6. "Modern System" ? • Many "Pattern"s in various white papers... • Distributed systems • Microservices • Containers • Serverless systems / FaaS • Common things: • Free from bare metal servers • Short process lifetime •
伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（前編）。QCon Tokyo 2016
クラウド上でアプリケーションを構築する新しい手法として「サーバーレスアーキテクチャ」が急速に注目を集めています。しかし一方で、サーバーレスアーキテクチャを採用することで得られる本質的なメリットはなにか、そもそもサーバーレスアーキテクチャとはなにを指すのか、などについてはまだ識者の間でも議論されていることです。 10月24日に都内で開催されたイベント「QCon Tokyo 2016」の伊藤直也氏のセッション「Serverless Architecture」は、こうしたサーバーレスアーキテクチャの本質について大きな示唆をもたらす内容でした。この記事では、その内容をダイジェストで紹介します。 （本記事は前編、中編、後編に分かれています。いまお読みの記事は前編です。） Serverless Architecture 一休 CTO 伊藤直也氏。 先に結論を言ってしまうと、サーバーレスアーキテクチャと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Serverless Architecture Patterns in #AWS - DEV