Microservice Architecture with ASP.NET Core

okay on today's episode of the on dinette show we're here with Cesare and we're gonna be talking about micro-services architecture with asp.net core you'll definitely want to check it out welcome to another episode of the on net show today we're gonna be talking about microservices and architectural patterns with Cesare della Torre right yeah so how do you quickly introduce yourself and then we'll get into the topic yeah so um I work as p.m. in the Dartmouth team yeah and my focus is most of all about dog net application architecture guidance reference applications and provide that through ebooks technical ebooks and on those applications and also in this kind of events yeah yeah we're teammates right I think we've worked together for what six or seven years or something like that longer in here yes at Microsoft yeah well Microsoft it's been 11 years ok but in in def day if it's gonna be yeah six years almost yeah exactly yeah so how about you tell me about this the site that you have up right now I think this is kind of the homepage for your guys right yeah so being we've been working on these for quite some time yeah it's not just about micro services so we we created a aside about.net application architecture as you can see here there are multiple areas about mobile applications for Windows apps for regular web applications but modern with asp.net core the cloud with uh sure how to modernize with Windows containers your existing apps and this is the area that we are focusing today which is about micro services architecture and darker containers so if you if you go to the microsoft.net side then you you click on the architectural link you'll get here and this is the the area that we're going to be talking about so we have a very extensive book about micro services that I wrote and then a reference application videos and so on so for instance the e-book is you can download it for free it's a deep content about micro services like around 300 pages so the first section is about architecture patterns and so you could really like this first 70 pages just to know about what is that and then the rest of the book is about the implementation with dotnet core so depending on how deep you want to go and that the cool thing is that it's not just this content it's also related to a reference application that we have in github so it's called a shop on containers it's a shop because we just wanted to find like a very well-known domain developers it doesn't we're not trying to create our reference about e-commerce this is just about to learn micro services and docker containers but you can see it's been pretty successful like we yeah we have like 2004 almost 6000 stars a lot of people watching it and then here you can see that you can run these kind of in two levels if you are just trying containers you can run everything in your laptop like here just with this a studio or even the CLI and just docker for Windows and everything we run all the containers will will deploy like I write I have it now here in business studio and then all the containers like if I do docker PS you see all the micro services and containers running locally and even the infrastructure is being deployed automatically so we are deploying a sequel container Redis container rabbitmq for 10 bars everything even a MongoDB everything running locally and you just need to to hit at 5:00 in Visual Studio and everything will get downloaded all the images pull down and everything will run that's kind of the first step but then you can also move ahead and if you're thinking about a production environment then you can swap things like for instance instead of a sequel container you will move to a sequel database cynosure or instead of a MongoDB container you move - well not document EB Christmas DB now instead of rabbit and Q for messaging you use service vos and and so on right is cache and so on so we have all that in place all the code ready you just need to put your your sequest your kids and instead of deploying on a regular docker container you would deploy in a scaleable Orchestrator either a KS with kubernetes or service fabric as well that's kind of the summary and here you can see the architecture where we have three clients client apps we have a summary nap regular MVC application angular single page application and then multiple micro services all of them autonomous independent with their own data IPA gateways and so on right so if I take this application kind of get familiar with it on my machine potentially make some changes to it just to kind of get a sense of what it means to make changes in multiple kind of parts of the architecture once I get there then it's you know and say I have an Azure subscription already what I'm hearing is it's relatively straightforward to yeah going to ploy that to Azure and then actually have that you know at some point I'd pretty mess the self certificate somewhere and it would just like appear like a real application in the cloud yeah yeah first of all you don't need a sure you know in order just to test it in for sure in literacy but then you can move to Usher and undo it pretty easily it's not just a code we also create here in the wiki all the you know procedures on how to set this up with a visual studio or even with anna mac and CLI or how to deploy these in in IKS or service fabric and you know all the details that you need to do step by step well looks like a lot of content now can you tell me about the type of like who do you what kind of customers do you talk to - you believe our using this content is there any kind of clustering there yeah I mean it could be any industry but microservices is not kind of the Silver Bullet so it's not for any kind of application so more than any type of customer I mean yeah it could be enterprise customers could be Isley's but most of all we're talking about large applications and that also need to evolve in the long term and potentially or probably in each area like one area per microservice you want to evolve that independently now you have a one development team for this area another development team for this area and then not just to deploy that independently or work on that autonomously because you deploy your micro servers you deploy your database related to that and it shouldn't impact as much as when you have a monolithic application right so here I ask you the hard question what is testing look like in this kind of model you know do you have you know fairly focused unit tests for each one of these systems and call it good I assume not like what what does the testing strategy like so we basically have kind of three levels of testing would be unit tests per micro service yeah and then we have integration tests so that would be taken into account data and all those things that are not just your code and finally what we're calling functional tests and that would be taking into account the whole system so let's say I do a create an order from the UI that is coming through the API gateway and then this is coming to one or two micro services in that whole execution would be a functional test and and for that you need to have the whole application either in docker docker host or in Indi Orchestrator sorry what did you mean by that last part you say you need the application in the docker host or doctor Orchestrator or in the kubernetes oh I see I yeah because it's not like just running unit tests with your code you need the actual micro services or containers to be up and running somewhere and then you run the tests the integration test early yeah makes sense and you didn't say this but yeah tell me what exactly which technologies used here I assume you used you know a bunch of asp.net core here and there and some xamarin mm-hmm can you talk to that a little bit yeah well from the client side the mobile application is summer in forms so it can run on on Android and iOS and then the web applications the single page application is angular but then in the server side it's NBC and the same thing for for the regular or traditional application it's MVC but all dot that code here is dotnet core so it's cross-platform usefully by default we are deploying into a Linux docker host you can also run it on a Windows docker host and and then usually we deployed into kubernetes also internal Linux right and then about the micro services all these micro services are asp.net core Web API s and and then the API gateway it's it's an op based on on ocelot which is an open source project especially made for api gateways but you at the end of the day you have like a nougat package and then you host that into web host asp.net core as well right now to remind us what is the so I think most people will understand what an API based micro service is and means what additional value does a gateway provide on top of those because I think the applications are just touching the Gateway they're not actually touching the services themselves yeah yeah that's right so think about in this case this is a kind of small medium micro service based application and we have like one two three four seven eight nine like micro service types and but even when with 10 micro services if you have to access those micro services directly from from the client apps you will need all those URLs from the client and but it's not just about the number of URLs it's also about even about security so you want to surface only the API is that the client applications need not the rest so potentially you might have quite a few micro services in internal API is that shouldn't be called directly from the outside so basically the API gateway is like a front-end for shot for your micro services so you are simplifying what the yeah that front-end of services to be consumed by the by the client apps no sorry yeah and something else that I want to say is that's one thing but then something that I I'm highlighting in the guidance is the fact that might not be good to have a single API gateway because because then you could be kind of breaking the autonomy of those micro services like if you are deploying autonomously these micro service but then every time you do something here you need to change to change something in a monolithic API gateway then that kind of API gateways is becoming the monolithic thing right yeah so that's why a good pattern is to have multiple API gateways it could be larger or smaller one pivot would be what you see here BFF is back in from for front end yeah so you can create or you can create kind of special API for the mobile apps as you can see here these two are specially made for the mobile applications and these two are especially made for the web apps because you might need different API when you are talking from the mobile ap mobile app or the web application right yeah and then the same thing could be about areas like business or domain areas so this is about the shopping area or the marketing area in this case because this is a small sample we just have two domains or areas but you could have more right now I could imagine a situation where you build up these facades which are these gateways and there's kind of this I assume maybe there's this tension between wanting to kind of aggregate functionality which seems like it could be a good thing but then also maybe the Gateway could get a little bit on the fat side and almost become a service on its own can you speak to that yeah yeah that's a good point because um in this diagram this is simplified and you can see just kind of the API gateway which at the end of the day an API gateways is like a reverse proxy yeah with single URL and then you you are redirecting to or route into different internal endpoints right but but then there's another well you could have also cache or authentication quite a few things in the API gateway but the most important thing is reverse proxy but then the other thing is aggregation yeah that's where I was headed so the aggregation so the less you put about logic or these kind of things in they pay go gateways they better it should be as thin as possible but sometimes it's important to have an aggregation here for instance and especially for the mobile applications or even the single page application which is remote if it is the MVC application which is you can see here it's running within the same Orchestrator same cluster because of the latencies is smaller well if I do a few calls here like two or three max services that's okay yeah but if you are talking to the server side from the mobile app or from the browser in the single page application and let's say if you are loading a single screen or page and you need to talk to three or four different micro services that would mean three or four HTTP requests and that's not going to be very optimal well and also I would imagine in many cases they can't be made parallel because you're actually using yeah the output of one call to do to make the other one so they have to be sequential so that's why if you see this other diagram which is a little bit more detailed that I have here in a you know deck what is it well I'm not sure if I have it here now well maybe here you can see no I don't have it here but in any case what we also have is like in the case of the shopping area because we need to talk to a few microservices here we have an aggregator container or API that for just some cases you do it a call from the mobile application for instance and then this one is talking to 2 or 3 micro services and respond in just a single time so that is optimizing so it's not so chatty it makes sense okay so it sounds like if people are really interested in this they can go to the website they can read the books that's probably good for the type of person that really was just wants to build up a mental model of what this whole space looks like and then they can kind of talk about it with some level of kind of authority and and context and then we also have these github repos for people who want to kind of really dig in experience it through visual studio you know step into code and and potentially even deploy it somewhere to figure out what that looks like I guess you have any advice for someone who's good yeah I've been like - you mean about architecture or about apart adopting about adopting these samples yeah but most of them yeah I can talk about two things one would be about how to adopt all the samples or even the micro service architecture and then the other thing we can talk about maybe a little bit of patterns or anti patterns in micro services okay the other thing I want to talk about so first thing on how to adopt this approach I we really recommend not to start you know scratch and trying to do everything right the first time so probably it's better to start with something which is even monolithic where you are putting the logic and the business domain that you know and then you start splitting that into smaller pieces but thinking about also that and this is the most important thing about micro services that each micro service has to own its own data so and that's one of the most challenging things in micro services so you shouldn't have just a single database or just a couple of databases and then a bunch of services because then it's gonna be monolithic because of the data and well instead of a a process you will have multiple processes but that is not what my services mean yeah it also makes a validation like your risk level goes up quite a bit when you deploy a change and the data side of it is being used through three things then it's not gonna be true that you have out on almost deployment because then it will be impacting the database right so in regards adoption well you can start with something which is monolithic and then start splitting it or even adding new features as micro services but each micro service with a new with its own data owned by it like you can see here small data base per micro service in the diagram that's one thing and another thing is if you use the API gateway pattern that's an advantage for that because from the client perspective you wouldn't know if you what do you have inside if you have like 100 micro services or just some monolithic web api plus some other small micro services and little by little you can evolve and split up that monolithic API in other micro services but from the client side you wouldn't notice it yeah well you are refactoring that yeah I think so I first read there was a blog post that I think Netflix put out I want to say like four years ago or something like that and I think that's where I first saw that BFF term and I think that was the the approach that they took was to infer from that ya build up that gateway first Reap lat the clients on top that gateway yep and then you have then you have the separation you need and then you kind of never have to talk to the clients again and then you do your architectural like you are kind of decoupling your newer microservices from the client and then you can play with that yeah that's one thing the other thing to me is the most important like each micro service has to own its data okay that's one thing but the other thing is and and this is a kind of financial pattern that I've seen from many many developers or companies is that they start using micro services like if they were objects and they start kind of you talk to or you do a request with one micro service and this one is talking to another one and this one to another one kind of long chains yeah of HTTP and that is really bad because at the beginning it's gonna work but then it's gonna be in reality what you're kind of building is like a monolithic a distributed monolithic right and the issue here is that if you if you start with having issues with one micro service or star and it's going to slow it slowly down is gonna impact exponents on it yeah just a pile of spaghetti yeah so yeah I have one slide here which is pretty and this is why it is also important to or do you have this yeah so this is what you shouldn't do like you have the Klein app is talking to from the API gateway for let's say to a basket maker service this one to another one another one and then respond in but then if that micro service is failing then or going slowly and think about thousands of HTTP requests like that is gonna be pretty bad or even if you if you were using retries because sometimes you have like a very small problem with the network and these micro services start giving a problem then all the microphones are going to start free trying and then you can cost like a denial of service to yourself to yourself so so the the important thing is to really isolate or identify autonomous boundaries so each micro service should be purely independent from other micro services and and then if you need because sometimes you might have like kind of the same entity in multiple like a services data so that's the challenge right so I mean one of the things I find with a lot of the work that we do and it applies here too is there's this modelling challenge like you have to spend a bunch of time on modeling and have a set of characteristics in your mind that you want that you want to apply to the software you built and your model is the thing that kind of has to account for all of that yeah so thinking about the models and how to split the the big model into multiple models is probably the most important thing like bounding context which is the name that you use in domain drew and design which is pretty similar yeah and then maybe one one entity could be even the same entity split up in multiple pieces that may be in the catalog I have all the all the attributes for that entity of the product but maybe in the basket I just need the ID and maybe the price but not the rest right so but then if you see here the Col when I talk to from the client with HTTP it would be just to the first level so if something happens in any internal servus you just send an event and you send that communication to other micro services through an event bus or service box or RabbitMQ so basically this is to have eventual consistency between those small models yeah another important word that's that's the most important thing here because maybe when I change the price in the catalog for a product I want to be a worry about that in the basket but I will keep the price in the basket and the new price is going to come with an event is synchronously so finally what you get is that from the client you're just when all that propagation of data and eventual consistency is done from the clan you just need to talk to one micro service and maybe something happens again and but it's like decline up or the AP API gateway should talk just to as much as possible to a single level of micro service not a long HTTP request yeah I almost see it as then we should kind of finish up is this kind of approach is almost like client first development meaning your architecture is oriented on the best possible experience for your client whereas the very first diagram is almost like a back-end first not that it's great for the backend but a back-end first approach which is its oriented on consistency now whatever the opposite of eventual consistency is so it it's kind of on the easiest way for the the backend but the client suffers a lot so on the second diagram the the backend has to kind of use these other techniques to cause data to flow and get various ways right and and and this is where if we come back to the architecture you see that we have an event bus as just running it on top of Robert and Q or service bus and we use that for this event which consists on your backplane and so that's okay is there anything else you want to just say in closing oh just that well it's not just running this locally you can also deploy this as you can see here in usher this is a KS and and you can deploy this into Cooper nudity nashor and and here you can also you know like scale out so if right right but so is there any if you know someone goes and looks at this and they've got some like pretty detail-oriented questions where would they ask these and with the hope of kind of giving or yeah sure so yeah that's a great question so first of all if you have any issue about when you're trying the the examples or the reference application you can go here and create an issue and we are monitoring these and and an answering and solving everything as much as we can that's one thing the other thing is if you have a like a specific question you can also send a question to in most of the pages here you you can see this in list email issue ok back you send an email as well okay thanks Azhar this has been excellent cool I know that there's a ton of folks that really appreciate this content I know you spend gargantuan amount of time on this yeah 40 hours a week right probably a few more than that okay well thanks for thank you yeah thanks for listening to another episode of the on net show and today we learned about micro services and architectural patterns

Channel: dotNET

Views: 91,712

Rating: 4.8936172 out of 5

Keywords: .NET, ASP.NET, dot net, asp dot net, DevOps, Programming, Software Development, Microsoft, Visual Studio, microservices

Id: RyHDWlIq6vI

Length: 27min 42sec (1662 seconds)

Published: Mon Jun 11 2018