Learn about serverless architecture and

microservices with C. This course is

taught by Muhammad Abdullah who is an

Azure certified solution architect. You

will build practical skills step by

step. Starting from the fundamentals of

serverless and microservices, then

moving into real world patterns like

onion architecture and containerization

with Docker. You'll build Azure

functions and triggers plus background

and IoT functions. You will learn to

organize microservices with Kubernetes

and Azure container apps. Security and

observability are covered to prepare you

for production and a full case study

project ties everything together.

>> Hi everyone, welcome to practical

serverless and microservices with C#

short course. My name is Mohammad Abula

and if you are wonder how to build model

scalable application without care about

the server the infrastructure then you

are at the right place. In this course,

we will not cover the theory about the

serverless and micros service, but we

will do real world uh practical work. We

will fix real business problem with

serverless and microservices in C. So uh

if you are new to this channel, so

please uh subscribe and hit the bell

icon to get latest video about this

course. So let's start this course.

First I will give you some introduction

about the serverless. uh so serverless

in serverless environment you don't care

about the infrastructure developer only

focus on the business uh requirements

and uh not managing the server so uh

serverless promise you a build and run

application without managing uh

infrastructure uh the cloud provider

like a Azure Google AWS uh handle server

allocation and provisioning and uh next

we mean the journey of the serverless

started in 2014 by Amazon they first

introduced use the uh AWS Lambda the

first uh serverless solution then

Microsoft introduced Azure function in

2016 and presently also Google also

provide uh serverless cloud functions.

So in this course we will only focus on

the Azure Microsoft Azure function.

Okay. So next step why we choose uh like

uh serverless. So there is few reason

few benefits like uh it autoscale uh

like no auto manual uh no manual scaling

required and uh the pricing model for

the Azure for cloud is pay as you go uh

only pay for what you use and it's a

reliable secure and uh we can only focus

on the development so we can do fast

development and uh a sustainable growth.

So this is the few benefits of using

serverless.

Okay. So serverless equal to is equal to

the microservices. So we will check this

uh uh fact like microservices in

microservices uh architecture each

component is loosely covered independent

component uh and uh each component cover

some business uh capability and uh

serverless is the way to build uh

microser architecture. So to deliver uh

microservices architecture uh serverless

is the best option. So

this is one example uh for example if

you have an application this is one

microservices of that uh uh application

the user authentication in user

authentication we will have like u

registration function blocking function

reset function so these three uh

component create a user this is one

example of the uh user authentication

microservices

okay uh so next uh uh is your function

launched by already cover 2016 by

Microsoft uh it's world as a uh function

as a service uh and we can uh write a

function in any any language like C#,

JavaScript, Java but in this course we

will focus on the uh C#. So um Azure

function also have a capability of

integration. We can integrate uh Azure

function with uh database uh events uh

workflows and third party APIs. So we

can easily integrate Azure function with

these uh technologies and uh uh there is

some advante if you want a stateful u uh

function so you can use a durable

function. We will see uh durable

function in uh other upcoming videos.

Uh we can also build uh CI/CD blind. We

can monitor our Azure function that we

can diagnose. We can troubleshoot. AWS

provide this uh sorry Azure provide this

uh facility uh to us to create CI/CD

pipeline. We can create logs and

troubleshoot any uh any problem in the

Azure function. So where you create uh

Azure function uh we you will select uh

hosting plan. So this is some u uh

consumption based flex uh information

about the hosting plan like consumption

uh it's work for event driven workload

it autoscale and cost effective. So in

this course we will uh uh use mostly the

consumption because it's a true

serverless

you can also use if you have

containerized application you can use a

container app hosting plan it's up to

your requirement. So this is some uh

information about the uh hosting uh

benefit no infrastructure management it

autoscaled and pay as you go model and

fast already mentioned in the beginning

okay uh you can uh use any language uh

for uh to write the function it's

reached ecosystem and secure deop also

supported so uh for this uh um video you

will first create as your account you

will set up aure account or you can

write as function uh any of your

favorite id like visual studio OBS code

and uh you will first initially if you

go in OBS code you will uh initially set

up Azure core tools. So uh we will

create uh Azure function uh uh using the

Azure portal you will see how we create

the Azure function.

So uh first you will create uh Azure

account uh uh in the portal.gu.com

com once your recovery is approved and

created. So you will see you will create

uh these resources from uh Azure uh for

example uh in the in this video we focus

on the Azure function. So uh to create

Azure function you will uh you will uh

search for Azure function uh function.

So you can see here Azure app. So first

you will create Azure app like uh this

is the Azure app. So um we will create

on the create. So you can see here uh

this is the hosting plan as I mentioned

in the uh slides.

We have flex consumption. It's for fast

event driven uh consumption based uh

it's for uh event driven workload uh

functions premium also for event driven.

Uh this is the some like matrix. So it's

up to you which uh um hosted plan suits

your requirement. If you you have a

containerized app so you can use

container app environment. So this is a

different workload different hosting

plan for uh we will select the

consumption because it's a true server

less and we will use consumption in this

video. So you will select this

and uh the pay model is a pay as you go

model reward for the consumption. So

select. So uh you will in the basic

setting you will uh you will select the

subscription uh you will create any

subscription. Uh accord I have one

subscription and uh you then you will

create uh resource group. Uh resource

group is important. Uh for example for

this course uh I created one um resource

group. Uh this is the resource group.

You can see here serverless and uh

microser. So each and everything we will

keep in this resource group. We will

check their billing. We can match uh

each component of resource in any

resource group. So how you can create

how you can create uh if you are new to

Azure and then uh how you will create

the Azure uh resource group. So this is

a is your uh services. Uh so you can see

here you can also search resource group

here resource group. So this is the

resource group I have created for other

application. Uh uh you will create uh

this create button and you will select

this your subscription. Then you will

give any uh name to this uh

subscription. Uh it will be for example

project A B C. So uh you will give this

name. Uh you can select uh nearest u uh

region to your uh uh project or

application user. Uh for example, I will

select South Southeast Asia. And then

next uh you will um review and create.

So uh when you create uh click on this

create button, you the resource will be

created. So I will not uh create again

because I already have resource group.

So once you create this resource group

then um when you come to this basic

setting you will see uh the newly

created resource group in your list. So

I have already uh serverless and micros

group. So I will select this. Now next

you will give uh one globally globally

unique identifier for uh this uh

function app name. So uh you can uh your

first uh function app demo

demo do for example. So this will be a

unique identifier uh for your app name.

After that uh you will select the

operating system you will select uh uh

window. If you are using uh Linux you

will use Linux. Next you will uh click

uh on this uh runtime stack. You will

select runtime stack. Uh I will use uh

net. You can also go here but Java.

Yeah, you are using other uh in

technology. So it's up to you. Uh this

is the version of net. I will go with

net and this is the region. Again you

will select region which is closest to

your targeted user. Okay. So next is the

storage. So you can see here basic one

is completed uh storage. So uh is your

function need uh uh storage account by

default. So you will if you don't have

any storage account then you will create

storage account. Okay. If you are new to

zu function then uh how you will create

your uh storage account you will search

uh z storage.

Okay. Storage account. You can see here

storage accounts. So um uh you will

create storage account. You click on the

create.

Okay. So this is basically while basic

setting you will select the

uh the resource group and you will give

name uh

let's

Michael

is

it should be 24 character and

for example.

So yes, so this is available or again

you will select a region. Um this is the

uh primary service. Uh if you use the

storage for Azure file, you will select

z file. If you want to use Azure blob

storage, you will go with this. So uh

this is optional. So next you will

create the performance

like uh I will go with standard uh if

you need uh other scenario low latency

for example you will select the premium

but it will charge you but so I will go

with the standard uh and this is the

redundancy uh for you will uh I will go

local redundant uh storage if you need

copies of your data uh to not cross your

data so you can use uh this option like

zone redundant geio redundant and this

is different type of uh redundant

account uh types. So uh for to use the

low cost option I will go with low

redundant storage. Okay. So uh this is

used for non-critical scenarios. Um if

you look on for example backup so you

can use uh geo redundant and uh if you

want to use highly availability scenario

so you go zone redundant and if you have

a very critical case critical data

scenario so you will go jeez red. So

this is different top of redundancy tag.

So I will go for with the redundancy.

Next uh is uh uh another one is

optional. We will keep it as default. Uh

so uh you will at the end you will

review uh the storage account and you

will uh click on the create button. So I

already created so I will not create

again. So I already have uh storage

account but uh this is uh is I show uh

how to create um storage account. So for

SU function you will need a storage

account. I already created one storage

account.

Okay. So this is uh the storage account

I created. Uh the next option is the

networking. This is for uh like security

purposes. Uh to enable public access you

will click on you will click on or

otherwise you can uh you can off this.

And uh next is the monitoring. uh you if

you want to add logging to uh

troubleshooting uh something like that

so you will uh use this monitoring uh

feature as well but uh it will cost you

for example uh enable application inside

if you want application inside you can

select yes otherwise no uh so currently

uh I don't need uh inside for this uh

demo so I will uh select no because it

will cost you next is the development so

uh you can create the CI/CD like for

your Azure function app. You can uh uh

attach GitHub account. Um but you will

select this option continuous dep once

this is enabled you can uh you can

select uh your organization the

repository you have in the GitHub

account. So you can uh you can select

your repository. Okay. So for example

this is the uh repository I created. So

you can also create the branches there.

So I will go with our deployment. In the

other demo demos we will uh create CI/CD

blind. For this we demo we will keep it

simple. Uh next is the authentication

uh we will uh use the default options

and next the take take uh it's

categorize the resource for you. So

currently we don't need uh this is

optional. And then next you will review

the application. So you will review uh

subscription they are using resource

group uh name of the function uh secure

default hosting. So this is the

information uh the option the detail of

the isue function if you make any

mistake you can go back to the specific

tab and you can correct. So once you

review and everything is fine you will

create on create button. So this is how

you will create the uh Azure uh function

app. So I will not uh uh click on the

create button because I already have uh

one is your function. You can see here

Azure function function is created. You

will see in the list here.

Okay. So uh if you open this uh you can

check the detail of your Azure app. Uh

please note this point that uh in one is

uh Azure function app we can create

multiple Azure function. So Azure

function is different and Azure app is

different. In one Azure app we can uh we

can react different applications uh

different type of uh Azure function. So

once uh you open you you will see the

overview how the function which resource

group it is targeting uh what is the

status currently it's running and the

location is southern uh Asia

subscription and the subscription ID and

this is the domain name of this uh SQL

function. You can also open this. You

can see here uh this is up and running

and this uh uh uniquely globally

uniquely identifier. So uh or or as your

app is uh running and uh the operating

system is window server plan the service

plan uh service plan and runtime. Okay.

So you can also check uh activity uh we

will cover this in upcoming uh sessions.

Uh you can uh uh deployment. This is for

deployment as you this is the uh

functions

uh environment configuration in setting

them you will you can see environment

variable configuration authentication we

will encode this uh in upcoming lessons.

Okay. So uh but this is the basic the

overview of the uh Azure function where

you create. Okay. So uh and below in

this section in the function section you

will see all the function inside this

Azure A. So this is uh for demo purposes

I created this just for practice. So uh

this is the already created uh Azure

function inside this is your app. You

can see the matrix uh you can also see

the properties of the Azure functions uh

in this is the notifications. So uh next

we will jump into the uh visual studio.

You can write a z function in VS code

and visual studio. But for this uh demo

we will use uh is uh visual studio

because it have uh rich in features. So

like debugging and other they provide a

lot of things. So we will uh open the

visual studio. Uh so you will select get

new app like we will create one health

check uh Azure function and we will

deploy it to the Azure app we created.

So you can see here uh you will search I

recently open the Azure function that's

why it's coming in my list. If you don't

see this function you will uh you will

search here as your function. You will

select Azure function. Next you will

give a name to Azure function uh like a

function app

uh two or something else according to

your requirement function

and p for example. uh you will select

the location you will go next. Uh okay.

So uh here is some important things like

uh this is the worker the function we

will select the net uh 8.0 and this is

important uh thing like the function uh

trigger each uh your function will have

one trigger. So we will discuss this uh

in detail like we we have uh is your

provide different type of trigger. If

you say here um is your function

triggers. So the basic concept is that

each function need a one trigger to

start. Without trigger we cannot start

the Azure function. So we will

definitely need one trigger to start the

execution of the uh function. Uh where

as your function can run in parallel uh

or and the other concept is that exe

execution rank is very uh by the hosting

client we selected. So this is the uh

the the first trigger which is mostly

used is the HTTP trigger. uh it exe uh

HTTP it uh execute uh uh via HTTP

request. It perfectly suitable for the

APIs and uh web hooks. If you have uh to

do something uh on our API uh or web

hook then uh you can use HTTP trigger uh

like it support HTTP methods. The other

one is the timer. Uh if you want to do

any schedule b execution so this will

suit you the timer it supports encode uh

tabs model. Uh so you can uh create your

expression and it will uh done in a

specific schedule.

And next is the blob uh storage trigger.

Uh whenever u a blob is created or

updated so based on that you can uh

trigger any function.

uh perfect for file pro processing and

uh like logging image login something

like that pre requirement but it work

for uh is your block. Uh next the qu uh

qu uh q storage uh trigger if you have

messages Q and b b b b b b b b b b b b b

b b b b b b b b b b b b b b b b b b b b

b b b b b b based on that you want to

trigger you will use this que

storage trigger and um the other one is

the uh even trigger. uh it will work

based on the Azure uh service event or

it will it's using the event

architecture. The other type is the

service bus trigger. Uh complex workflow

and uh inter application uh

communication we can use and uh the last

one is the if you want to work on the

cosmos data uh DB so you can use this

trigger Cosmos DB trigger. So you can

select but for this demo we'll select uh

the HTTP uh so you will select this uh

uh next is the authorization level.

authorization level. Uh if you want to

add any uh authorization to your Azure

function, you will select uh you can

select this options. Uh but for now, we

will uh go without uh authorization. So

we will go anonymous. Uh so once you

create here you can see the function the

actual function uh that will uh deploy

to the uh function app. So there is also

some uh settings and this is the program

uh to so we will write some code here in

this uh uh function app one. This is we

are passing the uh is your logger to log

the information. So here we will write

one uh uh h check uh function for

example it will return iction result and

u we'll use the run method uh it will

run uh the is your uh function and uh

there you can use the uh we will use the

http uh trigger http trigger uh http

trigger and we will give uh a

subparameter like uh authorization level

will be anonymous anonymous

authorization level and uh it will be a

at

like that and the next variable we will

pass the route. So we'll uh define the

route for this function. So this will be

the health and for example this is the

route.

Next uh we will http

request

http requester and get this we will use

this variable. So I will remove this

autogenerated code.

Uh

so

uh run regard anonymous

start.

>> Okay. So

so uh this is parameter is completed. Uh

okay. So next uh we will do some uh

logger. We will log out information.

for example auto log info

and we write here some message

for example

and the

check

proceeding

okay so it's some logger information

next I will create a response object

that will need dot ls

function and I return

that uh response. So function uh

function uh attribute this uh l check

this will be the can check this is the

function attribute needed to make this

as a function. So we can also download

this topic.

Okay. So you can see here uh it's

running and this is the path uh local

path. If I open this in browser

you will see that this app is you can

you can see that it's return the status

and the type. So uh it's uh running

locally. uh in next we deploy this to uh

Azure for example uh to uh publish this

to Azure uh we will click on right click

and publish.

Okay. So you will select the Azure. Next

you will uh select the Azure function

app. Uh once you select you will see the

Azure uh app uh resource in your Azure

function. You can see here this is our

Azure function uh demo which I created

initially. So you'll select this and uh

once you select uh it will create the

publishing profile.

Now publishing profile is uh completed

created. Uh now you can see here this is

the publishing profile and uh once I

publish for example if you go to publish

it will uh publish the application uh in

the Azure app and the publishing uh

succeeded and uh we can uh now uh access

this on Azure. So it's deployed to vure.

So you can see here uh the function is

now available in the azure function app.

So uh if you click on this it will give

you the the detail of that function.

This is the function to get a function

file. You can copy and check.

So you can see here this is deployed to

Azure and it's give you the same result

here.

Okay. So I have a few question for you

like which trigger fit for your use

case. You will write this in your in the

comment of this video on YouTube and uh

how you will organize your function and

what hosting plan meets your need. So

this is the question for you. So uh see

you in the next video. Thank you. Hello

everyone. Welcome back to practical

serverless and microservices with C#. My

name is Mouhammad Abdullah and I am

Microsoft solution architect and uh uh

I'm creating this course for net

developer engineer who want to learn

about serverless and microservices with

in this video we will understand

microservices architecture. So uh what

is microser architecture in

microservices architecture is nothing

but a software deployed on a computer

network. Okay and different

microservices communicate via uh network

protocol and uh there is some constraint

and rule that microservices must follow.

We will see those constraint and rule

later in this video. We have monolith

application. Monolith application have

large single system, one single

codebase, one deployment unit. They have

like different problem. The first

problem is everything is in one package.

So one deployment unit and the second

thing is different technology in

different department. And the third is

they are difficult. They are hard to

connect with other uh software. And the

fourth problem is uh poor software

communication like they cannot talk with

other system. So this is the main

problem in the monolith application. So

to fix this problem uh service oriented

architecture is introduced. So they have

some key feature like uh they have a

network of communicating processes like

each service talk together. So this is

the key feature of the service oriented

solution. The second is modules are

separated uh separated. So each module

have a separate process like uh they are

packed uh in different pieces. And the

third point is standard protocol

communication. So they have some common

uh language to their to that language

they communicate. So and the fourth

point is first step toward this is the

serviceoriented architecture is the

first step towards microser. So this is

the first step. So uh you can see here

this is the timeline timeline like in

the first phase uh we have some SOAP

protocol uh this is the first

implementmentation which is the XML

based the second is the JSON based web

API light data format and uh the second

phase the third phase rest web API like

we already familiar with the uh ASP.NET

web services and this is the foundation

for the microser. This is some timeline

for the uh serviceoriented

implementation. So uh here you can see

service oriented uh architecture fix

four problem. The first one cross

technology communication like different

tech uh work together like windows

apache. So this is the uh they fixed

this first key problem and the second

problem uh which is fixed by the service

oriented uh architecture uh is

independent version like each module

evolved separately and uh public service

offering like they communicate with

Google API MS API something they

communicate with external um a access.

Okay. And the fourth problem is they

have some uh protocol standards like

they talk with some protocol HTTP rest

and gpc uh they can communicate with the

text binary communication. So this is

some problem which is fixed by the

service oriented architecture and when

this service oriented architecture

evolved uh they face some issues like

the the scaling issue is the main major

issue. So like uh traffic increased user

increased dramatically they need a

performance optimization like speed

become critical. So and the third point

is uh like hardware resourcing uh uh

resource allocation was the other key

issue in the scaling and the fourth one

is the requirement like in software we

uh we u have to satisfy the new coming

requirement in any feature like to add

or extend any feature. So this is the uh

u main scaling issue which is faced by

the service oriented architecture. Okay.

So you can see here u as a system

involve we have four uh new critical

requirements. So the first requirement a

is a um system need to independent

scaling each module scale separately. So

this is the first requirement. Second uh

zero downtime like on video operation uh

sometime need zero downtime like

Facebook Twitter need a zero down time

uh other system like a banking system.

Um and the uh requirement number three

is independent uh team independence like

different uh separate team per service.

So this is the third new requirement and

the fourth requirement is like a

maintenance isolation. For example, if

we fix one thing in one uh service it do

not affect other. So this is the four

key u new uh requirement. Okay. So to

fix this we have microservices solution

like they each module have separate

service like u we uh every every every

service have their own um each service

work like independently and uh we can

replicate so uh service as many as node.

So this is the scalability and uh they

also uh offer orchestrator like u uh

intelligent service management uh we can

create many copy of uh any node and the

fourth point they fix is the hardware uh

dedicated resources. So this is the

problem that Microsoft fix microservices

fix and uh you can see here orchestrator

role uh we have orchestrator that can

scale u uh like uh decide service copy g

scaling decision they take the scaling

decision resource allocation and uh they

uh we can also multiply orchestrator

possible or manual management. So this

is the uh microservices uh solution.

Next uh when we work when we work with

microservices we have some constraint uh

to follow some rule to follow. So the

first constraint is uh we must follow

the domain driven boundaries. We define

we must define uh domain boundaries

clearly module boundaries by expert

domain. Okay. So the second constraint

is replicable service every uh for

example dual scaling if we need to uh

scale up the scale up the service it

should be scalable. So this is the

second constraint and uh the third

constraint is uh independent team like

different team work on different uh

modules different services. Fourth

constraint is we must define a well-

definfined interfaces. And uh fifth

point is uh standard they have some

standard communication protocol. And the

uh sixth constraint uh is interface only

dependency like services depend only on

the interfaces not on the actual

implementation. So it will decouple the

system. It will not depend module A on

module B. So this is the constraint we

must follow on the in the Microsoft when

we decide uh or design in Microsoft

environment. So um Eric Evan

theory each expert domain use typical

language. If we go with the domain

driven design, it checks by domain use

typical language and uh when language

change it detect the boundary and when

there is a common language it uh it show

boundary context and if there is any

loose interaction uh it show no common

language. Okay, this is something about

the domain design like application split

into when we design microservices u

every module or some module have their

own boundary context in one boundary

context to we have one uh module as well

as we can we have multiple module as

well. So we will see this in detail.

Okay. Okay. So you can see here uh this

is the second uh two level uh is one

terminology which have the two level

service decision. For example, if we

have you have a uh e-commerce u

microservices for example uh then you

have two approaches. The first one is we

divide logically uh we divide divide

logical microservices like we divide the

team in three uh parts like for example

shopping cart team handle all the

shopping related uh feature and we also

the business also divide into team like

handle all the related feature and the

third is like shipping team handle all

the shipping related feature and in the

second level in the second level like

physical microservices we divide uh uh

deeper like technical we split the teams

more uh more uh technical split like uh

shopping teams split into product

shopping uh and uh recommendation

service, payment teams play into payment

processing history and refund service

and uh uh the shipping teams played into

like more deeper like shipping,

packaging, delivery. So uh the main uh

purpose of this is to team independency

uh and clear boundaries. We find clear

boundaries. So this is main feature uh

two levels uh two-le approach we two

level service two-le approach. So and uh

you can see here um when we design

microservices architecture we uh have

like team to manage team we have like uh

we use some tools like context map us it

um in context map we have usual team

interaction like we usually define that

shopping team will interact with the uh

gamma team and inventory will interact

with the shipping team. So it's like a

neighborhood neighborhood map it show

like a team relationship. So we use this

in team management. This is one of the

tool and the second tool is the uh

service catalog or we also set a service

directory where we define the services

owner of this service uh cost status

requirement and we use uh tool like

swagger data do postman for

documentation. So this is why this tool

matter uh because uh it will prevent the

confusion it will reduce the meeting uh

it will track the cost it will use for

to blend better and uh when any uh new

team join it will be easy for that new

team. So this is some tool when we work

with microser so we will manage a team

through these tools. So um when we

design microservices for example each

microser have their own uh database

because u if we don't have a separate

data database um then for example if

service A and B share table T for

example and service A modify the

structure of the table then this

migration changes uh the service B will

also uh apply these changes. So this

approach will break the independence

principle of the module. So u the rule

is only same service instance can share

database. Okay. So this is the some

principle you will follow uh during uh

during designing microser. So uh there

is some challenges when you work with

microservices like uh you will face data

duplication challenge like uh the

problem is uh like in microservices uh

some m for example service A and B

service B need some data from service A.

So we must uh duplicate the data inside

service B. Okay. So uh this is some uh

like initable uh change we must

replicate the data but uh we will follow

some uh like rule like we will minimize

data duplication and the other point is

we will duplicate the data in uh few

microser we will try to uh there will be

a few microser that will duplicate the

data and only duplicate those data which

is needed for that microser. Okay. So uh

in this slide we will discuss the uh

communication between the different

microservices like for example if we

have one microser that uh need to call

the service B and service B call the C.

So it create a sequential dependency and

it will add up the response time like

the service remain block it will wait

and uh we invest the computation time

and uh the response time will be higher.

So uh this is about the synchronous

communication for example if we uh call

one service and the other service call

the third service. So it will create the

sequential dependency. So uh to the

solution for this uh problem is um

synchronous data sharing like this is

the proactive approach where uh service

uh send data when uh data change and

it's a pre-process data u like

pre-process data sent to the potential

uh color and there is no wait uh time

for that request and data is available

when it's needed and uh this is the

synchronous communication between the

microservices like the other one is the

request response which is the

traditional one and like client send

request server process and it respond Uh

this is something like synchronous like

it weight is uh involved in this case

and in this case response time is up and

about the message based communication uh

like it's a datadriven communications uh

synchronous messages and uh it it's

acknowledge versus response in the

message based we have acknowledged but

uh in the traditional one we have

response we wait for the response and uh

some benefit of the synchronous

communication like uh we completely

avoid the wait time the message send in

queue like we can use Rabbit MQ and the

mass transient if we have in inmemory

calls if we have like the microservices

is deployed in different u machines. So

we can use the uh like rabbit MQ um yeah

acknowledge mark completion uh we have

retry policy for example if any message

fail we have retry mechanism and there

is a timeout handling and uh error

recovery mechanism is also available in

this case. So uh this is all about the

section number two. Uh in the next video

we will discuss uh microservices type

and uh some patterns related to the

microservices. Hello everyone welcome

back to practical serverless and

microservices with C#. My name is

Muhammad Abdullah and uh I created this

uh course for net developer and engineer

who want to learn about serverless and

microservices in C#. So this is section

number three and uh if you missed the

section one and two please uh check out

the playlist. Uh so I will share the

link in description. So please check the

link and uh first watch the uh section

one and two. So uh in this section we

will uh uh we will cover um

microservices types and uh some

different patterns. So you can see here

um we have uh some front end

microservices and the worker

microservices. So there is uh difference

between these two microservices. So the

front end microser

face the client like the user it's the

uh userf facing uh microservices that

perform the uh client request and

response and it can also handle multiple

parallel requests from different user as

well and uh th request pattern. it

follow thread per uh pattern request. So

you can see here in the diagram we have

uh different microservices. Some of them

is front end microser like first query

microser and the at the bottom we can

see update microservices. This is the

front end microservices like it

facilitate the user or the client and

the next is the worker. You can see in

the diagram we have in the middle we

have worker microservices that only deal

the inner communication like no direct

user interaction only process the data.

uh it work in the assembly line

operation and uh it also work on a Q-

based processing it perform Q-based

processing. So this is two uh types one

is the front end the other one is the so

here is the example of car sharing

application. So in the whole course we

will focus on this uh car sharing

application we will create uh services

for it. Uh in this example you can see

here we have like six microservices uh

routing location at the top we have like

u routing allocation best uh matches and

the at the bottom we have car sharing uh

that fulfills request uh car seeking and

uh uh route choosing and in the middle

we have the route planner which is the

worker microservices the the top three

and the bottom three are the uh the

other type of front uh front end

microser and the the route planner is

the worker microser. So this is example

of the front end worker microser. So

next you can see here car sharing

application when we do analysis we find

two domain. The first domain uh

represent car sharer language which

represent six microservices and the

second domain is the routing language

like the meter uh route planner. So this

is the two domain we will uh cover in

this course. And um if you check the

architecture layout um the top

microservices are the query uh it only

give data to the user and the top at the

top microser they are update microser

update microser and the micro uh worker

microservices in the middle you can say

the gray shaded. So this is the worker

microser mostly query and update

microservices are the front end

microservices. So this is some

indication. So you can see here um this

is the car holding journey. car holding

journey. Uh it uh handle all the crude

operation for the car owner and manage

the creation and availability. Uh and it

also integrate uh integrate with route

planner. If you check in the diagram car

holder, it also interact with the route

location and route planner. Uh and uh uh

route choosing update microser. You can

see here uh car holding except car

seeker uh select route matching uh

resource destination remove incompatible

option after match. So this is some u

information about the microservices we

will uh cover in the course we will

actually uh practically do this all

microservices. Okay. So the um car

seeker request if we go if you check the

car seeker request it will uh handle all

the uh passenger request uh it will also

do the crude operation like the car

holder and it will also submit the

request uh after date selection they

will select the date and it will uh send

the request. So this is some about u uh

something about the car holding uh

holding holders and the okay. So uh in

this slide we will cover we will check

the complexity uh reality check like uh

some tooth about the microservices like

if in microservices we have like a

different services on different machine.

So the testing become complex. So this

is a truth about microservices and the

maintainability is uh time consuming and

complex data uh driven communication

pattern we will follow complex

datadriven communication pattern and uh

it will also increase the cost. So uh

this is some u truth about the

microservices. So while choosing the

microservices you will also keep this in

mind. Okay. So here many people ask

question like when to add up

microservices. So here is the some use

cases. So uh if uh your team is more

than five then you can go with the

microservices and if your application

have flight traffic and uh time

consuming modules are there in the

system so you can go uh with

microservices and um if you need module

level optimization so you can also

choose the microservices and uh uh in

microservices we must split the train

because it will uh define clear

boundaries and it will avoid

ambiguities. So uh when not to adopt the

microservices if your application is low

low traffic and uh you have small team

and uh the requirement is

straightforward. So you can not uh adopt

microservices. So uh next we will uh

like cover some patterns in

microservices like why we use patterns.

So uh in microservices we face different

problem. So uh developer and u

programmer create solution for that uh

particular problems. So that um solution

became a patterns. So whenever we face

the same problem in our micros service

so we can use the existing uh pattern

instead of creating uh our own pattern

because the already created pattern is

tested and it work for other users as

well. So uh we will cover some

microservices uh pattern uh mostly

mostly concerned with the resilient task

execution which is the one of the

microservices pattern. Okay. So what is

resilient task execution? So u in

microservices uh microservices can be uh

moved between machines uh for load

balancing. Okay. So uh load balancing

like distribute traffic between uh

nodes. So uh so also the microservices

can be restarted to recover from memory

leakage and performance issues and some

microservices can also miss some

messages uh during any operation and u

it also fail due to software bug or

hardware bug. So uh to uh to to deal

with this we have some strategy like

failure detection strategy. So in this

case we have two methods. One is

unexpected uh uh exception and the

second one is the timeout exception.

Okay. So uh we will see uh that how we

can cover this uh failure. So u we have

some reliability patterns reliability

patterns. So they have three major

standard pattern. The first one is the

exponential retry and the other one is

the circuit breaker and bulkhead

isolation. So we will check this one by

one. So the first is the exponential

retry. So what is the purpose? Uh to

overcome temporary failure. Okay. So

like when service restart during that

pattern uh we implement the retry and

the retry increase uh um exponential

number of retry and uh when the when the

maximum number reach we throw exception.

So uh we use we can use the exponential

retry u pin uh to get reliability in the

microservices. The second one is the

circuit breaker. Okay. uh like when uh

exponentially try reach maximum. Uh in

this in that scenario we use the circuit

breaker uh like block we can block

access to resource for fixed amount of

time and return immediate exception

allow time for human intervention or

manual fixes uh and it also circuit

breaker also prevent cascading failure

and the the third one is bulk ahead

isolation and it prevent failure and

cognition propagation. So here is one

point what is cognition propagation. So

uh cognition propagation happen when one

service become slow or overloaded. So it

start consuming all share resources of

other microservices like thread CPU and

DB connection. Other service that share

those resources also slow down. So uh

this is called cognition propagation. So

bulk ahead isolation prevent cognition

propagation. Okay. Uh and um replica use

same database this example um and one

replica open to many connection

cognition database for all the replica.

And what is the solution for this is

partition connection like we will define

maximum number of u replica per uh per

per service. So this is the solution for

it. So uh you can see we have some

strategies uh like uh we can limit

active request like only five database

request at a time per service instance

is allowed. This is one strategy. Second

one uh extra request keep the extra

request uh in the line. Uh so uh and the

third one is if the line is too big the

queue of the message the request is too

long stop accepting more uh request. So

this is the third strategy and the four

uh when um return error is instead of

crashing. So um if there is any uh bug

or crash scenario in our microser so

instead of crashing uh return the error.

So this is some strategy to uh bulk

ahead implementation. Okay. So next is

the uh communication pattern like um we

have output input message skew which is

needed for reliability and uh publisher

subscriber u we can get the loosely

coupling and the other one is the event

based messaging messaging which is uh we

will cover this in uh coming slides. So

when we u implement the sequence

communication we face some few uh

challenges like u message copy until

acknowledgement. Uh so we will keep

until the consumer of the message is

does not implement or accept or receive

that message. Uh we can enable retry

operation uh handle communication

failure and um the second is the message

duplication. uh in many scenario uh this

is a challenge in the synchronous

communication uh like message

duplication and the other one is the uh

like um message order like message can

arrive arrive out of order and wrong

order can cause uh consistency. So this

is a few things few challenges we we

will fix uh in as synchronous

communication. So what is output message

Q solution? What is the solution for uh

output message Q solution? So here you

can see in the diagram Q's all output

messages we will keep all the messages

in the queue and uh when any consumer

acknowledge the message just remove uh

the message from the queue and um if uh

any message fail fail or time out occur.

So just uh review the message and uh

include attempt number of exponential

exponential retry. So we can add the

retry mechanism and uh store minimum

retry time per message. So we can also

define u minimum retrive time for each

message. Okay. So this is output message

Q. The other one is the input message Q

solution. Okay. So here you can see u

recognize and discard duplicates. So in

this pattern uh in this uh communication

pattern uh we will uh avoid to

duplicate. We will recognize and discard

the duplicate uh messages and uh we will

reconstruct the correct message order.

And uh what is the processing rule? Read

message only after filling sequence

call. You can see here in the diagram

and uh what will be the result order um

we will uh we will keep the messages in

order and the duplicate free message

processing. This is what we can get from

the input messages cube. It will u uh it

will remove the duplication. It will

give order.

Okay. Uh in event based communication we

face some challenges like uh want to add

a stat uh statistic. If you want to add

a new microservices like uh that will

give you statistics to the car sharing

example I shared in the in the previous

slide. So what will be the problem? Uh

this statistic microser need like some

data from the existing microservices. So

what you will do? you will modify the

source microservices. So if you do this

you will violate the u modification

should not propagate principle. So what

is the solution for this problem? The

solution for this problem is the

publisher subscriber pattern which is

the another communication pattern. Okay,

you can see that diagram sender send

message to the publisher endpoint. Uh

there is no direct communication

reception and uh interesting

microservices like recipient one to uh

subscribe to that publisher endpoint and

uh publisher automatically forward

message to all the uh subscriber and new

microservices. what will the uh

statistic microser will do? It will just

uh subscribe to that uh pattern to

receive the messages. So in this pattern

we can uh like get the microservices

depend uh independency maintain uh so we

can get the each module will be

dependent. Okay. So for this we can to

also use the message broker like uh uh

handle by application called message

broker. We can use the message broker

like in market we have debit M2 and

Azure service bus uh which offer

publishing message and um it will

deliver to all the subscriber. So this

is a message broker and uh here is the

summary like u to get the resilience uh

in the micros service we will follow

some patterns like exponential retry uh

it will use for temporary faults circle

back long-term failure uh and bulkhead

isolation failure contentment and uh

some other uh communication patterns

like like out output input messages cues

we can get reliability publisher

subscriber uh we will we can get the

loosely coupling in the event best

messages uh so this is all about the

okay in the next uh section and we will

uh cover the doer and onion architecture

and uh uh if you are new to this channel

please subscribe and uh if you have any

questions so you can ask in the comment

thanks for watching. Hello everyone

welcome back to practical serless and

microservices with C#. My name is

Mohammed Tdula and I'm Microsoft Azure

solution architect and uh for this

course uh this is my edge agenda. So

first we will understand the how ser

serverless application work then we will

look the microservices then own

architecture then how to work with

docker we will understand different type

of function uh their pipes like trigger

background functions IoT function and

microservices how to organize

microservices with kubernetes uh then we

will see the container containerization

in microservices uh with help of

kubernetes and user container lab then

we will check the security observability

inside serverless microservices and uh

in the whole this course we'll consider

in one uh car sharing app. So we will

see this in action and lastly we will

understand how net spine work. So if you

miss the other sec session like one to

three. So please check out the first

second and third then continue the for

this session and um I will share the

link of the playlist in the uh

description of this video. So uh in this

uh session number four we will uh

understand the onion architecture. First

we will see some of the theory. Uh after

that I will show you this in practice.

uh uh there I create one template and I

will show each part in the template and

I will also share the template link in

the video description. So u so what is

onion architecture? So uh there is one

principle like u uh the onion

architecture software design first of

all this is a software design pattern

that organize the code in layer. So

onion architecture have different layers

but the key principle is the dependency

direction. So uh like the outer layer uh

can reference inner layer but the inner

layer doesn't have reference to the

outer layer. So this is the key

principle uh of the onion architecture.

So this is a basic diagram. We have the

first layer the infrastructure layer.

Then in the middle we have application

uh specific code. So infrastructure we

have a basis file uh cloud services. So

this is the basic version of the onion

architecture. So the core um concept uh

you will think like onion the inner uh

innermost layer contain your core

business logic but what your application

actually do uh it's in the um it's in in

layer while the outer layer handle

technical concern like database web APIs

web interfaces and the external system.

So this is the core concept of the uh

onion architecture. So in onion

architecture we have as we mentioned in

the slide we have some different type of

layers. So outermost layer is called

infrastructure layer. It contain all the

technical drivers like uh database

connections, web frameworks, uh UI

components and it handle the dependency

injection and reference all the inner

layer but uh never reference by them. So

this is the outer most we will see this

in diagram as well as in code as well.

So uh second we have uh if we go check

this is the uh complete on as you said

as I mentioned that in the outermost

layer we have uh infrastructure

infrastructure have database uh

databases files cloud services and web

APIs. So this is the first layer the

infrastructure layer uh handle

dependency injection reference all the

inner uh layers but never reference by

uh by other. So uh second we have

application layer uh uh define uh what

operation your application can perform.

So in this layer we have all the use

cases all the uh like command handler

queries inside this uh this layer uh

like it contains use cases application

specific workflows and uh it have only

uh reference by the domain layer. So

this is the second layer we have

application layer and this is the heart

of the on architecture like the domain

layer which is also called the core

layer. Uh uh it contain all the business

entities and rule uh and uh it's the

heart of the application like what

application fundamentally do it's inside

the domain layer and it has no

dependency on other. So uh we will see

this in action. It has no uh reference

by other project and uh

domain layer sometime like split into uh

model like entities and domain services.

We will see this in action like we will

cover this course uh with respect to uh

domain driven design. So in domain

driven design we have entities aggregate

root aggregate. We will see this in uh

in practice. So this is a complete uh

diagram of the model architecture. First

we have the infrastructure and uh then

we have application services and then we

have domain layer. So uh infrastructure

have database web APIs and other UI

component and uh application services

have all the use cases what the

application can actually perform and the

the heart of the application domain

layer all the business rules and models

is inside in the domain layer. So this

is the complete uh onion architecture.

Okay as you can see that uh this is the

onion architecture uh template. So as

you can see here we have uh basically

four layer the the first one uh we will

go one by one. So first we'll uh discuss

the infrastructure layers. So

infrastructure layer we have a DB

driver. So there is one uh C# class

library that contain the database

related things and uh we can also call

the web API layer as a infrastructure

layer. So these two layer web and DB

driver is the part of the

infrastructure. The DB driver uh handle

the DB connection. You can see here this

is DB context. Uh it has all the

required model and all the migration

related things. U and if we go to the

repository it has all the repository

implementation like uh in this template

I'm considering the car booking

application. So it have uh it has

booking repository, core repository and

uh uh and user repositories. So also we

have extension to connect this model to

other. So we have this extension we will

call this in uh like program the main uh

dependency injection. So this is the

infrastructure layer and second uh if I

go back to the you can see here um the

first layer infrastructure then we have

application layer. So if you go back to

the code you can say here application

layer this application layer and uh

first I will also show you the

references. So the key principle of the

the key principle of the uh onion

architecture uh this is the uh infra

infrastructure layer and it has only uh

reference uh of the automain layer. So

nothing else um command handlers like it

will create booking it will create car

create user. So this is like the command

uh command handlers use cases you can

see if I open uh so this will create a

booking for us. So this is uh one of the

use case and uh in this folder the

command folder we created the command

like if we if you are going to create a

booking so this will be the command this

is like a request okay first we will

pass the user id par ID start time and

end time. So this is like uh the command

for this command handler um you can see

here I'm passing it the I request

handler. So this is the command we

created in the command folder. So next

we have uh event some uh like inside

microservices or domain do design um

entity when any entity uh change and

when any change happen in entity so it

will u create some event. So when

booking happens this event will be uh

this will uh raised. So we will see this

uh in uh like detail uh in the event we

have extension uh like data uh uh

dependency injection handler and this

service collection to connect with other

part of the application. Then we have

queries. Uh so we have uh in the secure

we have some command and queries. So um

for this we um get all the available

cards we have this query get user

booking. So we uh we define all the

queries here. So this is my main point

is to show you the application layer. It

has all the use cases. Uh the domain

layer the domain layer have like all the

domain entities all the business logic.

So uh this is model booking model for

example. Uh this is the booking model uh

username car and uh this is the all for

the car. This is user. So we have all

the all the core model inside this

domain layer. So let's come back to the

slides.

Okay. So I practically show you how the

domain uh

domain look like like first we have the

infrastructure then we have application

then we have the domain layer. So the

dependency is going inward to towards

the domain layer. The domain layer will

be independent. It will not contain any

reference. the application service will

have reference only to the domain layer

and the infrastructure layer only

reference the application layer not the

uh domain layer. So this is the

dependency principle for the uh onion

architecture. Now next we will cover the

domain layer of the onion architecture.

So core concept is contain domain

entities like classes with behavior

encoded uh with public u methods and

entity can only be defined through the

method presenting actual domain

operation. uh you can think like as a

domain driven design we will uh focus

mainly on the domain driven design so it

use also use a unambiguous uh language

in the business uh business name will

follow the same language so this it's

called unbu language okay so then we

have the domain layer domain layer uh

domain entities we have state can only

be changed through the method that

encoded actual domain operation and uh

we have aggregate aggregate must be

completely covered from the persistence

code and we have like Each domain layer

have one repository interface as well

and uh in the domain layer we have like

one is called the domain entity and we

other have the core ef core yeah entity

framework core entity domain entity have

method enforce business rule and tree of

nested object like aggregate aggregate

is the group of related object it's

called the aggregate in in domain driven

design and um uh efropy

value pair with no methods and it have

uh only sing it only save data inside

the database uh so there is some

difference between these two. Okay. So

please understand this uh domain entity

have method in for business rule and uh

it also have the aggregate like group of

related entities and but the entity

framework entities just uh property

value pair and u then we have aggregate.

What is aggregate uh complex uh tree of

object related order. For example, if we

have order and uh the other um object is

purchase order. One is called purchase

order and the other one is purchase

order item. So this is the example uh of

the aggregate. So we will also check the

aggregate route as well. uh for example

if we have purchase order purchase order

and and one is purchase order item. So

uh purchase order item cannot exist

without the purchase item. So here the

aggregate root is purchase order and uh

child object cannot exist independently

like purchase order item cannot exist

without purchase item. So uh manipulate

it as a single unit. So we can treat

this as a single unit also called it

aggregate. So here is the example of the

aggregate. We have purchase order where

we have uh purchase order items. Okay.

And u only thing uh that can change uh

or manipulate the purchase order item is

the purchase order. We cannot access

purchase order item outside the purchase

order. So this is the rule of the

aggregate indent design. So uh you can

see here in this purchase order we have

we can add we can remove uh item to the

purchase order type list. So this is the

uh we have the aggregate inside domain

design. Then uh there is one another

concept inside domain domain design is

the value object object with no

identity. So in in identity in domain uh

identities we have one unique

identifier. So HD can be identified

uniquely but in case of value object we

have no u ID there is no uh identity

inside this object like for example if

we have address uh in address we have

phase number uh street number house

number. So these three connect value

object related to the address. Same for

the money as well and it's mutable once

it's created cannot be changed and uh

implemented as C# also provide the uh

record. So we can implement this as a

record when we do actual coding and

there is no repository needed repository

interface needed for value object. So

here is the example of the value object.

Uh in do design for example if we have

address like country on street so

combined we create one credit card which

is called the value object. So uh next

we'll cover the repository pattern um

like uh since aggregate and value object

differ from ORM entity like RM actually

save the data inside the database but

aggregate and value objects are

different we we checked in the previous

slides when using ORM to interact with

database you must translate OM entity

into aggregate and value object and vice

versa each time exchange data with ORM

to the ORM we exchange data from the ORM

entity to the aggregate value object and

uh aggregate and value object to the

ORM. So in this case the domain layer

interact with actual OM implementation

through the interfaces. So in this case

we need the repository pattern. So this

is the core uh concept why we need inter

um repository pattern in the domain

design. So this is the reason and there

is one rule each aggregate root I mean

we said that aggregate root main entity

in a group of related entity like in

aggregate we have related entities and

there is one thing uh entity uh which is

called the aggregate root all the child

entity aggregate depend on the aggregate

root uh should have its own repository

interface. aggregate root one interface.

This is the rule and the repository work

with the whole aggregate but not with

the individual entity. So this is the

another rule. This keep your code clean.

What is the purpose code clean modeler

and align with DDD domain driven design.

So we will follow the domain driven

design principle. So that's why we need

this repository. We must follow this

repository rules. Uh example of this uh

repository is purchase order. For

example, in previous uh slide we see

this is a purchase order. This is one

aggregate and uh what is the uh root

aggregate? Purchase order is a root

aggregate and that what is the child u

child entity purchase order item is a

child entity. So this aggregate it will

need one repository one repository and

here is the rule this example of the

repository. Okay and we have new geting

delete as deleted as with the purchase

order and get release. So this is all

the functionality it will provide. So it

will need the interface. So next we have

uh domain services layer. In complex

application, it's best practice to split

the domain layer into model layer and

domain service layer. Okay. So domain

layer uh contain only aggregate like

entities and value object entity have

unique identity and value object without

key. So this keep key difference and the

domain service layer. What is the

purpose of domain service layer? Contain

repository interface and domain

operation that does not belong inside

the aggregate. So contain repository

interface stis and domain operation that

does not belong inside aggregate. So

this is each like model have domain

layer have domain service layer as well.

So domain service layer have the

repository work only uh with aggregate

like order customer and but sometime you

do not want to the whole aggregate you

just need a read model like u uh get

data from any database. domain service

you want to show a dashboard. For

example, if you want to show dashboard

with customer name, order total order

and last order date. So this is the

requirement. So this will not come from

the single aggregate but it will come

from uh like customer and order. So here

we will use the domain service that will

interact with different domain or

different entities like um customer and

order. Uh now we will go deeper into the

application service. Uh it's a layer

about the domain layer. So uh you can

see here uh this is our application

layer. So it's uh have only one

reference domain layer. So it's the

layer above the domain layer. So the

second layer application layer. We'll

discuss this in detail. Uh it does

contain domain rule. Domain rule itself.

For example, order cannot be uh less

than zero. Something like when we uh add

item to the c or when we place order.

Order must be credit. This is one of the

simple uh business rule domain rules and

um not leave in aggregate and domain

service. But it accept command uh it

accept what what is the accept command

uh and query. They accept command and

query. You can see here um it have the

command and the queries

all the right repository or uh query

service public domain event uh is

something important. Uh we can see here

these are events. So when booking

created uh we will raise this event. So

service also raise the uh domain events

as well. Okay. We have a command

operation query operation uh command

modify aggregate through repository. Um

repository can raise domain event as

well like placeholder event and query

use query service it return duple uh no

domain events just return data. So this

is about the application layer uh when

you go to the query it does not have the

event no domain events just return the

data but uh this uh uh like we have

create event handler uh command uh when

booking is created if this event will be

generated. You can see here uh when we

create the booking so when we create the

booking at the last point publish to

main event. So this is called plishing

domain event. Uh command ar raise the

domain events. So this is I explain this

in the code. Um application uh service

operation operation in the application

service layer are split into two types

like queries command already discussed

command exe execution can trigger

events. Uh also application service must

uh also handle domain events already

explained and we have queries. This is

the some deeper look of the queries. a

query object one or several similar

queries usually have one or several

method that take input and return the

queries query result. If you go to the

query for example get available car

queries. So uh it will uh get it will

get this query uh we are only passing

the location this is the query and this

is the query handler most query method

call single repository method reming the

needed query to some some execute serial

repository. So query can also get data

from single repository and it also can

get data from multiple repositories as

well. Uh next we have uh query testing.

During system testing actual query

implementation are placed by fake

implementation. So each query has a

associated interface coupled with the

actual implementation in the dependency

in engine. This enable the UI to require

only the interface to infrastructure.

Allow testing with fake implementation.

If we don't use the interfaces here so

the system will be unable to test. So to

test that uh we must like you can see

here this query is inherit from the I

request handler. If we don't do this

like u inherit from the any I request

handler the system cannot be testable.

So uh to make the system testable is

most important thing. So we must follow

this uh testing principle. So like this

is the example we have one query that

contain and uh that will return the

basic uh information video and it will

take the start and uh you can see here

um uh we are inheriting this purchase

order by started from the I purchase

order by start query. So this is

important thing and uh and I purchase

order by started query is inheriting

from the IQ query interface. So I query

interface is necessary for to make this

system testable. Next we have command.

We will see command in detail. command

work differently because each command

represent a single application operation

for better code readability. Uh like

command we follow the single repository

principle like each command will have

only single operation. So each uh IU of

work like IU of what is unit of work in

DDD or Q plus CQS we are following

momentum design and CQS uh like in DDD

and CQS each command uh load aggregate

each command load aggregate via

repository uh call method on them to

apply changes uh command apply changes

and uh then we have save changes. So uh

first we load then call the method to

apply the changes then we uh have

another uh save changes in database but

in reality you may touch multiple in a

single command you want them to uh you

want them all to save or rotate together

like for the transaction if we deal with

multiple uh command so make uh to make

this atomic transaction this uh we will

use the uh unit of work the job of the

to make all the repository operation to

make it in the same transaction. If I go

back to the uh here to the code uh

you can see here I have I unit of work.

So it will make uh the atomic

transaction to make the transaction

atomic we use the I unit of work. We

save entities we have start as commit

async and roll back asing. So example uh

unit of work example uh save starting

commiting and roll back. So uh unit of

work uh breakdown um we have uh sing uh

save entity as save all the update in a

single transaction return true if store

actually change otherwise false and

start we use to start the transaction

commit and roll back uh respectively

commit or roll back and open uh

transaction. So this is needed to make

the uh data uh consistent. Okay. So unit

of work transaction control method are

useful for this is the uh save start

commit and roll back. So this method

transaction are useful for uh in closing

get operation and final save entity as

save in the same transaction. So example

of uh this is um we start the

transaction uh we get all the flight

async uh if flight um there is no seed

uh we roll back if the seat is less than

zero we roll back the system otherwise

we commit. Okay, next is the domain

events. For example, uh let's go back to

the code. Uh let's go back to the code.

Uh you can see here when booking is

created. This uh is raised. The booking

u booking create event is raised. So

this is called domain event. This is

called domain event. Uh raised inside

the same microser when something

happened to aggregate. When something

change in the aggregate, the command

runs the uh domain event. For example,

order placed event in our example uh

booking created event. uh when a new

record is created handle single

handle inside the same microservices. So

uh it will be inside the microservices

boundary and it follow the publish

subscriber pattern. So for this is the

publisher and uh where is the subscriber

it will be inside the handler. So this

is the um the actual event handler. So

uh whenever anything any uh anyone

subscribe it will subscribe to this one

and it will be notified the event

notification. Okay there is uh two

things like one is the domain uh and

other one the integration event. So

anything uh happen inside the microser

it is called domain event. But if one

microser communicate with other microser

uh then we use the integration event

array to communicate across the

microservices. Example order place

integration event send to a payment

microservices are notification microser.

So here two microservices are

communicating to the integration event.

So this is two type like one is domain

event other one is the integration

event.

So why use why we use the event like

inside microservices boundary. So why

why this important? Aggregate arrays

event about important side change.

Instead of writing uh side effect inside

we uh we capture the event we capture

the event. This event can uh collected

and then the command handler publish

them before calling in work. This ensure

that event are only published if the

transaction succeeded. So uh if we go to

the code here uh you can see here uh we

publish the event after saving making

changes to the car repository then we

raise the event. So this ensure the

event are only published if the

transaction succeeded otherwise we will

not uh so we will also take help of the

event of work uh save changes async as

well that's why we u we define um events

inside the uh microservices boundaries

so this is the structure of the event we

have interface and then we have a

handler if I go back to this this is the

publishing event uh code and uh go

inside uh this is a domain event and

this is a definition of the event and uh

we are inheriting from the uh from uh I

notification handler.

So this is the example uh notification

event and uh associated each event with

all its handler. So here is example how

to associate event with all its handler.

So we have event event triggers and uh

inside that we have one uh structure

then we have one trigger. We will uh

learn how uh domain object work with

database because uh the business logic

of the domain should not know about the

databases because uh if they do uh they

will violate the user. It will use the

infrastructure layer. So this is not uh

uh recommended. So database store data

in table and rows and uh the business

object like aggregate uh work

differently than the database table like

uh we cannot pass domain object directly

to the entity framework entity framework

but model is different than the

aggregates or the business domain and

the ef

domain objects. So this is one of the

problem. So how we will uh fix this

problem? So there is one solution called

a state object pattern. State object

pattern. So the core idea of the state

object pattern is that it separate the

state from the behavior. So uh state

mean like data like object has some data

and the behavior mean the logic. So uh

with the help of state object pattern we

separate the state and behavior. So how

we'll do this we will see in the next uh

slides. So uh first of all uh for

example uh uh first step we create the

state interface where we define all the

properties like uh creation date u

delivery time and the list of item. For

example if we use the purchase order

state. So this is the first step. The

second step will be u business object

use this interface. So we will pass this

uh state uh interface inside uh the

constructor. We will use the a get

constructor and we will pass that state

uh with the help of our constructor. And

uh then uh we will save this uh state

inside privately uh private variable

private state variable. As you can see

in this example we have one private

variable I purchase order state uh and

uh I'm passing the state inside the

constructor and we are saving the state

inside the private state v variable. So

this is the second step and the third uh

step you will modify the entity like

database entity you will inherit it from

the uh the interface purchase state. So

as you can see here uh in first step we

created the state interface and we are

inheriting u the database entity from

that state interface. So this is the

last step. So uh how I will show you

this in the code like if I go to the

code. So you can see here uh I modified

the code uh to uh fulfill the

requirement of the state uh pattern.

Okay. So you can see here uh now this is

the aggregate and uh I created one state

interface called IICR state. You can if

I go to this you can see here uh this is

all the properties needed uh for this

aggregate and uh this is the first step

and uh second we are the aggregate is

the uh we are passing this state

interface using this aggregate

constructor and we are saving the state

inside uh this private variable. So this

is the um example of the uh uh state

object pattern and uh you can see here

we have in this uh class we have

behaviors uh and uh we have behaviors

and uh the state is uh located in this

state interface and the second part this

is the database model. Uh so uh we are

inheriting this from the I state call.

So this is the last step. So you will

follow this pattern to uh make this u

like u state object to follow the state

object pattern. So that's uh this uh in

this way we can uh communicate with

database and uh database and uh so this

is the example of the state object

pattern. So here uh is the so this is

the life cycle of the uh aggregate

aggregate life cycle. So first uh for

example u we are uh we need some

customer data. So we'll use the uh

repository interface. Uh so uh it will

get all the data from the repository

using the DB driver and uh the DB driver

will contact with the ORM. ORM will map

the data and it will get the data from

the database. So this is the first uh uh

flow u it will give the data. Uh so you

can see here uh from the right side the

the database will provide you the tool

and uh then the ORM the ORM will start

tracking that entity. ORM will start

tracking the the entity and u the

aggregate the constructor aggregate will

create uh will accept the state state of

the uh entity state of the entity by

using the aggregate constructor and it

will create new aggregate. You can see

here uh in the dashed uh line the

aggregate is communicated uh the

accepting the state through the uh

aggregate constructor. So uh once the

aggregate uh ex uh receive the state uh

then uh we will make changes to the data

then uh unit of work in the last flow

you can see here from the left to right

uh we have unit of work after making

changes we will call the save entities

and uh implementation of unit of work

will uh pass that changes to the ORM

engine. Basically the OM engine will

follow the tracking. So the magic here

is the tracking. So you can see here the

test arrows uh it will track all the

changes and it will update the data

inside our database. So this is how the

uh state object pattern work. Okay. So

this is the last topic. So I hope you

will find this helpful. If you have any

question you can ask and if you are new

to this channel please subscribe and uh

like this. Hello everyone. Welcome back

to practical serverless and

microservices with shar. My name is

Muhammad Abdullah and I am Microsoft

certified as a as your solution

architect. For this course, our agenda

is uh to understand the ser serverless

application, how serverless application

work, how to deploy serverless

application. We will understand the

microservices on onion architecture,

different type of onion architecture

like domain layer, application layer and

uh uh infrastructure layer. Then we will

learn docker and then Azure function,

there are different uh triggers,

background function, IoT function,

microservices in detail. And uh we will

u u uh we will see microser organization

with uh kubernetes how to uh use

kubernetes with microservices. And then

we will uh learn practically container

and kubernetes and uh is your container

app and uh how to apply security

observability for serverless and

microservices application. And for this

course we will see the uh the car

sharing application uh microservices

practically and uh lastly we will see

microservices uh with netswire. So this

is our agenda. If you missed the

previous lectures, please check out and

uh you can continue. Session number five

is related to docker. So we will learn

about docker. So microservices need to

be independent of their host environment

to enable easy load balancing and to use

the hardware uh utilization. So uh we

are facing one challenge like if you are

working with legacy application with new

newer modules they use the different uh

development stack that create dependency

in the environment. Each uh stack has

own requisite. So this is our challenge

to to fix this challenge. Uh the older

solution is to uh deploy each

microservices on the separate virtual

machine. So this is the old uh solution.

But here is one problem with this

solution like virtual machine are slow

to start and stop. So this is the

problem with mic virtual machine because

they have their own copy of the

operating system which is insufficient

for microservices that need to be quick

like microservices need to be quickly

start. So uh this is the one problem

with virtual machine. So uh we can uh

fix with this problem with the container

solution like container is lightweight

and efficient uh form of the

virtualization. So uh in this uh video

we will see the uh container. So uh the

container solution how they work like u

virtual machine virtual machine that

utilize the entire um machine including

the operating system uh container

utilized at the file level and uh they

sit on the top of the operating system

kernel and they use the host operating

system like kernel DL driver but use it

native feature to isolate processes and

resources. This create an isolated

environment for the application they

run. So uh this is the um how the

container work like we will see in this

in diagram like uh we are comparing u

docker container and virtual machine and

you can see here virtual machine have

infrastructure layer then host operating

system then uh the virtualization uh

tool hyper visor and uh it have like

three virtual machine virtual machine 1

2 3 and they each virtual machine have

their own guest operating system but in

case of docker they are using the host

environment like host operating system

and they use the docker engine and they

create a container to run a different

application. So this is the main

difference between container and the

virtual machine. So a container have u

the what is container like uh the

running instance of application is

called container. Uh they are created

from the images. So first we have images

then uh from images we create multi

containers uh multiple instance of

container and what is images already uh

read only template that contain all the

necessary code instruction library

dependencies to run the application. The

same image can be used to create

multiple identical container. We can

create multiple uh container from single

um image. And uh what is image directory

where images are uh stored and managed

uh like you can think like uh docker hub

we can store images uh in docker hub we

can also use ACR as your uh container

registry. So this is a type of

repositories where we can uh save the

images and um this is the naming u image

naming and tagging. Uh for example u uh

first of all we have this is the example

ncr.microsoft.com. So this is the part

of the uh domain registry and net is the

name space and sp.net is the repository

name and 9.0 is the tag number. So this

is the URL of the image. Whenever you

need any image from any repository you

will just uh uh place this URL. You will

get this URL and you can uh you can use

that image. So this is the URL of the

image and um now we will discuss the

container and image life cycle like

process any runtime that need to create

container download the required image

from our registry. So for example if you

need a net runtime so you will use uh

that uh you will get this from registry

and you can use it. Uh some some uh

images required u credential as well

like there is two type of one is public

one and the private one. Private one

need the credential as well. image to

container. Once the image is downloaded

when you download the image the runtime

use it to create one or more container.

So then we can uh create container as

many as we want. So here you can see

here the u the instruction doer file uh

is nothing but instruction then we

create image from that and we save ACR

or docker hub. So we can uh use that and

then you can we can pull and we can use

and we can create containers. So uh here

we will see the docker what is docker

like u a defacto standard for working

with containers. So we have docker file

any runtime that need to create

container download the require image

from the registry it may need cred to

access the registry building images. Uh

docker images are generated by applying

change.

Okay. So now we'll discuss the form

instruction like when you create docker

file uh they have the form instruction u

like docker file usually start from a

form uh it specify the base you need to

modify for example uh form mcr

microsoft.com/net/sp.net

and uh 9.0. So this is the form

instruction you will see uh this uh when

we do a practical uh docker file u uh

creation and uh this uh set the build

stage or the starting environment. So,

so this is the like your computer pull

the image and uh it's built and they uh

after building they run the container

and you can see the application. So,

this is building we will see this uh in

pract practice as well. We will build

the image and uh registry URL the full

URL specify the registry domain we

already discussed the how the URL look

like they have the uh registry domain

name space repository and the tag we

already discussed this is the example

the uh you can use any type of registry

like docker hub registry and is uh is

your container registry. So this is a

view where you can store the image and

uh we have the images in a hierarchy um

like the images and container in the

hierarchy first like image one two and

uh you can number of images and uh each

num uh each image have n number of

containers. So this is some of the

hierarchy of the images and container.

Uh okay so uh key docker file

instruction. So uh when we see the

docker file we have working directory

instruction like we discussed the form

now we are discussing the working

directory uh so working directory define

the current working directory inside the

image file system if the direct does not

exist it's create so below is the

command instruction the full instruction

so uh yeah so next is the copy

instruction copy file or folder from

your computer into image file system can

copy a single file a whole uh folder and

multiple file as well here is command

instruction. So we will see this uh all

the command in our docker uh file. Uh

and next is the run execute a shell

command inside the image. For example uh

run uh net restore. So this is the type

of the uh run instruction. Next is the

cmd and entry point. Specify the command

and argument to be executed when a

container is run for the image. So below

is the cmd and entry point instruction.

And next is the expose. declare the

network port that container support it

act as a documentation. It does not

block traffic to other uh ports but uh

signal which port are intended for use.

So this is for port uh we can use the

expose and uh uh if next we'll discuss

the stages uh like um um docker have

docker file have sometime multi-stage

build as well. So so what is the concept

behind this multi-stage build? A docker

file can build intermediary image to

create the final uh smaller image. For

example, create an image that contain

the entire net SDK using form

instruction. This is the build stage for

example and then uh use run to compile

your entire net solution and create a

separate final image using a different

form instruction like uh just the net

runtime. So once your application is

built then you will run uh you will need

the runtime uh to run the application.

So uh this is multi-stage build. We'll

see this as well. Um and use copy from

build to copy only the compile binary

from the build image into the final

stage. So what is the benefit of this?

The final image is much smaller in size

because it does not include unnecessary

build tool or source code which is more

secure and efficient for production

level. So if you uh want to do a

production level setup so you you can

use the multiple stage build is highly

recommended.

So uh for example I will go back to the

my visual studio. Uh so you can see here

this is a multi-build stage. Uh this is

the the base it's create the base. So

this is stage number one the base stage

and this is the build stage. Uh this is

the build stage and this is the publish

and this is the final stage. So this is

uh like multi-stage docker file. So only

the only purpose is to u u get the

smaller image. So I will go back to the

slides. So

okay next is uh get in the docker file.

Uh if you are new to docker file you can

use the you can install the docker file

on your um Mac machine and window

machine. I already have um downloaded

for example uh what u docker file I

require for using docker on your

personal computer. It include like a

docker runtime to create and run the

container from images a docker client to

build images. We can build uh we can run

and uh we can also store the images in

local um uh local registry as well. And

u this course assume you are using the

Windows machine with WSL

windows subsignite for Linux install and

configure for the Linux container. So I

already install uh WSL uh so for Linux

so I will show you for example if I go

to the this is the docker desktop

application. uh you can see here

where you can find uh all the running

containers. So this is the uh one

container which is currently running.

When you click you can go to the log.

You can see the application is currently

running. You can inspect and uh this is

bind mouse execute all the execute uh

files and this is the file system of the

image and this is the states. So uh and

you can also see the images all the

images uh volume uh to get the

persistent state we can use the we will

see this in detail and all the builds

and this is the basic version if you are

you didn't you can install this docker

to run the uh application. So let's go

back to the slides.

Okay. Okay. So uh here we will create

one simple application de to demonstrate

how docker can build and run uh a

program without needing the language

runtime or SDK install on your host

machine. So this is the uh simple open

the visual studio. So I already created

one simple uh console application. So

there is nothing just uh one main

program and uh how you will add the

docker support to this project. So uh

here you have two option whenever you

create new project you will create new

project you can uh go with the name you

will uh give name then here you can see

uh that u framework and uh you can see

here enable container support when you

uh check this it will add the docker

support and here this is the container

OS so you can choose the Linux and the

windows so I will go with Linux and

here's the container build type so uh I

have docker file I will select the

docker file and you will create click on

the create. So when you create uh the

project will uh the visual studio will

be uh add the docker file in default. So

um but if you don't have uh docker file

uh in start you can also add it to

existing project as well. So you will

click on the u right click and you will

add click on the add and you will see

here u docker support. So when you click

on the docker support it will ask for

few options like I need I will go with

the Linux uh I will go with the docker

file not the net SDK and here is the

container image uh dro this is the

engine type so I will go with the

default one and uh this is the build

context this is the path where this is

root path of my project so I will create

the docker file in the same root level

so I will click on the okay

so you can see here one file is added

which is the docker file And here is the

detail of the toker. So it's a

multi-stage. I already uh discussed the

multi-stage. Why we need a multi-stage?

It's for production to get the image

smaller uh and production ready and

secure. And you can see here um first it

will uh get the net runtime for us and

the working is uh uh the current this is

the working the image image working

directory and this is the second build

stage. Uh it will get the net SDK 9.0.

zero and uh this is working direct for

this is uh CRS and it will copy from u

this is my current project uh path and

uh from my current project path it will

copy the file into a simple uh example

this it will create the new folder and

it will put here and next is the publish

part it will publish in final stage it

will uh run the uh delay net run you can

see here enterpoint net run so this is

the example if I uh run this you can see

here you can see this option uh dot uh

container docker file when I run it will

run the application currently. Uh you

can see here uh if I run this

application

so uh it's uh run.

You can see here when I open the

uh the container tab you can see here

the the application is running inside

the container. So this is how you can

add uh docker file to your u visual

studio project.

So uh you can see here uh this is the

same uh same code uh docker file I

created in the window studio. So now we

will discuss the different stage in

detail like uh this is the multi-stage

uh build. So the first stage is the best

the stage one is the best. You can see

here it's a runtime. Uh what is the

purpose? provide lightweight runtime

environment only the net runtime not the

SDK. So you can see here we separate the

net runtime from the SDK. So it's a

multi-build. So first is the base um and

uh image usage we are using the runtime

image contain just the end of that uh

for the net application and uh what is

the user app uid you can see here the

second instruction uh run the container

as a nonroot user security UID is

expected to be uh set externally. So you

can set this uh extendingly the UID uh

for the security purpose and the other

is the working the directory

instruction. Uh so we have set working

directory where the app will run. So it

will set the uh directory. So this is

the first the second is the build stage.

You can see here the build stage is u

compile application image usage. We are

using the SDK image uh that restore

build and publish. And uh this is the

steps uh like copy project from separate

optimized doer cache uh restore copy and

build command. And the third one is the

publish uh prepare the app for

deployment like net publish and uh uh

other uh instruction like use host uh a

host false. So you can see here if I go

to the publish uh the publish is using

the build config configuration to

release and they have some uh

instruction as well like uh use app host

equal to false and uh it will use the

net publish and the final stage uh the

final stage is the actual runtime uh

runtime container based on the base

stage runtime only not no SDK it will

only use the runtime copy publish file

from the publish stage into app and set

the setup command like net uh uh run net

simple uh simple example DL. You can see

the final one working directory app and

it will copy the file and it will uh run

the uh DL. So this is the multi-stage uh

build. I explain each uh stage in detail

and um next why we need multi-stage. If

you build everything in one image, the

final image could be uh include the SDK

and build file make it huge. The size

will be huge. So, which is not uh useful

for production. So, um uh this approach

uh like a multi-stage approach use the

SDK image only for building and use the

runtime image for production which is

lightweight, faster and safer. So, this

is the purpose. So, I will recommend to

use the multi-stage uh uh docker file.

Okay. So, next is the building how you

can build the docker file. So this is

the build command docker build uh / dot

slash uh then uh t sample app. So um

here is the explanation. The docker file

the command to build an image for from a

docker file uh and the dot forward slash

specify the the docker file is in the

current directory and and uh comma t

simple example take the new image to the

name. we specify the name uh and take

are used to name and version image. So

this is the uh type of u build command.

We'll write docker build dash forward

slash

um t uh and then you will give name. So

when you click uh enter it will start uh

building. So you can see here the image

is built. So this is how you can uh

build your image. So this is the build

command. And the next uh is all image

name must be in lower case. So you will

uh follow this rule like lower case. Uh

you can also uh run this command like

docker images that will give you all the

images list. For example, if I go here

and run the docker images. It will give

all the images. You can see here uh this

is the simple example is the latest

image I built. So uh this is about the

images list. You can also uh check uh

from the docker desktop UI as well.

Next.

Okay. Next is how you can run after

building you will run the docker image.

So this is the command docker run uh d

name. You will give name to your

container first container. Uh and this

is the image name uh simple example. So

you can see this create and run a new

container named first from the uh simple

image. Uh the program output this

program running in auto container will

be displayed. So this is the uh run

command. So how we will run like uh

docker

uh run d you will give name my first

container

and this will be the image name example

uh container. So next we will see a list

container. Uh there there is two command

like docker ps uh it will list my uh

running containers uh and u docker ps d

all list all the container including

those that have stopped. So let's uh see

these two command.

Okay. So uh first I will uh check the

docker

ps. So you can see here this is the

current running uh uh there is nothing.

So let's uh write the other command

a docker

docker ps uh d- all. So you can see here

one uh image is running one container is

running. This is the container id the

image name command and created date and

uh this is the other information. So

next we'll see uh restart and stop

container. You can also restart local

restart uh container name. This is the

restart command. And uh here is other um

removing and stopping container. You can

run docker stop my container. You can

run this command in powershell. And uh

the other one is remove a container,

remove an image from your local

registry. So this is some um other

command you can use in your uh this is

the text source take uh and uh target

image. This command attach a new tech to

an existing image. Take or native name

for an image. Taking is the first step

to prepare an image for the pushing to.

So this is when you want to push the

image to registry. So uh you can use

this uh by taking name.

Okay. So uh this is how you can like

push and pull uh images like u uh you

will need uh to know the registry like

docker. You must uh use the tag like

docker take my image you will push to

that repository. It will attach take to

that image when uh you visit the um

repository. Uh so you can see here uh

the tag. So you can also push to the

first you will take and then you can

push to the uh like Azure if you you

have Azure C ECR you can push to that.

So you can see first take and then push

pulling an image you can use this

command do pull uh regist uh URL u of

the uh image. So this is how you can

pull the image logging into registry. U

if you are using u Azure you can use uh

a login uh it will require username

if you uh su successfully login you can

uh use the login name you can uh mention

the registry name. So uh uh another

thing is that like visual if you are