M2M - Chapter 2(P33-P41): Planning a Migration
===
Less technical issues:
- Where you should start the migration?
- How should you manage the change?
- How do you bring others along the journey?
- Should you even use microservices in the first place?

## Understanding the goal
- Adopting a microservice should be:
- conscious decision
- based on rational decision-making

- Migrating to a MS architecture in order **to achieve something you can't currently achieve with your existing system architecture**

- **What you are trying to achieve?**
- To define where you focus your time, and prioritize your efforts
- avoid the risk of "cargo cult mentality":
- https://en.wikipedia.org/wiki/Cargo_cult
- for Vietnamese: https://toidicodedao.com/2020/05/19/cargo-cult-lap-trinh-kieu-bay-dan/?fbclid=IwAR2NPPN4SUOaNHCugC4JUSqIVYI9WbXLS0O3MpGWQSRpiTpAst0F37M_0jI
- Don't do things just because orther people is doing that. You should understand from the first place "why you do it?"

### Three Key Question
Questions for you to think again regarding whether to go any further with a microservice architecture:

- What are you hoping to achieve?
- outcomes aligned to what the business is trying to achieve
- the benefit to the end users of the system
- Have you considered **alternatives** to using microservices?
- How will you know if the transition is working?

## Why Might You Choose Microservices?
The reasons why MS are being adopted, what are other ways to achieve that without MS?

|Question|Describe|How to achieve it without MS?|
|---|---|---|
|Improve Team Autonomy|- autonomous teams: organizational groups small, allowing them to build close bonds and work effectively together without bringing in too much bureaucracy<br/>- When teams own microservices, and have full control over those services, they increase the amount of autonomy they can have within a larger organization.<br/>- [Spotify Engineering Culture](https://www.youtube.com/watch?v=Yvfz4HGtoPc) & [amazon's two-pizza model](https://medium.com/plutonic-services/why-two-large-pizza-team-is-the-best-team-ever-4f19b0f5f719)|- distribution of responsibility<br/>- Giving ownership to parts of the codebase to different teams, who is responsible for what part of code<br/> - modular monolith|
|Reduce Time to Market|- By being able to make and deploy changes to individual microservices, and deploy these changes without having to wait for coordinated releases|- define path-to-production modeling exercise<br/>- ook at how long they take, the durations (both elapsed time and busy time) for each step, and highlight the pain points along the way|
|Scale Cost-Effectively for Load|- scale up/down only neccesarry parts|- Vertical scaling: get "bigger box"<br/>- horizontal scaling: running multiple copies of monolith behind a load-destribution mechanism - easier to try (may have bottleneck at database)<br/>- replace to other technology to handle load better|
|Improve Robustness|- By using microservices, we are able to implement a more robust architecture because functionality is decomposed — that is, an impact on one area of functionality need not bring down the whole system -> focus our time and energy on those parts of the application that most require robustness|- running multiple copies of your monolith<br/>- Don't: the robustness of your application relies on human beings never making a mistake|
|Scale the Number of Developers|- adding more people will only continue to improve how quickly you can deliver, if the work itself can be partitioned into separate pieces of work with limited interactions between them<br/>- how the teams align to the service ownership, and what coordination between teams is required|- different teams own each module, and as long as the interface with other modules remains sta‐ ble, they could continue to make changes in isolation. (but the act of deployment still requires coordination between the appropriate parties)|
|Embrace New Technology|<br/>- With a microservice architecture, we get the option to vary these choices for each service. "right tool for right job" -> competitive advantages for delivering better results for customers<br/>- **In author experience**, mature microservice organizations often limit how many technology stacks they support(*), they are rarely homogeneous in the technologies in use.|- Monoliths typically limit our technology choices, change to a brand new stack!?|

(*) https://tech.mercari.com/entry/2019/12/23/084839:
MercariとMerpayのMicroservicesは基本的に全てGoで実装しており現在はPolygrotへの志向は持っていません（特に初期は技術を統一してその上で仕組みを構築することが大切だからです）．一方で，どうしてもGoのみでは十分でないところもあります．フロントエンドのためにNode.jsを使う，MLのモデルのServingのためにPythonを使うといった要望が挙げられます．これらの言語の要望に合わせてライブラリを開発してメンテナンスしていくには大きなコストがかかります．Goだけでも非常に大変です...

Sportify:
https://youtu.be/Yvfz4HGtoPc?t=228

https://martinfowler.com/bliki/MicroservicePrerequisites.html