Building a microservice architecture with ASP.NET Core - Gill Cleeren - NDC London 2022

all right so we'll get started so um i have something good uh to make your lunch uh very uh pleasant i think so we are going to talk about building a microservices architecture based on asp.net core so i'm going to make sure that i uh finish this presentation in time so we'll have about 60 minutes to talk about how to do a microservices setup based on network on asp.net core my name is joe i'm from belgium i lead experience which is a high level consultancy company so we do this stuff all the time on making sure that companies set up architectures for their mooc for their mobile applications for their web applications uh in a correct way um i'm also a pluralsight author i've been doing this for uh close to 10 years and this is actually a bit of a synopsis really of a very large course that i have on microservices architecture on pluralsight so if this is to your liking well then you can go out to pluralsight and uh listen to me for about five hours also maybe good for lunch or to fall asleep i don't know um and then i will dive a lot deeper into setting up this microservices communication based on asp.net core if you don't have access to pluralsight uh come up to me after the session i'll write down your email and then i can give you a month of free access to to access whatever course you want all right so since we don't have too much time let's dive straight in i'm going to do this using a business case we're going to look at a company effective company called global ticket which is in need maybe maybe of moving to a microservices setup so that's what we're going to be using um first i'm going to show you a symbol single microservice which is actually just an api and then we're going to start bringing in multiple microservices and how they are going to communicate how they're going to relate with one another is is what we're going to look at next so the microservices architecture and the microsoft's communication part and if we have time well we should have in fact also look at how we can connect with these microservices there are multiple ways of having a front-end or multiple front-ends connect with that microservices setup so that's what i'm going to be explaining to you in the next 60 minutes so as mentioned we're going to use a effective company called global tickets and global ticket is maybe in need of a micro services setup let's see what they are doing so as the name is already giving away so global ticket is a a ticket seller or ticket vendor a reseller company so they sell tickets for all kinds of uh of concerts and conferences like these and so they're really a market leader in the ticket selling business so they're very global company and they have a system of selling tickets of course um and in there in this fictive application that we're going to be using um the users of the application so it's really the end user application that we'll be looking at people can do all kinds of well regular things that you can do with a ticket shop you can browse the catalog you can put tickets in your shopping basket maybe you have a discount code so we need to apply that one as well and then of course you can uh create the order and then you actually also have to make a payment and maybe there's also some marketing information that we need to capture based on what tickets people have in their baskets we may also want to give them recommendations on other related sorts of concerts or events in general so these are the features of the application that we'll be looking at so instead of talking about it i'm going to give you a quick demo so the actual application is not really what matters in this presentation it's of course more the code and how to set up the architecture but it does give you a bit of a a better understanding of the application that we are talking about i'm going to start it here you're going to see a lot of apis booting up hopefully there we go just a second here i should have booted this up already but it actually shouldn't take very long there we go yeah i make it a bit larger even yeah i didn't have the time to actually test it is this readable for everyone yeah i can't see you because of the light in my face yeah there we go i see some hands going up all right so this is global tickets as mentioned it's a global it's a ticket selling website where i can select this ticket see the details select the number of tickets i want to add to my basket this is the shopping cart page or which i can update i can apply a discount code and if i'm good then i click here on checkout now this will create oh this will take me to the order page which i need to fill in quickly because there's some simple validation on there let's take this effective email there we go and then we'll place the order and this will send that off there's an asynchronous process we'll talk about that that is happening right now which is hopefully uh accepting my payment and if we're good it can take a while so i'm not sure if it's already going to be there then at some point the order will show up here has maybe gone through with the payment or not so that's basically the application that will use for this uh presentation nothing more nothing nothing very special it's just a front end sitting on top of the microservices that we'll take a look at so now that you know what we're going to be building let's take a look at the current state at deliver tickets the global ticket has been building this application for a long time and it's been built as a typical monolith now to be to be clear there's nothing wrong with a monolithic application don't rush out here and and go tell your boss or your cto whatever we need to change everything into a microservices setup that is not the case i'll talk about why it can be useful but keep that in mind having a monolithic application there's really nothing wrong with this because there's definitely some advantages to having a monolithic application it's easy to deploy it's easy to bring new members on the team because its setup is probably easy to understand as well and it probably is also easy to test because that is one of the downsides that we'll see when building or when going into microservices setup it might be more difficult to test so having a monolithic application which is what global ticket has at this point absolutely fun so this could be a very simple setup in which they have maybe an asp.net core razer pages or mvc application in which they have one overarching application but that does pretty much everything it goes from the uh it does it handles the event catalog which has some controllers some views maybe that's an area in an mvc application then they have the shopping basket and they have the discount functionality that handles that that discount code that you could enter in the shopping basket as well so really one application that does it all but being a ticket selling website well they are facing a couple of problems and i have listed a few of them here well the current application is a three-tier traditional setup nothing wrong with that we already mentioned that but it does have being a ticket a ticket selling website some issues maybe here and there when when a conference like this one goes online there's a very high peak in demand because of everyone willing to be here and and that results in a slow response time and a slow website in general everyone is on twitter these days so as soon as the site goes down these ctos on the ceo starts seeing it on the on twitter again oh global ticket is slow again he doesn't want that anymore that's definitely one of the issues that we can encounter with such such a setup another issue that that based on the current setup might be difficult to address is also the fact that they cannot handle multiple frontends because they've built everything as a monolithic application maybe with an asp.net core application they don't have an easy way to allow for maybe a third-party api to come in or a mobile application to connect those things can actually be pretty hard to put into an existing setup in which everything was done in one go another thing is also that as the teams grow maybe multiple teams will start building different parts of the application and maybe they are interested in using a different tech stack maybe the the departure that just uh mentioned about the marketing part maybe they're building some ai in there and they want to use python to see based on the consumer history of purchases what might be the next thing they want to do and they might want to do that on a different stack and that might also be hard to fit into a monolithic application and maybe those people also want to release more often than the general application because if you have a monolithic application in general it will be uh released in one go it's all or nothing really so those are maybe some issues that we might be facing when building a monolithic application and maybe just maybe a microservices setup could introduce us to a solution here when we are going to introduce microservices at global tickets we're basically going to be well splitting up the application in multiple smaller applications smaller islands of functionality that's what i like to call them smaller services which are really standalone functionality standalone applications they can do everything themselves they can do they have their own database they have their own model we'll talk about that in just a second they really are islands of functionality that do one thing one task maybe they do the discounts maybe the shopping basket will talk about the different microservices that you need but that's what they'll do they'll do just one thing they have their own data maybe they're owned by one team again think back of what i just said maybe that team that wants to build the market marketing service has that functionality in hand they have the knowledge they want to release that well maybe that service that application is owned by one team and it can also easily evolve over time not thinking about machine learning stuff but maybe we're building with net core and we have a dependency on one typical one particular version of net core which is blocking the entire application from moving to net six well if we split it up with multiple microservices while we can maybe just have one single microservice that needs to stay on an older version but all the other services can already evolve into the next version and that may arrive with something like this high level we're going to have a front-end application we'll talk about those by the end of the presentation that talk with different standalone applications and those will be the microservices and those will in fact just be apis as well um why they can be a solution well there are different reasons and i already mentioned quite a few but like i said they can be and notice the quotes around the can because that is very important it's not the solution for every problem that you may encounter it can actually make the creation of larger applications because microservices are typically used for larger systems it can make the creation of those a bit simpler they'll also think back of what i said earlier one of the problems that global ticket was facing was the availability maybe when the entire application is just a monolithic application it can be hard to actually have it be available all the time since there are separate uh since it's just one service that handles everything if you have micro services we can more easily tweak and find you then we can improve the scalability because of the different microservices being in place and like i already mentioned it is possible to have different services do or use different technologies one can use a machine learning setup using python another one can use an old version of net and another one can use dot net 6. so you can have different services use different technologies now it is not all good in the length of microservices and now i'm maybe painting a picture that is very positive but it's definitely not always going to be the solution as i already mentioned it the first thing that is pretty hard to do is finding the different microservices it's not a very clear cut all the time this is a damage setup and of course it's going to be easy to see well that's a microservice and that's a microservice and that's another one that works in a in a demo but it might not always be the case with your own business domain so finding what should be a microservice is sometimes hard to do i already mentioned the fact that it's more difficult to test very often you're working by default in a distributed system and distributed systems are hard to test they're definitely much that more difficult to test than having a simple asp.net core application that has everything in one place i know it's going to be other technical challenges that you encounter think of the fact that you have different services communicating with one another if one goes down well what happens with the rest of the system you'll need to think of things like resiliency how am i going to retry maybe communicating between a service that that is down or something and and how i'm going to retry that communication and maybe also thinking already about the front end maybe they need different bits of data so that's also an issue that we're going to try to solve in this presentation and in general the communication between different services is hard instead of having just a few classes that need to talk to one another now you are responsible for having multiple applications communicate with one another so communication between these services is definitely one of the challenges that you come across so now that we have set the groundwork i think for having possibly a solution with microservices at global ticket let's see how we can actually build that and we'll start with the first one a simple single microservice and then we'll start adding the other ones we'll have them communicate and we'll bring in front end so a first microservice and now before i show you those microservices and and the in the first one that we'll start with uh let me quickly recap what the application was supposed to do as these are the requirements to pick a list of requirements what are we going to be have what are we going to do with the application we're going to browse the catalog we're going to be able to add items to the shopping cart and we've seen that then we can create the order we can maybe while doing so apply a discount code then we can process the payment that you didn't see because that happens in the background to talk about that and um i missed one i think i can also recommend other events so if you get this list of requirements in in real life it's not often that clear but i think it's pretty easy to see what are going to be my different microservices i'm going to have a service that handles everything around the catalog um in this particular case that is going to say feed the data that is uh that is that allows me to browse through the different categories i haven't show you categories but they are available in categories those tickets um but it could also be um this service let's say could also possibly handle the admin side of things maybe creating new types of tickets or maybe uh doing a group booking or something so there could also be an administration site so everything that evolves let's say around ticket uh event sorry the catalog of tickets let's say that is definitely something that is a step the standalone functionality that is a first microservice that we've identified the shopping basket definitely another one keeping track of who has what in their basket is something that is a standalone functionality we'll see the code of the microservice or the shopping basket microservice in a minute because it's a very important one it's a crucial one the shopping basket will be the standalone application that keeps track of who has what type of tickets which want it is and so on in the baskets it will also do stuff with the shop with a discount code and that is definitely another microservice that we've identified there's going to be another service that is maybe checking the discount code against the database is that code already used is it still valid and so on and so forth that is definitely also a standalone functionality that you can wrap inside of a microservice there's two more the order microservice will look at that one as well that's a very central one in the setup of services that i'll have it'll handle ordering so it basically will go from uh the items in the shopping basket and move those into the database of the orders because that is a different database it's a different data store that it then handled and is fully controlled let's say by the order microservice payment um we're going to use a third-party payment system like stripe or something but we're not using that directly from within the application i'm going to add what i what i typically tend to refer to as a technical microservice a service that sits in front of it let's say a layer that sits in front of your payment system your external payment system that handles all the technical details around talking with that external payment system that's another microservice that we'll have and then marketing at another one that is one that is responsible for looking at what people have in the basket and make recommendations as the ones that are referred to as maybe something that you would do with the machine learning solution all right let's take a look at all these microservices let's start with one let's create oh let's look at the first microservice i don't have time to do all this by hand and well these services themselves you don't need to spend a lot of time at that because that is just an api a plain asp.net core api which has and that's important its own database its own data model its own controls its standalone it's a standalone application really so it's really something that is standing on its own so let's take a look at the first microservice already here if my mouse wants to work along there we go so without going in too much detail here already let's collapse everything and then we'll zoom in so if you take a look here um we have different services we have and in the solution you have different services each of these i've just explained already briefly and let's take a look at the event catalog for example first catalog is a plain api it's an asp.net api um and it has its own data structure so it has defined its own model it has defined its own uh database context so that means that it also has its own database it's a standalone application really it's an api that does everything around the event catalog and it also has of course its own controllers let's take a look at the event controller for example here so the event controller is a send an api that is accessible via api slash events a plain event controller which uses some dependency injection and then has this uh method here to get all the events as you can see here and also get an event by id really nothing special apart from the fact that i want to point your attention to the fact that this is using its own repository which uses the database context of this system and also has its own database and in fact all the other microservices from a high level perspective are doing exactly the same we're not here to talk about these individual services because those you can build using something like clean architecture for example that's not really the point here this is just a standalone application on its own that's the first api that's the first microservice that we have identified now we start we need to start looking at how these different services are actually going to work together because we're having a single api well that's not what we're here for i think we already know how to build this so what is more important of course is how to make these different services work together and that's where the architectural part comes in well this is this this picture this slide here should give you a bit of an overview of how these different microservices will interact with one another you have again these different services that i already mentioned so the event catalog shopping basket discount marketing payment and order um and so how is the system of microservices going to interact with one another and the thing in the middle is a mailbox a bus a message bus we'll talk about that in in just a bit but let's first see how the different services can in fact communicate with one another you see that i i draw i've drawn this first arrow here that goes from the event catalog to the shopping basket well it's very important to understand what is happening here there is a front end we'll look at the front end by the end of the presentation that actually is allowing the user to browse the event catalog that is using the event catalog service and at some point i'm going to click on a certain ticket to put that or to add that to my basket and at that point the front end is going to say well in the event in the shopping basket that user has now added this amount of this ticket that's what is happening here so the arrow might be a bit confusing but that's in fact what is happening and then the different other services will also start communicating within uh with one another the shopping basket will make a call to the discount microservice when i add a discount and i haven't shown you that i forgot that um when i click on add discount or buy discount it will talk with the discount microservice very similarly there's going to be communication between the shopping basket and all the microservice when i click on checkout at that point it's going to wrap all the information and throw it over the wall towards the the order microservice the order microservices stores all the information about the order and that will then handle or that will then communicate let's say with the payment microservice as you see here that's the error happening here and that in turn is talking with an external payment provider and that returns then information about how that order went through and does the error pointing in this way and then there's also some communication between uh the event catalog sorry the shopping basket and the marketing services these are the different streams let's say of information that i have happening between my different microservices now i talked about errors these errors what are they well they're network calls normally when we would have classes and services doing this we would have just method calls in this case the service costs their network calls the one service the one api will talk with another api yeah um what you will see and that's the way i and that's also the way that microservers are typically set up you have smart endpoints so apis know what to do and they will communicate overall basic types of communication layers so a rest call or a message buzz and that so and so on and so forth so we'll talk about that in just a minute that's the communication part but the logic will live inside of the services those are application endpoints that will uh well we'll talk with network calls are normal yeah we have different network calls going back and forth between those different systems that is of course between microservices the way to do it now don't over don't go overboard with that don't make chatty services because going between services is a network call and that has a delay right so you have to keep you have to make your services as smart as possible but also don't give them too much information about out of microservices and that's of course also sometimes difficult to do and that's also where you sometimes see that you have made a decision that you have to come back to afterwards because you haven't made the cut between different microsources correctly but it is as a normal thing that services will call other services so let's take a look at that i'm going to show you at this point um let's take a look at the shopping basket again the shopping basket if i zoom in here you'll see that it's very similar as again a repository has models has a database context i'm not going to show you that it's exactly the same structure at this point but if we if we look at the controllers let's take a look at the shopping basket basket controller that's the main entry point for working with baskets when i click on the checkout button in the ui the ui was actually going to invoke this method this checkout basket async method that is getting in a basket checkout entity i should say model because it's not really an entity and if you look at that one what does it have well it has information about the basket the basket id to be precise the basket id is the id of the basket inside of the database of the basket service that is being kept around by the front end and the front that is just saying okay this item goes in the basket this item goes in the basket it doesn't do that it just asks the micro service to the the shopping market microservice to distort all that information in its database and at this point when we click on checkout basket the service of the shopping basket knows hey this shopping market is being checked out i have all that information in my database so i can handle that perfectly what is coming in though is all the information about the user that the user has entered on the order screen and at this point that information comes in as you can see here there is no information about which products i'm checking out because i already have that inside of my shopping basket that is a very important thing to remember here so what will happen based on that basket id on line 92 i will actually get uh the information or get the products or the tickets which are currently inside of the basket um and then i will actually start the checkout process right the the all the creation process i should say and that's what i'm doing here i'm going to create a new type a bask checkout message and i'm going to start filling that with all the information i have i have the information of that was entered by the user on one hand and i also need information about the basket and that i get from a local database that was part of the shopping basket database that is what we see here so i'm going to create then the shopping basket and then maybe the user has also entered a coupon a coupon code right because that coupon code if you look here it is also coming along with the basket with the basket that was entered now the basket doesn't know about the coupon codes because that is we've already seen a different microservice that handles that at this point we are already basically creating or preparing the order but we need to do something with the coupon code so we need to go and invoke another service that's what uh what we'll look at in the next part because now we'll need to have multiple microservices communicate with one another communication between different microservices is one of the most crucial parts in the setup not only do you need to understand where a microsoft ends and another one begins you also need to understand what the technologies and the the ways of doing that communication are there are of course different ways of doing that and the one is of course better than the other and i explain both of you um we can do synchronous communication synchronous communication is based on a rest call a grpc call maybe a signal call and it is called synchronous not because it's not using a weight async but it's synchronous because it's going to be let's say blocking one microservice calls another one and the other one is just waiting to give back so the first one is waiting for the second one to give a response so they are in fact blocking one another that's why i talk about synchronous microservice communication i'll talk about that one first i will soon see that it's not the ideal solution for many of the problems a better solution is probably asynchronous communication why will use bus based communication or broker-based communication between the different uh microservices but let's first look at synchronous communication between our different services i have drawn here the disk microservice that's the one that will uh will useful for this part of the application um where in fact another service is going to come in and ask discount microservice hey can i get information about this coupon because i need to handle that before i can handle my shopping basket in other words one api is going to talk in a synchronous way with another api that's what we'll have here so we'll have this different microservices directly invoking another api another microservice and as mentioned that is what we have between the shopping basket and the discount microservice the discount microservice keeps track of all the discount codes right it is still applicable we are still valid and so on and so forth and it is invoked by another microservice and that is the shopping basket microservice and for their communication they are using a plate http cost of arrest-based call rest call that is sitting between them let's look at that um so i have here um the discount uh so this line here uh so line 120. uh on this line i'm going to basically go out to another service in the shopping basket service i need to invoke the discount microservice now i'm using here this getcoupon method this getcoupon method uses itself a class that is still part of the shopping basket microservice and that will invoke using http client the other microservice the discount microservice as you can see here i'm invoking api slash discount and i'm passing in the coupon code and that is a synchronous call in the sense that the other so the shopping basket service needs to wait for this response to come back right that is synchronous communication and while that works if all is is happy and and there is no interruptions in network and there's no delays and so on and so forth this will work fine right nothing if nothing goes wrong well then this would work absolutely fine but like i already said it could be that um there's a lot of people ordering tickets for a certain concert or a certain conference and then what it could be that well we're not in an ideal situation here it could be that we end up with an with a problem on one end it could be that that we have heavy load that we are in fact hammering the discount microservice and it could in fact cause the entire system to go down the drain with synchronous communication i've listed out a few of the possible issues that we are that we could possibly encounter here it could be that it becomes a bottleneck what i was just saying if that one microservice is being used for multiple places in the system and that all those other places are really hammering that service it could in fact bring down that that poor discount service and then that could compromise the entire system not a situation you want to be because it is difficult to find those types of errors it could be that there are intermittent errors with the discount microservice it might go down for a certain time and the other services are timing out and maybe they're trying again and at some point the discount microservice might be back up and then you don't see the address anymore then you start you need to go into logs and that sort of thing could be harder to find what is actually wrong another issue that i tend to see is the tight coupling between the different microservices it might be so that i have my different services and they're really they really know a lot about each other at this what we just saw at this point that the shopping basket service actually knows quite a bit about the um about the discount service it needs to know well i need to call it with this parameter and so on and so forth that may be not an ideal situation in what we're after and that's actually a loosely coupled system between different services that communicate with one another like i've already mentioned it is very easy to compromise this sort of setup if you think about this you could easily have a chain of different micro services calling one another because service a or service one could cause two could cause service three and so on forth and not available something goes wrong database goes out i don't know what well at some point the entire system can actually be infected this way because other microservices are not reachable anymore and in fact because this microservice 3 goes down the other one microservice one and two will actually also go down and this could cause really a domino effect throughout your entire application your entire system of microservices can go uh can go down and it can be harder to recover from these types of errors that is why in most cases you will not use synchronous communication between different microsofts and you need to default and say to asynchronous communication between them now like i said right there are places where you might want to use it this is uh sort of direct communication synchronous communication but in general asynchronous communication is preferred because if something goes wrong you will still have a way to more easily recover let's say because you have some some some intermediate let's say that sits in between and that will help you go through that difficult period um it's typically a broker-based system that we'll need to go into we'll need to talk or we need to move into a broker-based system as some some sort of message bus some sort of broker that all the different microservices know about and that will then uh receive messages and it's a forward messages for all the other microservices to read from and then they can get the information when they are ready to do so when you order something on amazon you all you typically don't get the email like straight away it takes a couple of minutes uh often that is actually because that order is being processed it's put up on some some bus and some other system some other service is picking it up from that bus and depending on how busy it is well there will be a longer delay because we're waiting for that message to be handled and that's exactly what we're going to try to do here as well and like i already mentioned asynchronous communication also uses the system of smart end points and dump pipes that's what you want you want just plain communication going through the pipes we typically don't add any logic on those messages inside of the inside of the broker but you have the smart endpoints knowing what to do when a certain type of message comes in um so this is what you'll get you have some broker that sits in between and you have different micro services of sending messages from one uh into the broker and then the broker will then let's say forwards not really forwarding because they're listening for messages uh to appear on on that broker on that bus and that's how the different services can communicate in a very um well a very independent way of one another because it's just the message that goes through and even if one microservice needs to change it doesn't affect the other systems and that's where that tight coupling comes in again and that that's what i want to avoid that is also much easier to avoid uh doing it this way now before i show you that um i'm not going to go too much into this but there are different ways of doing this sort of communication between different services between uh between different services in general you can do even though you're thinking well i'm i should be doing async asynchronous communication calling service one uh sorry service one calling service two you can still do point-to-point communication it's not because you have this broker sitting in between or this q sitting in between that you cannot do that anymore absolutely not you can still do what is known as point-to-point communication so is one the shopping basket service maybe directly only talks with the order microservice absolutely possible it will send the message into the queue that queue keeps those messages around and when that order microservice is ready it will pick up that message and it will handle it accordingly that gives us a much more reliable system it's very well possible that we have multiple services that are interested in a certain message appearing in the system it could be that we have the event catalog microservice event catalog like i said thus allows us for browsing all the tickets in the system but it may also be the one that handles a price change of the of a certain ticket maybe other microservices need to be let's say alerted about that well then the event catalog of microsoft can send a message into the system and there can be multiple other services which have registered for that and they can say well i'm interested in when a price change uh happens i need to also know about that and they can uh let's say subscribe to that and it's also possible this way to build a more extensible system if another microservice pops into the system we're extending the system when it's also easy to subscribe that also to receiving that message so where are we doing that well i'm going to show you the code for communication between the shopping basket and the order so that's what we'll look at but this happens in multiple places in fact everywhere in my system except from the discount service communicating with this with the shopping basket i'm using that sort of communication and we have a service bus and message bus sitting in between it will send a message to and that will then let's say be received by another system i'm typically more a fan of using azure service bus you can use whatever type of bus you want to use if you want to use another broker that's absolutely fine i'm using azure service bus here as well uh the only uh the waste of the things i typically tend to use here um is um yeah it's of course cloud-based it has a high reliability but it also has this this way of doing topics topics allows me to have multiple subscribers on certain messages that's a very good advantage of of this it also has this system of debt lettering even if a message cannot be handled or never appears on another micro series it will be it will not be discarded entirely it will be placed on some different queue and as a dead ladder that letter queue allows me to read through some management or a messaging queue system that you want to look at failed messages you can look at the debt letter and it's of course also highly scalable and that's why we use it in in our applications very very often as well now let's see how we are doing that how are we doing that asynchronous communication between these different systems now we'll need to look at we need to look again at the basket controller so we had seen this to be synchronous communication now we're over here as you can see here on this line here it's pretty hard to scroll here with the mouse on this uh on the steep desk here uh over here i have created that balance checkout message that is the that's a type that's a class and that's what is going to be sent over the wire of course i need to serialize that we'll do that in just a second but i have created this this sort of helper publish publish message method here on a message bus now what is message bus of course that is actually also a helper class that i wrapped my azure service bus functionality in i'm not making all my services dependent on azure service bus i think that would be a bad idea to do it that way because then if someone decides well we're not going to use azure service bus anymore we're going to use end service bus well maybe then i have to change all my micro services i have basically abstracted that away in this one uh project here with a separate project that i'm going to referencing and if i need to change message or message systems let's say i can easily do that so this publish message here is what is going to handle sending a message and i've created for all my messages a base class integration base message and what i'm then doing is i'm going to create a topic client topics in service bus what are basic are let's say separate buses separate queues that are used to store certain types of messages and multiple other subscribers can can listen to that in fact you're creating multiple types of topics and each of those can have multiple subscribers listen to them you're basically creating smaller topics smaller queues within your queue and what i'm doing here is i'm creating a client so i'm registering uh to work with this service business that i've created here uh in azure service bus or in azure and what i'm going to do is i'm going to convert my message into a string of json and i then simply sent that message off on the topic boom for the shopping basket the the work is over the work is done the message is waiting on the bus on the other receiving end so this message is now in the bus on the other receiving end we have the order service and that order service is if we look at it here it is very well or it is very interested in receiving those checkout messages because that's the time it needs to create an order how does it know that well maybe we have maybe we have in here another controller there's the order controller let's see what that's what that is doing no it's not doing anything and if you think about it well we're not doing api to api communication we've put a message on the bus and this service the the order service needs to well be notified about that message coming in so what i've done instead is i have created let's go to the program sorry let's go to the startup class instead um over here i have created this azure service bus consumer class and i've registered as a singleton within my application and at azure service bus consumer what is that doing that is going to over here subscribe to messages coming in on a certain topic that's what you see here down here at the bottom i'm going to subscribe to a certain message coming in on a certain topic and when that happens i'm actually going to invoke code when a checkout message is received over here i'm going to register so when this application starts in fact i should say i'm going to invoke this start method using uh from the startup class i'm going to then register a message handler that says that when a checkout message is received i want to invoke this particular method here that method is going to be notified about the message coming in that was the basket checkout message placed on the services by the uh by the basket service and this one this service is responsible for handling or creating the orders and that's exactly what it's going to do next so in here in this let's say background process i'm going to create an order store it in my database through the repository and we're done here in fact we're not done if you think about the schema again well the order was actually then going to do the same thing it was again going to create a message and it was going to put another message on the queue on the azure service bus that is then going to be an order uh i think an order repayment request message the first message that goes into the service bus again two words and the direction of the payment gateway and that is what is then handled here so we send in the information about the order there we go that's what we create and then we do the same thing messagebus.publishmessage passing in that order that the payment message order payment message that we then have handled by another service that is also listening for incoming messages so that's how about different microservices are going to communicate in a very asynchronous way and also in a very loosely coupled way if we go back here there's a couple more things i need to show you um i hope it's clear that the different microservices are not connected to the same database if you see someone doing microservices with the same database they're not doing it right and i've seen this type of system maybe we do a microservice we have one database yeah you're not doing microservices this is a very bad way of doing microservices because then you basically you just split up your application and you've probably made it harder on yourself maybe that's what you want but job creation that's called um but that's probably not what you want and you want to do it you want to do it right and you probably want to have all of these microservices have their own database and they are also not touching each other's database you're not going to have one microservice touching the database there we go you're not going to have um one microservice directly doing something in the database of another microservice well you could just add the connection string from one microservice into the next well again bad thing bad way of doing things that's not what you want you want to different microservices to only communicate using messages instead of directly changing something in one artist database so that's also a way of basically splitting up and making sure that these applications are really standalone and that's what you want to get to the final thing that i want to show you here before we look at the frontends is something that is known as eventual consistency i already mentioned the fact that maybe some ticket changes its price or the price is changed to the administration um pages which i don't have in the sample but imagine that also being part of the event catalogue it could be that um in a monolithic application when you change it in the database it's it's changed for everyone everyone knows about it right now maybe i'm changing a price of one of one ticket in one service and other services also need to know about that because the order service keeps track of order sorry the shopping basket service keeps track of hey i have five tickets of this type with this price in my shopping basket so it needs to know about the price of that ticket again that is not oh again not again that is something that we need to take into account and it is known as what is uh typically known as eventual consistency it might take a while before all the microservices are aware of a change and what we need in that case is typically some sort of different type of message which is known as an integration event a fire and forget message typically one service will say hey i have a change in the price and i'm going to like like i said the event catalog service might say i have a price change i'm going to then publish that into the system and everyone who is interested in knowing about that price change well they need to subscribe and it is again something that is pretty easy to do i can very easily create a service bus in azure and create multiple topics on that and on those topics i create multiple subscribers in fact i can just do it with one topic excuse me i can do it with one topic and i have multiple subscribers registering for what is typically known as an integration event i fire a message uh price change into the system and all the microservices that need to be notified about that will have registered for that price change message and they will automatically oops they will automatically be made aware of a price change to the system and again that is something that happens through a service bus much more easily than having direct service communication if you want to do this with an api call imagine that a new service comes in what that would actually mean that you go back to all your other services that do that that publishing of that message that price change that would make make it very hard to maintain your system because you need to keep track of everything that has changed and all the new services coming in that would be really hard this type of communication makes it a lot easier and the final thing i want to show you and because we've now seen the different microservices how can we now work with those i've shown you the ui yeah but how is that ui effect communicating with these different microservices well in fact this is what we've had so far i haven't shown you the front end the front is a plain asp.net core nvc application so it has just uh controllers and in effect has view services so classes that basically relieve the controllers from doing too much but we moved it all into separate classes but what we that's not really important for what we're looking at here what is important is that those or that mvc application is directly communicating with the different microservices direct to microservice communication is what is being used here now it works it works absolutely fine but it doesn't have uh it doesn't always make up for the best way of doing your communication between your front end and your microservices because it could be that we have different microservices communicate sorry different contents communicating with those microservices you're always going to end up with um coming or information about how the responses of the different microservices need to be combined and if an mvc if you have an mvc application and a maui application and maybe a third party api what you're going to end up with is having to copy that information about combining the responses multiple times into each of these frontends typically not what you want so you will have um too much information let's say about your different microservices inside of the front end and that's not what you want you always you're also going to have a tight coupling and a more um hardest time let's say to make your bike services evolve because if you have your front end directly talking with your microservices your microservices change the api while your front end also needs to change we're looking for a a form of less tight coupling or loose coupling well then this is often not a good idea what is often a better idea is well putting a layer in between and that's typically known as a gateway the gateway is basically well let's say an entry point to the microservices solution or microservices setup instead of having my front then directly talk with my microservices i'm going to have a gateway an extra layer that sits in between and that can be shared between multiple applications so the logic of combining the answers of microservices can actually be moved in here it is typically something that is used for larger applications but it's actually something that i tend to do most of the time and in this case we often talk about a back-end for front-end and i'll talk about that in just a second before i do that one risk that you have by creating a gateway is that that becomes a monolith because it might end up having too much information about the different microscopes this is something to be aware of um and the the place where you would typically end up with that is if you have your gateway has or is the front end for multiple um types of application maybe a mobile application and a web application and so on it might have too much information and in that case it's often a better idea to move to multiple gateways that's what you see here so this is what the gateway will do it will basically be a layer that sits between the front end and the microservices and it will communicate with the different services and only the front-end knows about the gateway and it knows about it knows nothing about the individual microservices it only knows about the gateway and the gateway will do the communication uh for towards the different microservices now like i said that gateway is at risk of becoming too large it might know too much about the different microservices and definitely if you start using it from different front-ends it might become too heavy and it might turn into a monolith as well not what you want in that case if you have different front-ends communicating with your microservices that's when you start looking at the back-end for front-end mechanism and the back-end for front-ends sorry that's what you see here so multiple com multiple uh front-ends communicating with the gateway like i said not an ideal situation to be in so what we are typically proposing or typically doing is having a specific gateway for a specific frontend then you have a specific backend for a front-end that's what you see with the bff pattern of the back-end for front-end pattern where you have a front-end and a plain mvc front-end that has a specific api then you have maybe a mobile application or xamarin and it has a specific separate bff for communicating with the microservices but giving back responses which are specific to your mobile application and that's what you should actually strive for in this particular case let's see if i still have time dylan is it okay if i do another small demo two minutes yeah yeah that that's that's definitely doable all right let's quickly do that so i have it already open here actually you need to still need to open it here this is a different solution and then i can show you how that is set up so um the microservices haven't changed nothing has changed there uh but we have different front panes so the actual front end so the regular one was this one that is basically an mvc application if we look at its controllers let's look at the event catalog controller if you look here that uses the event catalog service that's a service a view service really that does the communication with the backend if you look at that you will see here down here at the bottom for example here we do a get category by id call and that goes off to api slash events that is a microservice so we're going from the front end directly into the microservices typically not the ideal situation to be in a better solution is what is also included here uh is using different bffs as you can see you have gateway sitting in between and that gateway will now be the point of communication between my front end and my microservices so if we look here at so as you can see we have a mobile bff and a web bff the web bff has a controller for example for the catalog and that does what we did what we did before in the front end that now contains the information to get all the events and that will still do the call to um the api call that's what you see over here that will actually go out to the microservice ins itself but the front end will only know about this gateway so all the logic of combining the on the the responses of the different microservices is now wrapped inside of this gateway in this bff yeah and the front ends well that is this separate uh front end that's a canon mvc application that now only knows if you look at its event catalog controller that now only knows over here and it only knows about the api bff so it will only communicate to the through the bff and it also increases of course your security because you can put your microservices between uh after the firewall or the vpn and only this one will need to talk with the microservices in turn right so that's of course a much easier way to secure the system as well and with that we are almost done so let's wrap it up i hope i've given you a bit of an overview of how you can do mic services it first of all as a big reminder it might not be the solution for your particular problem it can be a solution for larger applications it's typically something that tends to attempt to lend itself better for larger applications but it's not always a solution even for those building it using asp.net core is of course very well possible it's just apis and those apis we need to consider how we let them communicate and of course a good way of doing that is a broker which uh which we've seen uh using azure service business image we have asynchronous communication to let the services communicate all right i hope i've given you an overview that that helps you a little bit i said i have a five-hour course that goes a lot deeper into setting up this sort of application hope it was useful for you thank you for skipping lunch to come and listen to me i hope you enjoy the rest of your day and the conference thank you you

Channel: NDC Conferences

Views: 49,178

Keywords: Gill Cleeren, Architecture, Microservices, ASP.NET, .NET, Core, MVC, ASP.NET Core 6, NDC, Conferences, 2022, Live, London

Id: SR53SKIUYPA

Length: 56min 51sec (3411 seconds)

Published: Tue Jul 26 2022