並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 437件

新着順 人気順

マイクロサービスの検索結果1 - 40 件 / 437件

  • サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める | gihyo.jp

    Google Cloudで実践! クラウドネイティブな開発 サービスメッシュを活用して⁠⁠、クラウドアプリケーションのオブザーバビリティを高める 本連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。 第6回では、サービスメッシュについて紹介します。 主に対象となる読者は、クラウドを利用してアプリケーションを開発するエンジニア、またはその基盤を構築するエンジニア、サービス開発に携わるプロダクトマネージャーを想定しています。 マイクロサービスアーキテクチャの課題 これまでの連載ではクラウドネイティブなアプリケーションの開発について紹介しました。小さい独立して動作するサービスが連携するマイクロサービスアーキテクチャは、スケーラビリティ、独立した開発の容易さ、

      サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める | gihyo.jp
    • マイクロサービスからモジュラーモノリスを経て新マイクロサービスへ - Techtouch Developers Blog

      バックエンドエンジニア兼万年ダイエッターの taisa です。テックタッチは、以前マイクロサービスからモジュラーモノリスを経て新マイクロサービスへの切り直しを実施しました。本記事では、マイクロサービス・モノリスについて簡単に触れながらテックタッチがどういったプロセスでマイクロサービスの切り直しを実施したかを紹介します。 はじめに マイクロサービスとモノリス マイクロサービスとは マイクロサービスの利点 モノリスとは 単一プロセスモノリス モジュラーモノリス 分散モノリス テックタッチの場合 初期の頃の構成イメージ マイクロサービス切り直し前 特徴 モジュラーモノリス化 サービスの移行 別ドメイン境界でサービス切り直し イベントストーミング マイクロサービス切り直し後 DB 統合へ続く まとめ 参考 はじめに テックタッチは初期の頃からマイクロサービスアーキテクチャを採用していますが、一部の

        マイクロサービスからモジュラーモノリスを経て新マイクロサービスへ - Techtouch Developers Blog
      • 5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる

        はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、

          5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
        • Kubernetesでアプリの安定稼働と高頻度のアップデートを両立するためのプラクティス / Best Practices for Applications on Kubernetes�to Achieve Both Frequent Updates and Stability

          Kubernetesでアプリの安定稼働と高頻度のアップデートを両立するためのプラクティス / Best Practices for Applications on Kubernetes�to Achieve Both Frequent Updates and Stability

            Kubernetesでアプリの安定稼働と高頻度のアップデートを両立するためのプラクティス / Best Practices for Applications on Kubernetes�to Achieve Both Frequent Updates and Stability
          • マイクロサービス環境におけるDB戦略 in DMMプラットフォーム

            Database Engineering Meetup #2 の登壇資料です。 https://scalar.connpass.com/event/310641/

              マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
            • サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services

              Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方

                サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services
              • ドメインモデリングとマイクロサービスの研修に参加してきたよ - ばやしのブログ

                どうも、ばやしです。 2/27に行われたJoe Yoder : Domain modeling techniques for designing microservicesに参加してきたので、参加レポです。 なお私はDDDに詳しいわけでもなく、英語もおぼつかないので誤っている部分があるかもしれませんが、ご了承いただければと思います。 www.eventbrite.com どんな研修だったの? ドメインモデリングを中心にドメイン駆動設計(以下DDD)の概念を学びつつ、それがどうマイクロサービスに役立つのかを学ぶ研修でした。 具体的にピザ屋のシステムや、交通違反システムを例に挙げてDDDの概念を理解しつつ、ワークショップではクレジットカードシステムを題材にイベントストーミングやマイクロサービスアーキテクチャ設計などを行いました。 全編英語だったのですが 英語で講義 日本人同士で日本語でワークシ

                  ドメインモデリングとマイクロサービスの研修に参加してきたよ - ばやしのブログ
                • モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog

                  こんにちは。モノタロウのTechBlog編集チームです。 モノタロウではECサイトでのお客様体験の向上を目指して、日々改善に取り組んでいます。 商品の出荷目安などの出荷関連情報は重要な要素の1つになります。 今回は、出荷関連情報の正確性を改善するとともにシステムの変更容易性を向上させるためにマイクロサービス化に取り組んだ活動をインタビューしました。 自己紹介 納期表示を高度化する サプライヤ在庫連携機能開発のつらみ AVLのマイクロサービス開発のすすめ方 リリース・監視・その後の展開 おわりに 今回インタビューしたみなさん 自己紹介 山崎 章裕 ECシステムエンジニアリング部門 開発生産性グループ、プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム兼務 2019年8月に入社し、主にECサイトの注文・配送周りのプロジェクトにテックリードとして関わる。またECサイ

                    モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog
                  • マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB/Developers Summit 2024 TiDB Sponsor Session

                    マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB/Developers Summit 2024 TiDB Sponsor Session

                      マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB/Developers Summit 2024 TiDB Sponsor Session
                    • 【個人開発】最新のNext.js+NextAuth.js+prisma+microCMSでECサイト作ってみた【フルスタックアプリケーション】 - Qiita

                      【個人開発】最新のNext.js+NextAuth.js+prisma+microCMSでECサイト作ってみた【フルスタックアプリケーション】TypeScriptフロントエンド個人開発Next.jsprisma はじめに 皆さんこんにちは、mamiなのだ! 今回はバックエンドは作らずにNextAuth.jsやprisma、microCMSなどを利用してNext.jsでECサイトを作成してみたので、その方法や手順などを公開しつつ、認証周りや大型開発案件でも採用されるstorybookなどについても解説していこうと思うのだ! フロントを勉強し始めた初学者さんや、フロントがメインではないバックエンドエンジニアの方に向けて、丁寧に解説を挟みながら書いていくので「へ〜フロントってこんな感じのことやってるんだ〜」と思ってくれたら嬉しいのだ! ちなみにこの記事は丁寧に解説しすぎて死ぬほど長くなってしまっ

                        【個人開発】最新のNext.js+NextAuth.js+prisma+microCMSでECサイト作ってみた【フルスタックアプリケーション】 - Qiita
                      • 開発者が注意すべき「マイクロサービスの問題点」、そのトップ10を解説

                        「Docker」と「Kubernetes」をベースとする環境で構築されたクラウドネイティブアーキテクチャが流行している。クラウドネイティブと相性の良いマイクロサービスには、次のような利点がある。 サービスごとに、アーキテクチャ、言語、プロセス、ツールを自由に選択できる ドメイン駆動型設計やイベント駆動型アーキテクチャなど、ソフトウェアコンポーネントで長年提唱されてきた多くのベストプラクティスが体系化されている 適切にカプセル化されているため、サービスを個別に更新できる 柔軟性が高く、短期間でのリリースが可能 マイクロサービスに対応した技術(DockerやKubernetesなど)は多くのハードウェアで動作する マイクロサービスはこうしたさまざまなメリットをもたらす。一方で、幾つかの重要な問題点があるため、アプリケーション開発チームは注意する必要がある。特に、信頼性の高いモノリスアプリケーシ

                          開発者が注意すべき「マイクロサービスの問題点」、そのトップ10を解説
                        • Why LinkedIn chose gRPC+Protobuf over REST+JSON: Q&A with Karthik Ramgopal and Min Chen

                          InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architects. View an example

                            Why LinkedIn chose gRPC+Protobuf over REST+JSON: Q&A with Karthik Ramgopal and Min Chen
                          • マイクロサービス化は本当に難しい

                            はじめに この記事は、AEON Advent Calendar 2023の21日目です🎉 イオンスマートテクノロジー株式会社(通称AST)のCTO室TechLeadチームの@t0doroki_takaです。弊社ではSREチームの発信に勢いがありますが、アプリケーションレイヤーよりの話題も積極的に発信していければと思います。 自分の敗戦の振り返り 以前、大規模ECシステムのリプレース案件に関わった時(そして敗戦したとき)の振り返りです。 今回取り上げるケーススタディは、システム全体(連係するシステム含む)としては段階的移行ではありましたが、主ターゲットとなるシステムは、全EC機能を包括する大規模なシステムで、それをフルスクラッチでリプレースするものでした。 巨大なモノリス構造であったため、マイクロサービスアーキテクチャに移行することで、サービス提供のアジリティを確保することが目的の一つでし

                              マイクロサービス化は本当に難しい
                            • マイクロサービスとメッセージングのなぜ [希望編] - 赤帽エンジニアブログ

                              レッドハットでインテグレーションのためのミドルウェアのテクニカルサポートを担当している山下です。以前、SAGAやEventStormingについて記述すると宣言していたのですが、実際のところ私が書くよりもよっぽど良い日本語の書籍や記事がでていて、もう書く必要もないと思っていたのですが、今回機会をいただいたので約4年ぶりに”マイクロサービスとメッセージングのなぜ"の希望編を書くことになりました。今回の記事ではSAGAやEventStormingの詳細は書かないのですが、私がイベントやメッセージングが必要と考えるに至った危機感や希望を共有します。そうした意味ではむしろ原点ともいえる内容になっています。なお今回記事にはとりわけ個人的な経験や意見が多く含まれますので、事前に異論は認めることにします。 以前の記事はこちら: 「マイクロサービスとメッセージングのなぜ [概要編]」 「マイクロサービスと

                                マイクロサービスとメッセージングのなぜ [希望編] - 赤帽エンジニアブログ
                              • マイクロサービスアーキテクチャへのIntegration Test導入のすゝめ

                                こんにちは、バックエンドを中心に開発をしています、野島といいます。 ソフトウェアテスト自動化カンファレンス2023に「マイクロサービスアーキテクチャへのIntegration Test導入のすゝめ」というお題で登壇しました。 そちらで発表した内容を記事にしつつ、当日話しきれなかった内容についても書きます。 発表は下記の内容を話しました。 Integration Testの導入を決意した背景にあった課題 Integration Testの導入/運用での工夫 Integration Testを導入して得られたメリット まとめ 本記事では、Integration Testを以下の定義で扱います。 マイクロサービスが依存する外部コンポーネントをモック化せずに行うAPIテスト。 外部コンポーネントとは、具体的にはデータストア、外部サービス、テスト対象が依存するマイクロサービス、などを指します。 テス

                                  マイクロサービスアーキテクチャへのIntegration Test導入のすゝめ
                                • Axon Framework で簡単にEventSourcing+CQRSなアプリケーションを作る - エムスリーテックブログ

                                  この記事はエムスリーAdvent Calendar 2023の13日目の記事です。 こんにちは、製薬企業向けプラットフォームチームエンジニアの桑原です。 前回のJJUG CCC の登壇についてのブログで Axon Framework について軽く触れました。今回はAxon Frameworkがどのようなもので、どういった使い方をするかを紹介したいと思います。 背景:CommandとQueryに最適なモデルが異なる CommandとEvent追記型との相性は良かった QueryがEvent追記型との相性は良くなかった 苦肉の解決策 Axon Framework ざっくりアーキテクチャ Command EventからReadModelへのマッピング Query まとめ 参考記事 We are Hiring! 背景:CommandとQueryに最適なモデルが異なる 上述のリンクで紹介したメッセー

                                    Axon Framework で簡単にEventSourcing+CQRSなアプリケーションを作る - エムスリーテックブログ
                                  • 複数サービス間でのデータの整合性維持に向けたSagaの実装 - NTT Communications Engineers' Blog

                                    マイクロサービスアーキテクチャにおいては、個々が独立に選定したデータベースを持つ複数のサービスにまたがって、データの整合性を維持する必要があります。 そのための方法として、Sagaパターンと呼ばれる設計方法がありますが、Sagaでは分離性が欠如しておりLost Update等の異常が発生しかねません。 そこで本記事では、Sagaの分離性を高めるための実装におけるTipsを解説します。 目次 目次 はじめに 複数サービス間での整合性維持における課題 Sagaパターン Sagaを構成するトランザクション Sagaによって実現される安全性 原子性(Atomicity) 整合性(Consistency) 分離性(Isolation) 永続性(Durability) 異常を防止/軽減する実装 分離性の欠如が引き起こす異常 分離性の欠如への対策 Semantic Lock Commutative Up

                                      複数サービス間でのデータの整合性維持に向けたSagaの実装 - NTT Communications Engineers' Blog
                                    • Uber、4000以上のマイクロサービスをKubernetesとMesosを実行する新しいマルチクラウドプラットフォームに移行

                                      Mark Fussell氏とYaron Schneider氏とDaprを知ろう 本日のエピソードでは、Thomas Betts氏がMark Fussell氏とYaron Schneider氏に、分散アプリケーション・ランタイム(Dapr)について話を聞いた。最新のInfoQ Architecture and Design Trends Reportでは、Daprはポータビリティとクラウドアプリケーションのための設計というアーリーアダプターのアイデアの一部となっている。

                                        Uber、4000以上のマイクロサービスをKubernetesとMesosを実行する新しいマルチクラウドプラットフォームに移行
                                      • E2Eテスト vs E2Eテスト: 柴田 芳樹 (Yoshiki Shibata)

                                        私が「WEB+DB PRESS, Vol.134」の特集1「実践API設計」の中で使っている用語「E2Eテスト」は、一般的な書籍で述べられているE2Eテストとは若干異なります。 どのように違うのかをウェブサービスのバックエンドのサービスで説明します。新たに図を起こすのが面倒なので、すでにある記事「マイクロサービスの開発とテストファースト/テスト駆動開発」からそのまま引用します。 この図では、「加盟店管理用APIマイクロサービス」が複数のマイクロサービスに依存しています。 一般的なE2Eテストとは一般的な書籍では、テストピラミッドにおける頂点にあるE2E(End-To-End)テストは、「加盟店管理用APIマイクロサービス」およびそれが依存するすべてのマイクロサービスを何らかの環境(たとえば、Docker、あるいは開発用のクラウド環境)にデプロイして「加盟店管理用APIマイクロサービス」をテ

                                          E2Eテスト vs E2Eテスト: 柴田 芳樹 (Yoshiki Shibata)
                                        • ジョインしたチームのマイクロサービスたちを再計装した話 / Getting started tracing instrument micro service with OpenTelemetry

                                          OpenTelemetry Meetup の登壇スライドです。 https://opentelemetry.connpass.com/event/296353/

                                            ジョインしたチームのマイクロサービスたちを再計装した話 / Getting started tracing instrument micro service with OpenTelemetry
                                          • GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.

                                            Architecture styles define how different components of an application programming interface (API) interact with one another. As a result, they ensure efficiency, reliability, and ease of integration with other systems by providing a standard approach to designing and building APIs. Here are the most used styles: SOAP: Mature, comprehensive, XML-based Best for enterprise applications RESTful: Popul

                                              GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.
                                            • マイクロサービス構成における NestJS での gRPC クライアントの運用戦略 - ドワンゴ教育サービス開発者ブログ

                                              はじめに はじめまして、バックエンドセクションの yukimochi です。 現在、N予備校ではバックエンドのアプリケーションの移行計画が進んでいます。 その一環で、一部のマイクロサービス間通信についても REST API + OpenAPI の現状から gRPC へと移行することになりました。 私の参画しているプロジェクトである教材入稿ツールでは TypeScript + NestJS を採用しており、結合している他マイクロサービスとの通信でgRPCを利用する際の gRPC クライアントと、そのスキーマ定義を担う proto の運用戦略、実現方法について記します。 proto ファイルと型定義パッケージの取り回しについて考える スキーマ定義である proto をどこに保存するか スキーマ定義である proto をどこに保存しておくかは、 proto のバージョン管理の観点で重要です。今回

                                                マイクロサービス構成における NestJS での gRPC クライアントの運用戦略 - ドワンゴ教育サービス開発者ブログ
                                              • 3層アーキテクチャとマイクロサービスアーキテクチャ、どちらを選ぶべきか

                                                高いレベルのモジュール性を求めるのであれば、マイクロサービスアーキテクチャが適している。だが、複雑さが増すことに価値があるかどうかや、どのように呼び出すかを検討しなければならない。 アプリケーションアーキテクチャの選択は重要な決定事項だ。どの程度の複雑さまで対処するつもりがあるか、アプリケーションにどの程度の柔軟性を持たせるか、アプリケーションをどのようなタイプの環境でホストするかによって、その答えは変わってくる。 モジュール型のアプリケーションを設計するのであれば、アプリケーションを3つの主要コンポーネントに分割する3層アーキテクチャを選択できる。あるいは、さらにモジュール性を高めるのであれば、マイクロサービスアーキテクチャも選択できる。 本稿では、3層アーキテクチャとマイクロサービスアーキテクチャを細かく比較し、どちらをいつ使用するかを考えてみる。 3層アプリケーションアーキテクチャと

                                                  3層アーキテクチャとマイクロサービスアーキテクチャ、どちらを選ぶべきか
                                                • マイクロサービス環境におけるToilを削減するTerraformの活用 in DMMプラットフォーム

                                                  Cloud Operator Days Tokyo 2023 の登壇資料です。 https://cloudopsdays.com/

                                                    マイクロサービス環境におけるToilを削減するTerraformの活用 in DMMプラットフォーム
                                                  • マイクロサービスの効率的な監視〜不安定な依存先との闘い〜

                                                    DMM.go #6 の登壇資料です。 https://dmm.connpass.com/event/295065/

                                                      マイクロサービスの効率的な監視〜不安定な依存先との闘い〜
                                                    • freee の権限管理基盤マイクロサービスの今を語ろう! - freee Developers Hub

                                                      はじめに こんにちは、freee の 権限管理基盤マイクロサービスを開発するチームでエンジニアリングマネージャーを務めている sentokun と申します。前職ではできることをできる限りやろうというスタンスで開発チームをリードし、アーキテクチャ設計やチームビルディングなどに取り組んでいました。その後 2022 年に freee へ入社し、freee で初めてエンジニアリングマネージャーの役割に。変わらずできることにできる限り取り組むスタンスでチームビルディングに従事しています。 この記事では、我々のチームが担当している権限管理基盤について語っていこうと思います! 権限管理基盤の成り立ち freee では、「スモールビジネスを、世界の主役に。」をミッションに掲げ、統合型経営プラットフォームの開発・提供を進めています。最近では freee Togo Panorama を公開するなど、統合に向け

                                                        freee の権限管理基盤マイクロサービスの今を語ろう! - freee Developers Hub
                                                      • マイクロサービスにおけるBFFアーキテクチャでのモジュラモノリスの導入

                                                        LINE株式会社 古田 大志 京都開発室 / 出前館マーチャント部 クーポンサービス チームリード 2023.9.12「モジュラモノリス徹底解剖vol.2〜実践者から学ぶLunch LT〜」の登壇資料です https://findy.connpass.com/event/293748/

                                                          マイクロサービスにおけるBFFアーキテクチャでのモジュラモノリスの導入
                                                        • 徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜 /why do you choose microservices architecture

                                                          JAWS UG 函館勉強会 Vol12 徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜

                                                            徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜 /why do you choose microservices architecture
                                                          • テストデータを貯めて感じたこと

                                                            https://toruby.connpass.com/event/286678/ の発表資料です。

                                                              テストデータを貯めて感じたこと
                                                            • Google Cloud での Go アプリケーションの作成をシンプルに | Google Cloud 公式ブログ

                                                              ※この投稿は米国時間 2023 年 8 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。 Go はクラウドベースの開発のために世界的に採用されている主要なプログラミング言語です。クラウド アプリケーションやビジネス クリティカルなクラウド インフラストラクチャを構築、スケーリングする目的で何百万人もの開発者に利用されています。CLI、ウェブ アプリケーション、クラウド サービス、ネットワーク サービスなど、どのようなものを構築するにしても、Go は習得するのも保守も容易で、組み込みの同時実行性や堅牢な標準ライブラリをはじめとする便利な機能が満載です。 このたび、Go を Google Cloud で使い始める際のハードルを少し下げることが可能になります。Go は最近、事前定義されたテンプレートを使用して新しいプロジェクトを Go でインスタンス化できる、gon

                                                                Google Cloud での Go アプリケーションの作成をシンプルに | Google Cloud 公式ブログ
                                                              • アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp

                                                                デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。 「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。 なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。 「今まで」と「これから」のギャップ 失敗1:半島型 新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕

                                                                  アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp
                                                                • 一休.comのアーキテクチャ変遷から考えるサービス分割の勘所

                                                                  techplayの登壇資料です。 https://techplay.jp/event/908123 #ikyu_TP

                                                                    一休.comのアーキテクチャ変遷から考えるサービス分割の勘所
                                                                  • マイクロサービスアーキテクチャは大変という話 - pospomeのプログラミング日記

                                                                    最近「マイクロサービスって大変だな」と感じることが多いので、書いてみた。 単なる感想です。 pospomeのマイクロサービス歴 面倒なのは技術ではない モノリスだと厳しい 楽しくもある 宣伝 pospomeのマイクロサービス歴 以下の企業で7年ほどマイクロサービスに携わっている。 DeNA(ゲームプラットフォーム) メルカリ(認証認可基盤) DMM(DMMプラットフォーム) DeNA, メルカリではサーバサイドエンジニアとして仕事をしていて、 DMMではプラットフォーム事業本部という120人のエンジニアが在籍する開発組織のアーキテクトとして仕事をしている。 それぞれの会社で開発の規模感、開発体制、自分の役割などが異なるので、 直接比較できないが、やはりポジション的に今のDMMが一番大変だなーと感じる。 面倒なのは技術ではない マイクロサービスというと "分散トランザクション" とか "通信

                                                                      マイクロサービスアーキテクチャは大変という話 - pospomeのプログラミング日記
                                                                    • 実践!モノリスからマイクロサービス!Event Stormingによるドメイン駆動設計から実装まで / AWS_Dev_Day_2023_E_3

                                                                      AWS Dev Day 2023 Tokyo. E-3 「実践!モノリスからマイクロサービス!Event Stormingによるドメイン駆動設計から実装まで」 2023/06/23 at AWS Dev Day 2023 Tokyo

                                                                        実践!モノリスからマイクロサービス!Event Stormingによるドメイン駆動設計から実装まで / AWS_Dev_Day_2023_E_3
                                                                      • メルコイン決済基盤における分散トランザクション管理 | メルカリエンジニアリング

                                                                        この記事は、Merpay Tech Openness Month 2023 の7日目の記事です。 はじめに こんにちは。メルコイン Payment Platform チームの @sapuri です。 メルコインではマイクロサービスアーキテクチャを採用しており、お客さまによりアプリの操作が行われると、それぞれのマイクロサービスを横断してリクエストが処理されます。 メルコインの Payment Platform は、お客さまの残高の管理や各種帳簿の作成などの決済事業のための基盤となる仕組みを提供しています。 そのなかで、Payment Service は決済トランザクションを管理するサービスとして、下位層のサービスが提供する各種決済手段を利用して、上位層のサービスが共通して利用できる決済 API を提供しています。 この記事ではマイクロサービスアーキテクチャにおける分散トランザクション管理の課

                                                                          メルコイン決済基盤における分散トランザクション管理 | メルカリエンジニアリング
                                                                        • Platform Engineering at Mercari

                                                                          Talk at Platform Engineering Meetup #2 https://platformengineering.connpass.com/event/280339/

                                                                            Platform Engineering at Mercari
                                                                          • 医療スタートアップのバックエンドをモノレポ化した話 〜戦略・プロセス編〜 - 株式会社ヘンリー エンジニアブログ

                                                                            こんにちは、ヘンリーの Lead Architect の @kohii です。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 最近 Henry のバックエンドをモノレポ化したので、その戦略やプロセスについて書きたいと思います。 こちらは前編となっており、モノレポ移行の手法やテクニックの話は後編で説明します。 dev.henry.jp Why モノレポ? ざっくり説明すると、既存のマイクロサービス/チームの分界点を抜本的に見直し、ドメイン(業務の領域)による分割を目指すため、一旦モノレポにまとめて、理想的な構造の切り出しをやりやすくするという目的です。 モノレポ化前のシステム/チームアーキテクチャ バックエンド Henryのバックエンドはマイクロサービスになっていますが、以下の2つのサービスが大部分を占めています。 henry-general-api …

                                                                              医療スタートアップのバックエンドをモノレポ化した話 〜戦略・プロセス編〜 - 株式会社ヘンリー エンジニアブログ
                                                                            • 「Amazonでさえサーバレスやマイクロサービスを理解できない」とDHH氏が主張する一方で、「進化可能なアーキテクチャこそ重要」とAmazonのVogels博士

                                                                              Ruby on Railsの作者として知られるDavid Heinemeier Hansson(DHH)氏が自身のブログに5月4日付けで投稿した記事「Even Amazon can't make sense of serverless or microservices」(Amazonでさえサーバレスやマイクロサービスを理解できない)が話題になっています。 これはAmazon Prime Videoの技術部門が3月に自社ブログに投稿した記事「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」(Prime Videoの音声映像監視サービスにおけるスケールアップと90%のコスト削減の実現)で紹介された、AWS Lambdaのサーバレスで作られたPrime Videoの監視サービス

                                                                                「Amazonでさえサーバレスやマイクロサービスを理解できない」とDHH氏が主張する一方で、「進化可能なアーキテクチャこそ重要」とAmazonのVogels博士
                                                                              • How to recover from microservices

                                                                                I won't deny there may well be cases where a microservices-first architecture makes sense, but I think they're few and far in between. The vast majority of systems are much better served by starting and staying with a majestic monolith. The Prime Video case study that blew up the internet yesterday is but the latest illustration. Maybe once you reach the scale of Netflix or Amazon, there are areas

                                                                                  How to recover from microservices
                                                                                • Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%

                                                                                  Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs. At Prime Video, we offer thousands of live streams to our customers. To ensure that customers seamlessly receive content, Prime Video set up a tool to monitor every stream view

                                                                                    Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%