The #1 Mistake Devs Make When Moving To Microservices
Вставка
- Опубліковано 3 жов 2024
- 💻Get the source code: go.dotnetacade...
Most devs will fall for this mistake when they start moving from a monolith to microservices. I'll show you why it is a problem and how experienced devs approach it.
🔥Become a Senior C# Backend Engineer: juliocasal.com...
🗺️Get My Free .NET Backend Developer Roadmap: juliocasal.com...
Join me on Patreon: / juliocasal
Follow me on LinkedIn: / juliocasal
Follow me on X: x.com/julioc
#microservices #csharp #dotnet
Hi Julio, great video! Is true that is a very common mistake, but what about when you depend on another microservice for a data query, when you need to query another microservice for an speficic info and you want to avoid the data duplication/sync.
In that case, have the producer microservice publish events any time it has new data and your consumer microservice consumes those events immediately, building out its own DB out of the data the other microservice is producing.
Then consumer microservice never needs to query the other one.
@@juliocasal thanks!
Will love to see more content about Masstransit
Thanks for letting me know! Added to my list.
All I see is extra complexity. Why not just move the notification service on to a host that offfers an SLA like the Broker host? Problem solved, less complexity.
Alternatively, could you not have a local queue and a background service that checks the queue for work and sends to the service based on what's in the queue? (A poor mans simple messagebus for the want of a better description). That would also decouple the services would it not?
Chris, it's not just about the machine that runs the microservice. What if the Notifications microservice devs deploy the service with a bug that make every REST API call fail? What if suddenly Notifications become super popular and now we have dozens of other microservices also invoking its REST API? What if the database service that Notifications uses suddenly starts throttling the microservice because it's making too many calls, and therefore that results in crashes any time Friends or any other microservice tries to use its APIs? All of that becomes irrelevant if you cut the REST API calls requirement and just have the Friends microservice publish messages to a queue. What happens after that, not the problem of Friends.
Regarding the local queue, that's fine, local to where? Microservices should be deployed as containers to a Kubernetes cluster. Would you host your own queue as a container in the cluster? Is it not better to hand off queue management to a hosted service like Azure Service Bus? The important thing is that the background service you mention lives in another microservice, which translates into another container in the K8s cluster, which allows it to scale independently from the REST API side.
They key is autonomy. You want to make sure the Friends microservice is completely independent from Notifications, and therefore the team that owns each microservice is fully autonomous from other teams, which lets them each move fast.
Hope that helps!
@@juliocasal I'm not disagreeing with you per se. I'm basing my observations on your example. Your example is small and all of the things you state are true and very possible "what ifs", but they are just that; "what ifs". I don't believe in adding complexity just in case. As previously pointed out, you haven't changed the coupling, you've just added another layer and moved the coupling elsewhere and all the things you say of the Notificiations service are equally true of the masstransit/rabbit queueing service. Where I don't agree is that you state the coupled way is wrong and that the queueing way is the right way. I think it depends on a number of factors and jumping straight to super complex isn't necesarily the way to go.
When I suggest a local queue I meant just that, a local background service running on the on the same server as the service consuming the Notifications service (the friends matching service I believe it was?). You send off the notification to that background service (instead of masstransit, something you can be easily written and maintained by the same people that wrote the services). It does more or less the same thing as masstransit by holding that notificiation in it's queue, which could be as simple as just an in memory queue and the background service periodically checks that queue for work and tries to send to the notifications service and returns it to the queue if that fails etc. Then the coupling would be between that local background service and Notifications and also solves the issues you have mentioned but with less complexity.
I am aware there are flaws in my suggestions too, especially in the "what if" scenarios you mention. All I'm saying is that I don't think it's right to say one approach is necessarily wrong because of a few scenarios that may never happen. I mean why stop at decoupling the services in the way you suggest, why don't we have 3 notification servers, behind a load balancing server, with 2 mass transit servers also behind load balancers along with 4 replicated database servers, scattered around the world, just in case.
Anyway, keep up the good work, I do really enjoy the content you bring out.
You are still coupled to the message broker, if that broker is down it will still be a problem. . .There is no silver bullets in software its all trade offs. . .l am speaking from having built these systems and not just a hypothesis
That's true, however hosted message brokers are designed to be highly available and they give you an SLA they have to honor, so you can rely on it.
From experience, it's much more likely having a broken/unavailable microservice (that breaks anything coupled to it) than having the message broker being unavailable.
@@juliocasal I think it's important to recognize that there are trade-offs to any software architecture decision, and it's crucial to carefully consider the potential risks and benefits before making a choice rather than saying this is what you should do.
It's possible that a broken or unavailable microservice could cause issues for other services. Also having a single point of failure, such as a message broker, creates a significant risk. It's important to consider not only the likelihood of a problem occurring, but also the potential impact of that problem. Coupling services to a message broker can create additional complexity and as well as potentially introduce latency into a system.
This is the other side of the coin that is never mentioned. Yes there is Async benefits if the business problem allows and you have carefully considered the trade-offs but that does not go to say there isn't any risks. Its okay to have coupling if it simplifies things and solves your problem without the additional complexity.
@BuildingPhase Yes, there are additional complexities of the async approach. My bad for not mentioning them. Yet, I don't think coupling can be justified in almost any situation, since that means that now you have a microservice that can't be easily modified and released without taking care of all the microservices that could be impacted by the updates. That's the root of a lot of problems and cause lots of headaches and slow down the entire team.
@@juliocasal Coupling can be justified in many cases, take this one for instance, you are rewriting a monolith into a microservice and you have taken out a piece of that monolith into its own service, you now need to integrate to some part of that monolith system to me its much simpler to do a http call in this instance. Why not add broker functionality to the monolith you may ask because in most instances when doing rewrites you don't want to spend too much effort on the thing that you are rewriting. If the other service is down you can still implement an outbox pattern to mitigate the risk of data loss and the outbox pattern just does not use a broker but an http call, just like you would have if a message broker is down. I am not against a message broker, l am against the messaging behind this how you should do it blanket silver bullet solutions. Everything in software is a trade off and we should train people to see things this way.
@@buildingphase9712 Totally agree on using the HTTP call to make it easier to start the move out of the monolith and into microservices, as long as you keep the north start to eventually arrive to the message broker based approach.