I am happy that people are realising that microservices are no silver bullets. Realistically things can be much much simpler, interfaces have been thought out a long time ago. The arguments people give about scalability is also a big BS, because most of the programs are written in a way that simply does not allow that, or have rules that need to process a whole group. Microservices don't have to be another process, they can just be libraries with interfaces which can be swapped between direct call/grpc/http and so on. Ideally we want to show users everything real-time, not to have to have them wait for the next cron job which will from service A their orders...
I have always been towards modular monolith design, I just didn't knew why this wasn't discovered earlier by the industry. I'm really close Linux, and the kernel officially uses modular monolith design, you can have kernel configuration explain if the module is 'y' present and built in to the binary, 'n' not present, 'm' exported as module to be loaded at runtime.
And yes, it does comes with its own pitfalls, one most prominently is that you atleast have to compile everything once to get incremental compilation working, and the first compilation of everything make 0.5 hour if codebase is big.
My suspicion is that this will just be a system design choice that will be tremendously useful for some and an unnecessary source of complexity and confusion for others. Just as gRPC/Thrift didn't universally replace JSON, I don't believe modular monoliths will universally replace microservices. I'm excited to work on the first big project where this will be awesome, and I'm also kind of excited to work on the first big project where this will be awful.
Great video. but i have some questions. 1. The first improvement of 2x as I understood was because of the serialization and deserialization cost savings. So wouldn't a better format than json, something like protobuf should also help here. 2. The second point was colocation. Shouldn't that point be covered by "PodAffinity" in kubernetes ?
1. I agree it would help, but I guess we would get the most out of the protocol if it is fully custom for the particular data being exchanged. 2. I think the runtimes can be implemented on top of any platform, including Kubernetes. In that case setting "PodAffinity" would be an implementation detail of the runtime on "how" it collocates services.
There is no problem with Microservice. The problem started when developers starts creating microservice for each domain (like UserService, ProductService, CatService, DogService etc). We must separate the services carefully based on the functionality, scale,..
I am happy that people are realising that microservices are no silver bullets. Realistically things can be much much simpler, interfaces have been thought out a long time ago. The arguments people give about scalability is also a big BS, because most of the programs are written in a way that simply does not allow that, or have rules that need to process a whole group. Microservices don't have to be another process, they can just be libraries with interfaces which can be swapped between direct call/grpc/http and so on. Ideally we want to show users everything real-time, not to have to have them wait for the next cron job which will from service A their orders...
Thanks for taking up this topic :)
This is the firstvideo I watch by you. Your channel looks very high quality. Thanks for good content
I appreciate that!
Informative and clear 🎉
Glad you liked it
This video blew me away. Such valuable insight. Thank you for sharing. Liked and subscribed.
Awesome, thank you! Do share it on your networks too!
I have always been towards modular monolith design, I just didn't knew why this wasn't discovered earlier by the industry. I'm really close Linux, and the kernel officially uses modular monolith design, you can have kernel configuration explain if the module is 'y' present and built in to the binary, 'n' not present, 'm' exported as module to be loaded at runtime.
And yes, it does comes with its own pitfalls, one most prominently is that you atleast have to compile everything once to get incremental compilation working, and the first compilation of everything make 0.5 hour if codebase is big.
I agree to this drawback ...high compilation time would also cost more for CI/CD.
It’s like they’re reinventing the actor model once again
Well explained 👏
Very interesting video 🤔🤔
Good video
My suspicion is that this will just be a system design choice that will be tremendously useful for some and an unnecessary source of complexity and confusion for others. Just as gRPC/Thrift didn't universally replace JSON, I don't believe modular monoliths will universally replace microservices. I'm excited to work on the first big project where this will be awesome, and I'm also kind of excited to work on the first big project where this will be awful.
I agree with you. But this paper might inspire more work on this front and more frameworks/solutions might come out.
Great video. but i have some questions.
1. The first improvement of 2x as I understood was because of the serialization and deserialization cost savings. So wouldn't a better format than json, something like protobuf should also help here.
2. The second point was colocation. Shouldn't that point be covered by "PodAffinity" in kubernetes ?
1. I agree it would help, but I guess we would get the most out of the protocol if it is fully custom for the particular data being exchanged.
2. I think the runtimes can be implemented on top of any platform, including Kubernetes. In that case setting "PodAffinity" would be an implementation detail of the runtime on "how" it collocates services.
It looks kind of similar to Ray Serve🤔
There is no problem with Microservice. The problem started when developers starts creating microservice for each domain (like UserService, ProductService, CatService, DogService etc). We must separate the services carefully based on the functionality, scale,..
Agree, the problem is not with the technology itself but with practises.
shocker, what can i say......