David Heinemeier Hansson: Microservices vs. Monolith - https://www.youtube.com/watch?v=rkXGSLf-rVQ
For the last several years, one of the big titanic battles in how to structure your application has been to go microservices or to go monolith. This debate has been raging on and off, sometimes intensively, otherwise dulling down. But as of recent note, it's kind of blossomed up again, because a lot of applications who've gone with a microservices architecture when that was the hot, hot thing, have I realized that perhaps it wasn't so hot for them? Even the likes of Amazon has backed off on microservices for at least some of their applications. And I think there's a really good reason for that. Microservices is a pattern that is about organizational structure much more than it is about how to organize your code. If you have incredibly large teams working on single applications and you have to break those up such that the individual teams can own a sub area of it, yeah, microservices can make sense in some cases. But if you're a team of 10, 20, maybe even 50 or 100 developers, going with a monolith is just so much simpler. Instead of replacing all your method calls with network calls, you can just keep it on the same computer. When you don't have to worry about network connectivity to make the app do its most basic functions, you cut out a huge swath of complexity that otherwise bogs you down, makes things hard to debug, makes it hard for any individual to understand the whole system. And I think what's really key here is to realize that different patterns fit different organizations. Microservices, and that whole approach came out of companies like Netflix, with thousands and thousands of developers who needed a different approach to building their systems and making it scale for that level of an organization. And if you take those kinds of patterns, the patterns that were built and extracted from companies of thousands of developers, and you apply them to companies of 5, 10, or 100 developers, you very often get really poor results. You are paying a heavy complexity tax for an environment and a context that just doesn't exist in your organization. That, to me, is one of the most foolish things that you can do. So I love the monolith. I love it so much. I coined the term the Majestic Monolith many years ago. I've been advocating for keeping things as simple as possible for as long as possible. And the Majestic Monolith does exactly that.
David Heinemeier Hansson: Microservices vs. Monolith - https://www.youtube.com/watch?v=rkXGSLf-rVQ
지난 수년간 애플리케이션을 어떻게 구조화할 것인가를 두고 벌어진 거대한 논쟁 중 하나는 마이크로서비스로 갈 것인가, 모놀리스로 갈 것인가였습니다. 이 논쟁은 때로는 격렬하게, 때로는 잠잠하게 계속 이어져 왔습니다. 그런데 최근 들어 이 논쟁이 다시 활발해졌습니다. 마이크로서비스 아키텍처가 가장 유행하던 시기에 그것을 채택했던 많은 애플리케이션이 자신들에게는 그다지 맞지 않았다는 것을 깨달았기 때문입니다. 심지어 아마존조차 일부 애플리케이션에서는 마이크로서비스에서 한발 물러섰습니다. 저는 거기에 아주 타당한 이유가 있다고 생각합니다. 마이크로서비스는 코드를 어떻게 구성하느냐보다 조직 구조와 훨씬 더 관련 깊은 패턴입니다. 엄청나게 큰 팀들이 하나의 애플리케이션에서 작업하고 있고, 각 팀이 하위 영역을 맡을 수 있도록 애플리케이션을 나눠야 한다면, 마이크로서비스가 의미 있는 경우도 있습니다. 하지만 10명, 20명, 많게는 50명이나 100명 정도의 개발자로 이루어진 팀이라면, 모놀리스로 가는 편이 훨씬 단순합니다. 모든 메서드 호출을 네트워크 호출로 바꾸는 대신, 같은 컴퓨터 안에 그대로 둘 수 있으니까요. 앱의 가장 기본적인 기능을 수행하기 위해 네트워크 연결을 걱정할 필요가 없다면, 그렇지 않았다면 여러분을 짓누르고, 디버깅을 어렵게 만들고, 누구도 전체 시스템을 이해하기 어렵게 만들었을 엄청난 복잡성을 덜어낼 수 있습니다. 여기서 정말 중요한 점은 조직마다 맞는 패턴이 다르다는 것을 깨닫는 것입니다. 마이크로서비스와 그 모든 접근 방식은 넷플릭스 같은 회사에서 나왔습니다. 수천, 수만 명의 개발자가 있어서 시스템을 구축하는 다른 방식이 필요했고, 그 규모의 조직에 맞게 확장해야 했던 곳이죠. 그런데 수천 명의 개발자가 있는 회사에서 만들어지고 추출된 이런 패턴을 5명, 10명, 100명 규모의 회사에 적용하면, 대개 결과가 아주 좋지 않습니다. 여러분의 조직에는 존재하지도 않는 환경과 맥락 때문에 무거운 복잡성 세금을 내고 있는 셈입니다. 제게 그것은 할 수 있는 가장 어리석은 일 중 하나입니다. 그래서 저는 모놀리스를 사랑합니다. 정말 많이요. 저는 아주 오래전에 '위풍당당한 모놀리스(Majestic Monolith)'라는 용어를 만들었습니다. 저는 가능한 한 오랫동안 가능한 한 단순하게 유지하자고 주장해 왔고, 위풍당당한 모놀리스는 바로 그 일을 해냅니다.
# Summary of "Monoliths vs Microservices: The Majestic Monolith" Video
이 비디오는 마이크로서비스와 모놀리식 애플리케이션 아키텍처 간의 지속적인 논쟁을 탐구하며, 각각의 접근 방식이 언제 그리고 왜 적합한지에 대해 강조합니다. 발표자는 많은 개발 팀들에게 모놀리식을 지지하며, 마이크로서비스 도입에 따른 복잡성 트레이드오프를 강조합니다.
---
## Introduction to the Debate [00:00:20]
- 애플리케이션을 **마이크로서비스 또는 모놀리식** 구조로 설계할지에 대한 논의는 수년간 계속되어 왔습니다.
- 최근에는 많은 조직이 마이크로서비스에 대한 초기 열정을 재고하면서 이 논쟁이 다시 주목받고 있습니다.
- 아마존과 같은 대기업조차 일부 애플리케이션에 대해 마이크로서비스에서 물러난 사례가 있습니다.
## Microservices: Organizational Pattern Over Code Structure [00:00:37]
- 마이크로서비스는 단순한 코드 구조보다는 **조직 구조**를 주로 다룹니다.
- 매우 큰 팀(수천 명의 개발자)에서 독립적으로 소유하는 하위 도메인으로 시스템을 분할하는 것이 적합할 때 가장 효과적입니다.
- 이 접근법은 넷플릭스와 같은 대규모 개발 팀을 가진 회사에서 시작되었습니다.
## Challenges of Microservices for Smaller Teams [00:00:58]
- 10명에서 100명 규모 팀의 경우, 마이크로서비스는 종종 불필요한 복잡성을 더합니다.
- 마이크로서비스는 로컬 메서드 호출을 네트워크 호출로 대체하는데, 이로 인해:
- 통신 복잡성 증가
- 디버깅 어려움
- 개인이 시스템 전체를 이해하기 어려움
## Advantages of Monoliths for Small to Medium Teams [00:01:10]
- 모놀리식은 모든 것을 동일한 시스템 내에 유지하며 네트워크 의존성이 없습니다.
- 이러한 단순성은 버그와 인지 부하를 줄입니다.
- 팀이 애플리케이션 전체에 대해 **명확하고 통합된 이해**를 유지할 수 있게 합니다.
## The Importance of Choosing the Right Pattern for Your Organization [00:01:35]
- 대규모 조직용으로 설계된 마이크로서비스 패턴을 소규모 팀에 적용하면 대응 이익 없이 **높은 복잡성 비용**을 치르게 됩니다.
- 각 조직은 자신의 규모와 필요에 맞는 아키텍처 패턴을 선택해야 합니다.
## Advocacy for the Majestic Monolith [00:01:55]
- 발표자는 애플리케이션을 가능한 한 단순하게 유지하기 위해 **"Majestic Monolith(장엄한 모놀리식)"**라는 용어를 만들었습니다.
- 모놀리식을 지지하는 사람들은 복잡성을 최소화하고 조기 아키텍처 과잉 설계를 피하는 것을 강조합니다.
---
# Conclusion
이 비디오는 개발자와 조직이 마이크로서비스를 도입하기 전에 팀 규모와 상황을 신중히 고려할 것을 권장합니다. 마이크로서비스는 매우 큰 팀에 유리하지만, 많은 소규모 팀은 모놀리식 아키텍처가 더 단순하고 관리하기 쉽고 효과적임을 알게 될 것입니다. **Majestic Monolith** 개념은 복잡성이 진정으로 필요해질 때까지 애플리케이션 설계에서 단순성과 명확성을 우선시하라는 메시지를 전달합니다.