David Heinemeier Hansson: Microservices vs. Monolith - https://www.youtube.com/watch?v=rkXGSLf-rVQ

지난 몇 년간 애플리케이션 구조에 관한 큰 논쟁 중 하나는 마이크로서비스로 갈 것인가 아니면 모놀리스로 갈 것인가였습니다. 이 논쟁은 때로는 격렬하게, 때로는 잠잠하게 계속되어 왔습니다. 그러나 최근에 다시 활발해졌는데, 이는 마이크로서비스 아키텍처를 채택했던 많은 애플리케이션들이 그것이 유행일 때 도입했다가 자신들에게는 그리 적합하지 않았다는 것을 깨달았기 때문입니다. 아마존 같은 회사조차 일부 애플리케이션에서 마이크로서비스를 포기했습니다. 이에는 좋은 이유가 있습니다. 마이크로서비스는 코드 구성 방식보다는 조직 구조에 관한 패턴입니다. 단일 애플리케이션에 대규모 팀이 작업하고 각 팀이 하위 영역을 담당해야 하는 경우, 그렇다면 마이크로서비스가 일부 경우에 의미가 있을 수 있습니다. 하지만 10명, 20명, 심지어 50명이나 100명의 개발자 팀이라면, 모놀리스로 가는 것이 훨씬 더 간단합니다. 모든 메소드 호출을 네트워크 호출로 대체하는 대신, 같은 컴퓨터에서 유지할 수 있습니다.  분산 시스템의 복잡성을 다루지 않아도 될 때앱의 기본 기능을 위해 네트워크 연결을 걱정할 필요가 없어 컴퓨터의 복잡성 중 상당 부분을 제거할 수 있습니다. 이는 보통 디버깅을 어렵게 하고 개인이 전체 시스템을 이해하기 힘들게 만듭니다. 여기서 핵심은 다른 패턴이 다른 조직에 적합하다는 것을 인식하는 것입니다. 마이크로서비스와 그 접근 방식은 Netflix 같은 회사에서 나왔습니다. 수천 명의 개발자가 있는 회사들은 시스템 구축에 다른 접근 방식이 필요했고 그 수준의 조직에 맞게 확장해야 했습니다. 만약 이런 종류의 패턴들, 수천 명의 개발자가 있는 회사에서 만들어진 패턴을 5명, 10명 또는 100명의 개발자가 있는 회사에 적용하면 매우 좋지 않은 결과를 얻게 됩니다. 여러분 조직에 존재하지 않는 환경과 맥락에 대해 무거운 복잡성 세금을 지불하게 됩니다. 제게 이는 가장 어리석은 일 중 하나입니다. 그래서 저는 모놀리스를 사랑합니다. 너무나 사랑해서 몇 년 전에 '장엄한 모놀리스'라는 용어를 만들었습니다. 저는 오랫동안 가능한 한 간단하게 유지하는 것을 주장해 왔습니다. 장엄한 모놀리스는 정확히 그렇게 합니다. 바로 그렇습니다.