Wade here. I've made a few changes to my video format with this entry. First, the content is focusing on a specific case study, rather than being more about general theory. And second, I learned to animate things. Our video editor also had a bit of fun with a few parts of the video. I'd love to know what you think of the changes. Do you like the focus on the case study? Do you think the animations help you stay focused on what I am saying? What do you think of the fun video edits? Let me know if you feel this video is more engaging than some of the others that I have done, or if you have suggestions for future videos.
In my opinion coupling is the root of all evil and it can be reduced by building the right logical boundaries across modules. And if those boundaries are built modules can be easily moved to separate microservices when necessary.
Wade here. Totally agree. Coupling sucks. To me, event-driven microservices are all about reducing coupling. It's all about finding ways to eliminate coupling in the database, coupling in the code, coupling in the APIs etc. And yes, you can absolutely do that inside of a monolith (or at least a lot of it), but Microservices kind of force you to think that way. I like when the architecture mirrors my goals.
Hi Wade, great job! Thank you for the high-quality video and explanation. I believe you've nailed this topic and use-case. Can't wait to see your next videos. Cheers, Roberto
Wade here. Thanks for the feedback. Glad you enjoyed the video. There's another five or so coming with this case study, so keep an eye out for those. And if you haven't already, check the playlist for the rest: ru-vid.com/group/PLa7VYi0yPIH0IpUKXb3q7NSjpJGO9GGGZ
Hey Wade, thanks for a wonderfull video. As a developer if i would start a new project these days i see vertical sliced architecture with endpoints for each slice as a very good candate. Its monolith in a begining but you can decouple it in any point of time. What you think ?
Wade here. Some very smart people recommend starting with a monolith and evolving to microservices later. I think that's a good approach, if you have the discipline to manage it. The problem is that often, by the time you reach the point where you decide you want to build microservices, you've had so many different developers working on the project and it's become such a mess, that it is very difficult to extract microservices from it. If I were a startup, building a pure greenfield project, I might consider a monolith. I'd be dealing with a really small team at that point, and limited domain knowledge. A monolith might make sense at that scale. But if I was starting a project inside of a company with any reasonable level of maturity, I'd absolutely look at building microservices.
I don’t understand the proposed asynchrony in the fraud detection system with Kafka in the middle. What good is the fraud detection system if it doesn’t stop/prevent fraud on the transaction being serviced? I would have expected it to be synchronous request-response framework. No?
Wade here. You probably want to take some time and watch the rest of the video series here: developer.confluent.io/courses/microservices In particular, you might find the most recent video helpful (and the comments below it): developer.confluent.io/courses/microservices/case-study-asynchronous-events/ But the gist of it is that Fraud Detection takes time. You generally can't look at a single transaction and say "oh, that's fraud." You have to look at patterns of transactions over time. Eventually, you develop enough information that you can start to say "Ah, something weird is happening here" and at that point, you lock the account and prevent future transactions.
guys i will save you time, they are not. As much as possible avoid and use simpler solutions, use only when needed or required. Keep solutions lean. The more you know
Wade here. I'd have to respectfully disagree. You said yourself you should use them when needed or required. That implies that sometimes they are the right solution. The point of the video is to highlight exactly that. It's important to analyze your business requirements and decide whether microservices are the right solution. If they are, you should absolutely use them. If they are not, then clearly it would be a bad decision. But making that decision without first looking at your use case is where the mistake lies.
@@ConfluentDevXTeam I would be inclined to disagree. There is no scenario where they are absolutely required. What I meant by required in my statement and it is my fault for using that is if you have no choice. You are capable of doing everything without them and still much of the worlds critical services do not use them. They address some of the pain points of monolithic and multi tier architectures as you pointed out. They are more of a convenience to get around the limitations of the old ways but they come with their own host of problems. The only question is if the tradeoffs are worth it. If not a problem go ahead, but if you can it's almost always better not to. It's just that modern teams want the easier and fastest solutions and don't want to spend time and resources on their old architectures and it is quite the resources. Microservices is more like an easy way out. Given enough resources, you can always find a way to not rely on them. In fact with time, you will notice that most companies and services that rely on microservices, managing them after a certain point is a nightmare and costs more to manage than to invest in alternatives. I must emphasize, there is no scenario where they are absolutely required. It's just a choice between convenience and resources. Even to this day, despite all the developments, well maintained monolithics are still running our most critical services from government, military, banking, medical, energy, etc Even for distributed systems with high concurrency, microservices still lag behind in benchmarks. Very few cases where they outperform.
