Thank you for this video. It is packed with lots of useful information regarding microservices architecture from making the commands/transactions that span multiple services, and also for making queries that span multiple services. The talk also describes the motivations for using saga pattern for the transactions and the CQRS pattern for the queries. Really awesome, concise and neatly packaged presentation. Cheers
The main problem I see with micro services is that it is overkill for an awful lot of systems. Sure if you are building a web based service and are expecting a few billion requests a day or more micro services are a must. But if you are building a hotel reservation system for instance you are maybe going to see a few thousand requests an hour if that. Looking at all the hoops one needs to jump through to make micros services a viable solution I am pretty certain that it will be way to heavy a lift for that hotel reservation system. Unfortunately the cool new thing in software architecture being the best solution for everything seems to still plague many software architects thinking. Yes, micro services are a cool but complex solution it certainly has a place but that place is not in a simple solution that just needs to handle a few hundred interactions a minute. Software architecture is just like any profession all about picking the right tool for the job, a monolith or a distributed monolith might be perfectly fine for the thing you have been tasked to architect. Sure it is not as sexy as the new kid on the block but it will provide enough resiliency and a far lower TOC than the new thing ever could. Ok rant over 🙂 I love the presentation though it covers a lot of the micro service pitfalls many organizations are encountering when they dive into the wonderful world of micro services.
There are other benefits to microservices other than ability to handle web scale, if you have multiple teams it makes a lot of sense for them to work on self contained de-coupled services so you can get proper autonomy and ownership at the team level. It really does depend on the use case and team set-up though, for example if I was designing an architecture for a startup where the team is small and they want to iterate fast I would probably go with a stateless monolith for simplicity and speed until such time as they prove the MVP and expand the team or the traffic/complexity tells you microservices are required. Ultimately I think software engineering is still so young as a profession we need to be way more scientific and make decisions on the basis of data and measure rather than the opinion of the dominant alpha geek
Great video, many likes. But CQRS, hmm one of the best architectural design patterns, but replicating databases for segregating commands and queries can get complicated and needs governance to ensure everyone follows the pattern, same applies for many other patterns of course.
Thank you for this video. It is packed with lots of useful information regarding microservices architecture from making the commands/transactions that span multiple services, and also for making queries that span multiple services. The talk also describes the motivations for using saga pattern for the transactions and the CQRS pattern for the queries. Really awesome, concise and neatly packaged presentation. Cheers
Learning from design guru is always a pleasure, thank you so much
I loved it. This presentations puts all components of a mature microservice together. I was looking for something like that for a long time. Congrats.
This was the best. You tackled most of the real-world problems in micro-services architecture.
Many Thanks.
Very good one & this is the best I have seen for micro-services.Thank you
Very nicely explained, every thing is crystal clear
Thank you so much for sharing all this excellent info about distributed data problems in microservice architecture!!!! It is so appreciated!!!
Awesome general lecture on data composition and sharing in microservices from and industry leader.
Awesome presentation, loved that.
Thanks for all your efforts.
Very clear as usual Chris :)
Amazing content. I can't thank you enough!
I love this deeply insightful video
this is goldmine
The main problem I see with micro services is that it is overkill for an awful lot of systems. Sure if you are building a web based service and are expecting a few billion requests a day or more micro services are a must. But if you are building a hotel reservation system for instance you are maybe going to see a few thousand requests an hour if that. Looking at all the hoops one needs to jump through to make micros services a viable solution I am pretty certain that it will be way to heavy a lift for that hotel reservation system.
Unfortunately the cool new thing in software architecture being the best solution for everything seems to still plague many software architects thinking. Yes, micro services are a cool but complex solution it certainly has a place but that place is not in a simple solution that just needs to handle a few hundred interactions a minute.
Software architecture is just like any profession all about picking the right tool for the job, a monolith or a distributed monolith might be perfectly fine for the thing you have been tasked to architect. Sure it is not as sexy as the new kid on the block but it will provide enough resiliency and a far lower TOC than the new thing ever could.
Ok rant over 🙂
I love the presentation though it covers a lot of the micro service pitfalls many organizations are encountering when they dive into the wonderful world of micro services.
There are other benefits to microservices other than ability to handle web scale, if you have multiple teams it makes a lot of sense for them to work on self contained de-coupled services so you can get proper autonomy and ownership at the team level.
It really does depend on the use case and team set-up though, for example if I was designing an architecture for a startup where the team is small and they want to iterate fast I would probably go with a stateless monolith for simplicity and speed until such time as they prove the MVP and expand the team or the traffic/complexity tells you microservices are required.
Ultimately I think software engineering is still so young as a profession we need to be way more scientific and make decisions on the basis of data and measure rather than the opinion of the dominant alpha geek
I learned so much. Thanks!
Seperate database for each service,
then you will have to make each database in HA and DR separately, this is huge cost and maintenance
ITS CALLED THE INSIDE STORY I LIKED IT
Great video, many likes. But CQRS, hmm one of the best architectural design patterns, but replicating databases for segregating commands and queries can get complicated and needs governance to ensure everyone follows the pattern, same applies for many other patterns of course.
Thank you!
it's awesome
gg, Chris!
Watch at 1.5x