Up next in 10
Join this live session with Magnus Mårtensson ft. Marc Duiker for the next episode of The Cloud Show with Magnus Mårtensson on June 11, at 01:05 PM (EST).
The show is about cloud leadership and all the important questions relating to cloud projects. Certainly, many matters when a company is going to and wants to be successful in the cloud, are about technology. However, there are many additional matters, adjacent to technology, that we also need to tend to regarding business strategy, human resources, organizational change, planning for a technical cloud approach, and many more questions. These conversations are critical for a healthy cloud and for a swift and accurate cloud approach.
Guest Speaker
Marc is a Sr. Developer Advocate at Diagrid with a strong focus on event-driven architectures. He loves helping developers to achieve more every day. You might have seen Marc at a developer meetup or conference, since he's a regular speaker and event organizer in the area of Dapr, Azure cloud, and serverless technologies. From 2019 to 2024, Marc received the Microsoft Azure MVP award for his community contributions.
📺 CSharp TV - Dev Streaming Destination http://csharp.tv
🌎 C# Corner - Community of Software and Data Developers https://www.c-sharpcorner.com
#CSharpTV #csharpcorner #TheCloudShow #CSharp #interview
🎙️ New to streaming or looking to level up? Check out StreamYard and get $10 discount! 😍 https://streamyard.com/pal/d/5348850450038784
Show More Show Less View Video Transcript
0:01
hello everyone welcome to another
0:03
episode of the cloud show today we're
0:05
going to talk about some really cool
0:08
building patterns when you build
0:09
applications in the cloud to help you
0:12
build better and faster applications
0:14
there is an open-source uh project
0:17
called Dapper uh and I'm going to talk
0:19
to one of the community managers of
0:21
Dapper uh it's going to be interesting
0:23
we're going to talk about how to build
0:24
effective applications for the cloud and
0:27
lots of things like that um so the star
0:29
of the show today is Mark Dalker
0:33
[Music]
0:43
hello Mark welcome to the uh cloud show
0:46
thank you so much Magnus thanks for
0:48
inviting me absolutely it's my pleasure
0:51
indeed uh it's lovely to have you i I
0:53
know that we tried to schedule this a
0:55
couple of times and we had to reschedu
0:56
but here we are finally it's it's nice
1:00
to uh to be to be here with you so um
1:04
you uh let's Hey let's let's start to
1:07
check in on you sir what's going on
1:09
what's going on in your life and who are
1:10
you
1:12
right so hi I'm Mark um you already gave
1:15
me the introduction that I'm one of the
1:16
deer community managers there are three
1:18
community managers in in total uh I've
1:21
been doing this for about two and a half
1:23
years now I think um so it's really like
1:26
an open- source role right because my
1:29
the role that gives me money is actually
1:31
being like a developer advocate for Die
1:33
Grid um and that's actually the company
1:36
founded by the co-creators of D open
1:38
source Mark Fussell and Yon Schneider
1:41
and yeah I've been very fortunate to to
1:43
join as a developer advocate and then
1:45
also getting this role as a um community
1:49
manager and yeah it's it's really it's
1:52
really a super nice role because like I
1:53
had lots of um audience engagement of
1:56
course lots of public speaking um I I
1:59
just finished our community call which
2:01
we do like once a month so I'm just
2:04
rolling from from one Streamyard session
2:06
to another Streamyard session so I I
2:08
feel like completely here oh great
2:12
that's lovely and so where does one go
2:14
if one wants to find the Dapper
2:17
community calls
2:19
so um they're live streams uh like via
2:22
stream but we we stream to both like
2:24
YouTube and LinkedIn and on X as well
2:27
the best place is u is YouTube so
2:30
there's the aterdev channel on YouTube
2:33
and that's really the best place to
2:34
watch because if you leave like comments
2:36
there we we actually see it and respond
2:39
to you so that's the best right lovely
2:42
so I said in the intro we're going to
2:43
talk about some some nice uh ways to
2:45
build cloud applications not only cloud
2:48
applications but that's that's how I
2:50
personally have have been in touch with
2:52
the Dapper because I'm a cloud guy and
2:54
um I have um you know over many many
2:56
years I have helped companies and and
2:59
teams and and and people to build
3:01
applications for the cloud and it's it's
3:03
challenging but a tool a um a a a
3:07
project like an open source project like
3:09
Dapper can really help so tell us first
3:13
of all which is the which is the problem
3:15
that we're facing here with building
3:17
applications like this
3:19
um one of the problems that that we're
3:21
facing is that that let's say the whole
3:24
development life cycle can become quite
3:25
tedious if you're like building
3:27
microservices and distribute
3:28
applications uh because like you have a
3:30
lot of things going on right you have
3:32
many different services that need to be
3:33
all be spun up at the same time uh the
3:36
testing becomes difficult um you usually
3:40
have a like you have like a dependence
3:41
on like cloud resources right so maybe
3:43
you want to do some like easy developing
3:46
locally but yeah sometimes you cannot do
3:48
that because you need to connect to a
3:50
state store in the cloud or you need to
3:51
connect to a message cloud and that can
3:54
be really really tricky sometimes so
3:55
yeah that's one of the reasons that and
3:57
the open source project right so um from
4:01
from from my own experience then um you
4:04
know like we have an we have a web
4:06
application or something an API I and
4:08
then we have to connect to a database
4:10
and then we might need to use a caching
4:12
service and then we might need to use
4:14
Azure storage and whatnot and and all of
4:18
these things have an API and all of
4:20
these things you have to implement the
4:22
uh the um the you know the usage
4:25
patterns that works with that service or
4:28
using a Cosmos DB and how do I know that
4:30
I'm using it properly and various visual
4:33
SDKs yeah exactly yeah all of them have
4:35
an SDK and all of them have a way to use
4:38
them right and so I have to I have to
4:40
write I have to author that custom code
4:43
for all of those exactly yeah so you you
4:46
need to learn all of these SDKs of all
4:48
these individual products out there and
4:50
and if you're just Yeah and if you're if
4:52
you're dealing with one cloud well one
4:54
cloud has dozens of these services
4:55
already but if you're dealing with
4:56
multiple clouds well then you just have
4:58
a multiplication factor of so many
5:00
different state or so many message
5:02
brokers so yeah if you're doing hybrid
5:04
cloud or or multiloud yeah it becomes
5:05
like like an exponentially difficult
5:08
thing to uh to have yeah have all the
5:10
knowledge of all these SDKs how to deal
5:12
with resiliency and security
5:15
derive takes takes time and effort right
5:18
so so how does then Dapper come into
5:21
this what do we like how do I put Dapper
5:23
in there and helps that helps me with
5:25
this yeah so the role of Dapper is is is
5:29
really let's say quite unusual so when I
5:31
first ran into it I felt oh really this
5:33
deer is not part of your own application
5:36
but it runs in a separate process next
5:38
to your application so the sidecar
5:41
pattern because it's it's you can maybe
5:43
visualize like a sidecar motorcycle
5:47
where the deer process sits in the in
5:49
the sidear of the motor um but that that
5:53
takes away a lot of the a lot of the
5:55
heavy lifting that you as a developer
5:56
would normal normally do so for instance
5:59
um if you need to write resilient code
6:01
and you want to include like a retry
6:04
mechanism or something well you either
6:06
take a dependency a certain package or
6:07
you write it yourself but there can be
6:09
different retry mechanisms again on the
6:11
different SDKs uh but in this case deer
6:14
provides like a built-in mechanism for
6:16
for retries and resilency and for
6:18
timeouts
6:20
but whatever you are calling all of the
6:22
communication goes through this sidecar
6:24
so you as a developer don't have to
6:25
worry about retry mechanisms because
6:27
that's what Dapper is doing yeah so
6:30
that's that's the I think the canonical
6:31
and really really cool example that that
6:33
and there there are many other other
6:36
applications and and and ways to use
6:38
Dapper and and and connect to different
6:40
services but but one of the really good
6:42
ones is what you're saying there there
6:45
is the retry mechanism and okay why are
6:47
we retrying well it's because our
6:50
application runs where it runs in in
6:52
some sort of a compute service right
6:53
it's running in a web app or in a
6:55
container app or somewhere and it calls
6:58
to a different service storage for
6:59
example i'm just calling storage what if
7:02
storage doesn't respond the way we
7:04
expect what do I do i retry i figure out
7:08
how to retry again and usually oftent
7:10
times that solves the issue and so
7:12
retrying is code that I have to write
7:15
and understand how to write and get it
7:17
right and do it right and and uh Dapper
7:20
has already implemented that for me
7:23
exactly yeah exactly brilliant so so how
7:26
do I then like from my code how do I
7:28
call this thing what do I do yeah
7:30
exactly yeah so um so Deer provides like
7:33
an whole API service that you can use in
7:36
your application so for instance in your
7:38
application let's say we are talking to
7:40
coos db to store some state uh so in
7:42
your application you would normally use
7:43
the coos dbdk
7:46
but when you use dapper you use the
7:47
dapper SDK or you make u http or gbc go
7:51
straight into the deer sidecar so you
7:54
don't have um dependencies anymore in
7:56
your application code to the underlying
7:58
infrastructure so ah right there's no
8:02
dependency on the specific SDK or SDK
8:05
version or whatn not of of whatever API
8:07
we're calling exactly yeah and so so
8:10
deer actually decouples your application
8:11
from the underlying infrastructure yeah
8:13
so you can see there's like an
8:14
abstraction layer and it has APIs for
8:16
like state management and for pops up
8:18
and for like secret stores it has a
8:21
built-in workflow engine now there's
8:24
actual model is bu built in so you can
8:25
see like with deapper you have like an
8:27
entire tool belt at your servers and you
8:30
could just pick tools from the tool belt
8:31
and then use it uh and if there's yeah
8:34
your tool a lot of tools you don't have
8:36
to use all of them just to use the the
8:38
stuff that you actually need yeah
8:40
because I mean that when you think about
8:41
it that's really just good architecture
8:43
right if you're a software architect
8:45
that's just good architecture to
8:47
abstract away the specific
8:48
implementation of a specific storage um
8:52
do I need to have a reference to the
8:54
storage uh SDK inside of my code not
8:58
really i should be using an interface or
9:01
similar to say hey uh store file uh my
9:04
my my code that's needs to store a file
9:07
doesn't need to know about which storage
9:10
mechanism it is that I'm in fact using
9:13
right exactly yeah that's just good
9:15
architecture i wish everyone did that
9:19
yeah definitely yeah well it has so it's
9:20
it's and it's not only useful for doing
9:22
like hybrid cloud or multiloud but it's
9:24
also very useful when you compare like
9:26
doing local development and then pushing
9:28
to test or another yeah smart because
9:31
it's just an abstraction at that point
9:33
yeah ex exactly yeah yeah so when I just
9:35
do some local development for like a
9:37
proof of concept code um I use like a an
9:40
in-memory state store which of course
9:43
you can see it more like a cache but but
9:45
for my local running proof of concept
9:47
that's totally fine but when I want to
9:49
push then I just change one of the deer
9:52
component files which is a yl file and
9:55
then point to like a different state
9:56
store like coos db and yeah no
9:59
replication changes are are required
10:01
right so you can have a pretty
10:03
rudimentary simplified um state store or
10:06
or local version and then I say okay but
10:09
when I run in the in the Azure cloud I
10:11
want to use Cosmos DB for example and
10:15
then technically if you ran in another
10:18
cloud you could say I want to deploy the
10:20
same application but now I'm using a
10:21
different state store I'm using what for
10:24
example yeah well you use like like like
10:27
S3 or something there if if you want to
10:29
use right an S3 bucket in Amazon or or
10:32
something like that and that's just at
10:33
that point that's just a technically a
10:36
configuration change yeah exactly
10:38
there's no code change involved no no no
10:40
no that that's really the power of
10:41
deapper that only requires some some
10:43
YAML files which of course nobody really
10:45
wants to write YML uh but there are also
10:48
some some tools for that to be honest uh
10:50
but yeah it is like a super convenient
10:52
way to just write i'm going to be I'm
10:54
going to be honest and say that I've
10:55
I've said in in in a couple of these
10:57
shows that that there's probably no
10:59
technology that I like less that we have
11:01
to use than YAML
11:04
yeah and I agree
11:07
but but uh but but fair enough so you
11:10
you the point still is that that the the
11:14
the code that handles all of that
11:16
messiness which you can swap for any
11:18
other kind of mess um is is separate
11:22
from your code and and it is it is a
11:24
separate concern and you call it from
11:26
your code um as a separate process one
11:28
process calls a different process says
11:30
hey I want to store this file and that
11:33
whatever it's configured to do it's
11:34
going to you know ring up that storage
11:38
service and and do its magic and if it
11:41
needs retries it's going to do retries
11:43
and various things
11:46
that's absolutely brilliant because I've
11:48
seen so so many um over the years
11:50
goodness me I've seen so many
11:52
interesting ones um I was um I I'll just
11:55
give share a brief anecdote and and
11:57
it'll probably make you laugh a little
11:59
um uh there was a a gentleman who who
12:03
was deploying an application and we were
12:05
testing it and um it was a cloud
12:07
application and was using ashure storage
12:08
and he was like okay this uh this you
12:11
know I've deployed it test it see what
12:13
you like and we started testing it was
12:15
really slow and something wasn't really
12:17
working so we're like what's up here and
12:19
so I started looking into the the the
12:21
storage traffic and and like checking
12:23
the monitoring like how many requests
12:25
are made to storage and I just noticed
12:27
this this really weird pattern of
12:30
requests i'm like this is makes sense
12:32
and I let me can I check on your code
12:35
there and he literally had copied the uh
12:38
getting started bit from the uh Azure
12:40
documentation and pasted it into his uh
12:43
you know and it worked right so what he
12:45
did all the time was that in every every
12:47
time he touched storage he first checked
12:50
to see does this storage account exist
12:52
oh yeah does this does this container
12:54
exist yes it does and then he went to
12:57
proceed to store his his server so so he
12:59
made several round trips extra for
13:01
everything that he did right and it's a
13:03
classic thing that the person who made
13:06
it work didn't really have cloud mileage
13:11
and deep deep understanding you know
13:13
what I mean sorry for the anecdote there
13:15
but you know what I mean this is this is
13:16
a common problem right yeah exactly yeah
13:19
that's it's also very hard to to fix
13:21
that you know so yeah you always need
13:24
like a certain level of understanding
13:26
even if you use deer right so even if
13:28
you don't really know all of the or
13:31
don't need to know all of the SDKs it's
13:33
still good to understand the underlying
13:34
model where your data actually is or
13:36
what kind of you're actually using um
13:39
but yeah sometimes also it also depends
13:42
on what kind of organization you are
13:43
right because some development teams you
13:45
need to do everything they're like truly
13:47
devops you build it you run it for some
13:50
teams they have like maybe like
13:51
dedicated platform engineering teams and
13:53
they can have like the ownership of all
13:55
of the infrastructure and how it works
13:57
and and why it works and and then then
13:59
you can give these the deer APIs to the
14:01
developers and they can be like
14:02
completely agnostic of what whatever
14:04
they're they're running on yeah and I
14:06
really like that again that's just good
14:08
architecture for me so how big is how
14:10
big is Dapper now i mean the huge
14:13
companies using Dapper right yeah
14:15
definitely yeah yeah so so Deer be so
14:16
deer is part of the uh CNCF the cloud
14:18
native computing foundation uh it's been
14:20
part of that since I think three and a
14:22
half years already now but since also
14:25
November it became a graduated project
14:27
which is a really big thing in in CNCF
14:30
um and you actually get like audited
14:32
like a really uh really really big big
14:35
audit and then they go and interview
14:38
like deer end users so what what do the
14:40
end users actually think of deer how do
14:41
they use it what what are the benefits
14:44
get all kinds of security test and and
14:46
so on and so on so yeah it's a really
14:47
big thing to be a graduated project
14:49
within the CNCFA it really means some
14:52
some big companies are indeed using
14:54
using Exactly yeah so exciting um really
14:58
this is this is um uh such a such a
15:01
unique service uh in in the cloud i've
15:05
I've been in the cloud for a long time
15:06
and and when I when I heard uh you know
15:09
um the founders of of of the sort of the
15:12
project or the open source project
15:14
starting talking like oh we're going to
15:15
go open source with this I was like
15:17
that's that's brilliant um and so the
15:20
community is thriving i mean this is
15:23
what you do you're a community manager
15:25
how's the community yeah yeah so well I
15:28
think in numbers so we have a pretty big
15:30
discord i think there's there's are I
15:32
think over 8,000 members in the Discord
15:34
so so they're not active all the time
15:36
all these 8,000 members but on any given
15:38
moment on the Discord there are like 5
15:40
to 600 users online there so that's
15:44
definitely the best place if you have
15:45
questions about Deer or maybe you want
15:47
to help out other people to become
15:49
successful with Deer Deer Discord is
15:51
definitely the place the place to be
15:53
yeah right what's the typical usage uh
15:56
of of Dapper like what kind of a uh team
16:00
is there maybe there isn't a typical one
16:02
but No it's it it Yeah it varies a lot
16:06
on it sometimes we see um backend
16:09
developers really um as Yeah it usually
16:12
like like a bottom up approach right so
16:13
the developers u see it in because they
16:17
went to maybe one of my sessions at a
16:18
conference or they just stumbled on the
16:21
deer.io your website and and read about
16:23
and try it so developers get excited uh
16:26
sometimes it's via more the platform
16:28
engineering angle yeah so platform
16:30
engineers they always look for for for
16:31
standards and and and easy ways to to to
16:34
configure things but also to be very
16:36
flexible without changing a million
16:37
things so so they discover Deer and then
16:40
mention it to their development teams
16:41
okay you should probably write your
16:43
write your applications using Dapper um
16:46
so so yeah those are the two routes we
16:49
see yeah so it's either from the back
16:51
end developers themselves or or from the
16:53
platform engineers who are kind of sneak
16:55
in to really be successful and quickly
16:58
um deploy stuff in the All right yeah so
17:04
so as a as a sort of a rounding off uh
17:07
today's episode um I'm new to Dapper
17:10
what am I going to do like how do I I I
17:12
like what I heard here today Mark i'd
17:14
like to get into this how do I do it
17:16
what do I do um well the first thing go
17:18
to the website it's deer.io that that's
17:21
the best starting point because that
17:22
points to all of the other places where
17:25
you can learn about deer so there's a
17:27
quick start um um um repository also
17:31
linked to the to deer.io and they can
17:34
just clone that locally you can run all
17:36
the samples locally and because we all
17:39
using local components so it's easy to
17:42
run locally um and next to that via die
17:45
grid I've created a lot of learning
17:47
content that's called deer university so
17:49
that's also linked from the dire deer.io
17:52
website um that's like a free uh online
17:55
sandbox where you just run deer
17:57
applications uh in online sandbox
18:00
environment so that's probably the
18:02
easiest because you don't have to
18:03
install anything locally oh by the way
18:06
we didn't mention compatibility right
18:08
how many languages can you use Dapper
18:10
from right well yeah yeah so so so since
18:13
it's run in a sidecar it runs in a
18:15
separate application yeah it's you can
18:18
use any language
18:20
with with deer as long as you can make
18:21
like HTTP calls to the deer sidecar but
18:24
there are just about anything exactly
18:27
exactly but to make it a bit easier to
18:28
communicate to the sidecar there are
18:30
some um language SDKs uh so there's a
18:34
.NET SDK Java Python JavaScript there's
18:38
Go there's even a PHP one as well make
18:42
it even easier for you like if it wasn't
18:44
easy enough
18:47
makes it even easier still all right
18:49
brilliant yeah yeah so no matter what
18:52
else you need to know before we close
18:54
out um No well um one thing that that I
18:58
always want to know and if there are
19:01
people out there who are using Deer uh
19:03
then please please come and find me
19:05
because I'm always looking for for for
19:06
for case studies that can be on the CNCF
19:09
website because it's always nice to uh
19:11
to to share what people have been
19:13
building so if you go to the CNCF
19:14
website now go to case studies and
19:16
filter on deer i think there are now 12
19:19
case studies mentioned there and so if
19:21
you want to know okay which actual
19:22
companies are successful with deer go to
19:25
that but I'm always looking for for more
19:27
of these case studies
19:29
all right uh I was trying to see if if
19:32
we can get the uh URL on the screen but
19:34
at least it's um it's a Dapper.io is the
19:37
uh is the main resource to go to and
19:41
then you you're working for Data Grid
19:42
and Data Grid has a Dapper University
19:44
where you can learn how to get into it
19:47
even more um so that's that's another
19:49
another starting point point with data
19:52
grid uh with data grid yes
19:55
brilliant well I mean that I guess
19:57
that's that's it we There we go dapper
20:00
Grid Dapper Data Grid Dapper University
20:02
fantastic all right i think that's
20:04
that's sort of the end signal right
20:06
there
20:08
thank you so much for coming on the show
20:10
today it was uh absolutely lovely
20:12
talking i love Dapper i love the
20:14
technology i love the the problem that
20:16
it solves so I'm so happy that you were
20:17
on the show today Mark thank you so much
20:19
Magnus love it yeah absolutely my
20:21
pleasure absolutely and come back
20:23
anytime so um audience uh we will see
20:26
you guys next time on the cloud show
20:30
[Music]
#Arts & Entertainment