27:38 hm, old talk, but the term "distributed monolith" is kinda misleading, it's actually one of the things you want to avoid. It's the situation described after first engaging with microservices: a distributed system that acts like a monolith because there are many interactions, everything depends on everything, a change in one place requires changes everywhere, braking one thing brakes everything, everything has side effects and you play whack-a-mole with bugs and tests. Monoliths are not bad per se, badly structured ones are. And distributed monoliths are the worst of both worlds: the horrible maintainability of a badly designed monolithic system combined with the complexity and overhead of a distributed system. The desired state is a system, that acts like a (distributed) "MODULith". A modulith is a term used to describe a monolithic application, that is cut into (bounded context) modules. In a well designed monolith (=modulith) teams can already work independently on modules without side effects because for example the data model is "separated" and the modules only interact over well defined and stable interfaces and you can work in your module without knowing much about the other modules. You have already many advantages of microservices, but you are usually limited in regards to testing and rollout. So if those things are important targets for your architecture, you can start to move modules out of your modulith and develop, test and deploy them independently. And because the interfaces should be pretty stable and the context is well cut, the friction between those teams is relatively low. Unfortunately, identifying those bounded contexts is incredibly hard, especially green-field. Finally, a team of 12 people with one backlog is not a realistic solution for many projects. If you can't find modules (microservices) that can be developed independently by a team with it's own backlog and your whole system is therefore limited to 12 people, you probably shouldn't bother with "microservices" and rather build 1 or 2 larger systems (unless you have a really good reason for the added complexity).
We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.
27:38 hm, old talk, but the term "distributed monolith" is kinda misleading, it's actually one of the things you want to avoid. It's the situation described after first engaging with microservices: a distributed system that acts like a monolith because there are many interactions, everything depends on everything, a change in one place requires changes everywhere, braking one thing brakes everything, everything has side effects and you play whack-a-mole with bugs and tests. Monoliths are not bad per se, badly structured ones are. And distributed monoliths are the worst of both worlds: the horrible maintainability of a badly designed monolithic system combined with the complexity and overhead of a distributed system.
The desired state is a system, that acts like a (distributed) "MODULith". A modulith is a term used to describe a monolithic application, that is cut into (bounded context) modules. In a well designed monolith (=modulith) teams can already work independently on modules without side effects because for example the data model is "separated" and the modules only interact over well defined and stable interfaces and you can work in your module without knowing much about the other modules. You have already many advantages of microservices, but you are usually limited in regards to testing and rollout. So if those things are important targets for your architecture, you can start to move modules out of your modulith and develop, test and deploy them independently. And because the interfaces should be pretty stable and the context is well cut, the friction between those teams is relatively low. Unfortunately, identifying those bounded contexts is incredibly hard, especially green-field.
Finally, a team of 12 people with one backlog is not a realistic solution for many projects. If you can't find modules (microservices) that can be developed independently by a team with it's own backlog and your whole system is therefore limited to 12 people, you probably shouldn't bother with "microservices" and rather build 1 or 2 larger systems (unless you have a really good reason for the added complexity).
We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.
Whilst distributed monoliths are a bad idea - the upside is often job security as no manager will really understand how it works ;-)