運営者情報

運営してるひと: @sters9

       

妻と猫と横浜あたりに住んでいる。最近は Go や Kubernetes や GCP をしています。 PHP や JavaScript もすこし。

プライバシーポリシー

tools.gomiba.co

アーカイブ

2021/06 (5) 2021/05 (10) 2021/04 (1) 2021/03 (8) 2021/02 (12) 2021/01 (8)

2020/05 (2) 2020/04 (2) 2020/02 (2) 2020/01 (1)

2019/12 (3) 2019/11 (2) 2019/10 (5) 2019/09 (3) 2019/07 (6) 2019/06 (4) 2019/04 (3) 2019/01 (2)

2018/12 (6) 2018/10 (4) 2018/09 (6) 2018/08 (7) 2018/07 (16) 2018/06 (7) 2018/05 (7) 2018/04 (5) 2018/03 (3) 2018/02 (10) 2018/01 (6)

2017/12 (8) 2017/11 (6) 2017/10 (10) 2017/09 (12) 2017/08 (12) 2017/07 (3) 2017/06 (1) 2017/01 (4)

2016/12 (5) 2016/10 (3) 2016/09 (1) 2016/07 (2) 2016/06 (1) 2016/04 (1) 2016/02 (1) 2016/01 (2)

2015/12 (1) 2015/10 (1) 2015/09 (3) 2015/06 (1) 2015/01 (1)

2014/08 (2) 2014/07 (3) 2014/05 (1) 2014/01 (7)

2013/12 (2) 2013/11 (4) 2013/10 (1) 2013/09 (1) 2013/08 (3) 2013/07 (4) 2013/06 (5) 2013/05 (2) 2013/04 (7) 2013/03 (1)

Microservice architecture patternsを読む - Monolithic Architecture

  • トップページ: A pattern language for microservices

  • 読んだもの: Monolithic Architecture pattern

  • これはアプリケーションアーキテクチャのひとつ

  • ひとことでいうと、アプリケーション全体が単一のデプロイでできるような状態

    • この記事ではECサイトを例に上げている。
      • ショップとしてのフロントエンド
      • アカウント管理
      • 在庫管理
      • 配送管理
      • これらを単一のアプリケーションとして開発、デプロイする。
  • Monolithicのメリットは簡単でわかりやすいところにあるが、逆にデメリットにもなる。

    • 開発は1箇所でよい
      • 言語やフレームワークによる制約が生まれる
      • コード量が大きくなる
    • デプロイも1個でよい
      • 開発の規模が増えるとデプロイ回数が増えていくが並行したデプロイが出来ずリリース調整みたいなことが必要
    • スケールもまるごと増やせばよい
      • コンポーネントによる負荷の調整が難しい(例えば、ある機能はCPUをよく使うが、別の機能はメモリをよく使う、とか…?)
  • 似た(同じレベル)のアーキテクチャとして、Microservice Architecture がある。

    • これは次に読む。
  • 例えば、アプリケーションがどうなっていくのか不明確なときとか、サクッと世の中に出していくぞ!みたいなときは簡単(いろいろなことを考えずに済む)なので、この選択はいいとおもう