Why .NET Core for building Cloud Native Apps? | Cloud Native Show

Just another WordPress site

Why .NET Core for building Cloud Native Apps? | Cloud Native Show

welcome to another episode of the cloud native show api’s serverless in Streamy apps are just a few types the applications that we’re gonna build for cloud native apps dotnet core is one of the languages built right here on campus I’m going to go find Scott Hunter and talk to him about why dotnet core should be one of the languages that we should choose when building these types of applications let’s go find him thank God man how’s it going today I want to talk to you about using net core for some cloud native apps yeah let’s talk about that and maybe even do a demo a bit later on awesome all right so best in class languages used for cloud native apps why why dotnet core that ofcourse interesting if you if you look at the history of net dotnet was built in 2002 and it was primarily at that time built as a framework for building Windows applications okay you know but a lot has changed since then yeah the clouds here now and around 2013 we started envisioning of brand new nets and we changed our roots completely we said hey let’s let’s be completely open-source let’s develop the entire thing in the open on github let’s have a roadmap to be public let the community see what’s going on we also said let’s take the technology and make a cross-platform and for us that means runs on Windows it runs on Linux it runs on Mac we support a variety of architectures x86 x64 arm 32 arm 64 and you know we’ve learned a lot since 2002 let’s go take the lessons we learned and what we see in the cloud and let’s make a dot nets it’s actually designed to be cloud first it’s a cloud first an image and Linux that we’re talking containers x64 obviously we went everywhere we’re hi women everywhere everywhere ok we could easily be here with it with the Raspberry Pi on the table and we could run a web app you know live on that PI if you wanted to awesome what we’re what were some of the the challenges that that you went at you were you know what was the approach about you know I got to run on Linux I run in container I run up I mean we’re talking about a framework in language that was pretty bulky was just for Windows what were some of the challenges and things that you get it to get around well obviously the first challenges we had to go find a version of.net that actually knew how to run on something other than Windows and so it might be surprising to people but we actually had built a dotnet called silver lights which could run on the Mac in the browser and it could run on Linux there was a there was a port that the people who worked on mono mono is an open source port of dotnet framework as well but they had built a thing called moonlight which was a port of Silverlight that ran on Linux but we went back and grabbed the Silverlight code because it was the closest code we had that had been kind of tested at production levels for cross-platform so we started there and then the next thing we said is as I said we had a lot of learnings over the years you know as as we had dotnet framework had a configuration system in it but is very rigid and it was hard to replace it on the fly various teams had find what it found ways to take things like dependency injection and bolt them into the framework after the fact and it’s amazing if you go back in time and say what if we put dependency injection in and configuration it’s first-class citizens so imagine your cloud world I’m developing locally and I’m using a configuration system that just talks to my file system all right but as soon as I go and run into something like kubernetes I can actually go and replace the configuration system on the fly with configuration system that actually can understand the container that I’m in kubernetes and read its configuration right but your code doesn’t have to change in the application another thing is logging we never had great logging in the original net framework I don’t know why you know we can attack some of it on after the fact but this time as we were thinking of you’re gonna put these apps in the cloud you need to have a great logging abstraction built in the framework so as an app developer or a framework

developer you can put rich logging in your application and if you want you could even replace that login with you know a third party logging but you’re still using the same abstraction so the code doesn’t change at all you know my logging was always I was riding out to a file on disk you know that’s how I did my logging back in the day and now we can just give it in a log provider or have that dependency injection I can write to a cloud and change that on the fly and not have to worry about recompiling my I was gonna say the big thing is the new configuration system because it was designed to be cloud –is– yeah you can actually go our old configurator configuration system every time you change the config the app free started yeah now you can actually change the config while the apps running so the example is your apps in the cloud it’s not doing so well and you need more logging so you just go and edit the config file and suddenly or go to the you know cloud setting you have for your particular application and suddenly the log level just changes on the fly right and so these these are a lot of like low level abstraction kinds of things that we baked at the bottom of the framework this time versus having them sit higher up in the in the framework and you know everybody can take advantage of them we put hooks in the framework so it used to be that the you know the framework is kind of generic it just boots up and assumes it’s running on Windows right now whatever the app is running in whatever you know let’s say you’re running in Azure and you might be running an azure app service well app service can basically there’s hooks so app service can say ah you’re a you’re a dotnet core application and you’re booting up let me inject some configuration for the Diagnostics so the diagnostic will actually write to the app service Diagnostics all right they can do that on the fly which means as a developer I don’t have to think about am i running in kubernetes am i running an azure app service i can just publish my app to all those different places and because the framework and the host can be aware of each other they can light those things up on the fly we also took approach from what from what I understand now is now that we are kind of opting into all of these different and we do a middleware approach right so that and speak to that if you will about how now we’re able to kind of take the pieces that we need those are either not everything’s in the box right so the old way was everything just came in a big box it was very with type of approach talk about maybe some of the middleware options that we have you talk about configuration and logging but what some of the other stuff I mean do we have routing and things like that that’s a great point if I go back in time and think again of where we started that in framework was the kitchen sink approach basically everything is chunked in there it’s on by default you get all this great stuff which was great if you didn’t really know web programming it was a great place to learn and get started because everything just kind of worked and was turned on by default right but let’s say you’re a bank and you’re trying to build a really high-performance micro service well you don’t want all that stuff and so what we did in that net core is number one everything is is very in-your-face it’s code first meaning that when you look at the the file to start up file we have a file called start at that CS and inside of it you’ll see all the middlewares that’ll be hooked up and as you said that’ll be some of those will be things like configurations some of those be logging some of those will be routing and you can decide to turn of serving static files for example HTTP support you know automatically redirecting to HTTPS those are all in your face so if you if you go I don’t need those three things hey I’m gonna turn off serving static files I’m gonna turn off HTTP I’m gonna turn off routing you can now dial those things as you want right you can also write your own so there’s a whole ecosystem where you know the community is going and built their own middleware is to do a variety of things like we don’t have soap support out of the box but there is a soap middleware for dotnet core that you can actually inject in the application and you’ve got great soup soap support another example of a middleware is you know we all build api’s today you know what if you want open API for your middle for your API well there’s plenty of middlewares you can inject that will actually give you an open API endpoint and generate the the swagger on the fly for you for that so those are examples of making the framework super pluggable and composable you know by pulling all these pieces out it sounds like you know first I start with maybe the the dump truck approach and now I’m down to maybe a you go but does that affect my performance and my size I mean how where are we at with that with you know my deployable executables or might it in my files I mean what are we looking at there today if you if you if you like put the entire dotnet core on a machine you’re looking

at somewhere between 60 and 70 Meg’s to put I think we’re on the machine which is not super big yeah I would still like to be like it to be smaller and so dotnet core 3 the next version we’re gonna ship we’re gonna introduce for the first time linking will you’ll be able to basically link out the pieces of dotnet core that you’re not using as part of your application so you know if you’re not using XML parsing then we can link that away and so that’s the first step for this we want to get to a point where we can at some point give you some kind of single eggsy äôt ish kind of thing you know äôt ahead of time compile it and a lot of that will come in the three wave the three wave will give you the single eggsy and it will give you some of the linking but we have steps to go where we can actually make our own frameworks easier to link to get the apps even smaller and smaller but you know we envision getting ourselves down at some point like a 30 or 40 Meg you know total on disk size for a SATA micro service sure so talking about micro services in knowing gone is some of the the ecosystem around that being kubernetes and linux and things like that was that the motivation behind getting dotnet to run on on Linux and these other devices was to get into that micro service world that cloud first world there was a couple motivations number one what we had seen was we have seen Linux being embraced by the cloud heavily and we wanted dotnet to be a great place to build cloud applications which means we had to go embraced Linux as well and so that that’s where the Linux side of it really comes down to play it’s kind of funny as a framework developer I don’t really think that most people that are writing a micro service think of the actual host OS anymore right as you get into the container space I think you really you stay within the framework you’re in weather let’s go whether it snowed whether it’s dotnet core you kind of stay in that space and whether you’re running on Windows or Linux doesn’t matter but making it making ourselves work on Linux was a a key thing and a great example this is you know you asked no why not one of the things that we are really proud about is the tech empower benchmark the tech apartments mark is a third-party independent benchmark kind of an open source project where people can submit their code to this benchmark and then like once a quarter they’ll run the benchmark on a variety of hardware and if you look net does pretty dang good in that benchmark you can write you know a micro service without a lot of framework or you can use our bigger framework which gives you a lot more convenience a lot more productivity and you if you look at the benchmark like the plain text both both are bare metal and our higher-level frameworks do very well over there but but that that benchmark is just kind of showing raw how fast can you shove stuff down a pipe you know we get to the point right now we’re running like four million requests a second which is pretty dang good that’ll saturate a 10 gigabyte network card before we run out of CPU the cooler demo to me is there’s another demo they’re called fortunes and the fortunes demo is serving HTML it’s talking to a database it’s doing the things that I would expect a real-world application to do and you’re gonna once again you’ll find us up towards the top of that as well you know we’re typically in the top ten if not higher in both of those benchmarks and this is a thing the team is embraced is is trying to make performance a key component of net core to the point we’ve even added language features there’s a language feature called span which allows you to map types on top of memory so you don’t it’s a double memory or I know as as stuff comes in so we’re actually modifying the framework on the fly as we think of performance and so we want to make dotnet one of the fastest frameworks for building any micro-service cloud application okay you know sorry about anywhere anything for any purpose and it’s I think sometimes we get the question of like a wide net what do you do the best we do a lot of things best you know you talked about we can run on a pie we can write a micro service I know in.net 3 oh we have you know the worker templates coming all right so it doesn’t use HTTP but maybe it’s just that process that runs and does work that’s our micro service type of templates you know I’ve spoken with the team about how we’re using that we’ve got G RPC coming we’ve got all those things but Before we jump into that what is what’s our basic micro service template look like what’s what’s a hello world look like for us yeah so we can we can show that if we want to show that so first off your point before we get into the code when you think of one of the things we struggle with is like there when you think of dotnet are people outside of Microsoft think of dotnet they might have they may think of asp.net yeah that has been the web framework that we’ve actually had since the beginning of dotnet and as we mentioned earlier when that framework was first built it was mint there was not a lot of web in 2002 and so we were

actually as a team trying to get desktop developers to be able to build web apps very easily and so a lot of convenience a lot of stuff done for you automatically drag and drop and a lot of that kind of stuff and some ways you have a reputation for that that historically you think of asp.net you think of web do you think of HTML and you think of those things but but the reality is dotnet is not asp.net and dotnet core are not just about that you can also build very lightweight high-performance micro services as we said for the for that tech and power benchmark and so what I’ve got on the screen here is a simple simple microservice and what you’re gonna see here is I say that I need to use routing because we need a route request into this thing right I’m gonna use endpoints and so what that means is I will then basically give it a path in this case I just said the route okay but I could also specify parameters there in that and if the request matches that whatever you put there it can then call this function and in this case I inline the function you know normally I would probably put that somewhere else and you can see that in what’s 10 lines 10 lines we wrote a micro service and on top of that we’re also asynchronous in inline here we’ve said we’ve got a sink we’re doing async here as well and you can’t see it because we’re not using it but this application supports logging this application supports the configuration model so you are getting some of those conveniences as well because we we put those in the root of all the applications but the point we’re trying to really show here is don’t think of dotnet especially down at corn asp.net core as this heavy bloated framework you can go as bare metal as you want to as full-featured as you want and that’s I that I think is the benefit of our stack you might have one API that you need to be really really high-performance and so you can write it this way sure you might want to have another API where the performance doesn’t to be as good and you want us to automatically map the parameters to types and do all that kind of stuff for you and we give you the best of both worlds you can basically dial from bare metal all the way up to full convenience at your choice and and in the past we kind of force that on you and no longer Sophy just run this is gonna be super exciting it’s gonna launch the browser and you know we served the hello world app here sure something else to talk about here is you’re never gonna notice I’m not in Visual Studio yeah you know the old next PS code required a large full-featured IDE another tenant of dotnet core was we work in all editors there’s an open source project called Omni sharp which provides the syntax highlighting that kind of stuff the language services inside of vs code it also works with other editors so you’re not locked to even vs code but you we have a we have an ID from the Mac we have an IDE for Windows we have vs code which runs on Windows Mac and Linux so we have a great command line experience as well yeah exactly we have a great command line experience if I wanted to I could easily just go to the command prompt so here we are in the command prompt and if I want I can just do dotnet run it’ll launch the application but I can also just say dotnet knew all the applications can be robot built right from command line dotnet build dotnet watch run if I actually want to stay in the IDE and just keep refreshing the app restarting the a pervert I might change code so we you know we’re fully supported all the way from a rich IDE down to the command line and that is a tenant of dotnet core as well is we actually build a command line first so the idea is everything starts at the command line and then we wrapped that in a rich IDE so once again you can dial that however you want you can go to the command line all the way to the full-featured IDE alright and you get the same level so do I like to live in vim and the command line on Linux on a boon to I’m good to go for you everything to go right yeah so dotnet core 3 we mentioned worker templates G RPC and and what are the other improvements we’re making for a cloud native I mean you talked about this is our simple 10 line 9 line app that we’re doing I know that we’ve got some things like HTTP client factory and a ton of things that we’ve added in the framework what we got coming down the pipe 4 4 3 2 not big stuff in 3 oh is the worker template which you described one of the things we try to do is we try to give our customers templates to get you started for some of the common types of applications so worker services I need to have a long serve a long-running process a service worker surface is pretty cool because it gives you that that that template ID for building that type of application imagine you want to listen to a queue and do something when a queue when some message goes into a queue that’s your typical in a lot of cases micro-service e things you can add a single nougat package of that and turn that into a window service you can add another nougat package of that and turn it into a system D diamond so whether you’re on Windows or Linux you get off

some first-class support for that I think that’s a pretty cool aspect of that G RPC G RPC is all about doing our pcs you know we already have great support in dotnet core for doing restful Web API s but a lot of customers really want to have contract based RPC and it is kind of tightly bound all right they’re aware of that historically we’ve had things like dub CF and dotnet remoting but what you know in the open source world we want to embrace open source so G RPC is an open source project that we’re contributing to right and the benefit of that means you can build your ERP service and dotnet and you can call it from node or call it from Java or call it from go at the same way same way you can actually build the GRP service and go and call it from net so we’re trying to play well in the in the open source ecosystem with like G RPC making it easy to you know to go both directions sure yeah that’s a again those are all those those you know in cloud type of technologies we’re looking to do and some of things we didn’t get into will get it later in the show series is is you know dotnet is like you said not just api’s it’s not just the web front-ends I mean we’re using dotnet and serverless we’re using it in in IOT we’re using it everywhere that we’re we’re creating these big distributed applications right is there anything else that you know if somebody says why dotnet why would I want to use this and this thing you know I know we’ve got dotnet 5 coming we’ve got a lot of things in the pipe and we’re constantly revving this we’re not tied to the visual studio release like we have been in the past we’re not tied to visual studio we’re not tied to windows other things we didn’t talk about dotnet core 3 has a bunch of new awesome diagnostic tools for running on like say Linux yeah we basically have first-class logging first-class diagnostics first-class ability to take dumps of your application all built into dotnet core 3 we didn’t talk about it but you know we did talk about REST API yeah so we have a bunch of support for the open API initiative as part of the.net core 3 wave as well where we can easily let you generate the swagger for your API and we can build a client side for you as well so it makes it very easy to call a REST API it’s all documented code yeah there’s about a 20 to 30 to 30 percent performance improvement in dotnet core 3 over dotnet core to to the one of the cool is we talked about was that plain text we can do serving of static files and stuff like that with zero allocations now which is pretty cool and you know as you mentioned as you go forward into like that net five wave that’s the wave after done it for three that’s when you’re gonna start seeing a shrink the size of those apps down even further the single-leg so you see the Lexi’s in in.net core 3 but we’ll have a much better flavor of single eggsy and net 5 lots of exciting stuff coming in the in the future and I can’t wait to see what we do on this show as we actually go and hopefully build some some real micro services and get em running in kubernetes yeah that’d be great awesome I think I appreciate you taking the time and talking to us about net core and building cloud native apps we’re gonna definitely dive deeper as we start to build some apps and looking at the stuff that’s coming that’s stuff that’s here now when we talked about speed performance build stuff anywhere with this tech and again appreciate time yeah and I’m gonna add one more thing so as you asked why yeah so performance we already have performance we have an awesome first-class language C sharp which just got better as part of that NIC or three with c-sharp eight bunch of new features added and productivity the real thing that we try to do is give you tools around the tech that make it easy to put your apps in the cloud and stuff like that so I think one of the things that some of the other tech it’s like here’s the tech and go for it right and we try to say you can do that or if you use one of our fancy IDs will actually make it as simple as right click publish or we’ll make it simple to say right click Add to see ICD and our goal is to actually make it easier for you to get your apps into those those environments first-class languages first-class tools yeah alright that’s what we’re at awesome that was a that was another episode of a cloud native show we appreciate you taking the time to watch us with Scott hunter talking about cloud native apps be sure to visit a kms slash cloud native show for future episodes thanks for joining us thanks for watching the cloud native show be sure to subscribe watch for future episode and especially our streaming shows on Twitch where we build apps based on the conversations had right here we’ll see you next time