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: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: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: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: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: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: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: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: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: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: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