1
00:00:00,180 --> 00:00:01,260
Memi: Our next topic

2
00:00:01,260 --> 00:00:04,230
is API gateway and discovery.

3
00:00:04,230 --> 00:00:06,450
So, the gateway and discovery patterns

4
00:00:06,450 --> 00:00:11,220
solve the loose coupling challenge of services.

5
00:00:11,220 --> 00:00:12,420
To make it more clear,

6
00:00:12,420 --> 00:00:15,000
let's talk about a full blown application.

7
00:00:15,000 --> 00:00:16,470
This application will probably have

8
00:00:16,470 --> 00:00:18,450
at least six services.

9
00:00:18,450 --> 00:00:21,540
Naturally, they are going to communicate with each other.

10
00:00:21,540 --> 00:00:24,120
Now, if they communicate directly like this,

11
00:00:24,120 --> 00:00:27,270
we will have what is known as the "spider web",

12
00:00:27,270 --> 00:00:29,610
I guess you can understand why.

13
00:00:29,610 --> 00:00:31,080
Now, imagine what will happen

14
00:00:31,080 --> 00:00:34,500
if a single service will change its URL;

15
00:00:34,500 --> 00:00:36,990
see how many services will be affected?

16
00:00:36,990 --> 00:00:39,630
If your services map looks like a spider web,

17
00:00:39,630 --> 00:00:41,490
be ready for a nasty surprise

18
00:00:41,490 --> 00:00:43,770
when even one of the URL is changed.

19
00:00:43,770 --> 00:00:45,600
The spider web is a true sign

20
00:00:45,600 --> 00:00:47,760
of a strong coupling system.

21
00:00:47,760 --> 00:00:49,260
Now, there are a couple of ways

22
00:00:49,260 --> 00:00:51,300
to solve this coupling:

23
00:00:51,300 --> 00:00:54,900
One, build a Yellow Pages directory for the service.

24
00:00:54,900 --> 00:00:56,880
Whenever the service needs to communicate

25
00:00:56,880 --> 00:00:58,140
with other service,

26
00:00:58,140 --> 00:01:00,540
it asks the directory for the URL

27
00:01:00,540 --> 00:01:02,790
of the service it wants to access,

28
00:01:02,790 --> 00:01:04,920
and uses the URL it gets.

29
00:01:04,920 --> 00:01:07,740
This way, the URL is not hard coded into the service,

30
00:01:07,740 --> 00:01:09,090
and when it changes,

31
00:01:09,090 --> 00:01:11,490
the change affects only a single service,

32
00:01:11,490 --> 00:01:12,840
the directory.

33
00:01:12,840 --> 00:01:13,740
In this solution,

34
00:01:13,740 --> 00:01:15,510
there is only a single URL

35
00:01:15,510 --> 00:01:16,950
the services need to know,

36
00:01:16,950 --> 00:01:18,660
the directories.

37
00:01:18,660 --> 00:01:20,040
And so if it changes,

38
00:01:20,040 --> 00:01:21,720
which won't happen frequently,

39
00:01:21,720 --> 00:01:25,020
the change will be limited to a single URL only.

40
00:01:25,020 --> 00:01:27,180
You can develop one of your own,

41
00:01:27,180 --> 00:01:29,790
and there are some great tools that do just that,

42
00:01:29,790 --> 00:01:31,173
such as Consul.

43
00:01:33,270 --> 00:01:36,540
Another way, is to build a middleman or gateway.

44
00:01:36,540 --> 00:01:37,620
In this scenario,

45
00:01:37,620 --> 00:01:39,570
the service accesses the middleman

46
00:01:39,570 --> 00:01:42,120
and asks it to go to the stock service,

47
00:01:42,120 --> 00:01:43,680
and make a query.

48
00:01:43,680 --> 00:01:46,050
The middleman holds an internal mapping table

49
00:01:46,050 --> 00:01:48,420
which maps tasks to URLs,

50
00:01:48,420 --> 00:01:50,640
and so it knows which URL to access

51
00:01:50,640 --> 00:01:52,110
in order to fulfill the task

52
00:01:52,110 --> 00:01:54,480
given by the calling service.

53
00:01:54,480 --> 00:01:56,250
The calling service has no idea

54
00:01:56,250 --> 00:01:58,470
what the URL of the stock service is,

55
00:01:58,470 --> 00:02:00,630
or even if there is a stock service,

56
00:02:00,630 --> 00:02:02,580
all it knows is that he asks

57
00:02:02,580 --> 00:02:04,440
the middleman to do something,

58
00:02:04,440 --> 00:02:05,730
and it was done.

59
00:02:05,730 --> 00:02:08,880
It doesn't care how, where, and by whom.

60
00:02:08,880 --> 00:02:10,139
In this solution, also,

61
00:02:10,139 --> 00:02:11,757
there is only a single URL

62
00:02:11,757 --> 00:02:13,710
the service need to be aware of,

63
00:02:13,710 --> 00:02:14,700
the middleman,

64
00:02:14,700 --> 00:02:18,120
so changes will be limited to this single URL.

65
00:02:18,120 --> 00:02:19,797
So we talked about the gateway

66
00:02:19,797 --> 00:02:21,390
and the discovery patterns,

67
00:02:21,390 --> 00:02:23,013
and let's compare between them.

68
00:02:23,880 --> 00:02:25,980
So, the first thing to note,

69
00:02:25,980 --> 00:02:27,360
is that API gateway

70
00:02:27,360 --> 00:02:29,280
is quite difficult to implement,

71
00:02:29,280 --> 00:02:31,710
especially in an on-premise environment.

72
00:02:31,710 --> 00:02:34,320
There are many cloud implementation

73
00:02:34,320 --> 00:02:35,460
of API gateways,

74
00:02:35,460 --> 00:02:37,170
and they are much easier to use,

75
00:02:37,170 --> 00:02:39,960
but if you want to set up an API gateway

76
00:02:39,960 --> 00:02:41,790
on your server form,

77
00:02:41,790 --> 00:02:44,730
then be ready for a long setup.

78
00:02:44,730 --> 00:02:45,840
On the other hand,

79
00:02:45,840 --> 00:02:47,790
discovery tools such as Consul

80
00:02:47,790 --> 00:02:49,860
are very easy to implement,

81
00:02:49,860 --> 00:02:51,690
and can usually be set up

82
00:02:51,690 --> 00:02:52,953
in a matter of hours.

83
00:02:54,180 --> 00:02:55,830
API gateway, as we saw,

84
00:02:55,830 --> 00:02:57,060
is man in the middle.

85
00:02:57,060 --> 00:02:59,220
So API gateway stands

86
00:02:59,220 --> 00:03:01,980
between the services that call each other,

87
00:03:01,980 --> 00:03:05,580
and the services actually do not call other services,

88
00:03:05,580 --> 00:03:07,560
but they call the API gateway.

89
00:03:07,560 --> 00:03:08,550
On the other hand,

90
00:03:08,550 --> 00:03:10,950
the discovery is an external service,

91
00:03:10,950 --> 00:03:13,710
so when the service wants to communicate

92
00:03:13,710 --> 00:03:15,000
with other service,

93
00:03:15,000 --> 00:03:17,520
it first goes to the discovery service,

94
00:03:17,520 --> 00:03:18,770
gets the URL,

95
00:03:18,770 --> 00:03:20,760
or the endpoint of the other service,

96
00:03:20,760 --> 00:03:23,430
and then performs a direct call

97
00:03:23,430 --> 00:03:24,843
to the other service.

98
00:03:26,160 --> 00:03:27,090
API gateway,

99
00:03:27,090 --> 00:03:29,760
in addition to providing, well, gateway,

100
00:03:29,760 --> 00:03:32,100
can provide many other useful features

101
00:03:32,100 --> 00:03:34,560
such as authentication and authorization,

102
00:03:34,560 --> 00:03:37,080
monitoring, routing policies,

103
00:03:37,080 --> 00:03:39,660
load balancing, and lots more.

104
00:03:39,660 --> 00:03:42,960
Discovery provides mainly URLs,

105
00:03:42,960 --> 00:03:44,670
and sometimes also provides

106
00:03:44,670 --> 00:03:46,680
some basic load balancing services,

107
00:03:46,680 --> 00:03:49,770
but it cannot be used for all the other services

108
00:03:49,770 --> 00:03:51,990
that the API gateway can provide.

109
00:03:51,990 --> 00:03:53,340
So this is definitely something

110
00:03:53,340 --> 00:03:54,900
that you should keep in mind

111
00:03:54,900 --> 00:03:57,480
when choosing between API gateway and discovery,

112
00:03:57,480 --> 00:03:58,950
and you must take into account

113
00:03:58,950 --> 00:04:00,330
the ease of implementation,

114
00:04:00,330 --> 00:04:03,120
as opposed to the richness of the features

115
00:04:03,120 --> 00:04:04,950
offered by the API gateway.

116
00:04:04,950 --> 00:04:07,320
Now, when talking about API gateway engines,

117
00:04:07,320 --> 00:04:08,550
there are a handful of them,

118
00:04:08,550 --> 00:04:10,680
and you can see here a sample

119
00:04:10,680 --> 00:04:13,200
of the most popular API gateway engines,

120
00:04:13,200 --> 00:04:14,370
either on the cloud,

121
00:04:14,370 --> 00:04:16,589
such as Azure API Management,

122
00:04:16,589 --> 00:04:18,510
or AWS API Management,

123
00:04:18,510 --> 00:04:20,850
or Apigee of the Google Cloud.

124
00:04:20,850 --> 00:04:22,830
And the on premises engines,

125
00:04:22,830 --> 00:04:26,220
such as WS02, and Tyk.

126
00:04:26,220 --> 00:04:29,400
So, if you are using cloud environment,

127
00:04:29,400 --> 00:04:32,730
I strongly recommend to check out the API management

128
00:04:32,730 --> 00:04:33,960
of the cloud you are using,

129
00:04:33,960 --> 00:04:36,060
and if your application is on premises,

130
00:04:36,060 --> 00:04:38,340
then take a look at both those engines,

131
00:04:38,340 --> 00:04:40,620
WS02, and Tyk.

132
00:04:40,620 --> 00:04:41,453
Now again,

133
00:04:41,453 --> 00:04:42,930
API gateway is not a must,

134
00:04:42,930 --> 00:04:45,210
there are a lot of applications out there

135
00:04:45,210 --> 00:04:48,210
with a lot of services and a lot of APIs,

136
00:04:48,210 --> 00:04:50,400
that don't use API gateway.

137
00:04:50,400 --> 00:04:53,010
But you should definitely take a look at them

138
00:04:53,010 --> 00:04:54,840
and make an informed decision

139
00:04:54,840 --> 00:04:56,583
whether to use them or not.