I could not agree more with your analysis. In an age when fiber-optic reaching practically everywhere and hardware is attainable enough that practically anyone can ran a decent server in their basement a lot of hype is created by so called big tech to sell more services and they keep getting expensive. Of course they do a lot to implement vendor locking tools and technologies, as well. Hence, server-less, microservices and more. Of course, these have their use cases. But if you are a company that continually runs high loads and pays 100K a month to a cloud provider with your serverless and microservices you might be better of having a data center in the basement of your company with a monolith.
The cost of that decision could be far greater. I think too often we worry about how much is paid to the cloud provider without considering the risk to the revenue. If 100k rakes in 100million in revenue, it’s worth it.
After working with microservices for almost a year now I was beginning to reconsider monoliths for new projects - moduliths sound like something I definitively want to learn more about!
Hello renegades! This video deserves a lot of deep thoughts. You struck on the nail regarding religious mindset -- Microservice Architecture is not the silver bullet for every company, but sure is for tech companies and tech agencies. What would they do they companies don't tear down their functional stuff??
I always had the idea that microservices were pushed by companies that benefit from these architectures. They came up with the narrative of all the advantages that microservices bring and most developers have swallowed these arguments, almost religiously, as the truth. Thank you for your analysis. I totally agree with your assessment. Modularity can be accomplished in many ways. In the early days we had JEE/Corba and DCOM in order to create a distributed component architecture. We nalso had OSGi, which I liked a lot. To my surprise I do see that Apache Karaf, an OSGi implementation, is called a Modulith runtime nowadays. Is this the revival of OSGi?
100%. Everything old is new again. Back in the day I wasn't a fan of the complexity in OSGi. In retrospect it is much simpler than a lot of the crazy architectural hoops we need to pass through.
Awesome analysis. I agree with the monolith-first approach. When using microservices, debugging can also be very difficult when events are sent from one to antoher. One reason for a microservice would be for a very fault-resistant part of the application that needs to be better isolated, but that's rather an exception. Although there are many advantages of monoliths, I see some challenges: Longer load and run times in the IDE, when the whole application needs to be loaded. Maybe there are options to just load and run a single module? How do teams work together and avoid merge conflicts?
for a video page if the video file is served from Database A and the stats(views, likes,comments etc) of that video was served from Database B is that doable in the Modular Monolith?
Sure. You can do that in a regular monolith too. You can have multiple databases in a single monolith. It isn't as rare as one would think, many monoliths have both SQL and Redis (or memcached) which are separate databases technically.
@@phoenicianathletix2866 Sure. You can do that. You can use block storage for the file or any other type of storage. You can even use two SQL databases e.g. if you have a service that tracks everything, you would want a time series DB like QuestDB. But it might not be what you want for the general storage where you might want to go with a more conservative storage. Spring and Microprofile support such a deployment where you can bind to multiple data-sources.
When number of microservices increases its become difficult to know where and in which repo you have the code to work with. A developer start coding in different repo when he sees new microservice
I hope also, one day, Devs doing manual testing makes a comeback, it forces you to system wide thinking and business domain knowledge You cannot properly test what you don't understand
Good points. Though I'm learning k8s and terraform right now and will be making money in microservices as long as web apps are using that architecture.
I am failing to see how is any of that "different" this time... He is just describing any modular architecture. The vast majority of web Frameworks are constructed around those concepts from the beginning. Django, Symfony, Ruby on Rails and yes, also Spring. In fact, microservices are just an evolution of that modular architecture, the main difference been the ability to run it in a separated node. In a way, any monolith using a DB and some mailer service, is also a microservice architecture So, what's the new stuff?
Historic monoliths were focused on layered architecture as opposed to standalone modules (similar to microservices). A company could rearchitect their monolith to use modules in the past but there was no way to enforce that efficiently and effectively. Spring Modulith (which recently reached 1.0) is a tool that both enforces that separation and provides a lightweight event bus (instead of MOMs). That's one thing that changed. Another thing is a change in mindshare. I figure that by now we all have enough real world experience with microservices, this has shown both the problems and the advantages of that approach. My second focus here is to show how the advantages can be a part of a monolith as well and are not exclusive to a microservice architecture.
Are you referring to things such OSGI or just informal project organization? Famously, monoliths at companies like Ebay, Amazon etc. were just divided based on layers and were difficult to maintain due to that division. OSGI garnered excitement, but I never ran into a project that actually used it for backend in all my years as a consultant. The main thing I'm talking about are standardized approaches for modularity that allow enforcing the module boundaries. These existed before but are only starting to gain awareness/traction recently.
a big disadvantage of a monolith in big applications still is, that you cannot upgrade individual parts of your application one by one. New hibernate version? All or nothing! New Spring version? All or nothing! Moving from jpa to jakarta persistence? All or nothing! New UI framework version? All or nothing! And you also need a very good test coverage or: all or nothing must be tested manually, unless you can afford production testing by the end user.
I would argue those are advantages. It's a matter of perspective. E.g. on microservices we have a hodgepodge of versions and features with very little standardization. No enforcement or control. A new vulnerability comes out... Our team needs to go through everything and hope that everything is clear and documented. It might be reasonable if we have an army of developers but for a more moderate team just updating the main project pom is so much simpler. It's interesting that you mention testing... Integration tests are FAR simpler with a monolith, I barely need to set stuff up to get amazing coverage. With Microservices it means I need to bring up a cloud of complexity just for a simple integration test. Then there's the test failures which are absolutely unreadable. Unit tests are simpler in Microservices but that's a bit of a misdirection because they don't cover as much.
Has Monular / Modulith neo-architecture been responsible for the infuriating data drop we've been noticing growing in Corp Service Front-ends? Who you are and what you're responding to gets dropped entirely between an email link with full purpose and engagement, and you winding up on just another Home Page with another log-in. Typically. The dirty shell game is hiding the customer support, or the proffered "free" deal, or actual terms of service, or to opt-out of auto-renewal, etc. I would think Architecture plays no role. Maybe security, and for sure bait and switch.
I could not agree more with your analysis. In an age when fiber-optic reaching practically everywhere and hardware is attainable enough that practically anyone can ran a decent server in their basement a lot of hype is created by so called big tech to sell more services and they keep getting expensive. Of course they do a lot to implement vendor locking tools and technologies, as well. Hence, server-less, microservices and more. Of course, these have their use cases. But if you are a company that continually runs high loads and pays 100K a month to a cloud provider with your serverless and microservices you might be better of having a data center in the basement of your company with a monolith.
The cost of that decision could be far greater. I think too often we worry about how much is paid to the cloud provider without considering the risk to the revenue. If 100k rakes in 100million in revenue, it’s worth it.
After working with microservices for almost a year now I was beginning to reconsider monoliths for new projects - moduliths sound like something I definitively want to learn more about!
Hello renegades! This video deserves a lot of deep thoughts. You struck on the nail regarding religious mindset -- Microservice Architecture is not the silver bullet for every company, but sure is for tech companies and tech agencies. What would they do they companies don't tear down their functional stuff??
I always had the idea that microservices were pushed by companies that benefit from these architectures. They came up with the narrative of all the advantages that microservices bring and most developers have swallowed these arguments, almost religiously, as the truth.
Thank you for your analysis. I totally agree with your assessment.
Modularity can be accomplished in many ways. In the early days we had JEE/Corba and DCOM in order to create a distributed component architecture. We nalso had OSGi, which I liked a lot.
To my surprise I do see that Apache Karaf, an OSGi implementation, is called a Modulith runtime nowadays. Is this the revival of OSGi?
100%. Everything old is new again. Back in the day I wasn't a fan of the complexity in OSGi. In retrospect it is much simpler than a lot of the crazy architectural hoops we need to pass through.
Awesome analysis. I agree with the monolith-first approach. When using microservices, debugging can also be very difficult when events are sent from one to antoher.
One reason for a microservice would be for a very fault-resistant part of the application that needs to be better isolated, but that's rather an exception.
Although there are many advantages of monoliths, I see some challenges: Longer load and run times in the IDE, when the whole application needs to be loaded. Maybe there are options to just load and run a single module? How do teams work together and avoid merge conflicts?
Funny you should mention that because I'm dropping a sequel tomorrow that goes deeper on microservices...
FYI the video I mentioned is now available here: ruclips.net/video/PrFZB9NqZ5E/видео.html
for a video page if the video file is served from Database A and the stats(views, likes,comments etc) of that video was served from Database B is that doable in the Modular Monolith?
Sure. You can do that in a regular monolith too. You can have multiple databases in a single monolith. It isn't as rare as one would think, many monoliths have both SQL and Redis (or memcached) which are separate databases technically.
Wow ok so SQL is for the video file and Redis for the video stats?
@@phoenicianathletix2866 Sure. You can do that. You can use block storage for the file or any other type of storage. You can even use two SQL databases e.g. if you have a service that tracks everything, you would want a time series DB like QuestDB. But it might not be what you want for the general storage where you might want to go with a more conservative storage.
Spring and Microprofile support such a deployment where you can bind to multiple data-sources.
When number of microservices increases its become difficult to know where and in which repo you have the code to work with. A developer start coding in different repo when he sees new microservice
I hope also, one day, Devs doing manual testing makes a comeback, it forces you to system wide thinking and business domain knowledge
You cannot properly test what you don't understand
Good points. Though I'm learning k8s and terraform right now and will be making money in microservices as long as web apps are using that architecture.
I think Kubernetes some very valid use cases in the very high end.
I am failing to see how is any of that "different" this time... He is just describing any modular architecture. The vast majority of web Frameworks are constructed around those concepts from the beginning. Django, Symfony, Ruby on Rails and yes, also Spring. In fact, microservices are just an evolution of that modular architecture, the main difference been the ability to run it in a separated node. In a way, any monolith using a DB and some mailer service, is also a microservice architecture
So, what's the new stuff?
Historic monoliths were focused on layered architecture as opposed to standalone modules (similar to microservices). A company could rearchitect their monolith to use modules in the past but there was no way to enforce that efficiently and effectively. Spring Modulith (which recently reached 1.0) is a tool that both enforces that separation and provides a lightweight event bus (instead of MOMs). That's one thing that changed.
Another thing is a change in mindshare. I figure that by now we all have enough real world experience with microservices, this has shown both the problems and the advantages of that approach. My second focus here is to show how the advantages can be a part of a monolith as well and are not exclusive to a microservice architecture.
Everyone who only read the title to Amazon’s article is on the monolith train
I have been around for just as long - not sure why their is an assumption that monoliths of old were not modular.
Are you referring to things such OSGI or just informal project organization?
Famously, monoliths at companies like Ebay, Amazon etc. were just divided based on layers and were difficult to maintain due to that division. OSGI garnered excitement, but I never ran into a project that actually used it for backend in all my years as a consultant. The main thing I'm talking about are standardized approaches for modularity that allow enforcing the module boundaries. These existed before but are only starting to gain awareness/traction recently.
a big disadvantage of a monolith in big applications still is, that you cannot upgrade individual parts of your application one by one. New hibernate version? All or nothing! New Spring version? All or nothing! Moving from jpa to jakarta persistence? All or nothing! New UI framework version? All or nothing! And you also need a very good test coverage or: all or nothing must be tested manually, unless you can afford production testing by the end user.
I would argue those are advantages. It's a matter of perspective. E.g. on microservices we have a hodgepodge of versions and features with very little standardization. No enforcement or control. A new vulnerability comes out... Our team needs to go through everything and hope that everything is clear and documented. It might be reasonable if we have an army of developers but for a more moderate team just updating the main project pom is so much simpler.
It's interesting that you mention testing... Integration tests are FAR simpler with a monolith, I barely need to set stuff up to get amazing coverage. With Microservices it means I need to bring up a cloud of complexity just for a simple integration test. Then there's the test failures which are absolutely unreadable. Unit tests are simpler in Microservices but that's a bit of a misdirection because they don't cover as much.
Has Monular / Modulith neo-architecture been responsible for the infuriating data drop we've been noticing growing in Corp Service Front-ends? Who you are and what you're responding to gets dropped entirely between an email link with full purpose and engagement, and you winding up on just another Home Page with another log-in. Typically. The dirty shell game is hiding the customer support, or the proffered "free" deal, or actual terms of service, or to opt-out of auto-renewal, etc. I would think Architecture plays no role. Maybe security, and for sure bait and switch.
Weird that it took you so long to realize this.