Monolith to MSA : 10가지 원칙

Decompose your monolith: Ten principles for refactoring a monolith to microservices
https://chrisrichardson.net/post/refactoring/2020/08/21/ten-principles-for-refactoring-to-microservices.html
Monolith to MSA : 10가지 원칙을 다룬 위의 내용 요약 + 첨언

 

1. Make the most of your monolith
Monolith를 최대한 활용해라

2. Adopt microservices for the right reasons
MSA는 Architecture Style중 하나일 뿐이다.
결합도/커플링이 낮은(loosely coupled) 서비스들로 구성하는 스타일이고 각 서비스들은 아래와 같이 되어야 right reason이라할 수 있지 않을까 (최소한)?
 - highly maintainable and testable
 - independently deployable (생각해볼것중 하나 : DB를 공유하면 독립적으로 배포가 될까?)
 - organized around biz capabilities (좀 추상적인 표현인데 최대한 업무 중심으로, Single Responsibility)
 - owned by a small team (생각해볼것중 하나 : 하나의 MSA를 여러팀에서 설계/개발?제어?관리?)

right reason 없이 MSA를 도입하면 안된다 !!! 

는 이야기를 하려는것 같다. 백번 공감한다.

3. It’s not just architecture
Anti-Pattern : Red flag law (Anti Pattern 에서 별도 설명 필요)

현재의 프로세스, 정책, 조직의 변환없이 MSA를 도입한다면?
Silo'd team, Manual testing, Monthly deploys, ...

 

MSA로 전환한다는 것은 아키텍처만 새로 적용하는게 아니란 의미이고

신기술이나 유행하는 기술을 적용해보겠다는 목적도 아니다.

4. Get the support of the business
Business(업무팀)의 지원은 필수다.

어떻게 서비스로 쪼갤지 개발자들로만 의사결정이 가능하겠는가?

5. Migrate incrementally
Monolith to microservices = Application Modernization
Monlith는 반드시 Incrementally 쪼개라 (Strangler 처럼, https://blog.daum.net/kooangelo/110)

6. Know your starting point
Migrating a monolith to microservices = Converting one module at a time 한번에 하나씩
=> You need to know the modules

7. Begin with the end in mind
Define coarse-grained services.
Service-per-team is a good starting point.

8. Migrate high-value modules first
Start with the modules that would give you the gratest return on investment (ROI)
무조건 효과가 큰것이라기 보다는, 가성비 좋은것 부터 떼라
X축 : Benefit of extraction Low, High
Y축 : Ease of extraction Low, High 
로 4분면을 만들고 각 4분면에 모듈을 배치해서 선택할 수 있겠다. 가성비 좋은것부터
이행전략 수립 시 어떤것을 어느 단계에 떼어낼지 유용한 도구가 되겠다.

 

Monolith에서 Service 추출시 장점 및 비용 (공짜는 없다, Trade off)

장점

 - 장애전파최소화, 개별확장성 등의 심각한 문제가 해결

 - 빠르게, 자주, 신뢰성 높은 배포 환경 구축

 - 리소스 제약/충돌 등의 확장성 문제 최소화 등

비용

 - 기존의 Monolith를 변경하고 특정 모듈을 재작업하여 적용하는 비용

 - 내부적인 Dependency(App, DB) 를 끊어내는 Decoupling하는 어려움

 - 보상 트랜잭션이나 Saga 등의 추가 설계/개발 필요

9. Success is improved velocity and reliability
Success != Number of microservices

한번에 하나씩 모듈을 떼어 서비스로 성공하는 경험을 하고 나면, 이후에 다른 것을 떼어낼때는 속도도 더 빨라지고 보다 안정적으로(신뢰성 향상) 수행할 수 있게된다. (자신간과 노하우가 생겼으므로)

10. If it hurts, don’t do it
아프면... 힘들면 하지마 ㅋㅋ, 웃을일이 아니다, 진심으로 느껴지는 원칙이다.

다르게 말하면 준비되어 있지 않으면 하지마.

최소한 적용하려는, 공부하려는, 마음의 준비라도 있어야 시작할 수 있다.

쪼개진 서비스가 너무 많거나, 복잡하거나, 커플링 심하거나, 어떤 작전(로드맵)이 없거나, 
또는 9번과 같은 성공경험없이 내재화없이 일단 MSA를 도입하게 되면 많이 아플수 있다.

 

준비가 되지 않은 상황에서도 이럴진데, 윗사람과 아랫사람의 생각이 다르고, 발주사와 수행사의 생각이 다르고, 적당히 흉내/포장만을 원하는 상황이라면 당연히 Don't do it. 대신 원래 잘하던 방식으로 하는게 현명하리라 생각한다.