On .NET Live - Cloud Native Patterns for .NET Developers

[Music] [Music] do [Music] [Music] [Music] [Applause] [Music] and we're live hey everyone thank you so much for joining us for this week for on.net live i'm your host my name is cecil phillip and today we're going to be talking about some cloud native patterns that you can start implementing in your applications today and i have my friend nishi who's going to talk to us about it so nish why don't you just introduce yourself to the folks a little bit let them know who you are and what do you do yeah absolutely my name is nish i work on the dotnet community team and we focus on doing a lot of community stuffs and i specifically focus on the architectural guides and reference samples i kind of like to put itself as uh you know helping developers you know build production-ready apps with.net so it's one of my favorite areas cloud native and micro services and we are doing the micro services one so i'm super super excited to be uh doing a lot more in-depth talks on microservices and thanks awesome and i know this is market service march here on.net live tv we know that you nish and talking about those architectural guides i know you work on a lot of those you know cloud native guides the containerization guides and so on and so forth right yes absolutely yeah so there is a bunch of guides guidances out there and that is specifically focusing on two things one if you're just getting started with microservices and cloud native apps and other things we have some great guidances to help you go through that we last week i think last last week we announced the dapper for.net developers which is also a great application runtime that you want to take a look at if you're getting started with microservices uh there is also other guidances like you know if you're someone who's coming from the uh you know dotnet framework side of things you are actually modernizing things and you're looking at dockers kubernetes and other kind of things and using how do i modernize things you want to have a step-by-step approach so there are some great guidances and reference samples up there uh to help you get go through the journey awesome well hey i'm definitely excited to kind of dive into it um just want to acknowledge the chat really quickly looks like we have some folks joining us from from poland from turkey um hey i know it's probably really late where you folks are so thank you so much for joining us i really hope that you could enjoy some of the great demos and content that niche has prepared for us today now before we dive into it though like i need to share some links so you know folks can know what exactly is going on so what i'm going to do i'm going to bring up my screen really quickly and i just want to share some of these links so you know hopefully you guys will check this stuff out um so first one i want to share introduction to microservices which i think is very fitting because like i said it's micro service march and look who it is it's nish right nish is here with james montemagno on the xamarin show and you can find this over on channel 9 and they're talking about introduction to microservices so i think that's pretty cool i'll share these links in the chat too as we go on but uh if you want just head over to channel 9.msdn.com and you can see some of these uh the next one cloudnativelearningresourcesfor.net developers and look it's initial again initially you all over the place man so nish wrote this really cool blog post on the.net blog so the official.net blog and he's sharing a lot of cool tips and resources for you know if you're just getting into macro services if you're interested in learning some new things and how to adapt them into your.net applications definitely check out this blog post again it's on the.net blog so again i'll share the links in the chat but again you can just head over there and check these out as well um another blog post coming from the.net blog is from our our friends rob and sarab is talking about opentelemetry.net reaches 1.0 which i think is pretty great i know later in the session we're going to talk a little bit about open telemetry what it is what we could do it and how to use it um but again if you don't know what it is if you're unfamiliar with open telemetry want to hope you stay watch the show and learn about it but two again definitely check out saurabh's blog post also available on the.net blog and last but not least tomorrow so tomorrow march 26th um we're gonna have another let's learn.net event um and this one i think is gonna be um our friends jamie and shane let me make sure all right so jamie and shane are gonna be here um again it's gonna be completely free we're gonna be on learn tv and on youtube i believe and they're gonna be kind of going through you know walking us through some some micro service content um and nish i believe you worked on some some some content for this as well right uh yeah that's right the the getting started sample that they would probably use would be uh the one which is on the dartmouth website and also the ms learn uh which is about you know deploying microservices uh into the aks and then just executing it all the you know features and things that you want to roll out for example there's a coupon feature that you want to roll out uh so that's a really nice ms learn module that you can try it yourself but i think there will be more a lot more discussed on this one um tomorrow so definitely stay tuned for that one right so today on the show we're gonna see a lot of demos about microservices about patterns like health checks and you know using open telemetry and feature flags and things of that nature but tomorrow is going to be a little bit more hands-on it's going to be more demos we're going to be going through some learning modules and it will also have some folks in chat helping you along so if you find a little bit hard to follow or you need some help definitely make sure that you do that as well all right so my time is over i'm not the star of the show so my desktop is going to go away and now we're going to focus on niche i'm learning about microservices oh and look at this really quickly too so i'm getting poking again in the chat wow looks like we have some folks from brazil we have some someone who's here from slovenia so hey thank you slovenia thank you all for joining us and also romania too wow we have a lot of folks argentina is here ukraine is here no pressure man no pressure at all i'm just letting you know the world is watching everything amazing that's amazing the world is watching the world is watching it's amazing amazing yep okay so i'm gonna bring up your screen right now and why don't we start talking about microservices or first what do we talk about like what are what is what is cloud native and like what are some of these cloud native patterns that we're going to talk about today let's start there yeah that's right i mean we put the title club native patterns and apparently there are so many patterns out there and it would be almost impossible to cover everything i think last time we we act actually last time when i was on your show says we covered the resiliency aspect of microservices we did yeah we talked about circuit breaker retry patterns and other things that was more into the designing of micro services and things and today we are talking about cloud native patents it's more to do with you know what are the things that is available uh on the platform to kind of like look in uh specifically when you're writing applications that are distributed in nature and kind of taking advantage of the cloud right and two aspects i want to really focus on today one is the observability and monitoring and the second one is centralized configuration and feature flags both of it is a very large topic and by itself it is a lot of content so i'll try and go as much as i can but one thing i try to do on cecil's show specifically is i try to keep it simple because he always asks me to keep it simple so so we will keep it simple so the demos are going to be very straightforward simple point a to point b how do you do a uh to get to b kind of things uh but we can uh concept wise we need to kind of like put in perspective so last time we we did completely on the demos because that was fine but this one needs some kind of concepts to be kind of like explained to those who are joining fresh and they have no idea about where where how these all come up and where all it it makes sense and i think so that's why i have some slides in there but uh but we will get to demos too sure and you know what i also believe too is you know as much as as much as we love demos i think it's always great when you know we don't focus so much on the the logic of the demo right like we really want to see the concept so you know i don't care if you're running you know a store or a bank or a pet shop or whatever the case is but i do well at least in the context of this like i really care about you know how can i turn on monitoring and observability in my app like how can i do centralized configuration and health checks feature flags at my app right so keeping the code simple you know because i know a lot of folks ask oh well this is not a real application we don't really build apps like that and i'm like i get it i get it but again we want you to focus on the pieces that are important for the thing that we're going to talk about and so that's what we're going to do today that's right all right let's get started for those who are joining for the first time with the microservices world uh so let's put things in perspective like you know there is this monolithic architecture where you have i mean we always had these applications split into multiple uh layers like you know you had an app layer the i mean sorry the web layer there's a services layer there's a data access layer then there's a database but eventually they're all packaged into a single deployable unit and they are scaled into vm so the vms becomes the you know scalable unit right which is fairly simple in terms of deployments and other things but you know the challenge with this is when the application is large and you have really large teams it is really really difficult to kind of ship uh you know features into productions very often so that is why we will look at something like a micro services architecture which is like you decompose your application into kind of smaller services which focuses on a business functionality uh so when you deploy it uh you know they are actually deployed into multiple vms probably and they may have multiple replicas as well some something like a kubernetes in place can kind of like orchestrate this whole thing together and services connect to other services they do not connect to uh databases of the other services directly first and foremost the database itself is split uh in terms of like each service focuses on its own business functionalities that means it owns its own data the database choice is also uh is defined by that microservice right um so uh you know the problem with this is you know now the the the application the church which was simple uh which were in single boxes which we can actually kind of debug and figure things out have not have now this uh you know it's decomposed and it's everywhere right it's kind of like a distributed in nature and that's why we probably need more better tools to kind of like understand and what's happening in the system and go uh into the details of that um so you know so let's talk about the challenges with with this distributed computing in place right um for example you know there's one thing that is very common systems failures system failures are inevitable right so there's you can't you can actually be prepared for a failure uh but you know there's nothing that you can do when it fails uh like you can't avoid failure sorry so you can you can do a lot more things when you fail uh so you need to have tool sets to do that and you know the failures you can actually classify them into known failures and unknown failures and known failures are the ones which are prepared for for example last time when we talked about resiliency we talked about you know retrying when things go down uh having circuit breaker in place and kind of those kind of patterns kind of you know make your system more resilient uh and that is where you prepare yourself for a known failure but in unknown failures happen too like you uh i mean there are times when actually when these failures happen you you probably realize that oh there was a service like that in this place first of all which was failing you know uh those kind of situations happened and you may even discover a code that you probably thought you know it never existed in the first place so there are uh you know unknown failures there right uh and the other challenge as i mentioned earlier the failures are now distributed um so gone are those days when something goes wrong in a particular box you could just log into that box and try to figure out from the logs and what exactly happened and kind of like you know get to the bottom of the issue but now we're talking about multiple systems coming together multiple services uh it becomes a challenge because you have to know probe failures in multiple places right and you know what that reminds me of just you know not too long ago like before i even started working at the company and you know we had this architecture where like you said it's a lot of machines we weren't in the cloud but we're on on premise but even though we had a lot of machines it was really annoying to have to go into log into one machine oh it was a problem here was a problem here and then logs were in so many different places right there was the windows events thing that we had to search for some applications logged to disk um some of them were sending it in some people were logging into databases and so now it became very challenging because now we had to aggregate all that information and to get a holistic view of what exactly the problem was that's right that's right so so many issues right i mean just to get to that bottom of the problem uh you had all these hassles in place and and and so is you know the legacy systems uh the apms that we used in the past will not work in this case because you need that distributed nature uh in place uh so these are currently the kind of identified challenges uh now let's look at like you know how we can solve these things right um so we're going to monitoring and observability and though they all they sound very similar but they are two different things um you know uh somewhat like uh so monitoring is it tells you where the problem is so it tells you okay there this the system can fail or you know it can give you those information but observability is all about going deeper in understanding why and it can give you more probing informations like you know what vm what node you know you can go into all those kind of details and you can get to the point where you can kind of like start fixing those uh issues right so the three killer key pillars of an observability that as i say is the logging the metrics and tracing uh logging we have been always been logging uh ever since we started writing the hello world applications we always wrote console.write or printf or anything that's just a fair you know a simple log that goes into the console right and logging gives a lot more information and matrix is basically the numerical value and it also is based on the time series database that means you can actually relate your probably your applications performance based over a period of time and things like that and tracing is an important aspect which is as the name says you trace the entire request uh so when you look at uh you know distributed computing in place you do not know which vm which node which container which service is actually connecting and taking the request so you want to get that entire holistic view of it and that's where distributed phrasing comes into picture right and then we also one more thing i wanted to add here is the health check and which is the key thing in terms of understanding if the system is up or not right so you will probably implement the health systems to query your services if they are up or not right so um so this is what we want to cover uh today and we will also look a look at centralized logging which we probably will be left out with a little bit of time but i'll try and show you places where you can actually grab more information about that right um so cool so let's let's get started with the health check now talking about health track as i mentioned earlier you know uh it is technically two things one uh it needs to tell the services need to tell is the system running and the other is can it perform tasks and they're two different things because um it's it's like the heartbeats right or it's like the more like a binary thing which says okay if you say the system is up that means you're good but there is also the other side of thing is can it perform task and that is an important aspect and that comes into picture when for example your service is up but then there are hundreds of dependencies that you probably are relying on there not all of them are up so you you can't perform tasks to complete it and that is something which the health monitoring system uh should be aware of and depending on what health monitoring system you use um you know you probably will be using uh you will be answering similar things and letting those systems know and for example in a kubernetes world of things they are represented in two things like one is the liveness pro and the other is a readiness probe so liveness probe is all about hey is the system live that means your application have to bake in some sort of code to say yes i am alive and the second thing is are you ready uh for performing task and the system has to say yes i'm ready when uh you will perform certain tasks to figure out is the system is the service ready right so that's just two different things and this is very key if you're working with kubernetes because in liveness you want to be really quick and say you're up or not and that could be bare minimum just a ping and you respond back with two on the status code and that should be good enough and you should not put any other code because uh you know if you go wrong there uh the chance that the kubernetes if if if you don't respond to android immediately it will restart your application so that's the key uh thing there but in the red i think this is a good distinction i'm sorry to control i was just saying i think this is a good distinction for us to have because kind like you said it's like what does it mean for something to be ready to go like like what does this mean to be hey my service is up like what does up me right it could be yes the machine is up it could be yes you know it's not throwing errors or exceptions or anything like that but you know can it reach the database can it reach the redis can it you know connect to like some external service that it needs to do its job you know right and so then now we think about health as like the health of the application like the intuit instance of that service or the health of the machine or the health of like the architecture right like all of the different pieces that kind of plug together to make that thing do you know the job it's supposed to do that's correct and that's where the readiness thing comes into picture and and the important thing to know is in in terms of kubernetes if the readiness probe does not respond if it says not ready that means the traffic itself will not be diverted there so there's no sort of cascading failure that will happen if your service is not able to handle that particular task right so it's a it's an important thing so that's why you need to um and and the whole aspect is like uh in terms of kubernetes in the yaml file you basically provide these two path which is like you it has to be part of your service and the service have to have to say uh you know what is the path which will tell kubernetes what does liveness mean or what does the readiness mean in this case there's liveness and hetc so we need to we need to uh you know write this thing within our micro service so that's what we will try and look at it today uh as part of the demo uh we're going to implement a health track in asp.net core we'll look at a a nice little uh nuget package exponent code diagnostics health checks uh which kind of like helps in adding dependency checks and things and also we look at health check ui which is a dashboard that you can build in.net itself uh for creating that health monitoring system right all right let's look at that one um so i'm going to open my terminal let's okay this is my micro services project and you can see that like i have more than one service so there's a front end there is a back-end so back-end services i mean if you have uh seen our previous talk it's just the weather service which basically uh gives you some weather data all right let's let's run this for the matter let's say i'll do a tie run um are you using kai nowadays it's become so easy for me yeah i'm a big fan of tai for sure um particularly now since i don't have to write any docker files i could just tie around and it just does it for me i love that exactly so it gives you this nice dashboard as well so it kind of tells you like okay what are the services that's running you can go into the logs of it and it also gives you this port like automatic ports uh in your code so you don't have to like really hard code these things uh so let's go to the weather so it's a static weather data you can see that and if you refresh it uh it just refreshes some um you know random data in there right so it's very simple so let's uh we're technically not writing a microservice we're just writing simple web apis to show you know multiple services there and how do you go and implement health check one other thing i want to show you is this web status app and this is an app that is written in asp.net asp.net with just five or six lines of code and that's all it's just you create an asp.net uh web api uh or even an empty app project and then just write five lines of code and you get this entire dashboard and if you look at this dashboard it actually tells you uh what does health mean right so there is a self if the front end has a self health check which is which itself is saying whether it's healthy or not but it also is depending on on a back in service because if it has to complete a task it has to connect with the backend it is also doing its uh it's a it's another check right in terms of backend if you look at there's a self uh but then backend does not depend on anything so it is healthy but this is where we are going to implement something new here which is like we will go and implement uh a code uh which is will implement caching like bringing in the redis cache into the back end and kind of like you know instead of every time you sending send a random value you probably want to wait for five seconds and and and send them a new value that is you implement a cache right so for that i'm here at weather forecast controller uh i'm good what i'm going to do is the demo tricks is just uh uncommenting quotes that you know it's going to work and uh and commenting codes that so that's a simple thing so um that's all i did now what it does is actually it's it's actually injecting an eye distributed cache for which i have configured redis uh connection string already in the program.cs and um and then we look at this activity this is part of the distributed tracing we'll look at that later i'm using some loggings and things like that which is fine i'm also using some kind of some sort of a feature manager which basically is like if i'm running in production um i want to see if i want to connect to an external weather api that means i'm not sending him sending the user with any kind of random dummy data instead i'm actually connecting to a real weather uh api that is using the azure uh side of things right so and then so this is where the feature manager that i want to get to at some point and then i have the static data basically static data is the one which is getting some random data it should be here yeah let's go that's just a random data out there right and then we have this cache cache works for five seconds and then it just refreshes right now that i have done this now this has a dependency right i need to write this cache uh so i need to first thing i need to do is i need to make sure the tie knows that i need to run a reddish image or create a container for it so i'm going to uncomment this code so that means when i run the thai run it will also bring in the redis and i also have the connection string configured so i'm all good to go like if i just run it it should just uh you know send send in values from the cache which is fine but the next thing that i need to do is because this is a depend there's a dependency on my health of my system right now i need to go and configure the health check there right let's go do that excuse me so here are the two endpoints that i talked about so this is uh the we're using the asp.net health check implementation we there's uh endpoint that you can create call with using map health checks so i'm using a head cn point so this is basically the readiness probe which means like you know at what point do i tell uh that i'm ready to accept traffic all right and then this is a liveness probe and the liveness probe is basically uh telling you know i'm a live signal so these each of it has its own uh uh you know representation of it so let's uh let's uh let's get into this um you know uh there's an important thing that i need to show you this is this one and health check so you basically add health check first so basically you implement i health check so i helps can i help skin in the high sorry i health check uh okay i will have a method which where you will kind of define what does health healthy mean right in this case the for it to be healthy we were until now we were just using self which is basically if you're just hitting uh the end point liveness it is just going to respond with with self sorry with the healthy endpoint which is which is actually configured in this predicate we just say okay pull out all the health check that are configured with the name self and if that is there then we are healthy right so that will respond back with healthy but now we're going to add um ready so you can see that i'm just going to use dot add radish and you'll be wondering what does that even mean like you know how does the system know what address means right so what i'm doing is uh to instead of i imp instead of me implementing the eye health check to define what uh you know connecting to radish is healthy like to define what that means instead of that i'm using an external library called the asp.net core diagnostic health checks this is from zebral and it's it's really nice library so it has all the health checks implemented for um for each of the things that you probably will be working with like in a cosmos db document mysql sql server right so like for example you know in this case we are talking about redis but we can quickly go into this sql server one you have the sql server health check you can see that there's an eye health check implementation uh it has this method called check health async given by.net but then you define what healthy status means basically if you're able to make a connection to it that means you're healthy right so when you're when you're creating this connection you probably want to have a really really simple sql uh statement like something like select one right that should be good enough because you want to be quick in responding so similarly this one has um let's go back and see what does the reddish uh health check look like so this one that is health check so you can see that there's a check health sync method and it basically makes a connection ping and then as long as it's working and there's no exceptions uh it seems to be healthy right so but in in case of my.net code i just had to add redis and just configure a tag name to it and then say uh you know if that if i'm able to make the connection uh that means i'm good to go right so that's basically that that means that in your in your back end code right so in your cs project for your backend project um i know asp.net core like what we ship as microsoft we have a health checks package but what you just showed was like um a community-run collection of additional packages with product specific health checks so there's like you said there's a a specific check for redis and there's a specific check for sql server and cosmos and etc etc etc so to get that i could either go on nougat or i could you know in visual studio i can install that but that's not like something that's in the box by default i have to like go and get it correct and bring it right all right and and and that also like you know when you're building systems and you probably have a legacy system that you which you depend on in that case you can actually go and implement a health check and write your own right for all the popular ones for the cloud native ones and things uh various libraries to help you with that right cool all right let's uh let's go and uh get to the dashboard so multiple monitors this is an issue and you get too many things to look at yeah too many browsers and i kind of get lost in this uh all right so now we're going to the web status and uh if you look at the web status and you can see this back end and quite easily now it has this radius check and it tells you that it's healthy right i can probably delete the thing and it'll it'll show you that it's not healthy but then it will be cascading off uh the failures like for example because front end is depending on back in backhand is depending on this one and you'll see this uh thing right now what you see here this is the health check ui thing this is the web status project i'll just quickly show you that one too uh it is basically if you it's again from xavier lis itself so if you go to the web status project if you go to the cs proj all that i'm doing is asp.net core health checks ui and just adding it and because i'm just using it local so i'm using an in memory storage for storing all those you know health check informations and things like that okay and then if i go into the startup.cs it's it says add health checks ui and basically now looking at the end points right in this case i'm looking at the hcn point which basically is the readiness probe that we will configure in kubernetes later on but for this web status i need to know because this is a dashboard that i'm building i need to know all the dependencies too so and that's why it makes it easier for me to just kind of like have a endpoint that will tell all the dependencies so as well so that's about it that's that's all you need to write in there and just map the uh you know health checks ui path where you want to show that and and the whole dashboard that you saw it just magically comes up uh and you can actually go and customize the styling and make it look like your own health check and that kind of thing so this is a pretty neat trick so that was easy right yeah that was pretty good and i i love the fact that in this particular app that you're showing right now that it makes me feel like i can aggregate health checks from across services so i don't have to have dui in every single micro service i can have a a monitoring app of some sort right and i can have the ui in there but then i can point it to like these different endpoints and then now it will just aggregate that information right you can go to those different services pull in those health checks and i can see it in one consolidated view about let me know like you know what's going on and how things are going that's correct and the important thing to remember is these endpoints have to be reachable by these implementations for example uh if you're deploying this to kubernetes the service discovery within kubernetes have to kind of like be able to reach there right so that that is something which you need to be aware of nice okay okay so that was about health checks and let's move on because we have a lot more to be talking about uh let's talk about logging logging right so talking about logging i mean uh believe it you know the truth lies in the logs okay so no matter what tooling you use if you want to get to the you know problem it's always in the logging and that's why you need some tool sets to kind of like build some better logging for example like um look at this one it has um there's an exception called system.net.sockets.soccerexception which is great but uh you may you may as a you know developer you may be looking at okay i can look at the call stack and probably figure out where exactly the exception is that's correct but think of it in hundreds of different services and hundreds of different uh application that it will work with right so wouldn't it be nice if the logs had some more information for example in this case i'm actually showing you uh some things like you know what environment it is running on it's a dev environment okay what requires path and things but this is fine i mean this is something which you're getting it by default uh with some sort of uh tooling with distributed tracing and other things but you know logs can have more information i um i did not add those information here because i obviously didn't want to complicate these things but it could have information like for example what runtime am i running in or what git commit was used to deploy this to production or for example what team is working on this right so you have hundreds of services and you have socket exception happening on one of the services or let's forget the socket section so your second exception is something straightforward to properly figure out uh from the thing but it could be some kind of business exception where you will probably have certain coupon code that when you're using an e-commerce application for a certain region it is throwing an exception and how do you kind of trace it back right so then you want to log some more information into the logs so that you get to the bottom of this information and that capability needs to be there in the logging tools that you're going to build yeah and you know i always when i would talk to younger developers like people just getting started in career i always tell them logging and exception handling are two of the most underrated skills as a developer very very underrated um and i say that because you know it's all good and dandy when things are working well but when they're not working so well how do you figure it out where do you look how do you solve the problem how do you deal with you know issues that you weren't expecting and that's why i always think logging is such it's almost like an art too to in a sense because at the same time you don't want to have logs littered across every other method of your code right because then you'll be writing a login application you'll be doing more logging in business logic but at the same time too you want to have enough that'll give you context right so it's like as logs come in i want to know what's um i don't know what happened but i also might want to know what happened just before or if possible what happened just after so that now i can kind of get an understanding about like the path that my code took to see these types of things right and that's and then that's one of the things for me why i think logging is important absolutely and you rightly said you need to log enough to get get to the bottom but uh you shouldn't log something like pii or sensitive information you need to be very very careful in what you log and how if you're logging something like that you need to be aware of how many days you can retain it and kind of like work with the tools to make sure that you know you don't uh retain things that you shouldn't be retaining for a long time right sure um so yeah as you as you likely said i mean as i mentioned earlier as well you know the the truth lies in the log so you need to know how to go to the bottom of it so you need to have those skills and i love those skills i mean and that's a good way to learn as you likely said you know for the the new developers the right place to start is actually start exploring logs and start debugging things and that's when you learn a lot more about the application than you will learn from just reading the code right so um when you talk about logging and now let's talk in terms of you know distributed applications and there are three three things that is very important uh one is you need to have a structured logging i mean text-based logging kind of doesn't work really because the text is lost in the in the in the noise right but when you write structured logging it's easier to kind of systems to probe and you can kind of like make meaningful uh meaningful decisions about it and i'll show you and this is something that you might have to write in the dot in the code it doesn't have to be dotnet could be any code you need to write structure logging so that you can retrieve it later and similarly now that the we the vms are many the nodes are many the controllers are many the the uh pods are many the services are many you know when it happens that way you need you can't have you literally can't go to a physical box to check uh on the logs the one of those is the rolling file systems and other kind of things now it's all about having a centralized database or having some sort of collector and then you actually ingest all the logs in there and that also means you have to go and you should be able to search and correlate them and that's a key important aspect right how do you correlate between one thing to another thing so that you can make sense of those uh logs that were put in like you know if you really just generally go and go to the centralized database and try to search for information it's you find so much of noise so yeah again it's another skill to kind of relate and kind of make uh sense of uh the situation there all right so let's look at these things in demo one is structured logging in.net using city lock and for the sake of time i will be avoiding writing any sort of code from now on and i'll show you the implementation part where what has been done and you can uh we'll share the the demo with you later on so that you know you yourself can go and check it out and also we look at centralized log with two collectors or two extractors aggregators sec and azure monitor as well right so let's go look at the code for where the uh implementation of structure logging happens right uh so if we go to the program.css okay i'm in the right wrong one let's go to the backend and then while you're looking around we did have a question coming from youtube that i think is related and we could talk to really quickly and carol from youtube is asking isn't centralized db breaking the micro servers pattern um so what do you what are your thoughts about that one yeah that's a great question and uh centralized database with respect to business will actually uh break the pattern but this is not about this is more from the infrastructure angle you're actually looking at the distributed trace even for some reason the trace is not up the database is down down you will you will not be able to reach the system that's about it but your businesses will not fail right so think of it in that way so um you know you when you use some kind of systems behind the scenes like um like a central uh log collector that would be uh easier for you to kind of phrase the information because you have to look at it from a holistic angle and not from a single uh particular uh information otherwise if it's not in one place it will be easy difficult to code it and figure these things out right so yeah for sure yeah like the business logic can definitely be siloed as as necessary but again when you when you look at trying to solve problems i need to know what happened across the board versus just in one place and again that's at some time centralization of things is a good thing yeah uh yeah i mean there are also debates happening about monolithic is the still right way to do it and other kind of things for the simplicity and things like that all right let's uh let's go into the logging thing right right so let's talk about logging um cecil do you want to a little bit explain about the net logging system so that i can take it from there sure so i believe it was whenever dot net core first started um so this is a couple years ago you know they introduced a lot of interesting abstractions to the framework so di being one configuration being one but then logging being another one of those things uh and i always thought that was great right because if you look at the ecosystem there was always so many different things to log right like there was yep you know serilog was always there there was log for net that was there um there was there was a s there was there's a whole bunch of them right there's tons of different things that do logging um but that means that every time you wrote your application you had to like rethink and i had to reinstall a nuget package and i had to configure this thing and so on and so forth and you didn't really get maximum reusability sometimes and it would also mean too that like the framework code and then your code might be using completely different loggers right um so in the effort to one with asp.net being cross-platform now um because a lot of people still don't know that it runs on windows linux and mac and with it also being cross-platform and open source and needing to be able to capture information across these these systems you know we can't just log to the windows event store like we're doing before right we have to consider a wide range of options so now we have like you know the built-in logging abstractions which gives us tons of great options for doing structured logging like like you were speaking to not too long ago but then also too being able to plug in different logging targets so targets being i want to log to the console i want to log to an in-memory thing i want to log to the database or file or whatever the case is but now the abstraction is consistent right like meaning like i don't have to you know the way that i log an info message or fatal or error or a trace message is still the same it's consistent from an api perspective and then now i just as i create my logger i just need to you know figure out like what are the actual targets that i need to send them to right right right and and what we're doing with the city log in this case actually we are actually plugging it into the existing system so there's nothing additional that you need to do and uh what to explain structure logging better again lost in the browser i want to show you the serilog website itself which kind of explains it in a much nicer way for example if you have the position uh with some sort of uh you know object uh which has more information like latitude longitude and then when you do the logging information you know you can actually put that entire object into the log in this format and it will completely serialize them and give you this more key value pairs when you log so which which means that now i can actually go and uh query okay what were the you know responses that were given uh when we queried a particular endpoint with latitude 25 right so you can kind of like come up with these kind of questions and then uh the logs can uh give you more information about uh those things right so um so that's that's the uh that's a very very uh starting point of understanding structured logging uh so we're just gonna use seleg again it's a nuclear package you add it to that add it to your project and then you configure them and uh here in this case i'm actually configure uh you know one is about structured logging and the other is about where do you want to see it like you know you need some sort of aggregator to see the entire logs in one place and i'm using uh two of them one is the application insights which is azure based and you can actually monitor those things there using azure monitor the other is in again an um you know open source uh i'm not sure if it's open source but it's free for personal use and they also have commercial offering called sec as well or seek and and basically i'm configuring these two of this and i'm also writing it to the console as well right so in the weather controller if you look at when i was retrieving the weather i did one more thing is uh i'm logging the entire weather information here right just to just to show you that you know hey here's the object that came in uh sorry here's the data that came into this object from whatever query that i made but i'm actually logging that entirely into the into the log because i'm using structure logging right now that that is done i can go and search probe this information for example i can um let's go to the uh um where are my dashboard let's see let's refresh this so this is my dashboard so you can see that i'm also using sec here so i can go into the sec so before going there we can do because now now that we have actually made one okay we don't have it here so let's go back and go to the front end and refresh this page let's go back to the dashboard um and go to the backend code view and you can see that it's we also said write to console you can see that the entire data is also written in the console now in console it may not make sense to kind of like query this data but i can actually query this data based on okay i want to know uh how many times maybe a mile temperature was sent right so i can just copy that mild thing and go to some curry like the sac uh which i need to go back here and go to the sync and here you can see this whole bunch of information that's getting logged i can see this mile so now you can see that i'm able to make uh get into the more details of this information right so it just goes into and you can see that you know there are it's not only logging just the data it's also logging with some kind of action id there's a trace id there's a request id um you know because this is a demo data you probably may not make sense but in a business transaction you probably will have some more information to kind of like make more sense of it like for example okay i want to know what is this count by value how many applications have uh worked on it right so we can see that you know charts and other things which is uh which gives you this nice dashboard of configuring and things like that so that's pretty cool so from my understanding structured login is almost like logging a dictionary right like there's key value pairs so i don't just get a string of text but i get again that that contextual information and because you know that contextual information that dictionary has made it structured i cannot issue queries against this again like you're saying hey if i logs the correlation id right i can say hey give me all of the requests that match or give me all of the events that match this correlation id and now i could you know based on the car like correlation id and maybe the time stamp i could watch the flow of information from top to bottom and i could see exactly what happened yeah so that that you also actually touched upon a brief aspect of distributed tracing to understand the trace of the entire information as well right yeah you get those kind of information as well so let's um let's look at uh one more thing over here in terms of logging i'm actually you saw that i was actually logging into the you know the log application in size as well so which where i can query here so for for just get to this one i'm what i did is i used tie deploy and actually i have deployed this to my kubernetes uh so you're running like a local kubernetes cluster now this is running in aks right now so this is configured in my aks so let's put forward this so that we can get to this uh using front end 9001 which is fine and i'm putting forwarding to 80 and you can see that all of these webster is a sack reddish and all those things is all there uh but let's go into localhost um 9001 and now it's actually you can see that you know this one is actually working with the azure weather data which has this information like seattle london weather so these are real information these are not uh dummy data right because as i deployed the production i enable the feature to work with this one right so now i can just go copy this one let's say the all the summary that were cloudy and go into my login sites and search for that one right so uh and a bit of time probably yeah there you go so now we're going to go into this you can see that you know it gives me this whole trace of information but the interesting thing is if you hit on this view or in logs uh it will also give you this nice custom query for you to kind of like execute this right oh yeah and yeah so you will get more information you can actually configure some more things for example in real data when you're working with multiple services probably you had a production you you want to ship a beta feature and you really want to understand how many people are using those features and how many are using certain things or how many exceptions are happening and things like that you can you can kind of like trace back in those instances for example you can see that this one also gives you those information which uh cloud roll instance was running it um you know what um other levels like you know the client type who how it reached and also there's custom dimensions that which is nothing but the data that gets locked here right also all the trace ids and other things which we actually captured we saw it in the sec it has the similar things that is also being logged in so just by writing that you know from the city log we're just adding a sync saying okay go and lock this application inside we get a ton of information already on this uh you know azure monitor site and and those you were asking about why would we want to you know centralize db uh yeah it is going to be difficult to maintain if you were doing it yourself but then if you look for some cloud managed services that's when uh things get better and it'll give you you can you have this whole range of tools that you can uh use it to you know kind of make your applications better right and then so we're looking at this right now it's inside of is inside of azure monitor right so that i can i keep i keep wanting to call it application insights it's inside of that monitor and the language you're using right the query language you're using is actually called cousteau so that's k-u-s-t-o right and so using crystal and i think you could use coastal and some other parts of azure as well outside of azure monitor but again you could use that to query events and inspect logs and and really dig into that structured data so again you showed an example of showing charts and graphs and things of that nature so oh yeah that's not for me yeah it kind of sounds for me like i could use seek or i don't know your log aggregation tool of choice locally um if i wanted to um and if i'm running on premises like those are great options but now when i move to the cloud and using azure i should be able to point to that as well but hopefully i could do that without a lot of interruption to my code which kind of goes and plays into the point of hey we have a very structured consistent api model for doing logging now we just have to change the target right and once the targets change the rest of our application code doesn't need to change it's already instrumented for that correct correct and i feel like explaining a lot more in this dashboard because there's too many things here but we'll just get back to the yeah yeah presentation and connect so more stuffs uh which are really cool um you know uh you probably would have seen something called as tracing that i was denying to touch there at that point of time and that's because i wanted to get to explain this right before we go into that and that is about distributed trace and it is also called as distributed request racing which is me from the point of initiation of a request to the entire life cycle of that particular uh trace you need to get the whole information and that information probably need to know for you you need to know probably you know how many how many times how many seconds is this taking some of the services that may take longer than that and then a few other things like you know you have a new method that is introduced and then you want to understand how how is that method performing so you need to get those information right so this is this is technically understanding from a holistic view you have the entire cloud a lot of services a lot of things that is coming together to work together but you want to get to the entire information and you want to get deeper into these things right so that's where distributed tracing comes into picture and with azure monitor um that's baked in uh so you will get those information there if you especially especially specifically if you're using application insights uh it has those built-in mechanic mechanisms to instrument your code so it gives you those information right there but you can also use uh things like zipkin and other things as well uh which is what we will look at in a bit uh to just understand this better i want to touch upon two important things i mean there are a couple of more things about tracing one is what trace really mean it's just basically the end to end request tracing and every trace is unique because it has a trace id and that id is technically added to the header and just flows through it doesn't matter what you call under the hood those entire crease already have to flow through it right and similarly there's something called a span and span is basically a unit it's the smallest unit of one of your tasks like it may be a method call it maybe something you're calling to a messaging queue uh or any other external dependencies right so that will have a unique span id and the span will have parents as well like you'll have children so you can connect back using parent id you will have multiple maybe one at one point you will you are connecting two different uh services that means they go parallel that means they will have different span ids but they will have a single parent id which is this vanity that initiated it right so something like that so when you when i talk about all these things one thing you probably will be realizing there are number of cloud tools out there right so how do we standardize there and that's where specifications like open telemetry comes into picture and as cesar showed you in the start of the uh you know and for this show we we talked about the open telemetry sort of actually wrote about the open telemetry being version uh you know 1.0 and i think cecil you should actually get him on to explain more about open telemetry because uh i got into this when he pinged me and told me about you know how we can uh bring the eshop on contains one of the popular reference samples and enable open telemetry to it and that's when i looked at and i thought like okay this is a good time to actually bring in that uh into our demo so i wrote that uh completely newly uh on this one and uh technically open telemetry uh is two things uh coming together there were open formats like open tracing and open sensors uh open tracing is more like an api and uh open uh which is the all the uh you know people who are consuming code as well as writing libraries uh they write it by defining well defined uh you know based on specific specs and open senses has been used by google for a very long time uh and it actually has more implementation side of things like the libraries and other sdks and things right so technically they're all specs so when you follow this open telemetry when this logging and tracing happens they are followed by a certain standard so that means it is vendor neutral you can have a.net application and node.js application connecting with each other but this entire trace can flow through without an issue because both of them will implement this open telemetry right and similarly if you want to go from one from a when one vendor to another vendor for you know collecting the trace or you're kind of like seeing the dashboards and things it can work with anything right so you basically define that very clearly uh in the approach uh so let's look at open telemetry api in.net and we'll look at zipkin and azure monitor as well right sure let's go all right so uh open telemetry now that we are in the trades i just want to quickly show you this trace thing so you can see this is the end to end transaction details and right now we i don't i did not log anything meaningful here so that's where you're seeing all these things here but when you log something meaningful you can actually do a lot more things right for example um let's go to this one so this is the http so this is the outside code that is actually going out now i can click on this show what happened before and after this dependency and user flows and it kind of like gives you that graph of those information how they came in the index page and the weather forecast uh get method and think now think of it in hundreds of different flows out there so you kind of understand how the user is like navigating through your application and what services were being called and kind of things right so and a lot more information that you can actually add it to these trays right so um [Music] okay so this is uh distributed tracing uh i'm pretty sure i'm forgetting a few things that were pretty cool uh which were part of the azure monitor which i'm probably gonna show you okay let's have a look can you do like the app map thing oh yeah yeah yeah that's pretty that's pretty much it application map so there you go so now we have this application map it tells you about like what are the things that we're connecting with uh so there's a back end um there is also this is the api that we were calling that we were making the external calls to it and uh it's pretty um unique actually you know what let's try something new um so don't blame me if this fails but i have no worries we don't know you're responsible for any any code that gets termed in this this demo yeah so this is pretty much the last part of it so i think we can just try on something so what i'm trying to do is i'm actually trying to delete the delete pod and i'll delete this back in for just for the sake of seeing how the failures happen and how this is being traced back so so you know that kubernetes when you delete a part because it has to stay true to the configuration that you set with it so it will bring back the part alive back in no time but there will be a fraction of seconds where the part will go down and i need to make sure i need to make a request there at that time refresh this let's see i think it would have let's do that again which would be uh between your number i see and again let's do this um okay exception yes that's what i wanted and let's go back to the application map refresh probably and see that record oh there you go so it basically had an exception at the zipkin level i think uh but the back end seems to be fine and that's because it probably oh yeah there you go it takes a bit of time but it actually comes into the picture so you can see that you know there was faulted there were cancellations and you can actually now go and investigate failures like what exactly happened and um this should give you more information as well when it comes up right sir yeah so you know now now put this in perspective like with hundreds of uh of services coming together to make your application run right all right so so and you've got to believe me that that will come up and you will have money all right um so now let me show you one more thing let's go back today i also love how much detail application insights gives us like you could really drill into you know all the way down to you know the log and the exception and all that and then it goes all the way back the other way and gives me that high level of view of well what are the different applications that are making up this thing um so regardless of whatever type of information you need you can start up higher then you can drill down lower and early understand it correct right so now if you look at this one now i'm i'm i'm using zip key it's another uh in open source um you know a nice uh dashboard um so if you run this query basically go back to front and lets me just refresh it so that i get the right data refresh this is again on this query and so you can see that you know right now if you look at this thing uh so it gives you this trace of each of it and now you see this interesting aspect there's a weather forecast that was called and uh then there was this 307 redirect and the very next request was uh the weather forecast itself and that's something strange right if you go inside if it was a http colon call but if you go to this one it's a https thing so it basically traced that redirection that we actually had put in dotnet and now uh you can actually i mean you can get more meaningful information in real time but this is a good point to understand you know okay now i can fix that i can optimize further optimize to go and fix this to have direct https calls and not do the http code and calls right uh so and and similarly just just like how you saw it another one it also you get this kind of dashboard for understanding dependencies and things right yeah and what does it take to have these things in place right then that's what we need to look at next which is basically if you go into the um startup.dscs i'm actually adding this application insides telemetry um and also the open telemetry configuration you can see this add open telemetry tracing so this is what configures the open telemetry and in this case i'm actually using a zipkin exporter you can use any exporter jager or anything that is azure i think that's one is in preview right now but you can use any of those exporters as well right so and adding all the instrumentation also kind of like automatically whatever you saw related to the.net and that kind of things it is all the application insights and other things which is doing the magic inside it and if you want to write something more custom then you can actually write this one this is what i was talking about earlier using activity activity source.startactivity and uh yeah i was wondering about that like what is because that doesn't i don't see a log statement i see an activity and so that's that's a little different to me so i was kind of curious what role does the activity play in my distributed tracing right so by default if you just go to the startup.cs i think oh wait the main method is in the program.cs right if you just define activity default id format dot w3c all those dot net code that is under the hood will actually participate in the tracing so all those uh you know tracing rate information uh that is getting generated based on the open tracing api uh it will all be done there now remember i talked about that everything has a trace id and then you can actually have your own span ids so this in in in.net world activity can be related to a span okay so when you do a start id it basically creates that span id for you and then that becomes the context of information for what you're going to do so in this case we are actually making an external weather call which is an external weather api so we i want to have that in a span right so that's why we're doing that okay so now when we make these external calls so i'm guessing i'm using stuff like um like a grpc thing or i'm using http client once i set that activity and i'm guessing once i configure some things in startup that's cs do my external http client calls just automatically get captured and and become a part of the trace or do i have to do something else with http client to get that to work um like for example like if it's totally external even though these tray settings and all gets cascaded into it but you won't be able to get it because you can't collect what happened the other side of things sure sure but within your internal systems you can and the way it works is yeah it works on the http headers right you add all this information in the headers and that makes sense and then another question really quick from some folks so in your startup.cs again you did show the application insights um telemetry configuration do you have to do you still have to add that or do you so i guess i guess the question is so we have open telemetry we have application insights does can i just use open telemetry to point to application insights or do i still need both of those you need both of those so one is doing distributed tracing the other is logging information right you probably will have those log related ones but tracing related ones are like it has more information related to the code that you're using the other sdks that you probably are using even live manufacturers we can actually instrument the code to you know implement open tracing so you get all those kind of information added in uh when you use that one got it okay and then one more question really quick and i know this guy's been trying to get this question in for a while um the person's asking if we choose to log into app insights how can we mass sensitive data from blogs like remove customer information i don't know the answer to that probably we need to check the app and sites and see if there is any kind of like uh logging some sort of sensitive data and that kind of things but um yeah i know by default application insights would not capture certain things so you know um like ip addresses for instance like that's considered pii and those types of things um if you do it yourself you know like if you intentionally add it to your logs um you know that's that's kind of up to your discretion right like i don't think there's any intelligent filter or machine learning thing at this point that could look and say oh hey niche is logging an ip address or niche is logging a password or whatever like all it's it's a dictionary right it's key value appears and so um if you don't want it log you shouldn't put it in there um but again that doesn't stop other people from doing it so i don't think i don't think there's a way that you could specifically do that um but yeah i think i think it's just one of those you know you gotta you gotta you know you got a knife you gotta try not to cut yourself right so how are we doing with the time by the way uh we got a couple more minutes we have a few minutes we could we can hang out for a little bit okay so let's uh um lost in the browser sorry um where are we yeah so here i want to show you one more thing let's go to the aks i wanna show you the metrics basically so we have this uh container uh because we are running an aks and we also have those other metrics in in there uh so let's look at that one just to make sure that so there you go so this is the metrics that you get directly from your ikea so uh technically when you relate all these things together you can make more sense of what it all means right so now in this case we have this nodes running so we i only probably have only one node to work with and then i have like a lot more containers you can actually see the containers um that are working on here and get into the more details of it like you know uh what is the creation time and how much cpu limits if your requests and things are using and over a period of time you can kind of like take a look at it um like you know how performance uh how about things with performance and uh based on situations like okay you may need more um maybe more nodes to kind of like scale up and uh you can make those decisions and kind of configures alerts and all kind of things right so um i i'm pretty sure there's a lot to be talked about here but then um you know there is enough documentation out there to just get to those information that you want quickly right so like for example like for this is a very fairly simple application but we can kind of like build these dashboards out here and kind of look at like okay here's the raw apis and the other sort of information uh that kind of built in to kind of like you know run this uh application in real time got it all right now let's look at the uh the feature manager and the reason why i want to talk about that very quickly uh is um i mean centralized now that when you when you're having this whole world of distribution uh you want to configure something uh you don't want to keep the configurations in local instead you want to work with something like a centralized configuration so that no matter which part it which comes up and you know the services going up and down or things it can actually go for centralized configuration and look for what information that it needs to work with for example um and um there is also feature manager as well like you know whenever you want to uh deploy something to production but you are your you want to enable a feature on a certain time or certain region or certain set of people right so then you can actually use something called as feature management which actually depends on the configuration on the centralized configuration and then you can you know toggle those things for example in this case i have this weather data you can see this i'm using the the data which is actually going and hitting the real api but in the real time i can actually toggle this uh using this simple switch here which is the static weather api uh once i toggle this and if i just go and refresh this now i don't i'm using the static data back again on live i basically change a running production application and if i want to do some testing kind of things i can put all those things and and and i did not write a code uh to do any sort of deployments and other kind of things for just to test this thing right so this is really really handy feature one of the patterns are key features that you can probably make use of in the distributed world is to have a centralized configuration and you can uh use them like this right so this is what we i showed earlier where in this scenario where we had this feature manager that is enabled sync this is what looks for that information right and then configures and you saw that you know the ui also was toggling and that's because we have this nice uh uh uh razor component out there which actually has this so when the feature name manage feature feature is configured whether api it puts all those you know select options uh and then if it is the other one it just puts in some static data so you can see that how you can toggle these things in real time also baking this code and checking run it in production it's all it's just going to be the configuration changes and yeah i wish we had more time to talk about these things but then but you know i'm such a big fan of of the feature management stuff and early on i was one of those folks that was like uh why do we need this i don't see what the point is because if i wanted to change the behavior i used to do with like the environment settings so you know in asp.net core you have i think it's called i host environment or iweb host environment or something of that sort yeah and then i would check and i would see well i would have am i in production or am i in development and then i used to have additional environments i sometimes i do a thai environment or a containers environment or you know whatever the case is right and i would feature toggle that way but then like i like what you mentioned before when you're in this world of distributed systems now it's not just about like me and my single app now it's about like the collection right and things that we want to have across the board and how do i how do i reset all the services at the same time so that they're using the same feature or the same feature flag or the same feature toggle because features can span multiple services and not just one service you know what i mean um and so now i'm a big fan of i'm a big fan of feature management right now um i really love those asp.net core um components that you showed a little while yeah this makes it even so much easier and another thing too that i didn't realize but you know maybe some folks that are watching may not have realized that as well the feature management um package you know you actually you don't need azure for it right like you can just run it locally and you can configure it with a file or you can configure it with the feature management service that's in azure so again you have options to pick and choose how you want to to do these things and build your micro services correct and as you likely said feature manager is two different things like you know feature manager just toggles it like it gives you those entire infrastructure in place to kind of like toggle the things but that's when you put into centralized configuration that's when it makes more sense because now you're not configuring it through the configs files anymore you're configuring at the central point and then regardless of kubernetes throwing your pods around and other things and the feature is active for any service as you rightly said it can be multiple services too which will use the same feature yeah yeah exactly exactly exactly so what else what else you got first niche um so i think this is something that you'll hear for the first time on this show you're breaking news like what do we get yeah so it's where do you learn all these things right wouldn't it be nice to have some some kind of page in which you can actually learn everything in one place so now we have this brand new page called cloud native and micro services if you click on this right and so this is on the net website so if i go to the.net website and i click on learn right go down and here it is cloud native and micro services nice click one there is one and then there is like a lot of other things like you know microservices hands-on modules uh actually you can click on this one let's see um so once you go inside this one whatever i talk today instrumenting at cloudnativeasp.net core microservices start with this and it talks about sex serilog and you're going to actually do a hands-on coding on this and it is all going to be run behind the scenes inside the azure kubernetes services so you don't have to come with any installation don't even come with a pc just come with a ipad sit on a coffee table and there's you know you can execute this code so that's you can do that that's something and yeah and also feature flags like you know i literally showed up a lightning uh thing of feature flags but i think there's a lot more to that so you can actually go and look at that those information out here so really great places to get started and have more information um so there is there are also architecture guidances and there's like bunch of ebooks you can exactly for example like if you want to understand more about architecting cloud native apps right you can go here and say click on download pdf and then there you go there is a pdf no no information no no name new email id and no contact information and all that you need to do is just click on the download pdf and then you have this really amazing book that you can read it at your convenience and you know every time i go to that architecture guidance page there's just so many books and there's so many books and they're all for free you know i don't have to put in my email address i don't have to give you my phone number or my firstborn child i could just i could just download the ebook and it's fantastic um yeah so i think it's a great resource for people that maybe you want more detailed information about deploying things or maybe you just want to get started maybe you want to learn about dapper maybe you want to learn about the kubernetes or docker or whatever the case is tons of great stuff and it's all for free and all you have to do is head over to the.net website and click on that little learn item at the top of the menu and then um you'll be on your way yep that's perfect um so we can take questions now or uh sure we did have a couple questions i'm gonna do a couple before we we turn off um so uh this one's coming from youtube and this person is asking nish can you tell us if you have any suggestions about the api gateway structure so i'm guessing do you have thoughts about how it's used how to use it maybe one of these ebooks talks about it as well maybe right uh if you come here and search for eshop uh you show up on containers this is a reference sample you click on this this is the very popular sample on microservices implementation and here we do have implementation of how to use api gateways and also while we talk about api gateways there is also implementation like back and forth and pattern which is like if you have mobile applications you have web applications you want to have separate aggregation for each of it you can actually implement those gateways and things like that for eshop actually you know uh we used to use opsilot for a very long time uh we have used oscillator as an api gateway but there was a time when we had to move all the internal communication to grpc so all the service to service communications are on grpc which is mostly the aggregator and ocelot did not have that support at that time and we looked at it and we said like okay for for now api gateway we are not using any of the other api gateway features so what we're going to do is we're going to use online proxy which does nice configurations for path three directions and other things and we also handed the service mesh implementation that was coming on top of it which is using link id so because of that we we standardize on having on the proxy it doesn't have a lot of api gateway uh implementations but it did definitely have good routings and things and the aggregators are basically written uh in the in the net code itself so take a look at that and it has more information on the api gateways and i know we have we also have a reverse proxy right we have something called yarp um you're still pretty fresh like it's still in development but uh it'll be interesting to see if in some future version of of what we're showing here if you know we can see how europe can plug into some of these architectures yeah i think i think we can replace it online proxy and then put any up there and uh it's it's it's uh it's it's i think it's it's actually focused on building uh making performances higher performances for the azure implementations and that kind of things yeah so i think we would definitely use something like that when it won itself out awesome awesome awesome all right let me scroll through i believe we did have a few more questions let me see what folks are asking about um we got that one let's see someone's asking of the browser please name name of the browser used this one this is edge this is oh you're using the vertical tabs in edge people a lot of people don't really know about that this is so cool you know if you have especially if you have a large real estate in terms of monitors it just makes it easier and i'm just making it easier because i need to read so the moment you go like this i literally can't like if you have more tabs you'll only see these icons and i can't see what exactly that means so yeah i think the usability of the site tabs helps and you know i notice i have less tabs open when i use the site tabs for some reason i feel like i need to close them when they're at the top i kind of just ignore them but i don't know maybe maybe that's just my psychology but that that definitely happens for me yeah it's the same with me like if you have more than certain tabs i feel like closing the entire browser and just coming back to yeah exactly uh we got one question that came in earlier and this was about the health checks um ui that you showed earlier now the person's asking i'm curious if the dashboard for health checks can be customized i'm guessing that means like if you could you know update the user experience and you know maybe probably brand it or you know change the layout and things of that nature yeah i know for sure as changing the branding is possible like you can just go and change the siteman css and then change make the look and feel of it add your images and things but how much of the other customization i'm not very sure like i mean you can go to it it's an open source project so go to the health checks ui project from zebra and you probably can see the code uh to see how much of customization you can you can do on that one all right um this person is asking got a url for that image and stuff image um i'm guessing i'm guessing he's talking about the eshop and containers one the one that you're sharing right now so that one's on github right yes yep this is here github.net architecture so that's the url so github.com.net architecture so i'll i'll make sure that folks in the chat get that really quickly sparky texture and then it's just eshop on containers right correct that's okay all right pasting that in the chat right now you also have eshop on dapper now it's pretty cool like it it actually shows how much of code that we actually you know uh removed from eshop and containers when we move to the rapper yeah yeah um all right so i think i think that's about it i think that's those are all the questions um okay so nish hey thank you again every time you come on you come with like some really great demos and i really appreciate um you know all the cool information um i know people are gonna ask me where are the demos where can where can they get where can they get your stuff um yeah so where what what what should i tell them oh yes it's uh so this is i i will add the readme and things because i was i was in a hurry to just complete these demos so sure so it's called the on.net hyphen observability um so pretty much every time i do a show with you like i kind of have i'm probably going to have my own i appreciate that i appreciate it yeah so it's all in here uh you can actually run this locally with thai run but i i'm actually adding getting more uh by the way submit to one of my team members he kind of like helped me with a lot of other stuffs in this and uh he's gonna uh he i think he has an implementation on aks one separately uh we will add some more readme stuff on this so that you know you have more information how do you deploy this to azure and kind of like do that in data log analytics and tracing and things like that right right for sure all right well hey again so i've shared that link with everyone so you should have the links to the eshop on containers that's in the chat you should have the links to niche's demos and again i also want to remember remind everyone that tomorrow we are going to have that lex learn microservice event um i'll paste that in the chat again as well um so that's going to be tomorrow morning afternoon depending on what time zone that you're in um it'll be 8 a.m pacific time so again adjust that to your you know your time zone but you know they'll be talking about microservices they'll be doing some microsoft learn hands-on workshops and also too i mean nish also created some content for that so that'll be cool to kind of check out but with that being said i think i think it's a wrap man i think we call it a day thank you all for joining us um and i know i called out a bunch of uh countries earlier but i i see everyone that's in here i see folks from mexico i see everyone from istanbul we have folks here from africa joining us so again just want to let you know i see all y'all i appreciate it thank you all for joining us make sure you join us next week because we'll be back um it won't be microservice march but it'll be something different but make sure you come and check it out anyway so thank you everybody take care thank you thank you so much [Music] so [Music] you

Channel: dotNET

Views: 6,952

Rating: 4.9565215 out of 5

Keywords:

Id: PDdHa0ushJ0

Length: 83min 56sec (5036 seconds)

Published: Thu Mar 25 2021