Don’t start with a monolith… when your goal is a microservices architecture. Great article by @stilkov on @martinfowler web site. Check it out: martinfowler.com/articles/do… #microservices #monotith
3
3
12
I fully agree with @simonbrown if you are not able to build a well structured monolith, why should you be able to build a well structured microservices system....
1
2
That is completely backward, and @simonbrown and I have disagreed about this for a long time :)
1
1
We have? I thought that we disagreed about monolith first vs going microservices from the start ... not a team’s lack of ability to create a decent modular codebase. 😀
1
3
Maybe I remember our discussions incorrectly, entirely possible. My point is: The whole point of microservices/self-contained Systems is that they prevent you from accidentally creating tight coupling
2
3
I agree 100% that a distributed monolith is much worse than a non-distributed one
1
1
2
But the early-stage separation, if done correctly, can help you prevent creating it in the first place
2
But that’s just like saying we wouldn’t need debuggers if we simply created correct programs in the first place
1
1
This is a pretty weird analogy. We use a an architecture with less tooling support and higher complexity because we aren't disciplined enough to structure our codebase correctly?
1
2
No. It’s the realization that coupling will creep in unless you make a very explicit effort to avoid it

Sep 26, 2019 · 10:03 PM UTC

2
2
And this is true whether it is a single deployable unit or multiple. It is just entropy playing it's part: we need to consciously put effort to keep things under control. What we can do to help is to have well defined fitness functions that enforce our architectural constraints.
4
Proper architecture, tests, discipline... that's enough for us to create fully modular and loosely coupled monolith. :)
1