移行が大変だもん
![Node.js v12 を使い続けていたのはなぁぜなぁぜ?](https://cdn-ak-scissors.b.st-hatena.com/image/square/b581831688c988827cedd85f326ed312af7a1121/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5b6fc1aa80654e889813dbad72aa880f%2Fslide_0.jpg%3F28164805)
Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ
複数のクラウドサービスを利用している(マルチクラウド)など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
re:Invent 2019 SVS343 Building microservices with AWS Lambdaのセッションレポートです。 はじめに SVS343-R1 - Building microservices with AWS Lambdaのセッションレポートです。 [REPEAT 1] Building microservices with AWS Lambda このセッションでは、AWSでの普遍的なマイクロサービスパターン、及びLambdaでのマイクロサービス作成について触れます。 AWSのmicroservice AWSのサービスは数多くのマイクロサービスの上に成り立っています。例えば、Amazon S3はロンチ時に8つの異なるマイクロサービスの上に成り立っていました。2018年時点では235以上の異なるマイクロサービスの上に成り立っています。 マイクロサービスの組
100万行オーバーのモノリシックRailsアプリをマイクロサービス化したクックパッドの手順 マイクロサービスの導入事例を、中の人が徹底的に語ります。クックパッドでは、100万行オーバーの超巨大なRuby on Railsアプリのマイクロサービス化に挑みました。アプリをいかに分離し、連携できるようにするか、など、同社が採ったマイクロサービス化の戦略を聞きました。 Ruby on Railsのバージョンアップに1年かかっていた 【マイクロサービス化戦略】まずはコードを減らすことから 【マイクロサービス化戦略】アプリ固有のバッドノウハウを減らす 【マイクロサービス化戦略】まずは分離しやすい部分からお試しで 【マイクロサービス化戦略】データベースが切れていればサービスも切りやすい 【マイクロサービス化戦略】インフラ構成を標準化する 【マイクロサービス化戦略】サービスメッシュを入れて通信の課題をクリ
1. CyberAgent, Inc. All Rights Reserved JSUG 勉強会 SpringOne Platform 2016 報告会! CaseStudy その1 Yusuke Ikeda / @yukung CyberAgent, Inc. 2. CyberAgent, Inc. All Rights Reserved 事例紹介 3. 私が聴講した 2 社を 紹介します 4. 事例紹介 ● Lessons Learned from Migrating Legacy Enterprise Applications to Microservices ○ Ontario Teachers’ Pension Plan(オンタリオ州教職員年金基金) ● Gap Inc.’s Cloud Migration: Lessons Learned ○ Gap Inc. 5. Cyber
データとML周辺エンジニアリングを考える会 #1 2019 / 01 / 18 の資料です https://data-engineering.connpass.com/event/111658/
Site Reliability Engineering チームの @yuya-takeyama です。 年末年始頃は React Native でのアプリ開発をやっていた気がしますが、「スキルを Web 開発から SRE の領域まで広げたい」という以前からの私自身の思いと、「Kubernetes による Microservices 基盤を作っていくメンバーがもっと必要」「Microservices を技術面だけでなく組織面でも Production Ready な形でやっていく上で Developer と SRE のつなぎ役が必要」という会社の状況が一致したので、異動して AWS, Kubernetes または MongoDB などと向き合っています。 3 行でまとめ Sidecar Pattern はアプリケーションのコンテナから再利用可能な部分をもう一つのコンテナとして切り出すパター
ベルリンで開催されたmicroXchg 2016カンファレンスでRichard Rodger氏は,“Surviving Microservices”と題したプレゼンテーションを行なった。マイクロサービスアーキテクチャの安定稼働を維持したいと望む開発者を対象とした,実践的なガイドだ。講演で議論されたおもなテーマは,メッセージ思考システムのメリット,サービス間コミュニケーションにおけるパターンマッチングの使用,障害時の対処,Seneca.jsマイクロサービスフレームワークの紹介などだ。 InfoQは先日,nearFormの共同設立者でCTOのRodger氏と席を共にする機会を得て,この講演のテーマについてさらに詳しく聞くことができた。話題はさらに,Seneca.jsフレームワークを開発した動機(およびマイクロサービスプラットフォームの現在の状況における位置付け)や分散システムにおける効果的な障
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く