タグ

microservicesに関するyosfのブックマーク (69)

  • Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開

    Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開 Googleは分散アプリケーションの開発とデプロイを容易にするフレームワーク「Service Weaver」をオープンソースで公開しました。 Introducing Service Weaver! Service Weaver is an open source framework for building and deploying distributed applications. It allows you to write your application as a modular monolith and deploy as a set of microservices. Learn more → https://t.co/XmnVALYXNC pic

    Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開
  • マイクロサービスアーキテクチャを、あなたの開発チームは本当に使うべきなのか

    ガートナーの米国社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、@IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。 Gartnerが行ったソーシャルメディア分析調査によると、2019年1月から2020年9月までの間に、「マイクロサービスアーキテクチャ」への言及数は42%減少した。 この傾向は、マイクロサービスアーキテクチャへの幻滅の高まりを示している。マイクロサービスアーキテクチャは、サービス指向アーキテクチャとドメイン駆動設計原理を分散アプリケーション――つまり、マイクロサービスに適用することで、アジリティ(開発の迅速性)、デプロイ(展開)の柔軟性、きめ細かいスケー

    マイクロサービスアーキテクチャを、あなたの開発チームは本当に使うべきなのか
  • C#アプリをマイクロサービス化するために 品質を保ち続けるのにKOSMISCHが有効な理由

    マイクロソフトとオルターブースが、Azureを利用したクラウドアーキテクチャおよびアプリケーションアーキテクチャの設計を検討する際に必要な知識やスキルについて発表しました。オルターブースKOSMISCH開発リーダーの松村氏からはアプリ開発を効率化するCI/CD活用とKOSMISCHについて。 アプリケーション開発の効率化にはCI/CD設計が有効 松村優大氏(以下、松村):ここからは私、松村がお話をします。みなさん、日はお集まりいただきましてありがとうございます。私は「アプリ開発を効率化するCI/CD活用の仕方」についてお話ししたいと思います。今回はC#で作るアプリケーションでどうやるかお話をしたいと思います。 まずは私、松村はChief Technical Architectというポジションで活動しています。一番得意なのは開発系ですね。C#やPHP、Azureなどクラウドを使った開発

    C#アプリをマイクロサービス化するために 品質を保ち続けるのにKOSMISCHが有効な理由
  • なぜマイクロサービスは失敗するのか? - kawasima

    Eberhard Wolffさんのこのプレゼンの要約です https://www.youtube.com/watch?v=B3O-qYM-Kkw 共通のデータモデル 共通のデータモデルを通信に使う 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、す

    なぜマイクロサービスは失敗するのか? - kawasima
  • マイクロサービスの刻み方、「粒度」を決める2つの観点

    小さなサービスを疎結合に連携する「マイクロサービス・アーキテクチャー」を取り入れるITシステムが増えてきた。システムの変更速度を上げ、ビジネスの変化を素早くキャッチアップする狙いがある。ただしマイクロサービスに取り組むとき、誰もが同じ悩みに突き当たる。その1つが「サービス粒度の設計」である。 「モノリシック(一枚岩)」と表現される従来型システムは、各機能が密接に結び付いている。そのため、ある機能に変更を加えようとすると、他機能への影響調査やリグレッション(回帰)テスト、リリース・タイミングの調整などに多大な時間がかかる。 一方、小さなマイクロサービスとして実装し独立性を高めておけばこうした手間が省け、変更スピードを上げられる。ここでの考えどころが、いったいサービスをどれくらい小さく切り刻むのかという、サービス粒度の設計である。その手法を探っていこう。 ビジネスニーズを優先 サービスの粒度を

    マイクロサービスの刻み方、「粒度」を決める2つの観点
  • 銀行勘定系にマイクロサービス採用へ、ふくおかFG「決断」の裏に潜む必然

    「非常に重い選択だった」。 ふくおかフィナンシャルグループ(FFG)の横田浩二取締役執行役員は振り返る。2020年度にモバイル専業銀行を新設するFFGは、新銀行の勘定系システムをスクラッチで開発する決断をした。地方銀行がパッケージ製品を使わずに勘定系システムを構築するのは珍しい。しかも、マイクロサービスという新しいアーキテクチャーを採用する方針だ。 即断即決だったわけではない。「銀行のシステムが止まればどれだけ大変かは身をもって経験してきた」(横田取締役)からこそ、全く新しい勘定系システムの構築を巡るリスクも心得ている。海外製品も含め、最終的には4~5つのパッケージ製品に絞ってぎりぎりまで可能性を探ったが、「サービスを当に高速回転で作れるかというと、どうしても制約がある」と、横田取締役はスクラッチ開発という重い選択をした理由を語る。 勘定系システムは、SoR(システム・オブ・レコード)の

    銀行勘定系にマイクロサービス採用へ、ふくおかFG「決断」の裏に潜む必然
  • マイクロサービスに興味があるあなたの背中を押すかもしれない10の質問 - Qiita

    はじめに 前回「マイクロサービスが開発・運用コストの削減にどう貢献するか考えてみた件」という記事を投稿させていただき、多くの方に読んでいただけたようで大変うれしく思います。 先の記事ではマイクロサービス化のモチベーションの一つとして、コストダウンに貢献できるのか?について、マイクロサービスの文脈で活用する技術と併せて整理しました。 次に、私の記事の内容を受け @atsuo0o が 「デジタルトランスフォーメーションにおけるシステムの俊敏性とは?を考える」 でDXの課題とその進め方について整理しました。 これまでの記事を読んでいただいた方は、自分たちに必要な技術やそのモチベーションについてご理解いただけたのではないかと思います。 しかしながら、まだ一歩を踏み出すには不安がある!という方に向け、気になる点をまとめた記事を書いてみました。同じような悩みを持つ誰かに届けば幸いです。 よくお問い合わ

    マイクロサービスに興味があるあなたの背中を押すかもしれない10の質問 - Qiita
  • Istioでマイクロサービスのテスタビリティを向上させる - Uzabase for Engineers

    SPEEDAの開発チームの石橋です。 最近ではマイクロサービスでプロダクトを開発することが多くなってきていると思います。 そういった状況の中でマイクロサービスのテスト、特に異常系のテストをするコストがやや高いという話を何度か耳にしました。 記事ではIstioのFault Injectionで「エラーが発生する」、「処理に時間がかかる」などの異常系のテストを容易に実現する方法を紹介します。 異常系のテストをする際の課題 環境構築 Gateway Service Deployment DestinationRule VirtualService Fault Injection Injecting HTTP Aborts Injecting HTTP Delays まとめ 参考 異常系のテストをする際の課題 サービスAとサービスBがあるとします。サービスAからサービスBにリクエストした際、サー

    Istioでマイクロサービスのテスタビリティを向上させる - Uzabase for Engineers
  • なぜ Go はマイクロサービスのための言語なのか - Why Go is a language for microservices

    なぜ Go はマイクロサービスのための言語なのか - Why Go is a language for microservices

    なぜ Go はマイクロサービスのための言語なのか - Why Go is a language for microservices
  • マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング

    この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス(外部サービスも含め)が提供する各種決済手段を利用して、上位層のサービス(メルカリ、NFC,コード払いなど)に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき

    マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
  • なぜMicroservicesか?

    現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った.未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった.記事ではそもそもMicroservicesアーキテクチャとは何かを整理し,なぜやるべきか?・なぜ避けるべきかを整理する. Microservices? Microservicesアーキテクチャとは「Single purpose,High cohesion,そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である.それぞれの原則をまとめると以下のようになる. Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の

  • テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話

    「悪い方が良い」原則をご存じだろうか? プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル(Richard Gabriel)氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも

    テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
  • マイクロサービスの学習に使えるサンプルアプリケーション「Sock Shop」 - kakakakakku blog

    個人学習用にマイクロサービスを体験できるサンプルアプリケーションを探していたら,Weaveworks から公開されている「Sock Shop」を発見した.「Sock Shop」は名前の通り「下 EC サイト」で「ユーザー登録/商品閲覧/カート/ウィッシュリスト/購入(ダミー)」など,EC サイトに必要な機能が一通り実装されている.ドキュメントに以下の記載があり,マイクロサービスを体験したり,デモに使ったり,トレーニングに使ったりする用途に適している.良さそう! Sock Shop can be used to illustrate microservices architectures, demonstrate platforms at talks and meetups, or as a training and education tool. microservices-demo.g

    マイクロサービスの学習に使えるサンプルアプリケーション「Sock Shop」 - kakakakakku blog
  • Microservicesでなぜ作るのか - An Epicurean

    「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流

    Microservicesでなぜ作るのか - An Epicurean
  • 開発から10年を越えたエンタープライズ巨大アプリ! マイクロサービス・コンテナに全面移行するにはどうすればいいか?【デブサミ2019】

    既存のモノリシックな業務アプリケーションを、どのようにマイクロサービスに移行するかは、エンジニアにとって現在大きな課題のひとつとなっている。せっかく問題なく稼働しているものを、いかにパフォーマンスを落とすことなくリニューアルするのか。ドリーム・アーツでは、10年以上にわたって運用され、200万行を越えるApache Struts1のWebアプリケーションを、Kubernetesアーキテクチャへと段階的に移行しつつある。現在も着々と進行中の移行プロジェクトについて、同社CTOの石田健亮氏が語った。 講演資料:【祝】k8sデビュー! エンタープライズ巨大アプリをマイクロサービス・コンテナ化。段階的移行(中)の全記録を追う。 株式会社ドリーム・アーツ CTO 石田健亮氏 運用負荷の解消に向け、マイクロサービスへの移行を決意 今回移行の対象となったのは、ドリーム・アーツが運用する「Shopらん」と

    開発から10年を越えたエンタープライズ巨大アプリ! マイクロサービス・コンテナに全面移行するにはどうすればいいか?【デブサミ2019】
  • マイクロサービスについて何でも聞けるOffice Hoursに参加したよ! #メルカリな日々 | mercan (メルカン)

    こんにちは! メルペイTalent&Cultureチームのはなです。 今日は、メルペイオフィスのオープンスペースで開催されていたMicroservices PlatformチームのOffice Hoursに少しお邪魔しました。 Microservices Platformチームは、メルカリやメルペイの基盤となる環境を構築・開発しています。そんな彼らが、なぜOffice Hoursを? さっそく、企画者である@lainraに話を聞きました! Microservices Platformチームの @lainra と @nathan ーなぜOffice Hoursをやろうと思ったのですか? @lainra:このOffice Hoursは、Microservices Platformチームのメンバーにマイクロサービスについて何でも自由に質問できる1時間です。毎週金曜日16時に開催しています! 「い

    マイクロサービスについて何でも聞けるOffice Hoursに参加したよ! #メルカリな日々 | mercan (メルカン)
  • マイクロサービス化を支える継続的切り替え術 - クックパッド開発者ブログ

    こんにちはこんにちは。技術部のクックパッドサービス基盤グループのシム(@shia)です。グループ名が大きいですね。 クックパッドで運営しているサービスの中、一番古くから存在しているレシピサービス (cookpad.com) ——以下このサービスのコードベースを cookpad_all と呼びます——があります。 クックパッドサービス基盤グループはこのレシピサービスの運用及び改善という責務を持つグループとして今年の2月に発足しました。 わかりやすい業務の一つとしてはお台場プロジェクトが挙げられます。 お台場プロジェクトに関しては昨年12月の最後を飾った青木さんの クックパッド基幹システムのmicroservices化戦略 〜お台場プロジェクト1年半の軌跡〜という素晴らしい記事があるので紹介は省きます。 お台場プロジェクトの一つとして、僕は最近 cookpad_all からフィーチャーフォン向

    マイクロサービス化を支える継続的切り替え術 - クックパッド開発者ブログ
  • マイクロサービスアーキテクチャ向けにサービスメッシュを提供する「Istio」の概要と環境構築、トラフィックルーティング設定 | さくらのナレッジ

    Istio環境の構築 さて、続いては実際にIstioを利用できるクラスタ環境を構築していく流れを紹介していこう。 前提条件 Istioの利用には、まずコンテナエンジンとしてDockerが必要となる。また、対応するコンテナクラスタはKubernetes(バージョン1.9以降)もしくはNomad+サービスディスカバリツールConsul環境となっている。ただし、現時点ではNomadベースのクラスタでの利用は未テストというステータスのようだ。そのため今回は独自に構築したKubernetesベースのクラスタ上でIstioを利用する流れを説明する。 なお、IstioKubernetesのServiceやPod、Deploymentといった機能と連携して動作するようになっている。そのため、利用にはKubernetesの知識が前提となる。記事もKubernetesに関する知識がないと理解が難しい点があ

    マイクロサービスアーキテクチャ向けにサービスメッシュを提供する「Istio」の概要と環境構築、トラフィックルーティング設定 | さくらのナレッジ
  • これなら分かる!マイクロサービス(活用編)~そのアーキテクチャを実現するデザインパターンを一気に学習

    マイクロサービスについて、前回はそのアーキテクチャの概要から利点、そして課題についてまとめました。第2回の今回は、マイクロサービスを構成する個別の要素(デザインパターン)を一挙に説明します。マイクロサービスを学ぶ上で避けて通れない用語たちを、ひとつひとつ、分かりやすく丁寧に解説しました。さらに、マイクロサービスが持つどの利点に結び付くかをセットで解説することにより、単なる知識の列挙を避けたイメージしやすい構成をとっています。紹介しているものはいずれも特定の製品などに依存しない核となる要素ですので、エンジニアの方、ビジネスサイドの方問わず、長く役立つ知識となるはずです。 前回記事:これなら分かる! マイクロサービス(入門編)~モノリスと比較した特徴、利点と課題 マイクロサービスは「複数のデザインパターンの集合体」 入門編で解説したようなマイクロサービスを構成し、その利点を実現するためには、ひ

    これなら分かる!マイクロサービス(活用編)~そのアーキテクチャを実現するデザインパターンを一気に学習
  • クックパッド基幹システムのmicroservices化戦略 〜お台場プロジェクト1年半の軌跡〜 - クックパッド開発者ブログ

    インフラストラクチャー部の青木峰郎です。 最近はDWH運用の傍ら、所属とまったく関係のないサービス開発のためのデザインスプリントをしつつ、 Java 10でgRPCサーバーを書きつつ、 リアクティブプログラミングを使った非同期オーケストレーション層を勢いだけで導入したりしています。 ですが今日はそれとはあまり関係なく、クックパッドの中核サービスであるレシピサービスの アーキテクチャ改善プロジェクト、「お台場プロジェクト」の戦略について話します。 これまで、お台場プロジェクトで行った施策について対外的に発表したことはあっても、 全体戦略について話したことはありませんでした。 その一番の理由は、正直に言って、プロジェクトオーナーであるわたしにもプロジェクト全体の姿が見えていなかったからです。 しかし現在プロジェクト開始から1年半が経過してようやく全貌が見えてきたので、すべてをお話ししようと思い

    クックパッド基幹システムのmicroservices化戦略 〜お台場プロジェクト1年半の軌跡〜 - クックパッド開発者ブログ