Microservices Architect in DMM Platform - DMM inside｜DMM inside
技術選定とアーキテクトの育成について - NRIネットコムBlog
こんにちは佐々木です。NRIネットコム Advent Calendar 2021 開催中です。しかし、内部で検討した結果、私は枠外になりました。ということで、Japan APN Ambassador Advent Calendar 2021として書かせていただきます。どちらも宜しくおねがいします。 今日のテーマは技術選定とアーキテクトの育成についてです。ITエンジニアの間には、定期的にどう技術選定するのかといった議論が出てきます。いろいろな観点があるとは思いますが、私が重要であると考えている所を簡単に述べてみます。 技術選定に銀の弾丸はない まず最初に言っておきたいのが、『技術選定に銀の弾丸はない』ということです。銀の弾丸とはIT業界でもよく利用される比喩で、英語で“silver bullet”とは「狼男を倒せる武器」が元々の意味です。それが転じて「困難を解決する決め手」という意味で使われ
ビジネス・アーキテクチャとシステム・アーキテクチャ - Runner in the High
うちのコンサルが「システムアーキテクチャを決めるためには、ビジネスアーキテクチャを先に固めることが必要」と言ったら、お客様が「事業構造の変化が激しすぎてビジネスアーキテクチャを固めることが難しい」と仰った。 そうだよなぁ。システムの寿命よりビジネスの寿命のほうが短くなってるのかも— ボム / SIer (@bombombomb2017) 2021年8月29日 これにめちゃくちゃ共感した。 よくあるアーキテクチャ設計では、ドメイン層と応用層を分離することで応用層におけるコントロール不能な変化をドメイン層に及ばないようにさせたりする。しかし、現実のプロダクト開発ではDBやフレームワークなどの応用層で起きる変化よりもドメイン層の変化のほうが圧倒的に多い。システムにおけるすべての中心にあり、あらゆるところから依存されているドメインが頻繁に変化するとなると非常にツライ。 とはいえ、ビジネス・アーキテ
Zero Touch Productionとは何か
GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた．これはインフラの権限管理やインフラの構築そのものの指針となる概念であり，自分がそうあるべきだとずっと思ってきた考え方でもある．これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく． Zero Touch Production Building Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている． The SRE organization at Google is working to build upon the concept of least
分析基盤と組織のあり方 - DeNAの事例
今回のテーマは「分析基盤をうまく組織に浸透させる方法」です。 「分析基盤を浸透させていく上で、分析基盤を担う組織(分析基盤組織)がどのように形を変えていったか」という内容です。組織設計の参考になれば幸いです。
マネーフォワードCTOが考えていること（2020年3月） - Money Forward Developers Blog
こんにちは、マネーフォワード CTOの中出(なかで)です。 CTOの私が普段なにを感じて、どんなことを考えているかを、改めて言語化して、社内に共有するという取り組みをしています。 そうしたところ「当社のエンジニア組織に興味を持っている方にも読んでいただくのがいいのでは？」という社内の意見もあり、今回公開することにしました。 もちろん、日々考えていることは変化しているので、今後は四半期に一度ぐらいの頻度で、変更があれば更新していきます。 ※公開用として、社内向けの内容を一部編集しております。 これからのマネーフォワードのエンジニア組織について まず、マネーフォワードのエンジニア組織として「どこを目指すのか」という話をしたいと思います。 もちろんビジネスには「やれる・やれない」という議論も必要ですが、まずは私たちが「どこを目指すのか」という意志が必要です。 そして、「どこを目指すのか」を決めた
Mercari Microservices Platformの進捗（2019年） | メルカリエンジニアリング
Microservices Platform TeamでTech leadをしている@deeeeeeetです． 昨年のMTC2018ではMicroservices Platformチームの立ち上げから1年で僕らが取り組んできたことを紹介しました． speakerdeck.com 具体的にはStranglerパターンによるMonolithからMicroservicesへの段階的なリクエスト移行を行うためのAPI gatewayの開発や，Microservicesのインフラのセットアップを簡単にしサービス開発チームのSelf-service化を進めるためのStarter-kitの開発，GoでのMicroservicesの開発を高速で始めるためのTemplateプロジェクトの開発，Spinnakerの導入などについて紹介しました． これらはPlatformとして最低限の機能を整備したにすぎず，さ
なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://engineering.mercari.com/entry/2019/12/01/microservices-migration-progress
System of Record と System of Engagement