1
00:00:00,480 --> 00:00:03,480
foreign

2
00:00:08,820 --> 00:00:12,540
welcome back everyone I hope everyone

3
00:00:10,679 --> 00:00:14,940
had a good lunch

4
00:00:12,540 --> 00:00:18,060
uh our first Speaker back after lunch is

5
00:00:14,940 --> 00:00:20,520
Seoul kaganoff principal at Deloitte and

6
00:00:18,060 --> 00:00:22,500
involved in the apis AIDS Australia

7
00:00:20,520 --> 00:00:26,480
conference so so please take it away

8
00:00:22,500 --> 00:00:26,480
okay thank you

9
00:00:28,680 --> 00:00:33,480
okay well thanks for coming along today

10
00:00:31,560 --> 00:00:35,579
I hope you're all enjoying the

11
00:00:33,480 --> 00:00:41,100
conference I'm having a great time I got

12
00:00:35,579 --> 00:00:42,840
my geekong with the uh ska earlier today

13
00:00:41,100 --> 00:00:47,040
um right

14
00:00:42,840 --> 00:00:49,440
um so I'm talking about not only apis

15
00:00:47,040 --> 00:00:51,899
for the connected universe but also

16
00:00:49,440 --> 00:00:55,620
events related to the connected universe

17
00:00:51,899 --> 00:00:58,140
as well I guess a motivation for picking

18
00:00:55,620 --> 00:01:00,059
this topic is that I work with a lot of

19
00:00:58,140 --> 00:01:03,539
people on designing distributed

20
00:01:00,059 --> 00:01:06,360
Solutions on designing apis and they've

21
00:01:03,539 --> 00:01:09,240
been driven architectures Etc and I'm

22
00:01:06,360 --> 00:01:11,640
increasingly hearing people so it's a

23
00:01:09,240 --> 00:01:13,860
vibe that I observe

24
00:01:11,640 --> 00:01:16,560
um a lot of people saying oh we want to

25
00:01:13,860 --> 00:01:18,780
make everything now event driven and

26
00:01:16,560 --> 00:01:22,380
asynchronous and that's going to be the

27
00:01:18,780 --> 00:01:24,900
new goodness and I kind of worry when I

28
00:01:22,380 --> 00:01:27,380
hear that because I think there's

29
00:01:24,900 --> 00:01:29,460
benefits and drawbacks to events

30
00:01:27,380 --> 00:01:32,159
event-driven architecture there's

31
00:01:29,460 --> 00:01:34,380
benefits and drawbacks to apis and so I

32
00:01:32,159 --> 00:01:37,259
wanted to talk about that today and talk

33
00:01:34,380 --> 00:01:39,960
about how you can conceptualize the two

34
00:01:37,259 --> 00:01:43,380
how they relate to each other and how

35
00:01:39,960 --> 00:01:47,060
you can make judicious choice assets as

36
00:01:43,380 --> 00:01:47,060
to um which way to go

37
00:01:47,100 --> 00:01:52,200
so just in terms of um defining what

38
00:01:50,520 --> 00:01:54,180
we're talking about I think you all know

39
00:01:52,200 --> 00:01:55,740
about apis so I'll probably just skip

40
00:01:54,180 --> 00:01:59,460
over that one but I'm talking about web

41
00:01:55,740 --> 00:02:01,200
apis not so much modbus apis but with

42
00:01:59,460 --> 00:02:03,540
web apis

43
00:02:01,200 --> 00:02:05,759
um and when we talk about events we're

44
00:02:03,540 --> 00:02:07,799
talking about the representation of

45
00:02:05,759 --> 00:02:10,800
something that has already happened

46
00:02:07,799 --> 00:02:12,900
typically in the world things like

47
00:02:10,800 --> 00:02:14,959
somebody's clicked the button on the

48
00:02:12,900 --> 00:02:17,700
user user interface

49
00:02:14,959 --> 00:02:20,099
a trade has happened on the stock market

50
00:02:17,700 --> 00:02:22,200
so we've got a new price tick on a

51
00:02:20,099 --> 00:02:24,720
particular instrument

52
00:02:22,200 --> 00:02:29,340
oh we had something like a plane has

53
00:02:24,720 --> 00:02:31,680
landed or a train goes over a way Bridge

54
00:02:29,340 --> 00:02:34,800
etc those are events that we are

55
00:02:31,680 --> 00:02:37,560
interested in in our systems

56
00:02:34,800 --> 00:02:40,680
um and when we talk about event-driven

57
00:02:37,560 --> 00:02:43,680
architecture then typically these are

58
00:02:40,680 --> 00:02:48,599
solutions or applications where we are

59
00:02:43,680 --> 00:02:51,319
using events to uh to deliver an outcome

60
00:02:48,599 --> 00:02:54,720
to communicate information between

61
00:02:51,319 --> 00:02:57,420
Loosely coupled services and good

62
00:02:54,720 --> 00:03:00,180
examples of events are Twitter where

63
00:02:57,420 --> 00:03:03,660
we're getting this Pub sub I'm I'm

64
00:03:00,180 --> 00:03:06,239
forever grateful to Twitter for making

65
00:03:03,660 --> 00:03:08,900
everybody understand what Pub sub means

66
00:03:06,239 --> 00:03:12,000
right publish subscribe

67
00:03:08,900 --> 00:03:15,120
podcasts are event driven you might not

68
00:03:12,000 --> 00:03:18,000
know the behind your podcast feed is a

69
00:03:15,120 --> 00:03:21,120
thing called RSS which is a list of

70
00:03:18,000 --> 00:03:22,920
events representing the publication of a

71
00:03:21,120 --> 00:03:24,840
media stream

72
00:03:22,920 --> 00:03:26,819
um and then you know areas like

73
00:03:24,840 --> 00:03:29,280
Logistics and those sorts of things

74
00:03:26,819 --> 00:03:32,280
utilize event-driven architecture

75
00:03:29,280 --> 00:03:32,280
extensively

76
00:03:33,659 --> 00:03:37,860
so

77
00:03:34,739 --> 00:03:41,940
if I'm a solution architect and I'm

78
00:03:37,860 --> 00:03:43,620
deciding how to design a solution I

79
00:03:41,940 --> 00:03:47,519
might be looking at well should it be

80
00:03:43,620 --> 00:03:49,920
API driven should it be event driven and

81
00:03:47,519 --> 00:03:53,340
there's various trade-offs that I can

82
00:03:49,920 --> 00:03:55,560
consider from that perspective so were

83
00:03:53,340 --> 00:03:58,860
they if we look at apis how do I use

84
00:03:55,560 --> 00:04:01,319
apis to deliver an outcome there's some

85
00:03:58,860 --> 00:04:05,459
benefits around apis they're pretty easy

86
00:04:01,319 --> 00:04:07,560
to use the tooling is very mature the

87
00:04:05,459 --> 00:04:09,780
tools and methods are very mature we've

88
00:04:07,560 --> 00:04:12,780
got lots of affordances built into our

89
00:04:09,780 --> 00:04:15,959
libraries Etc so apis are great they're

90
00:04:12,780 --> 00:04:18,060
awesome there's direct control over an

91
00:04:15,959 --> 00:04:20,820
API when I make a call

92
00:04:18,060 --> 00:04:23,639
when I get I will wait and get back a

93
00:04:20,820 --> 00:04:25,800
response and that response might be what

94
00:04:23,639 --> 00:04:29,100
I'm expecting or it might be an error

95
00:04:25,800 --> 00:04:32,220
and at that point I can then respond to

96
00:04:29,100 --> 00:04:34,440
that error or outcome and uh act

97
00:04:32,220 --> 00:04:36,300
accordingly so

98
00:04:34,440 --> 00:04:39,720
so they're very easy to work with

99
00:04:36,300 --> 00:04:43,080
there's also strong consistency usually

100
00:04:39,720 --> 00:04:45,360
in a well-designed system when I call an

101
00:04:43,080 --> 00:04:47,759
API and I make an update and the

102
00:04:45,360 --> 00:04:50,880
response comes back I can be guaranteed

103
00:04:47,759 --> 00:04:53,699
that that piece of information has gone

104
00:04:50,880 --> 00:04:55,380
into that system typically

105
00:04:53,699 --> 00:04:56,460
um however there's some drawbacks to

106
00:04:55,380 --> 00:04:58,440
apis

107
00:04:56,460 --> 00:05:00,780
um one is latency because I have to wait

108
00:04:58,440 --> 00:05:03,120
for the request and the response there's

109
00:05:00,780 --> 00:05:05,699
a round trip time there okay there's

110
00:05:03,120 --> 00:05:08,520
serialization overhead and there's also

111
00:05:05,699 --> 00:05:11,220
runtime coupling so if I make a call and

112
00:05:08,520 --> 00:05:13,080
the server isn't there what am I

113
00:05:11,220 --> 00:05:15,600
supposed to do about that or if I make a

114
00:05:13,080 --> 00:05:19,620
call and no response comes back at times

115
00:05:15,600 --> 00:05:22,620
out what do I need to do so that runtime

116
00:05:19,620 --> 00:05:25,080
coupling is often seen by people as a as

117
00:05:22,620 --> 00:05:26,580
a drawback

118
00:05:25,080 --> 00:05:28,800
on the other hand the vent driven

119
00:05:26,580 --> 00:05:31,139
architecture has got some strengths

120
00:05:28,800 --> 00:05:32,759
which address some of those issues with

121
00:05:31,139 --> 00:05:35,340
apis

122
00:05:32,759 --> 00:05:37,620
typically you can get higher volume and

123
00:05:35,340 --> 00:05:39,539
scale through events because they're

124
00:05:37,620 --> 00:05:40,639
Loosely coupled they're we're just

125
00:05:39,539 --> 00:05:43,320
publishing

126
00:05:40,639 --> 00:05:45,720
we do a fire and forget we don't have to

127
00:05:43,320 --> 00:05:47,880
wait for a response we can get higher

128
00:05:45,720 --> 00:05:50,400
volumes through our system

129
00:05:47,880 --> 00:05:51,660
uh there's runtime loose coupling when I

130
00:05:50,400 --> 00:05:53,940
publish an event

131
00:05:51,660 --> 00:05:56,759
there might be one or more subscribers

132
00:05:53,940 --> 00:05:58,440
to that that event I don't need to wait

133
00:05:56,759 --> 00:06:01,979
around and make sure that they've

134
00:05:58,440 --> 00:06:04,139
received the uh the information

135
00:06:01,979 --> 00:06:06,300
and I can talk to multiple subscribers

136
00:06:04,139 --> 00:06:08,039
at the time depending on what technology

137
00:06:06,300 --> 00:06:10,199
I'm using

138
00:06:08,039 --> 00:06:11,820
um however there's some also drawbacks

139
00:06:10,199 --> 00:06:14,520
around the Venture of an architecture

140
00:06:11,820 --> 00:06:17,100
because I'm typically doing this

141
00:06:14,520 --> 00:06:20,039
asynchronous publish

142
00:06:17,100 --> 00:06:21,900
um and fire and forget I don't

143
00:06:20,039 --> 00:06:25,020
necessarily have the information about

144
00:06:21,900 --> 00:06:27,600
failures at that point in time I often

145
00:06:25,020 --> 00:06:30,539
have to use other mechanisms to detect

146
00:06:27,600 --> 00:06:33,900
and respond to failures in my solution

147
00:06:30,539 --> 00:06:37,259
and that can that can create complexity

148
00:06:33,900 --> 00:06:40,620
uh so complex workflows in event driven

149
00:06:37,259 --> 00:06:43,020
architectures can be difficult or

150
00:06:40,620 --> 00:06:45,240
challenging

151
00:06:43,020 --> 00:06:48,300
so if apis have got some benefits if

152
00:06:45,240 --> 00:06:51,000
events have got some benefits uh how

153
00:06:48,300 --> 00:06:53,520
should I choose and maybe the answer is

154
00:06:51,000 --> 00:06:56,759
not to choose but why don't you use both

155
00:06:53,520 --> 00:06:58,979
okay and the way that you can think

156
00:06:56,759 --> 00:07:02,340
about using both apis and events

157
00:06:58,979 --> 00:07:05,400
together in a solution is to think about

158
00:07:02,340 --> 00:07:06,419
State models

159
00:07:05,400 --> 00:07:08,460
foreign

160
00:07:06,419 --> 00:07:11,639
so I'm going to introduce a state model

161
00:07:08,460 --> 00:07:14,940
to you the concept of State modeling and

162
00:07:11,639 --> 00:07:18,960
I'm going to use a Rideshare application

163
00:07:14,940 --> 00:07:20,460
right Uber Uber ride share or DD or what

164
00:07:18,960 --> 00:07:23,460
have you

165
00:07:20,460 --> 00:07:25,380
um as an example and we start out in

166
00:07:23,460 --> 00:07:27,960
order to get the state model for our

167
00:07:25,380 --> 00:07:29,759
solution we start out with our user

168
00:07:27,960 --> 00:07:31,919
stories and I won't read through all of

169
00:07:29,759 --> 00:07:33,479
these but typically the the business

170
00:07:31,919 --> 00:07:36,419
analysts have come to me and have said

171
00:07:33,479 --> 00:07:38,520
here we go here's the user stories can

172
00:07:36,419 --> 00:07:40,860
you go build this please right so I get

173
00:07:38,520 --> 00:07:44,699
a bunch of user stories about a rider

174
00:07:40,860 --> 00:07:46,620
wants to make a request for a ride a

175
00:07:44,699 --> 00:07:48,539
driver will accept that request the

176
00:07:46,620 --> 00:07:49,699
driver will show up at the pickup

177
00:07:48,539 --> 00:07:52,620
location

178
00:07:49,699 --> 00:07:55,319
the rider will jump into the car and

179
00:07:52,620 --> 00:07:57,840
they'll head to the destination

180
00:07:55,319 --> 00:08:00,840
after the ride has completed there will

181
00:07:57,840 --> 00:08:02,759
be a charge in the bill right

182
00:08:00,840 --> 00:08:05,099
um pretty standard stuff that I'm sure

183
00:08:02,759 --> 00:08:09,060
everybody's pretty familiar with

184
00:08:05,099 --> 00:08:12,419
so using these requirements these user

185
00:08:09,060 --> 00:08:14,660
stories we can come up with a diagram

186
00:08:12,419 --> 00:08:18,419
that looks kind of like this

187
00:08:14,660 --> 00:08:21,960
and this is this represents the state

188
00:08:18,419 --> 00:08:24,180
model for that ride share application

189
00:08:21,960 --> 00:08:26,699
our state model is really it's just a

190
00:08:24,180 --> 00:08:29,400
graph the nodes in the graph those

191
00:08:26,699 --> 00:08:32,599
um those rectangles rounded rectangles

192
00:08:29,400 --> 00:08:35,880
they are allowed states in the solution

193
00:08:32,599 --> 00:08:38,099
and the arrows the lines between the

194
00:08:35,880 --> 00:08:41,459
states represent State transitions right

195
00:08:38,099 --> 00:08:43,380
that's um I I'm sure many of you

196
00:08:41,459 --> 00:08:46,260
familiar with this

197
00:08:43,380 --> 00:08:48,180
so basically the idea is it's kind of

198
00:08:46,260 --> 00:08:50,700
like a workflow but actually it

199
00:08:48,180 --> 00:08:53,220
represents the universe of all possible

200
00:08:50,700 --> 00:08:55,320
states that my application can go

201
00:08:53,220 --> 00:08:58,380
through and so for example if we start

202
00:08:55,320 --> 00:09:01,080
out with that Circle up the top where

203
00:08:58,380 --> 00:09:03,600
where the the rider has opened their app

204
00:09:01,080 --> 00:09:06,180
and the requests for the ride that

205
00:09:03,600 --> 00:09:08,519
creates a new ride request and that

206
00:09:06,180 --> 00:09:10,980
immediately goes into the searching

207
00:09:08,519 --> 00:09:13,920
state so the ride request is out there

208
00:09:10,980 --> 00:09:16,019
and we're searching for a driver to

209
00:09:13,920 --> 00:09:19,740
respond to that ride request so we're

210
00:09:16,019 --> 00:09:22,860
now in that first state of searching and

211
00:09:19,740 --> 00:09:25,380
in the ideal World a driver will pick up

212
00:09:22,860 --> 00:09:28,200
that request they will respond on their

213
00:09:25,380 --> 00:09:30,000
app and say cool I'll I'll pick that

214
00:09:28,200 --> 00:09:32,940
person up

215
00:09:30,000 --> 00:09:35,940
and we will transition from the

216
00:09:32,940 --> 00:09:39,300
searching state to the accepted state so

217
00:09:35,940 --> 00:09:42,540
now the the rider knows is notified on

218
00:09:39,300 --> 00:09:47,940
their app that a driver has accepted the

219
00:09:42,540 --> 00:09:49,980
request and uh and is on their way to

220
00:09:47,940 --> 00:09:53,100
pick them up okay

221
00:09:49,980 --> 00:09:55,080
uh after the accepted State we go

222
00:09:53,100 --> 00:09:58,080
through to the next state which is where

223
00:09:55,080 --> 00:10:00,420
the driver is on approach and we want to

224
00:09:58,080 --> 00:10:04,140
send a notification to say that the car

225
00:10:00,420 --> 00:10:06,180
is approaching it's one minute away

226
00:10:04,140 --> 00:10:08,880
um Rider hops into the car

227
00:10:06,180 --> 00:10:11,940
we then in the next state which is in

228
00:10:08,880 --> 00:10:13,920
progress and then at the conclusion of

229
00:10:11,940 --> 00:10:16,440
the ride when they get to the

230
00:10:13,920 --> 00:10:20,160
destination we go into the final state

231
00:10:16,440 --> 00:10:22,920
which is the completed State okay

232
00:10:20,160 --> 00:10:26,279
um that that's the sunny day scenario

233
00:10:22,920 --> 00:10:28,620
where the ride succeeds we've also got

234
00:10:26,279 --> 00:10:30,540
other possibilities in the sense that

235
00:10:28,620 --> 00:10:32,580
well first of all there may be no

236
00:10:30,540 --> 00:10:35,279
drivers in the area so no one picks it

237
00:10:32,580 --> 00:10:38,100
up okay and that means that the ride

238
00:10:35,279 --> 00:10:40,140
request could time out and go into the

239
00:10:38,100 --> 00:10:43,620
state up at the top left which is

240
00:10:40,140 --> 00:10:46,160
there's no uh drivers available and

241
00:10:43,620 --> 00:10:49,680
that's pretty much the end of that ride

242
00:10:46,160 --> 00:10:53,100
uh tough luck to take a taxi

243
00:10:49,680 --> 00:10:56,839
um or the either the rider May cancel

244
00:10:53,100 --> 00:10:59,640
their request or the driver maybe after

245
00:10:56,839 --> 00:11:03,600
accepting a request the driver may

246
00:10:59,640 --> 00:11:05,579
cancel as well sometimes that happens

247
00:11:03,600 --> 00:11:08,100
so you get the idea we've got these

248
00:11:05,579 --> 00:11:10,200
State the state model and the arrows

249
00:11:08,100 --> 00:11:11,279
represent transitions from one state to

250
00:11:10,200 --> 00:11:14,820
another

251
00:11:11,279 --> 00:11:16,519
so what has this got to do with apis

252
00:11:14,820 --> 00:11:20,459
so basically

253
00:11:16,519 --> 00:11:25,320
you can use the state model to design

254
00:11:20,459 --> 00:11:30,000
your apis and if you think about an API

255
00:11:25,320 --> 00:11:33,060
um an API gives you a way of Performing

256
00:11:30,000 --> 00:11:36,480
two two real two types of actions

257
00:11:33,060 --> 00:11:39,600
one is a command so a command might be

258
00:11:36,480 --> 00:11:43,260
create a write request a command might

259
00:11:39,600 --> 00:11:46,519
be accept a ride another command might

260
00:11:43,260 --> 00:11:50,160
be change the destination location

261
00:11:46,519 --> 00:11:53,760
so commands end up being

262
00:11:50,160 --> 00:11:57,060
a mechanism an affordance which allows

263
00:11:53,760 --> 00:11:59,880
you to move your state model from one

264
00:11:57,060 --> 00:12:02,220
state to another state okay so commands

265
00:11:59,880 --> 00:12:04,040
move you across those arrows they move

266
00:12:02,220 --> 00:12:07,019
you from one state to another state

267
00:12:04,040 --> 00:12:09,420
there's also another thing that an API

268
00:12:07,019 --> 00:12:13,019
needs to do is tell you what the current

269
00:12:09,420 --> 00:12:15,779
state is okay and that's a query so my

270
00:12:13,019 --> 00:12:19,380
API a well-designed API should allow you

271
00:12:15,779 --> 00:12:21,779
to get the current state of the ride has

272
00:12:19,380 --> 00:12:25,440
it been accepted by a driver yet I don't

273
00:12:21,779 --> 00:12:27,600
know let's get the state and check and

274
00:12:25,440 --> 00:12:29,540
see okay

275
00:12:27,600 --> 00:12:34,440
so you can think about

276
00:12:29,540 --> 00:12:38,279
an API as being a way of driving

277
00:12:34,440 --> 00:12:41,459
um a state through a sorry a model

278
00:12:38,279 --> 00:12:44,040
through its different states and that's

279
00:12:41,459 --> 00:12:46,019
all inherent in the the HTTP protocol

280
00:12:44,040 --> 00:12:48,300
it's all built around that state

281
00:12:46,019 --> 00:12:52,560
modeling and in fact if you're familiar

282
00:12:48,300 --> 00:12:56,040
with a arrest API representational State

283
00:12:52,560 --> 00:12:58,399
transfer that's the s in rest s stands

284
00:12:56,040 --> 00:12:58,399
for state

285
00:12:59,760 --> 00:13:03,600
um

286
00:13:00,600 --> 00:13:07,500
you can also use the state model for

287
00:13:03,600 --> 00:13:10,440
events and basically any one of those

288
00:13:07,500 --> 00:13:13,380
arrows between states is an opportunity

289
00:13:10,440 --> 00:13:17,339
for you to publish an event representing

290
00:13:13,380 --> 00:13:21,480
the change in state right so a command

291
00:13:17,339 --> 00:13:24,660
changes state and an event notifies you

292
00:13:21,480 --> 00:13:29,459
that the state has changed okay so for

293
00:13:24,660 --> 00:13:32,399
example when uh the rider creates a new

294
00:13:29,459 --> 00:13:34,860
ride request that's a command the driver

295
00:13:32,399 --> 00:13:37,079
receives a notification an event

296
00:13:34,860 --> 00:13:39,600
notification to say hey there's a new

297
00:13:37,079 --> 00:13:42,480
ride request in your area what do you

298
00:13:39,600 --> 00:13:45,000
want to do okay

299
00:13:42,480 --> 00:13:47,160
um so any

300
00:13:45,000 --> 00:13:49,560
transition in our state model is an

301
00:13:47,160 --> 00:13:52,200
opportunity to trigger an event

302
00:13:49,560 --> 00:13:54,180
notification

303
00:13:52,200 --> 00:13:55,459
so if we come back to our Rideshare

304
00:13:54,180 --> 00:13:59,579
model

305
00:13:55,459 --> 00:14:01,620
I've color-coded it now to show the

306
00:13:59,579 --> 00:14:05,279
different perspectives from the

307
00:14:01,620 --> 00:14:06,420
different users in in our solution so

308
00:14:05,279 --> 00:14:10,100
the green

309
00:14:06,420 --> 00:14:12,720
arrows represent commands

310
00:14:10,100 --> 00:14:16,620
that a rider

311
00:14:12,720 --> 00:14:21,540
can perform through their API

312
00:14:16,620 --> 00:14:25,560
the pink arrows represent commands that

313
00:14:21,540 --> 00:14:27,779
a driver can perform through their API

314
00:14:25,560 --> 00:14:30,540
and then the um

315
00:14:27,779 --> 00:14:34,260
the blue arrows represent kind of system

316
00:14:30,540 --> 00:14:36,600
Transitions and there because the car is

317
00:14:34,260 --> 00:14:39,420
on its way through its journey and the

318
00:14:36,600 --> 00:14:42,180
GPS system is picking that up and and

319
00:14:39,420 --> 00:14:44,940
notifying people about things like the

320
00:14:42,180 --> 00:14:47,760
car is approaching okay so if we go from

321
00:14:44,940 --> 00:14:52,320
the top we can see that the rider

322
00:14:47,760 --> 00:14:54,779
uses the API uses their app to create a

323
00:14:52,320 --> 00:14:57,060
ride request

324
00:14:54,779 --> 00:15:01,380
um and that moves us into the searching

325
00:14:57,060 --> 00:15:03,420
State now it's actually that command

326
00:15:01,380 --> 00:15:05,579
that line

327
00:15:03,420 --> 00:15:07,500
um also represents an event notification

328
00:15:05,579 --> 00:15:10,980
out to all the drivers in the area

329
00:15:07,500 --> 00:15:13,139
saying there's a new ride request okay

330
00:15:10,980 --> 00:15:16,500
the driver can then respond through a

331
00:15:13,139 --> 00:15:20,480
command to say I'll take that one and

332
00:15:16,500 --> 00:15:25,260
that's moves us into the accepted State

333
00:15:20,480 --> 00:15:29,519
uh then when the car is on its way and

334
00:15:25,260 --> 00:15:31,740
the GPS system figures out uh in some

335
00:15:29,519 --> 00:15:34,560
magical way that the car is one minute

336
00:15:31,740 --> 00:15:38,399
away from pickup that's when the system

337
00:15:34,560 --> 00:15:41,100
can trigger an event notification out to

338
00:15:38,399 --> 00:15:44,880
typically the rider to say get ready the

339
00:15:41,100 --> 00:15:48,660
cars around the corner okay so you can

340
00:15:44,880 --> 00:15:51,660
see that these arrows are in each case

341
00:15:48,660 --> 00:15:54,980
either a command or an event or in many

342
00:15:51,660 --> 00:15:54,980
cases both right

343
00:15:55,380 --> 00:16:02,220
and lo and behold if we

344
00:15:58,440 --> 00:16:06,779
um okay so if we look at the

345
00:16:02,220 --> 00:16:09,180
um apis that we might set up for that

346
00:16:06,779 --> 00:16:10,860
um that application for the ride share

347
00:16:09,180 --> 00:16:12,720
application

348
00:16:10,860 --> 00:16:15,360
um these are what you might have with a

349
00:16:12,720 --> 00:16:18,480
restful API call so create a ride

350
00:16:15,360 --> 00:16:22,019
request as a post to a collection of

351
00:16:18,480 --> 00:16:24,420
requests uh get a ride request I want to

352
00:16:22,019 --> 00:16:27,360
check the state of that request is a get

353
00:16:24,420 --> 00:16:30,360
request if I want to cancel the request

354
00:16:27,360 --> 00:16:32,339
I might send a delete and then if I

355
00:16:30,360 --> 00:16:34,800
wanted to change the pickup or the

356
00:16:32,339 --> 00:16:38,519
destination along the way I might do a

357
00:16:34,800 --> 00:16:41,759
put into that and then lo and behold if

358
00:16:38,519 --> 00:16:44,459
we look at the Uber Rider API well who

359
00:16:41,759 --> 00:16:46,380
would have thought their API looks

360
00:16:44,459 --> 00:16:48,300
exactly like that okay so they're

361
00:16:46,380 --> 00:16:53,220
thinking along the same lines which is

362
00:16:48,300 --> 00:16:57,540
great to see so the Uber API represents

363
00:16:53,220 --> 00:17:02,779
those State transitions as commands on

364
00:16:57,540 --> 00:17:02,779
their restful API or rest their API

365
00:17:04,020 --> 00:17:06,660
okay

366
00:17:05,459 --> 00:17:09,959
um

367
00:17:06,660 --> 00:17:11,900
so we can see how the state model has

368
00:17:09,959 --> 00:17:15,360
helped us design

369
00:17:11,900 --> 00:17:18,959
commands for our apis we can also see

370
00:17:15,360 --> 00:17:23,400
now in blue what are the potential

371
00:17:18,959 --> 00:17:26,100
events that a rider is interested in

372
00:17:23,400 --> 00:17:29,040
um from their app so events like a

373
00:17:26,100 --> 00:17:30,559
driver has accepted the ride the driver

374
00:17:29,040 --> 00:17:33,600
is arriving

375
00:17:30,559 --> 00:17:36,120
the ride is complete or the ride has

376
00:17:33,600 --> 00:17:39,140
been canceled by a driver okay you kind

377
00:17:36,120 --> 00:17:39,140
of want to know about that

378
00:17:39,780 --> 00:17:45,480
and lo and behold also if we went to the

379
00:17:42,780 --> 00:17:50,240
Uber API documentation we would see that

380
00:17:45,480 --> 00:17:53,520
Uber has web hooks to notify

381
00:17:50,240 --> 00:17:56,400
a subscriber about these changes in

382
00:17:53,520 --> 00:17:58,679
state okay and this is what the web hook

383
00:17:56,400 --> 00:18:02,520
looks like it's an event it's got a

384
00:17:58,679 --> 00:18:05,640
unique ID it's got a time stamp it's got

385
00:18:02,520 --> 00:18:08,940
information about the ride and the URL

386
00:18:05,640 --> 00:18:13,020
to the particular ride that it

387
00:18:08,940 --> 00:18:15,780
references okay now actually the Uber

388
00:18:13,020 --> 00:18:18,120
web hooks have been deprecated now don't

389
00:18:15,780 --> 00:18:20,160
know why maybe it wasn't getting much

390
00:18:18,120 --> 00:18:23,039
use or maybe it was getting too much use

391
00:18:20,160 --> 00:18:24,900
and it was too expensive don't know but

392
00:18:23,039 --> 00:18:26,640
anyway they've thought about web hooks

393
00:18:24,900 --> 00:18:28,679
when they were designing this which is a

394
00:18:26,640 --> 00:18:31,200
good thing

395
00:18:28,679 --> 00:18:33,840
so we've looked at the rider perspective

396
00:18:31,200 --> 00:18:35,100
of the solution

397
00:18:33,840 --> 00:18:37,140
um we can also look at the driver

398
00:18:35,100 --> 00:18:40,440
perspective and the driver will also

399
00:18:37,140 --> 00:18:43,260
have their API okay so the driver's API

400
00:18:40,440 --> 00:18:45,900
will be about accept the ride request

401
00:18:43,260 --> 00:18:48,600
get a ride request cancel the ride

402
00:18:45,900 --> 00:18:51,539
request and also a driver is interested

403
00:18:48,600 --> 00:18:54,059
in events like the new ride request is

404
00:18:51,539 --> 00:18:56,460
the the main one or a change in the

405
00:18:54,059 --> 00:18:59,000
pickup location the driver wants to know

406
00:18:56,460 --> 00:18:59,000
about that

407
00:19:00,600 --> 00:19:07,500
so we can see that our

408
00:19:04,020 --> 00:19:10,860
simple ride share application has got a

409
00:19:07,500 --> 00:19:13,320
combination of both apis and events to

410
00:19:10,860 --> 00:19:16,679
it and we can use them to complement

411
00:19:13,320 --> 00:19:19,440
each other so why are events important

412
00:19:16,679 --> 00:19:21,240
and useful in this type of solution well

413
00:19:19,440 --> 00:19:23,820
first of all we've got publish subscribe

414
00:19:21,240 --> 00:19:26,280
so we've got loose loose coupling

415
00:19:23,820 --> 00:19:30,240
publish subscribe we can publish those

416
00:19:26,280 --> 00:19:34,440
events to multiple different people loss

417
00:19:30,240 --> 00:19:37,559
or applications in the solution

418
00:19:34,440 --> 00:19:40,500
um and uh the events are eventually

419
00:19:37,559 --> 00:19:42,480
consistent which can be a good thing or

420
00:19:40,500 --> 00:19:44,400
it can be a bad thing if you want

421
00:19:42,480 --> 00:19:47,280
eventual consistency then that's great

422
00:19:44,400 --> 00:19:49,740
if you want strong consistency maybe

423
00:19:47,280 --> 00:19:51,140
it's not so good

424
00:19:49,740 --> 00:19:54,059
foreign

425
00:19:51,140 --> 00:19:56,760
I can illustrate the power of events

426
00:19:54,059 --> 00:19:59,400
through looking at the broader context

427
00:19:56,760 --> 00:20:01,679
so we've just considered Riders and

428
00:19:59,400 --> 00:20:03,660
drivers so far but what about all of the

429
00:20:01,679 --> 00:20:06,600
other parts of the system what about a

430
00:20:03,660 --> 00:20:09,299
billing system or a reputation rating

431
00:20:06,600 --> 00:20:11,640
system okay those are other things that

432
00:20:09,299 --> 00:20:15,419
I need to consider in my solution and we

433
00:20:11,640 --> 00:20:18,120
can see that if I create a ride request

434
00:20:15,419 --> 00:20:19,679
the event notification goes to the

435
00:20:18,120 --> 00:20:22,080
driver

436
00:20:19,679 --> 00:20:24,840
if the driver accepts the ride the event

437
00:20:22,080 --> 00:20:27,240
notification goes to the rider as we've

438
00:20:24,840 --> 00:20:30,660
discussed the billing system is probably

439
00:20:27,240 --> 00:20:33,299
also interested when a driver accepts

440
00:20:30,660 --> 00:20:35,960
the request because we might have a

441
00:20:33,299 --> 00:20:38,340
requirement where if the rider cancels

442
00:20:35,960 --> 00:20:40,679
uh we might want to charge them a

443
00:20:38,340 --> 00:20:43,140
cancellation fee okay so the billing

444
00:20:40,679 --> 00:20:44,760
system is interested in those kinds of

445
00:20:43,140 --> 00:20:48,000
events

446
00:20:44,760 --> 00:20:49,980
uh once we're in progress we might also

447
00:20:48,000 --> 00:20:52,740
let the Billing System know that the

448
00:20:49,980 --> 00:20:54,660
ride is actually underway

449
00:20:52,740 --> 00:20:56,640
and then when the ride is completed

450
00:20:54,660 --> 00:20:59,220
obviously the Billing System wants to

451
00:20:56,640 --> 00:21:03,179
know so that we can then charge the card

452
00:20:59,220 --> 00:21:05,160
associated with that Rider and probably

453
00:21:03,179 --> 00:21:07,260
the rating system might want to know so

454
00:21:05,160 --> 00:21:09,059
we've got this published subscribe we've

455
00:21:07,260 --> 00:21:11,700
got this multiple

456
00:21:09,059 --> 00:21:14,280
um fan out of being able to notify

457
00:21:11,700 --> 00:21:16,679
different parts of the system when those

458
00:21:14,280 --> 00:21:18,900
events happen

459
00:21:16,679 --> 00:21:20,400
okay

460
00:21:18,900 --> 00:21:23,280
so

461
00:21:20,400 --> 00:21:26,539
um hopefully I've persuaded you the apis

462
00:21:23,280 --> 00:21:30,780
and events are really useful together

463
00:21:26,539 --> 00:21:33,780
and try not to think about all apis or

464
00:21:30,780 --> 00:21:36,179
all event driven I worry when people go

465
00:21:33,780 --> 00:21:39,240
to the extremes like that

466
00:21:36,179 --> 00:21:40,919
um not that it's wrong but you need to

467
00:21:39,240 --> 00:21:44,100
know what you think what you're wanting

468
00:21:40,919 --> 00:21:46,020
okay so aprs and events they are

469
00:21:44,100 --> 00:21:47,460
harmonious they work in relation with

470
00:21:46,020 --> 00:21:49,919
each other

471
00:21:47,460 --> 00:21:52,260
they there's a duality between them

472
00:21:49,919 --> 00:21:54,480
they're both different expressions of

473
00:21:52,260 --> 00:21:56,220
the same underlying State model that

474
00:21:54,480 --> 00:22:00,059
we're working with

475
00:21:56,220 --> 00:22:02,580
um and a good balance like yin and yang

476
00:22:00,059 --> 00:22:06,059
a good balance is a solution that uses

477
00:22:02,580 --> 00:22:09,240
them both judiciously

478
00:22:06,059 --> 00:22:11,159
so where do you start start simple news

479
00:22:09,240 --> 00:22:13,260
apis for commands and queries so

480
00:22:11,159 --> 00:22:16,860
commands and queries just use your good

481
00:22:13,260 --> 00:22:19,500
old HTTP request reply apis event

482
00:22:16,860 --> 00:22:24,120
streams use you know use something like

483
00:22:19,500 --> 00:22:26,760
Kafka to publish event streams out and

484
00:22:24,120 --> 00:22:29,820
also when you're choosing between

485
00:22:26,760 --> 00:22:32,059
getting the state of a system whether

486
00:22:29,820 --> 00:22:34,919
it's via a query or a notification

487
00:22:32,059 --> 00:22:37,020
consider your consistency requirements

488
00:22:34,919 --> 00:22:39,840
does it need to be strong consistency

489
00:22:37,020 --> 00:22:42,059
use a query or if you're happy with

490
00:22:39,840 --> 00:22:44,659
eventual consistency

491
00:22:42,059 --> 00:22:44,659
um use an event

492
00:22:45,620 --> 00:22:52,080
think carefully about

493
00:22:48,740 --> 00:22:55,020
choreography events for complex

494
00:22:52,080 --> 00:22:57,539
processes we've seen a simple process so

495
00:22:55,020 --> 00:22:59,520
events work really well in our ride

496
00:22:57,539 --> 00:23:02,760
share example because that's a

497
00:22:59,520 --> 00:23:05,940
relatively simple end-to-end process but

498
00:23:02,760 --> 00:23:08,340
if I'm doing complex processes like um

499
00:23:05,940 --> 00:23:11,280
like like a mortgage application or

500
00:23:08,340 --> 00:23:12,600
something like that that may not be so

501
00:23:11,280 --> 00:23:15,059
good because you get into race

502
00:23:12,600 --> 00:23:18,659
conditions you get into out of order

503
00:23:15,059 --> 00:23:20,730
events and it can be really hairy for

504
00:23:18,659 --> 00:23:21,120
those kinds of things so

505
00:23:20,730 --> 00:23:22,799
[Music]

506
00:23:21,120 --> 00:23:25,500
um

507
00:23:22,799 --> 00:23:28,220
think carefully if you want to go all

508
00:23:25,500 --> 00:23:28,220
event driven

509
00:23:29,159 --> 00:23:33,059
thank you for your time and I'm not sure

510
00:23:31,020 --> 00:23:35,330
if we got time for a question or

511
00:23:33,059 --> 00:23:38,720
so we do okay

512
00:23:35,330 --> 00:23:38,720
[Applause]

513
00:23:41,050 --> 00:23:45,240
[Applause]

514
00:23:42,780 --> 00:23:46,679
thank you very much sir if anyone has

515
00:23:45,240 --> 00:23:49,620
any questions

516
00:23:46,679 --> 00:23:51,980
signal Jack so that he can run a mic up

517
00:23:49,620 --> 00:23:51,980
to you

518
00:23:53,100 --> 00:23:58,020
what kind of um Technologies do you use

519
00:23:56,100 --> 00:24:01,559
with events in terms of like message

520
00:23:58,020 --> 00:24:03,419
cues or um or are there other methods I

521
00:24:01,559 --> 00:24:05,460
haven't worked much with events so I may

522
00:24:03,419 --> 00:24:08,280
not even know the right question to ask

523
00:24:05,460 --> 00:24:09,360
but um yes yeah yeah that's a great

524
00:24:08,280 --> 00:24:11,280
question

525
00:24:09,360 --> 00:24:12,419
um so events

526
00:24:11,280 --> 00:24:16,320
um

527
00:24:12,419 --> 00:24:18,720
uh really the the technology that a lot

528
00:24:16,320 --> 00:24:21,240
of people use now is Kafka right so it's

529
00:24:18,720 --> 00:24:24,120
a distributed log you can just read the

530
00:24:21,240 --> 00:24:27,480
events off the log and it's pretty easy

531
00:24:24,120 --> 00:24:29,640
to use and I would recommend yeah Kafka

532
00:24:27,480 --> 00:24:33,000
or if you're in the cloud you know

533
00:24:29,640 --> 00:24:35,280
manage services Kafka or some of the the

534
00:24:33,000 --> 00:24:38,039
other Cloud native

535
00:24:35,280 --> 00:24:42,120
um examples like that

536
00:24:38,039 --> 00:24:43,080
um cheap and cheerful is the RSS feed

537
00:24:42,120 --> 00:24:46,039
right

538
00:24:43,080 --> 00:24:48,659
um you request and you get back an XML

539
00:24:46,039 --> 00:24:51,780
document and it's got events listed in

540
00:24:48,659 --> 00:24:55,140
it that's effectively what Kafka is like

541
00:24:51,780 --> 00:24:58,260
a high performance version of an RSS

542
00:24:55,140 --> 00:25:00,360
feed uh some people use web hooks web

543
00:24:58,260 --> 00:25:02,760
hooks have got some downsides in the

544
00:25:00,360 --> 00:25:05,760
sense that you've got to send a web hook

545
00:25:02,760 --> 00:25:10,159
to a subscriber you're assuming the

546
00:25:05,760 --> 00:25:13,320
subscriber can have an always available

547
00:25:10,159 --> 00:25:14,760
server waiting for the web hook so that

548
00:25:13,320 --> 00:25:15,840
can be problematic

549
00:25:14,760 --> 00:25:19,620
um

550
00:25:15,840 --> 00:25:21,840
uh message cues I I love message queues

551
00:25:19,620 --> 00:25:25,320
I've spent my career with message queues

552
00:25:21,840 --> 00:25:27,240
but in reality I think message cues now

553
00:25:25,320 --> 00:25:30,000
these days are probably good for

554
00:25:27,240 --> 00:25:32,039
commands and they're good for high

555
00:25:30,000 --> 00:25:34,260
availability or high performance

556
00:25:32,039 --> 00:25:36,779
applications if you're doing banking

557
00:25:34,260 --> 00:25:39,659
systems or your Google or something like

558
00:25:36,779 --> 00:25:41,700
that so I tend to use message cues less

559
00:25:39,659 --> 00:25:45,419
and less these days

560
00:25:41,700 --> 00:25:49,820
um but I'll use you know rest apis and

561
00:25:45,419 --> 00:25:49,820
I'll use um Kafka for events

562
00:25:53,340 --> 00:25:56,159
hey how's it going um that wasn't the

563
00:25:55,440 --> 00:25:57,240
question

564
00:25:56,159 --> 00:26:00,900
um

565
00:25:57,240 --> 00:26:02,340
is there a vocabulary for event driven

566
00:26:00,900 --> 00:26:04,320
systems like when you're talking about

567
00:26:02,340 --> 00:26:08,279
an API driven system you're quite used

568
00:26:04,320 --> 00:26:11,760
to talking about get or push or patch or

569
00:26:08,279 --> 00:26:14,520
query or mutate when it comes to events

570
00:26:11,760 --> 00:26:16,700
there's event

571
00:26:14,520 --> 00:26:18,779
um what sort of

572
00:26:16,700 --> 00:26:20,460
conceptual distinctions are there

573
00:26:18,779 --> 00:26:22,500
between types of events you might be

574
00:26:20,460 --> 00:26:24,000
publishing what sort of vocabulary is in

575
00:26:22,500 --> 00:26:26,880
use when you're building this kind of

576
00:26:24,000 --> 00:26:30,360
thing yeah a good question

577
00:26:26,880 --> 00:26:33,120
um so events I think there's really two

578
00:26:30,360 --> 00:26:36,299
types of event there's

579
00:26:33,120 --> 00:26:38,700
event carried State transfer which is a

580
00:26:36,299 --> 00:26:41,340
real mouthful so when you publish an

581
00:26:38,700 --> 00:26:43,860
event so I've you're publishing

582
00:26:41,340 --> 00:26:45,720
something about the the resource you're

583
00:26:43,860 --> 00:26:48,240
looking at okay with an API we're

584
00:26:45,720 --> 00:26:51,179
operating on the resource with an event

585
00:26:48,240 --> 00:26:53,700
with no defined changes to a resource so

586
00:26:51,179 --> 00:26:55,620
that ride request with all the details

587
00:26:53,700 --> 00:26:57,299
about it where to pick up where to drop

588
00:26:55,620 --> 00:26:59,400
off Etc

589
00:26:57,299 --> 00:27:01,919
when I publish an event do I just

590
00:26:59,400 --> 00:27:04,500
publish an event with a link to the

591
00:27:01,919 --> 00:27:06,600
resource like uber did and that's that's

592
00:27:04,500 --> 00:27:09,240
small it's lightweight it's easy to work

593
00:27:06,600 --> 00:27:11,100
with but then you're often getting you

594
00:27:09,240 --> 00:27:13,980
might get a message storm of requests

595
00:27:11,100 --> 00:27:16,320
coming after it or do I package up the

596
00:27:13,980 --> 00:27:18,360
whole resource and send the whole thing

597
00:27:16,320 --> 00:27:20,760
and that's one choice that people have

598
00:27:18,360 --> 00:27:23,880
to make so packaging up the whole

599
00:27:20,760 --> 00:27:26,159
resource event carried State transfer or

600
00:27:23,880 --> 00:27:29,220
an event might just be something like

601
00:27:26,159 --> 00:27:32,220
that the tooling and the terminology is

602
00:27:29,220 --> 00:27:35,520
still young and evolving we've got Cloud

603
00:27:32,220 --> 00:27:38,520
events as a good standard for having an

604
00:27:35,520 --> 00:27:42,299
envelope for what an event should look

605
00:27:38,520 --> 00:27:43,039
like so if you Google that cloud events

606
00:27:42,299 --> 00:27:48,539
um

607
00:27:43,039 --> 00:27:51,440
async API is is an approach to give us

608
00:27:48,539 --> 00:27:56,159
the Swagger for an event okay

609
00:27:51,440 --> 00:27:59,520
async API is the standard so that's just

610
00:27:56,159 --> 00:28:03,360
like open API specification is for

611
00:27:59,520 --> 00:28:06,059
request reply apis async API is the

612
00:28:03,360 --> 00:28:08,640
equivalent for events and that's a an

613
00:28:06,059 --> 00:28:10,440
emerging standard as well so yeah the

614
00:28:08,640 --> 00:28:14,600
tooling is kind of evolving and that's

615
00:28:10,440 --> 00:28:14,600
why it's it's it's more fun right

616
00:28:15,960 --> 00:28:19,860
thank you again so all right and on

617
00:28:18,179 --> 00:28:22,200
behalf of the conference thank you for

618
00:28:19,860 --> 00:28:24,720
talking enjoy your Adelaide python mug

619
00:28:22,200 --> 00:28:25,900
okay thank you

620
00:28:24,720 --> 00:28:29,749
foreign

621
00:28:25,900 --> 00:28:29,749
[Applause]