1
00:00:01,150 --> 00:00:05,070
We've now got a working definition of what a micro service is now.

2
00:00:05,080 --> 00:00:07,580
At the end of last video we were looking at this diagram right here.

3
00:00:07,600 --> 00:00:10,580
And when you were looking at this you might have said to yourself Oh OK.

4
00:00:10,610 --> 00:00:12,090
Micro surfaces are easy.

5
00:00:12,100 --> 00:00:16,060
Oh we have to do is take a feature rapid and service and that's it.

6
00:00:16,060 --> 00:00:19,020
Well unfortunately reality is just a little bit different.

7
00:00:19,650 --> 00:00:23,880
It turns out that when we start working with micro services there are some really big challenges that

8
00:00:23,880 --> 00:00:25,430
we start to run into.

9
00:00:25,440 --> 00:00:29,730
So in this video I want to start to introduce one of these really big challenges.

10
00:00:29,730 --> 00:00:34,440
So here's what it is data management between services.

11
00:00:34,740 --> 00:00:40,080
When I say data management I'm talking about the way in which we store data inside of a service and

12
00:00:40,080 --> 00:00:44,420
how we communicate that data between different services.

13
00:00:44,460 --> 00:00:47,610
Let me take a pause right here and just tell you flat out.

14
00:00:47,730 --> 00:00:51,330
This is a very big very challenging problem.

15
00:00:51,330 --> 00:00:55,950
It is a huge obstacle to effectively using micro services.

16
00:00:55,950 --> 00:01:01,110
The good news is that this problem right here is what we are going to have an unending focus on in this

17
00:01:01,110 --> 00:01:01,590
course.

18
00:01:02,010 --> 00:01:06,210
And by the end of this course you're going to have a couple of different strategies we're working with

19
00:01:06,210 --> 00:01:08,610
this data management problem.

20
00:01:08,750 --> 00:01:11,600
Now let me tell you a little bit more about why this is a problem.

21
00:01:11,630 --> 00:01:17,510
Let me help you understand why this is such a big thing get so a little bit of preamble here a little

22
00:01:17,510 --> 00:01:24,500
bit of background with micro services the way in which we store data and access data is a little bit

23
00:01:24,620 --> 00:01:29,330
weird and what I mean by weird is that it's just a little bit different than what you might be used

24
00:01:29,330 --> 00:01:32,240
to with a monolithic application.

25
00:01:32,240 --> 00:01:36,860
So in the next couple of diagrams we're going to take a look at how we store data and how we access

26
00:01:36,860 --> 00:01:39,680
data in a micro services approach.

27
00:01:39,680 --> 00:01:45,860
So first off how do we store data in a micro services system we might recall the diagram we were looking

28
00:01:45,860 --> 00:01:52,300
at just a moment ago I showed a separate database for every service that we had created so whenever

29
00:01:52,300 --> 00:01:58,210
we are making use of micro services we're going to create a separate database for each service.

30
00:01:58,330 --> 00:02:02,530
If the service actually needs a database if a service doesn't needs a database that's fine.

31
00:02:02,530 --> 00:02:03,850
We're not going to give it one.

32
00:02:03,850 --> 00:02:07,720
But the point is every service gets its own database.

33
00:02:07,720 --> 00:02:12,790
Now that might sound really strange but going to give you a very good reason for this in just a moment.

34
00:02:12,790 --> 00:02:18,370
First let me also show you how we access data and once again this is going to be a little bit strange

35
00:02:19,900 --> 00:02:23,920
to access data on I'm not going to tell you exactly how we're going to access data I'm going to tell

36
00:02:23,920 --> 00:02:26,260
you how we are not going to access data.

37
00:02:26,260 --> 00:02:33,860
So we are never going to access data by reaching from one service into another services database.

38
00:02:33,910 --> 00:02:37,830
So under no circumstance will we ever have service say right here.

39
00:02:37,870 --> 00:02:41,270
Try to reach into the database for service B.

40
00:02:41,440 --> 00:02:46,360
And once again I'm going to give you a very good reason for this in just a moment OK.

41
00:02:46,440 --> 00:02:52,080
So in total here are the two big kind of surprising facts that I've now mentioned.

42
00:02:52,080 --> 00:02:55,000
First off each service is going to get its own database if it needs one.

43
00:02:55,020 --> 00:02:59,760
And secondly services are never going to reach into another services database.

44
00:02:59,760 --> 00:03:02,850
Now let me tell you why this is why are we doing this.

45
00:03:02,850 --> 00:03:08,310
Because these seem like two very strange rules there's a couple of different reasons.

46
00:03:08,320 --> 00:03:13,330
First I want you to understand that this whole idea of giving every service its own database is known

47
00:03:13,360 --> 00:03:17,110
as a pattern the pattern is called database or service.

48
00:03:17,260 --> 00:03:21,090
So as you'd expect that just means every service has its own database.

49
00:03:21,110 --> 00:03:24,910
Here are a couple of reasons and this is by no means an exhaustive list.

50
00:03:24,910 --> 00:03:31,030
The first reason and this is the really big reason is that we want every service we create to run independently

51
00:03:31,090 --> 00:03:32,960
of other services.

52
00:03:32,960 --> 00:03:37,630
So let me show you a quick diagram to help you understand why giving each service its own database is

53
00:03:37,630 --> 00:03:40,730
going to help with that all right.

54
00:03:40,860 --> 00:03:47,430
So first let's imagine a scenario where we have every service using the same common database.

55
00:03:47,430 --> 00:03:51,150
So maybe just one database right here we'll call it database for everything.

56
00:03:51,150 --> 00:03:56,250
The problem with this approach is that if anything bad ever happens to this database all of our services

57
00:03:56,280 --> 00:03:58,400
are going to crash immediately.

58
00:03:58,410 --> 00:04:03,270
The other big problem is that scaling this database right here would be really challenging if every

59
00:04:03,270 --> 00:04:05,990
service inside of application uses the same database.

60
00:04:05,990 --> 00:04:12,000
We're going to scale up that one database instance or that one database to service all of the different

61
00:04:12,000 --> 00:04:13,490
services of our app.

62
00:04:13,620 --> 00:04:20,950
It would be a lot easier to scale just the databases that need additional capacity or throughput.

63
00:04:20,960 --> 00:04:22,610
The other scenario that we could run in.

64
00:04:22,610 --> 00:04:29,340
Let's imagine that we've got service a reaching out to database these service right here if anything

65
00:04:29,520 --> 00:04:34,940
ever goes wrong with the database be right there then all of sudden service day is going to start to

66
00:04:34,940 --> 00:04:39,580
crash because we have introduced a dependency between service say and service B.

67
00:04:39,680 --> 00:04:45,050
So if a request comes into service a and feature a tries to reach over to this database and something

68
00:04:45,050 --> 00:04:48,790
is wrong with that database boom service say is going to crash as well.

69
00:04:48,860 --> 00:04:54,850
And so rather than just losing service B we would now also be losing service a.

70
00:04:54,980 --> 00:05:01,400
So why given each date of each service its own database and making sure that each service only uses

71
00:05:01,400 --> 00:05:08,090
its own database we dramatically increase the uptime of our entire system now.

72
00:05:08,090 --> 00:05:14,120
Next reason let's see right here the next reason that we have this database per service pattern is that

73
00:05:14,120 --> 00:05:18,110
the schema or structure of a database might change unexpectedly.

74
00:05:18,110 --> 00:05:23,240
So quick example of this as well I want you to imagine for a second that we've got service a reaching

75
00:05:23,270 --> 00:05:25,460
directly over to database b over here.

76
00:05:25,460 --> 00:05:27,160
And again this is not what we want.

77
00:05:27,170 --> 00:05:29,830
I'm giving you an example of why we do not do this.

78
00:05:29,890 --> 00:05:35,900
Let's imagine that future Ray usually runs a query of something like get user inside a b and usually

79
00:05:36,110 --> 00:05:40,840
database B returns an object that has a name of Jill or something like that.

80
00:05:40,970 --> 00:05:45,100
Whatever the name is the point is that's got a key of name right there.

81
00:05:45,140 --> 00:05:50,660
Let's imagine that for some reason service be the team that is in charge of it decides to change the

82
00:05:50,660 --> 00:05:56,630
schema or the structure of this database and maybe they decide that rather than giving every user a

83
00:05:56,630 --> 00:06:04,130
name property maybe they want to call that first name instead let's further imagine that maybe the team

84
00:06:04,160 --> 00:06:09,980
in charge of service B does not tell the team in charge of service say about the change to the schema

85
00:06:09,980 --> 00:06:11,120
right here.

86
00:06:11,120 --> 00:06:16,340
If that were to happen then the next time that service a makes a query down here they're going to get

87
00:06:16,340 --> 00:06:23,250
back an object that has a first name property instead of name service say was probably not configured

88
00:06:23,340 --> 00:06:25,680
to expect to see a property of first name.

89
00:06:25,680 --> 00:06:31,950
And so now we might start to have some issues start to arise and service a all because we tried to rely

90
00:06:32,040 --> 00:06:37,320
upon a database located in a different service and that second database right there had its structure

91
00:06:37,320 --> 00:06:43,020
or schema change at some point in time the last reason I'm going to throw out your really quickly is

92
00:06:43,020 --> 00:06:47,580
that some services might be able to function more efficiently if they are using a different type of

93
00:06:47,580 --> 00:06:48,150
database.

94
00:06:48,210 --> 00:06:54,270
So for example maybe one service can run more efficiently if it uses Mongo or Mongo DB as opposed to

95
00:06:54,270 --> 00:07:00,630
post crests or something similar to that this whole database per service pattern might seem a little

96
00:07:00,630 --> 00:07:04,860
bit surprising and you might already be saying Steven there's no way this is how it's done there's no

97
00:07:04,860 --> 00:07:07,850
way we're creating a separate database for every service.

98
00:07:07,890 --> 00:07:09,320
Well this is reality.

99
00:07:09,330 --> 00:07:15,030
This is how every successful engineering team out there is using micro services.

100
00:07:15,030 --> 00:07:18,420
They are all every last on them following this pattern right here.

101
00:07:18,420 --> 00:07:21,150
One database or service.

102
00:07:21,180 --> 00:07:21,420
OK.

103
00:07:21,450 --> 00:07:24,240
So now we've set up this kind of weird pattern right here.

104
00:07:24,240 --> 00:07:29,700
We still have not really touched on why data management between services is really challenging.

105
00:07:29,700 --> 00:07:34,050
So quick pause right here we're going to come back next video and start to expand on this in just a

106
00:07:34,050 --> 00:07:34,770
moment.