はじめての投稿です。
少し自己紹介、2年間IT基盤運用保守をしてきましたが、異動となり、AP開発担当（あしかも開発手法はアジャイル）に異動になったので、早く仕事を覚えるためにアウトプットすることにしました。
毎日1投稿以上する縛りのもと俺は強くなる！！！
ということで、仕事中に出た不明用語を調査してきまーす。
マイクロサービス
複数の独立した小さなサービスを組み合わせて、1つの大きなアプリケーションを構築する開発手法。
マイクロサービスで構築されたアプリケーションの構成はマイクロサービスアーキテクチャという。
対義語はモノリシック、すべての機能がひとつにまとまった塊としてアプリケーションを作成していた。
サービスが小さいだけではなく、自らの役割に専念して、自律的に機能するという要素を持つ。
個々のサービスはできるだけシンプルにし、個々のサービスの依存度を低くすること。また、サービスの呼び出しはネットワークを介して行うのも特徴。
メリット
新しい技術を用意に採用できる。
上記に書いた通り、個々のサービスはネットワークを介して、それぞれ公開したインターフェースを呼び合うのだけで、その他の依存関係はない。呼び合うためのインターフェース仕様が一致していれば異なる技術を使用しても問題ない。
保守性の向上、改修の容易さ。
各サービスは依存度が低く、小さなものなので、機能追加した際の影響範囲が狭い。
俊敏性
各サービスに対して、少人数の独立したチームが責任を持つことで、大規模な開発チームと比較して早く開発できる。
アジャイル開発に超向いてる
アジャイル開発は少人数のチームが各サービスを開発しているのでマイクロサービスに適した開発手法といえる
デプロイが容易
各サービスは依存関係が低いので、デプロイする際にシステム全体を停止する必要がない。
デメリット
設計や統括に高いスキルが必要
メリットで各サービスに異なる技術を採用できると記述したが、裏を返せば、システム全体の難易度は上がる。また、最初に分割したサービス単位は後から変更できないため設計には高スキルが求められる。
結合テスト以上の難易度が高い
各サービス内のテストは容易だが、実際は複数のサービスが連携してユーザに提供される、そのためテストでエラーが出た場合、どの機能が原因か特定するのが難しい。
API管理が大変
各サービスはAPIなどを通じて、通信しあうので、1つのアプリケーションに多くのAPIが使用される。サービスに変更がなくても、APIに変更があればそのAPIを使用している機能すべてに影響がある。
まとめ
柔軟性、拡張性の求められるアプリケーションに向いていると感じた。
アジャイル開発に向いている。
各サービス毎に異なる技術を採用できるので、IT人材育成の面でもよいと感じた。
APIに関する知識がないので調査したい