Splitting up a Monolith to (micro)Services

Splitting up a Monolith into (micro)services is not an easy task. It can be broken apart into multiple steps. Defining boundaries and capabilities are key. Depending how much coupling you have within your Monolith, and how you couple is a big factor.
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to source code & demos!
/ @codeopinion
🔥 Don't have the JOIN button? Support me on Patreon!
/ codeopinion
📝 Blog: codeopinion.com/splitting-up-...
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
0:00 Intro
0:22 Coupling
2:28 Boundaries
3:43 Communication
5:00 Database Separation
5:46 Async Messaging
7:01 Saga / Message Driven
📝 Context is King: Finding Service Boundaries
codeopinion.com/context-is-ki...
CodeOpinon: codeopinion.com
Twitter: / codeopinion
#softwarearchitecture #microservices #eventdrivenarchitecture

[@Hakayami]

Thank you for all of your content. It's help me a lot

[@russellf]

It’s important to weigh-up the saga/message-based approach to the initial version of the system. The former scales but the latter is much simpler. Experience helps inform us when it is time to transition from one design to the other.

[@thanhvo2092]

Yaa, very useful to me. Thanks 😍

[@666santilmo]

This is awesome

[@rafaspimenta]

I can't learn so much good and free content without being at least a member. Fixed. Thanks for sharing, Derek!

[@CodeOpinion]

Thanks a lot!

[@coderanger75]

Another piece of great content! Saga seems pretty neat -- I will have to check it out.

[@CodeOpinion]

My examples are using NServiceBus in the Loosely Coupled Monolith sample app. There's a branch for NServiceBus if you want to play around with it.

[@salahfarzin3554]

Splitting up a Monolith to (micro)Services Great, thanks man, keep going

[@CodeOpinion]

Thanks, will do!

[@Omar_Thinks]

Amazing Video :)

[@CodeOpinion]

Thanks!

[@edgarmendoza48]

What do you think about having all of the routes in one file?

[@manishagnani7200]

Where can I get the code? for both Mono and micro

[@joeglik1211]

Very helpful, thank you. I have a couple questions: 1. Say you have a UI where you can create an order. With the coupled backend, you might be able to return the label immediately since everything occurs in a transaction. How do you handle this when you switch to microservices? 2. Where should sagas live? API Gateway? If so, would you recommend the gateway talks to microservices over RPC? 3. Is fetching logic (e.g. here's an order id, get me the label and billing info) in a saga as well?

[@CodeOpinion]

1 - Dealing with async workflows just means providing the user with what is actually happening. If they place an order and it's initial state is "Processing". Then that's the state you show them and details about all the steps in the workflow. 2 - Saga should live in the place that's doing the orchestration. In my example of an order, in the sales since that's where the orchestration of the order is. 3 - Saga should just be consuming events and publishing commands. It shouldn't be fetching data or doing anything beyond knowing the workflow based on the series of events.

[@matiascasag]

@@CodeOpinion I think that for point 1 he needs to push notifications to the UI, something like SignalR perhaps. But the thing i dont know if its necesary to keep the socket always connected or only use it in special cases like this and when the order is created, disconnect from the socket. What is your opinion?

[@CodeOpinion]

@@matiascasag Yes, you can use something like SignalR to notify the client when something has finished processing via an event. Often times as well you can just use polling to know if an operation has completed. Really depends on the situation

[@konczykl]

How billing can know which customer to charge knowing only order id? Should it make a request to sales for customer id?

[@CodeOpinion]

There's many different options. It could call back to the publishing service to get more data/info. Another option is to include it in the event. However you may not want to do either and prefer to use orchestration to send a command to billing rather than an event. Check out my video on Event Choreography and Orchestration: kzbin.info/www/bejne/qICcc4upoZl0g7M

[@rollinOnCode]

What do you mean by "saga"?

[@CodeOpinion]

Check out this video: kzbin.info/www/bejne/qICcc4upoZl0g7M

[@aliroshan89]

With microservices everything becomes complicated. For a small team, dev ops, database back ups, and monitoring the entire system would become really hard. What are thoughts about this?

[@CodeOpinion]

I don't think you start with microservices. I think it's an evolution of your system, ultimately because of Conway's Law. I really do think creating a Loosely Coupled Monolith (as in my series) is a better approach as you can carve off sections more easily as required by your org.

[@Born2EditHD]

The whole point of a microservice architecture is that its difficult to get set up to start with, but ultimately once everything is in place it's far easier to manage. This ease becomes more prevalent when you use more good coding practices like TDD and clean architecture.