Pendulum swung back! Now The "modular monolith first" is the best advice. But is it? It sounds great in theory but can fall short in practice.In practice, too often: module boundaries erode, resource isolation is absent, and that promised "easy split" rarely happens. Also, ease of deployment is not so easy, as CI/CD tooling is not existing or absent. Read more in the recent article!
One thing that I think you missed in the article (although you did mention about team experience) is team size. Microservices is not only a technical solution. It is an organization solution as well and it is important. One solid and expirienced team can work with a monolith faster. The catch comes when the scope of works increases
Good point, Manos. I should have highlighted that more. Indeed, the choice is not simple, and Conway's Law is kicking in. An important factor is how much our teams can collaborate and how much cognitive load they can comprehend.
I saw people going to extremes, where you have >1 service to maintain per person. On the other hand, needing to understand the whole system when you want to make a simple change is the other range of scale.
As you said, it's important to aim to find the "sweet spot" where you have just enough autonomy and just enough ceremony. But that can only happen when we understand what we need to build, then "how" can come.
Exactly, you expressed it much better than I did. Unfortunately, despite all the community efforts, we still face a shortage of experienced engineers actually doing the work. It's like being an architect — even if I design the best possible architecture on paper, if I’m not there reviewing, mentoring, and teaching, it won’t matter much. It's not just about improving skills; it’s also about helping others understand how to save time, create value, and generally do what senior engineers are supposed to do. Without that hands-on involvement, even the best architectural decisions lose their impact on the final outcome.
Yup, I agree, from my perspective, Architects should always be hands-on. Of course, that doesn't mean that it's their main activity, but they should be aware experience people are facing by applying their decisions.
Also, I believe that we should have more architects than a single one, and it would be best if all people were somehow responsible for making architecture and held accountable.
Of course, we still need decision-makers and people who make hard decisions and shape strategy, so the Architect role is still needed, but it is different from the past.
I enjoyed this very much. I like how it all comes full circle to use modular design, a relatively very old concept. There is some truth ringing here that first principles of good software design are not pre-empted by fancy new approaches. I think it was revelatory and honest to say compartmentalization (of any kind) is great until you need to use data from multiple sources and then the elegance is gone and the problems come in. There are no easy answers. It's sort of like the only way to keep a computer secure is to power it off and put it in a locked room. The only way to have elegant system design is to not allow any business logic. Real world problems are messy, and so are the programs that handle them. An excellent point towards considering the trade-offs of any design.
> There is some truth ringing here that first principles of good software design are not pre-empted by fancy new approaches. I think it was revelatory and honest to say
Yes, I think that we should have some sort of regular activity to get back to basics and kinda "nurture our ignorance". Of course, in a positive way to reevaluate our decisions, and see if they still apply. Plus the same for practices.
As you said, nothing is simple if we work on that enough long. That's also why I don't like the overselling and hot-takes that are not going further than 0-day issues.
Good modularization requires taking a moment to pause and think about how the components interact with each other, where the responsibility for a particular decision should fundamentally lie — how a given question should be exposed, and so on.
But honestly, I get the feeling that people don’t like to think. They just want to start banging on the keyboard right away — or nowadays, just copy the task into GPT or some other cloud tool, then paste the result back in. :/
Fully agreed, I think that "vibe coding" always existed in our industry. Many developers just want to solve "coding sudoku". Business cases, budgets or technical constraints, are not blocking that from producing more code.
That's also why I believe that "being in the zone" is also overrated. I mean, I love that feeling, but each time I've spent too much time "being in the zone" I realised afterwards that I actually didn't solve anything but just was moving code from one place to the other.
An interesting read as usual. While reading I realized how blessed I am by being in a team that does not take the path of least resistance and organization that would not remove practical simple solutions to make sure that people do not take the path of least resistance. No trust, no efficiency. How to build trust then is another story.
Click bait :) Majority of the projects can start with simple monolith. Doing them in more complicated way will results in : too long time to market, project never finishes because missed estimates. Good modular monolith is almost as complicated as microservices, just cheaper.
One thing that I think you missed in the article (although you did mention about team experience) is team size. Microservices is not only a technical solution. It is an organization solution as well and it is important. One solid and expirienced team can work with a monolith faster. The catch comes when the scope of works increases
Good point, Manos. I should have highlighted that more. Indeed, the choice is not simple, and Conway's Law is kicking in. An important factor is how much our teams can collaborate and how much cognitive load they can comprehend.
I saw people going to extremes, where you have >1 service to maintain per person. On the other hand, needing to understand the whole system when you want to make a simple change is the other range of scale.
As you said, it's important to aim to find the "sweet spot" where you have just enough autonomy and just enough ceremony. But that can only happen when we understand what we need to build, then "how" can come.
Exactly, you expressed it much better than I did. Unfortunately, despite all the community efforts, we still face a shortage of experienced engineers actually doing the work. It's like being an architect — even if I design the best possible architecture on paper, if I’m not there reviewing, mentoring, and teaching, it won’t matter much. It's not just about improving skills; it’s also about helping others understand how to save time, create value, and generally do what senior engineers are supposed to do. Without that hands-on involvement, even the best architectural decisions lose their impact on the final outcome.
Yup, I agree, from my perspective, Architects should always be hands-on. Of course, that doesn't mean that it's their main activity, but they should be aware experience people are facing by applying their decisions.
Also, I believe that we should have more architects than a single one, and it would be best if all people were somehow responsible for making architecture and held accountable.
Of course, we still need decision-makers and people who make hard decisions and shape strategy, so the Architect role is still needed, but it is different from the past.
My longer take: https://event-driven.io/en/architect_manifesto/
I enjoyed this very much. I like how it all comes full circle to use modular design, a relatively very old concept. There is some truth ringing here that first principles of good software design are not pre-empted by fancy new approaches. I think it was revelatory and honest to say compartmentalization (of any kind) is great until you need to use data from multiple sources and then the elegance is gone and the problems come in. There are no easy answers. It's sort of like the only way to keep a computer secure is to power it off and put it in a locked room. The only way to have elegant system design is to not allow any business logic. Real world problems are messy, and so are the programs that handle them. An excellent point towards considering the trade-offs of any design.
> There is some truth ringing here that first principles of good software design are not pre-empted by fancy new approaches. I think it was revelatory and honest to say
Yes, I think that we should have some sort of regular activity to get back to basics and kinda "nurture our ignorance". Of course, in a positive way to reevaluate our decisions, and see if they still apply. Plus the same for practices.
As you said, nothing is simple if we work on that enough long. That's also why I don't like the overselling and hot-takes that are not going further than 0-day issues.
Good modularization requires taking a moment to pause and think about how the components interact with each other, where the responsibility for a particular decision should fundamentally lie — how a given question should be exposed, and so on.
But honestly, I get the feeling that people don’t like to think. They just want to start banging on the keyboard right away — or nowadays, just copy the task into GPT or some other cloud tool, then paste the result back in. :/
Fully agreed, I think that "vibe coding" always existed in our industry. Many developers just want to solve "coding sudoku". Business cases, budgets or technical constraints, are not blocking that from producing more code.
That's also why I believe that "being in the zone" is also overrated. I mean, I love that feeling, but each time I've spent too much time "being in the zone" I realised afterwards that I actually didn't solve anything but just was moving code from one place to the other.
Indeed, GenAI tooling now extrapolates that.
An interesting read as usual. While reading I realized how blessed I am by being in a team that does not take the path of least resistance and organization that would not remove practical simple solutions to make sure that people do not take the path of least resistance. No trust, no efficiency. How to build trust then is another story.
Click bait :) Majority of the projects can start with simple monolith. Doing them in more complicated way will results in : too long time to market, project never finishes because missed estimates. Good modular monolith is almost as complicated as microservices, just cheaper.
am curious what the "correct" alternative is to The Boundary Problem code snippet.