Skip to content

Instantly share code, notes, and snippets.

@abdmmar

abdmmar/Evolusi Arsitektur Backend di Blibli PZN Reaction.srt

Created November 15, 2023 07:41
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save abdmmar/adc45d11017d0b50e72c9602123065aa to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save abdmmar/adc45d11017d0b50e72c9602123065aa to your computer and use it in GitHub Desktop.
Download ZIP
Transcript of Evolusi Arsitektur Backend di Blibli PZN Reaction using faster-whisper on GTX 1050 4GB using CUDA with compute type int 8.
Raw
Evolusi Arsitektur Backend di Blibli PZN Reaction.srt
1
00:00:01,180 --> 00:00:15,480
evolusi arsitektur backend di blibli ini sebenarnya saya sendiri yang bikin ya tahun 2018 ya hampir 5 tahun yang lalu dan kayaknya sih waktu saya bikin artikel ini saya belum punya channel programmer jamano ya kalau gak salah
2
00:00:15,480 --> 00:00:26,300
programmer jamano itu channelnya kayak sekitar 2018 akhir gitu ya nah saya bikinnya jadi waktu itu dulu saya sebelum bikin channel youtube sebenarnya saya lebih senang nulis ya
3
00:00:26,300 --> 00:00:37,220
nah tapi sekarang lebih banyak di youtube nah sekarang kita akan coba reaction ya tapi lebih ke detail kan ya untuk artikel ini jadi evolusi arsitektur backendnya di blibli.com
4
00:00:37,220 --> 00:00:49,860
oke kita langsung aja poin pertama blibli.com versi 1.0 jadi blibli.com bukanlah perusahaan startup seperti pada biasanya dimana kebanyakan perusahaan startup itu mereka berisi founder-founder
5
00:00:49,860 --> 00:00:56,280
seorang programmer dimana mereka build perusahaan startupnya sendiri nah sedangkan blibli.com itu adalah anak perusahaannya
6
00:00:56,300 --> 00:01:06,040
yang memang dibuat untuk menjadi perusahaan e-commerce jadi kalau teman-teman perhatikan ya di awal-awal banyaknya e-commerce di Indonesia itu kebanyakan startup ya
7
00:01:06,040 --> 00:01:17,660
jadi memang perusahaannya dibikin dari awal dan kebanyakan ada founder-foundernya jadi foundernya biasanya dari kecil gitu ya seperti contohnya mungkin Tokopedia atau Bukalapak gitu itu mereka ada founder-foundernya
8
00:01:17,660 --> 00:01:26,280
nah kalau blibli.com itu berbeda ya blibli.com itu beneran dari awal memang dibikin oleh perusahaan jarum ya jadi bukan startupnya
9
00:01:26,300 --> 00:01:35,220
juga kalau startup itu beneran merintis dari bawah gitu ya kalau ini enggak memang dari awal sudah pengen disetup sebagai perusahaan toko online oleh jarum
10
00:01:35,220 --> 00:01:45,740
nah sebenarnya sih ada yang mengikuti ya pada waktu itu ada matahari mall ya matahari mall itu bikin juga matahari ya e-commerce-nya tapi sekarang udah nggak ada udah tutup matahari
11
00:01:45,740 --> 00:01:56,080
jadi waktu itu sekitar tahun 2015 kalau nggak salah atau 2016 gitu ya itu matahari juga bikin ya matahari mall itu bikin juga e-commerce ya
12
00:01:56,300 --> 00:02:00,980
dan tapi sayangnya nggak bertahan lama cuma sekitar dua tahunan akhirnya mereka tutup
13
00:02:00,980 --> 00:02:08,820
oke ini versi awalnya itu monolith ya jadi blibli.com pada awalnya mengejar rilis ke pasar secepatnya
14
00:02:08,820 --> 00:02:15,260
nah kalau perusahaan biasanya kalau bukan startup-startup itu kan biasanya dari kecil gitu ya bertahap
15
00:02:15,260 --> 00:02:21,520
nah kalau perusahaan yang memang sudah pengen dari awal pengen bikin toko online gitu ya ya pasti mereka pengen rilis ke market secepatnya
16
00:02:21,520 --> 00:02:26,280
nah sehingga untuk mempercepat proses rilisnya blibli.com tidak membuat sistem e-commerce untuk mengejar rilis ke pasar secepatnya
17
00:02:26,300 --> 00:02:31,020
jadi kalau hiring dulu gitu ya develop dari awal mungkin lama
18
00:02:31,020 --> 00:02:37,860
nah jadi melainkan membeli produk yang sudah jadi dan meng-outsource-kan pembuatannya ke perusahaan software house
19
00:02:37,860 --> 00:02:41,160
ini udah common sih ya di jaman-jaman dulu
20
00:02:41,160 --> 00:02:46,020
jaman dulu kan mungkin ini tahun 2011 ya itu belum terlalu populer startup ya
21
00:02:48,080 --> 00:02:52,880
bahkan jaman dulu tuh kebanyakan ya IT konsultan perusahaan-perusahaan teknologi tuh
22
00:02:52,880 --> 00:02:55,660
jadi kebanyakan perusahaan-perusahaan yang non-teknologi
23
00:02:55,660 --> 00:02:56,280
kayak contohnya
24
00:02:56,300 --> 00:03:01,740
ya perusahaan korporat itu mereka pasti akan meng-outsource-kan pekerjaan teknologinya
25
00:03:01,740 --> 00:03:05,320
jadi ini di-outsourcen ke software house
26
00:03:05,320 --> 00:03:09,720
dan sudah bisa ditebak ya awal blibli.com adalah sebuah sistem e-commerce monolith
27
00:03:09,720 --> 00:03:12,800
karena dari tahun 2011 kayaknya belum rame gitu ya
28
00:03:12,800 --> 00:03:15,760
apa itu microservice dan lain-lain gak terlalu rame ya
29
00:03:15,760 --> 00:03:18,720
jadi dulu pokoknya bikin aplikasi toko online selesai gitu ya
30
00:03:18,720 --> 00:03:22,640
jadi di awal memang dibikin aplikasinya satu aplikasi e-commerce
31
00:03:24,700 --> 00:03:25,540
scaling team
32
00:03:26,780 --> 00:03:29,440
permasalahan yang terjadi di semua perusahaan berbasis produk
33
00:03:29,440 --> 00:03:33,840
seperti contohnya blibli.com dan perusahaan yang lainnya adalah mengejar fitur
34
00:03:33,840 --> 00:03:34,640
oke
35
00:03:36,040 --> 00:03:40,400
bedanya kalau perusahaan misalnya yang kayak bank gitu ya jaman dulu ya
36
00:03:40,400 --> 00:03:43,760
itu kan kebanyakan atau korporat itu kan tidak mengejar banyaknya fitur
37
00:03:43,760 --> 00:03:46,220
nah kalau sekarang ya perusahaan yang berbasis produk
38
00:03:46,220 --> 00:03:48,460
nah sekarang itu jarang banget kita bikin produk
39
00:03:48,460 --> 00:03:51,680
abis itu di-develop selesai udah diem gitu ya
40
00:03:51,680 --> 00:03:52,900
gak diapa-apain lagi
41
00:03:52,900 --> 00:03:54,080
itu jarang banget kalau sekarang
42
00:03:54,080 --> 00:03:56,160
sekarang itu pasti kalau misalnya di-develop
43
00:03:56,300 --> 00:03:58,460
produknya pasti akan selalu di-improve gitu ya
44
00:03:58,460 --> 00:03:59,860
makanya kebanyakan sekarang
45
00:03:59,860 --> 00:04:02,060
develop produk itu in-house ya
46
00:04:02,060 --> 00:04:04,860
in-house itu artinya mereka bikin sendiri timnya
47
00:04:04,860 --> 00:04:06,820
jadi jarang menggunakan outsource lagi
48
00:04:06,820 --> 00:04:10,840
kenapa? karena kalau in-house itu kan nanti di-developnya oleh internal team sendiri
49
00:04:10,840 --> 00:04:13,900
jadi mereka bisa improve fiturnya terus-menerus
50
00:04:13,900 --> 00:04:15,800
nah sekarang itu pasti harus seperti itu
51
00:04:15,800 --> 00:04:17,380
kenapa? karena kompetitor makin banyak
52
00:04:17,380 --> 00:04:19,320
jadi contohnya sekarang toko online banyak
53
00:04:19,320 --> 00:04:21,460
ojek online juga banyak gitu ya
54
00:04:21,460 --> 00:04:23,620
bahkan yang jenis-jenis yang lain pun banyak
55
00:04:23,620 --> 00:04:26,180
kalau kita gak improve fiturnya gitu ya
56
00:04:26,300 --> 00:04:28,400
jadi cuma bikin di awal
57
00:04:28,400 --> 00:04:30,200
setelah jadi udah aja gak pernah diapa-apain
58
00:04:30,200 --> 00:04:33,700
orang mungkin gak akan pakai lama-lama gitu ya
59
00:04:33,700 --> 00:04:36,060
karena tidak ada inovasi di produknya
60
00:04:36,060 --> 00:04:37,620
makanya perlu banyak inovasi
61
00:04:37,620 --> 00:04:40,420
akhirnya yang jadi masalah adalah
62
00:04:40,420 --> 00:04:42,460
fiturnya harus bertambah terus
63
00:04:43,200 --> 00:04:45,960
iya biasanya ini terjadi tarik-menarik
64
00:04:45,960 --> 00:04:47,940
antara tim produk dan tim teknologi
65
00:04:47,940 --> 00:04:50,500
tim produk ingin menyajikan fitur secepatnya ke pasar
66
00:04:50,500 --> 00:04:52,760
dan tim teknologi harus bisa mengimbangi
67
00:04:52,760 --> 00:04:54,800
kecepatan permintaan fitur tim bisnisnya
68
00:04:54,800 --> 00:04:55,940
jadi
69
00:04:56,300 --> 00:04:57,880
saat kita bikin company kan
70
00:04:57,880 --> 00:04:59,760
pasti ada yang tim teknologi
71
00:04:59,760 --> 00:05:01,140
ada tim yang non teknologi
72
00:05:01,140 --> 00:05:02,100
atau tim bisnis ya
73
00:05:02,100 --> 00:05:03,060
atau tim produknya
74
00:05:03,060 --> 00:05:04,340
nah pasti kan tim produk
75
00:05:04,340 --> 00:05:05,400
kalau misalnya lihat
76
00:05:05,400 --> 00:05:06,620
oh kompetitor udah punya A
77
00:05:06,620 --> 00:05:07,920
kita juga harus bikin A
78
00:05:07,920 --> 00:05:09,240
atau kompetitor belum punya
79
00:05:09,240 --> 00:05:10,700
kita harus coba jadi yang pertama
80
00:05:10,700 --> 00:05:12,000
punya fitur ini
81
00:05:12,000 --> 00:05:14,040
artinya terus-menerus permintaan
82
00:05:14,040 --> 00:05:15,480
dari tim produk itu pasti selalu ada
83
00:05:15,480 --> 00:05:16,760
nah masalahnya adalah
84
00:05:16,760 --> 00:05:18,900
sekarang tim teknologinya
85
00:05:18,900 --> 00:05:20,020
itu harus bisa ngejar
86
00:05:21,020 --> 00:05:22,060
permintaan dari si
87
00:05:22,760 --> 00:05:23,440
ininya ya
88
00:05:23,440 --> 00:05:25,120
si tim produknya
89
00:05:25,120 --> 00:05:26,220
jadi kalau ada fitur
90
00:05:26,220 --> 00:05:27,620
banyak ya mau gak mau harus dikejar
91
00:05:27,620 --> 00:05:30,140
nah makanya dulu itu sekitar awal-awal
92
00:05:30,140 --> 00:05:30,400
tahun
93
00:05:32,400 --> 00:05:34,360
2011-2015 gitu ya
94
00:05:34,360 --> 00:05:35,660
itu banyak banget
95
00:05:35,660 --> 00:05:38,020
akhirnya perusahaan-perusahaan yang hiring
96
00:05:38,020 --> 00:05:39,620
programmer gitu ya
97
00:05:39,620 --> 00:05:41,120
dan pada waktu itu mungkin memang
98
00:05:41,120 --> 00:05:43,620
karena permintaannya tinggi gitu ya
99
00:05:43,620 --> 00:05:46,100
makanya harga programmer itu
100
00:05:46,100 --> 00:05:47,620
mahal-mahal pada waktu itu
101
00:05:48,480 --> 00:05:50,580
rata-rata orang awam terhadap teknologi
102
00:05:50,580 --> 00:05:51,900
biasanya berpikir seperti ini
103
00:05:51,900 --> 00:05:54,100
kalau sebuah produk dikerjakan oleh
104
00:05:54,100 --> 00:05:56,020
satu programmer ya dapat selesai dalam
105
00:05:56,220 --> 00:05:56,980
waktu lima bulan
106
00:05:56,980 --> 00:05:59,260
berarti jika lo menggunakan lima programmer
107
00:05:59,260 --> 00:06:00,740
produk tersebut bisa selesai dalam
108
00:06:00,740 --> 00:06:01,520
waktu satu bulan
109
00:06:01,520 --> 00:06:03,520
nah kenyataannya tidak seperti itu
110
00:06:03,520 --> 00:06:05,720
ada banyak faktor yang harus kita perhatikan
111
00:06:05,720 --> 00:06:07,340
jadi banyak orang yang mikir
112
00:06:07,340 --> 00:06:09,180
oke kalau misalnya satu orang ngerjain
113
00:06:09,180 --> 00:06:11,180
satu produk selesai satu tahun
114
00:06:11,180 --> 00:06:13,480
yaudah saya tinggal hire 12 orang
115
00:06:13,480 --> 00:06:15,960
pasti selesai dalam satu bulan
116
00:06:15,960 --> 00:06:18,220
kenyataannya gak seperti itu gitu ya
117
00:06:18,220 --> 00:06:19,500
banyak faktor yang
118
00:06:19,500 --> 00:06:20,540
ininya
119
00:06:21,160 --> 00:06:21,760
menentukannya
120
00:06:21,760 --> 00:06:24,080
apakah produk itu bisa dipercepat
121
00:06:24,080 --> 00:06:25,060
atau tidak gitu ya
122
00:06:25,060 --> 00:06:26,200
jadi gak se-percepatan
123
00:06:27,560 --> 00:06:28,160
sesimpel
124
00:06:28,160 --> 00:06:29,140
yaudah tambahin orang
125
00:06:29,140 --> 00:06:30,180
pasti lebih cepat
126
00:06:30,180 --> 00:06:31,200
gak juga gitu ya
127
00:06:31,200 --> 00:06:32,840
nah salah satu permasalahannya adalah
128
00:06:32,840 --> 00:06:35,300
dengan sistem monolith yang ada di blibli.com
129
00:06:36,140 --> 00:06:38,040
sistem monolith tidak bisa mengikuti
130
00:06:38,040 --> 00:06:39,900
scaling team yang dilakukan perusahaan
131
00:06:39,900 --> 00:06:41,800
jadi karena aplikasinya satu gitu ya
132
00:06:41,800 --> 00:06:43,100
mungkin jadi kalau misalnya
133
00:06:44,780 --> 00:06:45,780
orangnya banyak
134
00:06:45,780 --> 00:06:47,720
bukannya malah makin cepat
135
00:06:47,720 --> 00:06:48,920
malah makin ribet ya
136
00:06:48,920 --> 00:06:50,680
jadi kayak ada satu barang ya
137
00:06:52,160 --> 00:06:53,840
dikerjakan secara rame-rame gitu ya
138
00:06:53,840 --> 00:06:54,760
kadang-kadang kan ada yang
139
00:06:54,760 --> 00:06:55,740
cuma satu part itu
140
00:06:56,220 --> 00:06:57,580
bagusnya dikerjakan satu orang gitu ya
141
00:06:57,580 --> 00:06:59,020
bukan tiba-tiba 20 orang
142
00:06:59,020 --> 00:07:00,100
ngerjain hal yang sama
143
00:07:00,100 --> 00:07:02,280
nah itu kan jadi ribet
144
00:07:02,280 --> 00:07:03,580
jadi semakin banyak
145
00:07:03,580 --> 00:07:04,780
blibli.com menambah tim
146
00:07:04,780 --> 00:07:06,000
ternyata tidak berbanding
147
00:07:06,000 --> 00:07:06,800
dengan kecepatan
148
00:07:06,800 --> 00:07:08,060
untuk menambahkan fitur
149
00:07:08,060 --> 00:07:09,780
pada sistem monolith tersebut
150
00:07:09,780 --> 00:07:11,060
nah hal ini
151
00:07:11,060 --> 00:07:12,400
dikarenakan semua programmer
152
00:07:12,400 --> 00:07:15,060
harus kerja di satu codebase yang sama
153
00:07:15,060 --> 00:07:17,500
sehingga rawan konflik pekerjaan
154
00:07:17,500 --> 00:07:19,320
dan teknologi yang tidak terlalu familiar
155
00:07:19,320 --> 00:07:20,940
di produk monolith tersebut
156
00:07:20,940 --> 00:07:22,480
juga menyebabkan programmer baru
157
00:07:22,480 --> 00:07:24,020
sulit untuk belajar
158
00:07:24,760 --> 00:07:25,460
oke
159
00:07:26,220 --> 00:07:27,200
saat kita misalnya
160
00:07:27,200 --> 00:07:28,940
saya sudah sering ketemu ya
161
00:07:28,940 --> 00:07:30,640
teman-teman yang bikin startup
162
00:07:30,640 --> 00:07:31,500
dan awalnya
163
00:07:32,120 --> 00:07:33,580
codenya itu di outsourcen
164
00:07:33,580 --> 00:07:35,080
nah problemnya adalah
165
00:07:35,080 --> 00:07:35,900
ketika misalnya
166
00:07:35,900 --> 00:07:37,180
si pemilik startup itu
167
00:07:37,180 --> 00:07:38,540
tidak ngerti tentang teknologi
168
00:07:38,540 --> 00:07:40,000
yang penting jadi aja gitu ya
169
00:07:40,000 --> 00:07:40,560
produknya
170
00:07:40,560 --> 00:07:42,160
nah ketika baru dia hire
171
00:07:42,160 --> 00:07:44,080
orang teknologinya sendiri
172
00:07:44,080 --> 00:07:45,720
ketika lihat codenya misalnya
173
00:07:45,720 --> 00:07:47,660
ya codenya berantakan gitu ya
174
00:07:47,660 --> 00:07:48,580
nggak ada testing
175
00:07:48,580 --> 00:07:49,700
nggak jelas gitu ya
176
00:07:49,700 --> 00:07:50,400
deploymentnya
177
00:07:50,400 --> 00:07:51,780
masih manual
178
00:07:51,780 --> 00:07:54,140
habis itu masih banyak spaghetti code gitu ya
179
00:07:54,140 --> 00:07:55,400
tidak clean code dan lain-lain
180
00:07:55,400 --> 00:07:56,200
artinya
181
00:07:56,220 --> 00:07:59,000
malah bukannya nanti bisa mempercepat
182
00:07:59,000 --> 00:08:00,340
malah jadi memperlambat
183
00:08:00,340 --> 00:08:02,140
karena banyak banget gitu ya
184
00:08:02,140 --> 00:08:04,900
hal yang sulit untuk diubah
185
00:08:04,900 --> 00:08:06,260
di kode yang sekarang
186
00:08:06,260 --> 00:08:07,820
nah pada waktu itu
187
00:08:07,820 --> 00:08:10,140
kalau misalnya teman-teman kejadian kayak gitu
188
00:08:10,140 --> 00:08:10,940
nah pasti sih
189
00:08:10,940 --> 00:08:12,000
kalau misalnya teman-teman
190
00:08:13,620 --> 00:08:15,980
pernah ya menerima legacy code
191
00:08:15,980 --> 00:08:17,480
tiba-tiba legacy codenya susah di maintain
192
00:08:17,480 --> 00:08:19,180
pasti ada kejadian seperti itu
193
00:08:19,180 --> 00:08:21,440
nah tim produk atau non-teknologi
194
00:08:21,440 --> 00:08:22,340
biasanya akan bertanya
195
00:08:22,340 --> 00:08:24,700
kok lama banget ya ngerjainnya gitu ya
196
00:08:24,700 --> 00:08:25,580
padahal
197
00:08:26,220 --> 00:08:27,680
orangnya udah ditambah gitu ya
198
00:08:27,680 --> 00:08:30,340
nah mereka mungkin tidak punya sudut pandang
199
00:08:30,340 --> 00:08:33,340
kalau ternyata produk ini tuh udah hancur gitu ya
200
00:08:33,340 --> 00:08:35,900
kalau misalnya kita tambal sulam-tambal sulam
201
00:08:35,900 --> 00:08:37,220
ya agak susah gitu ya
202
00:08:37,220 --> 00:08:39,240
ya cara yang paling gampang
203
00:08:39,240 --> 00:08:40,140
mungkin kebanyakan orang
204
00:08:40,140 --> 00:08:42,360
biasanya akan melakukan rewrite ya
205
00:08:42,360 --> 00:08:44,720
jadi rewrite dari codebase yang sudah hancur ini
206
00:08:44,720 --> 00:08:45,720
yaudah kita ganti
207
00:08:45,720 --> 00:08:48,200
dengan codebase yang lebih baik
208
00:08:48,200 --> 00:08:50,420
dan yang memang tujuannya adalah jangka panjang
209
00:08:52,220 --> 00:08:54,360
baby.com versi 2.0
210
00:08:54,360 --> 00:08:55,680
eranya microservice
211
00:08:56,220 --> 00:08:59,300
jaman now hampir semua startup migrasi besar-besaran
212
00:08:59,300 --> 00:09:00,980
dari monolith ke microservices
213
00:09:00,980 --> 00:09:02,820
bahkan saking hype-nya
214
00:09:02,820 --> 00:09:06,620
startup yang baru muncul langsung menggunakan arsitektur microservice
215
00:09:06,620 --> 00:09:09,540
jadi banyak banget ya orang-orang yang sekarang itu
216
00:09:09,540 --> 00:09:11,380
ketika develop produk di awal
217
00:09:11,380 --> 00:09:13,260
ya bahkan belum release produknya
218
00:09:13,260 --> 00:09:15,220
udah langsung pilih microservice
219
00:09:15,220 --> 00:09:17,720
saya sendiri sebenarnya kalau ada orang yang seperti itu
220
00:09:17,720 --> 00:09:19,660
tidak rekomendasikan langsung ke microservice
221
00:09:19,660 --> 00:09:21,300
kenapa? karena microservice itu
222
00:09:21,300 --> 00:09:23,080
banyak tantangannya
223
00:09:23,080 --> 00:09:24,960
terutama jumlah team membernya
224
00:09:24,960 --> 00:09:26,200
ketika jumlah team membernya
225
00:09:26,220 --> 00:09:27,860
membernya sedikit contohnya cuma 5 orang
226
00:09:27,860 --> 00:09:30,280
ada 2 frontend, 2 backend
227
00:09:30,280 --> 00:09:32,160
misalnya habis itu 1 infra
228
00:09:32,160 --> 00:09:34,180
lalu disuruh develop microservice
229
00:09:34,180 --> 00:09:36,820
yang ketika di total ada puluhan microservice
230
00:09:36,820 --> 00:09:38,680
bukannya malah makin simple
231
00:09:38,680 --> 00:09:39,960
malah makin kompleks ya
232
00:09:39,960 --> 00:09:41,120
jadi ribet banget
233
00:09:41,120 --> 00:09:43,080
makanya di awal biasanya kalau ada
234
00:09:43,080 --> 00:09:45,020
orang yang bertanya ke saya
235
00:09:45,020 --> 00:09:47,240
saya biasanya rekomendasikan dulu untuk monolith dulu
236
00:09:47,240 --> 00:09:48,580
kecuali butuh scale up
237
00:09:48,580 --> 00:09:50,220
baru nanti pindah ke microservice
238
00:09:50,220 --> 00:09:52,980
yang penting monolithnya dibikin sebaik mungkin
239
00:09:52,980 --> 00:09:54,000
codenya gitu ya
240
00:09:54,000 --> 00:09:55,700
jangan sampai codenya berantakan
241
00:09:56,640 --> 00:09:58,220
blibli.com mulai rewrite
242
00:09:58,220 --> 00:09:59,880
semua sistem ke microservice
243
00:09:59,880 --> 00:10:01,440
pada tahun 2014
244
00:10:01,440 --> 00:10:03,500
jadi mungkin dari 2011
245
00:10:03,500 --> 00:10:05,960
3 atau 4 tahun setelah
246
00:10:05,960 --> 00:10:07,300
launching ya
247
00:10:07,300 --> 00:10:10,060
transisi ini disetuskan oleh manager-manager
248
00:10:10,060 --> 00:10:12,460
dan senior-senior engineer di blibli.com
249
00:10:12,460 --> 00:10:14,280
tujuan utama dari transisi ini adalah
250
00:10:14,280 --> 00:10:16,320
scaling product dan scaling team
251
00:10:16,320 --> 00:10:17,620
jadi yang tadi ya
252
00:10:17,620 --> 00:10:19,860
jadi karena ada satu product yang sulit
253
00:10:19,860 --> 00:10:21,420
kalau di develop barang-barang yaudah
254
00:10:21,420 --> 00:10:24,500
di pecah productnya jadi microservice
255
00:10:24,500 --> 00:10:26,200
sehingga nanti tiap productnya
256
00:10:26,220 --> 00:10:28,260
itu punya team masing-masing
257
00:10:28,260 --> 00:10:30,260
jadi nanti developmentnya lebih gampang
258
00:10:30,260 --> 00:10:33,140
kalau misalnya fitur e-commerce ya disini
259
00:10:33,140 --> 00:10:34,860
fitur misalnya travel disini
260
00:10:34,860 --> 00:10:37,600
fitur misalnya digital product disini
261
00:10:37,600 --> 00:10:38,080
dan lain-lain
262
00:10:38,080 --> 00:10:40,580
jadi semua teamnya punya product masing-masing
263
00:10:40,580 --> 00:10:44,020
nah dengan menggunakan arsitektur microservice ini
264
00:10:44,020 --> 00:10:46,120
sekarang semua team programmer memiliki
265
00:10:46,120 --> 00:10:47,260
code base masing-masing
266
00:10:47,260 --> 00:10:48,720
sesuai dengan domennya
267
00:10:48,720 --> 00:10:51,100
dan bisa fokus mengerjakan fitur
268
00:10:51,100 --> 00:10:53,200
yang berhubungan dengan productnya masing-masing
269
00:10:53,200 --> 00:10:55,120
tanpa harus bersinggungan
270
00:10:55,120 --> 00:10:56,200
dengan code base teamnya
271
00:10:56,220 --> 00:10:57,540
jadi yang tadi ya
272
00:10:57,540 --> 00:10:58,540
kalau misalnya
273
00:10:59,080 --> 00:11:00,580
toko online kan kalau kita perhatikan
274
00:11:00,580 --> 00:11:01,620
banyak ya fiturnya ya
275
00:11:01,620 --> 00:11:02,880
ada yang ya retailnya
276
00:11:02,880 --> 00:11:04,740
ada yang jualan produk digitalnya
277
00:11:04,740 --> 00:11:06,280
misalnya pulsa gitu ya
278
00:11:07,220 --> 00:11:08,840
saldo apa gitu ya
279
00:11:08,840 --> 00:11:10,060
habis itu ada yang mungkin sekarang
280
00:11:10,060 --> 00:11:12,320
udah ada yang hotel gitu ya
281
00:11:12,320 --> 00:11:13,580
ada travel dan lain-lain
282
00:11:13,580 --> 00:11:15,220
nah problemnya adalah
283
00:11:15,220 --> 00:11:17,020
ini kan sebenarnya domennya berbeda ya
284
00:11:17,020 --> 00:11:17,960
produk-produknya itu
285
00:11:17,960 --> 00:11:19,920
jadi kalau kita di satu code base yang sama
286
00:11:19,920 --> 00:11:21,780
nanti kita agak menyulitkan
287
00:11:21,780 --> 00:11:23,660
kalau kita misalnya mengubah di bagian ini
288
00:11:23,660 --> 00:11:25,980
takutnya efek ke domen-domen yang lainnya
289
00:11:26,220 --> 00:11:28,020
nah dengan dipisahkan gitu ya
290
00:11:28,020 --> 00:11:29,300
domen-domennya ini ada
291
00:11:29,300 --> 00:11:30,880
mungkin ada retail
292
00:11:30,880 --> 00:11:31,920
ini mungkin ada digital
293
00:11:31,920 --> 00:11:33,040
ini mungkin ada travel
294
00:11:33,040 --> 00:11:34,660
nah itu lebih independen
295
00:11:34,660 --> 00:11:36,340
tiap programmernya
296
00:11:36,340 --> 00:11:38,380
karena mereka nge-handle code base masing-masing
297
00:11:39,060 --> 00:11:40,420
dan yang paling penting
298
00:11:40,420 --> 00:11:42,580
tiap tim sekarang bisa rilis fitur terbarunya
299
00:11:42,580 --> 00:11:44,120
ke pasar secara independen
300
00:11:44,120 --> 00:11:46,300
tanpa harus menunggu tim lain
301
00:11:46,900 --> 00:11:48,460
nah ini salah satu biasanya
302
00:11:48,460 --> 00:11:50,180
tujuan dari microservice gitu ya
303
00:11:50,180 --> 00:11:52,040
jadi tiap tim itu punya produk masing-masing
304
00:11:52,040 --> 00:11:53,060
jadi kalau mau rilis
305
00:11:53,060 --> 00:11:54,920
yaudah rilis aja sendiri gitu ya
306
00:11:54,920 --> 00:11:56,540
jadi nggak perlu nunggu tim yang lainnya
307
00:11:56,540 --> 00:11:58,080
kalau masih monolith gitu ya
308
00:11:58,080 --> 00:12:00,100
kalau misalnya tim ini sudah melakukan perubahan
309
00:12:00,100 --> 00:12:01,080
dan sudah selesai
310
00:12:01,080 --> 00:12:03,080
ternyata ada tim lain yang belum selesai
311
00:12:03,080 --> 00:12:03,980
maka harus nunggu
312
00:12:03,980 --> 00:12:06,600
karena nggak mungkin ya kita deploy perubahannya
313
00:12:06,600 --> 00:12:09,540
tapi fitur yang di sebelahnya itu masih
314
00:12:09,540 --> 00:12:11,200
belum selesai gitu ya
315
00:12:11,200 --> 00:12:12,940
cuma sebagian kan itu aneh gitu ya
316
00:12:12,940 --> 00:12:15,500
nanti ini udah rilis gitu ya
317
00:12:15,500 --> 00:12:17,580
tapi fitur yang sebelah sini malah nggak jalan
318
00:12:17,580 --> 00:12:20,740
nah jadi dengan adanya microservice
319
00:12:20,740 --> 00:12:22,700
otomatis tiap tim independen
320
00:12:22,700 --> 00:12:24,560
dan semua punya roadmap masing-masing
321
00:12:24,920 --> 00:12:27,120
nah ini biasanya tujuan dari microservice
322
00:12:27,120 --> 00:12:28,780
makanya saya nggak saranin
323
00:12:28,780 --> 00:12:31,160
kalau teman-teman misalnya baru cuma ada 5 orang
324
00:12:31,160 --> 00:12:32,440
tiba-tiba pengen microservice
325
00:12:32,440 --> 00:12:34,780
padahal beberapa microservice di-develop-nya
326
00:12:34,780 --> 00:12:36,100
sama orang yang sama gitu ya
327
00:12:36,100 --> 00:12:37,860
malah bikin pusing gitu ya
328
00:12:37,860 --> 00:12:39,760
jadi mendingan yaudah di-monolith dulu
329
00:12:39,760 --> 00:12:41,120
kecuali nanti timnya udah besar
330
00:12:41,120 --> 00:12:42,560
udah nyampe puluhan orang
331
00:12:42,560 --> 00:12:45,120
yaudah nanti kita baru split, pecah
332
00:12:45,120 --> 00:12:47,180
produk ini di-develop sama 5 orang
333
00:12:47,180 --> 00:12:48,800
produk ini di-develop sama 5 orang
334
00:12:48,800 --> 00:12:50,440
produk ini 5 orang dan seterusnya
335
00:12:52,380 --> 00:12:54,360
masa transisi ke microservice
336
00:12:54,920 --> 00:12:57,000
baby.com selesai rewrite
337
00:12:57,000 --> 00:12:59,520
semua sistem dari monolith ke microservice
338
00:12:59,520 --> 00:13:00,880
pada tahun 2016
339
00:13:00,880 --> 00:13:03,760
yap cukup lama memang sekitar 2 tahun
340
00:13:03,760 --> 00:13:06,120
jadi dari 2014 mulai
341
00:13:06,120 --> 00:13:07,440
dan selesainya baru 2016
342
00:13:07,440 --> 00:13:09,900
pertanyaannya kenapa bisa lama sekali
343
00:13:09,900 --> 00:13:12,400
hal yang paling sulit melakukan rewrite
344
00:13:12,400 --> 00:13:13,960
adalah proses transisi
345
00:13:13,960 --> 00:13:16,400
dimana kita harus menjalankan 2 sistem bersamaan
346
00:13:16,400 --> 00:13:19,460
yaitu monolith dan juga microservice
347
00:13:19,460 --> 00:13:21,800
dan selama 2 tahun tersebut
348
00:13:21,800 --> 00:13:24,340
tidak mungkin kita menghentikan fitur di sistem lama
349
00:13:24,340 --> 00:13:24,900
terlalu lama
350
00:13:24,920 --> 00:13:26,860
tetap harus mengembangkan fitur di sistem lama
351
00:13:26,860 --> 00:13:29,180
sampai sistem baru benar-benar bisa mengejar
352
00:13:29,180 --> 00:13:32,200
semua fitur di sistem yang lamanya
353
00:13:32,800 --> 00:13:34,800
oke jadi ini tantangan kalau kita pindah
354
00:13:35,580 --> 00:13:36,980
dari monolith ke microservice
355
00:13:36,980 --> 00:13:38,200
tapi bisnis sudah jalan
356
00:13:38,740 --> 00:13:39,220
problemnya adalah
357
00:13:39,220 --> 00:13:40,420
nggak mungkin kan tiba-tiba
358
00:13:40,420 --> 00:13:42,400
woy bisnis kita nggak mau develop fitur lagi
359
00:13:42,400 --> 00:13:43,540
kita mau rewrite gitu ya
360
00:13:43,540 --> 00:13:45,340
kita butuh 1 tahun misalnya
361
00:13:45,340 --> 00:13:46,640
ya nggak mungkin gitu ya
362
00:13:46,640 --> 00:13:48,400
masa nanti tim bisnis mau bengong gitu ya
363
00:13:48,720 --> 00:13:49,680
nggak ngapa-ngapain
364
00:13:49,680 --> 00:13:51,000
nggak kerja ya nggak mungkin
365
00:13:51,620 --> 00:13:54,480
intinya di sini perlu ada pembagian jadinya ya
366
00:13:54,920 --> 00:13:56,620
jadi yang pasti sih biasanya
367
00:13:56,620 --> 00:13:57,760
kalau pindah ke microservice
368
00:13:57,760 --> 00:13:59,900
yang saya biasa rekomendasikan adalah
369
00:13:59,900 --> 00:14:02,200
diskusi dulu dengan tim bisnis
370
00:14:02,200 --> 00:14:03,220
atau tim operation
371
00:14:03,220 --> 00:14:04,340
biar ngerti gitu ya
372
00:14:04,340 --> 00:14:05,900
kenapa perlu pindah ke microservice
373
00:14:05,900 --> 00:14:08,160
misalnya untuk tadi scalability team
374
00:14:08,160 --> 00:14:09,120
dan lain-lain gitu ya
375
00:14:09,120 --> 00:14:10,640
nah kalau misalnya udah oke
376
00:14:10,640 --> 00:14:12,840
nah sekarang tinggal ya
377
00:14:12,840 --> 00:14:14,980
negosiasi win-win solution gitu ya
378
00:14:14,980 --> 00:14:17,220
oke kita akan develop fitur tetap di
379
00:14:17,220 --> 00:14:18,720
misalnya di monolith
380
00:14:18,720 --> 00:14:20,400
atau semua fitur baru
381
00:14:20,400 --> 00:14:22,700
kita akan langsung pindahkan ke microservice gitu ya
382
00:14:22,700 --> 00:14:24,760
tapi mungkin developnya tidak akan secepat
383
00:14:24,920 --> 00:14:27,000
karena butuh maintain 2 sistem
384
00:14:27,000 --> 00:14:29,620
sistem yang monolith dan sistem yang microservice
385
00:14:29,620 --> 00:14:32,180
nah jadi banyak banget ya strategi untuk
386
00:14:33,060 --> 00:14:35,640
melakukan migrasi dari monolith ke microservice
387
00:14:35,640 --> 00:14:37,900
tapi intinya kita nggak bisa tiba-tiba stop
388
00:14:37,900 --> 00:14:38,900
hentikan gitu ya
389
00:14:38,900 --> 00:14:40,940
lalu tiba-tiba langsung bikin ulang
390
00:14:40,940 --> 00:14:42,700
dan microservicenya itu nggak bisa
391
00:14:42,700 --> 00:14:43,980
biasanya yang dilakukan adalah
392
00:14:43,980 --> 00:14:46,060
kita akan parsial ya
393
00:14:46,060 --> 00:14:49,140
jadi sedikit-sedikit fiturnya akan dipindahkan ke microservice
394
00:14:49,140 --> 00:14:51,180
ya nanti fitur yang lamanya
395
00:14:51,180 --> 00:14:53,600
kalau udah selesai dimatikan di yang monolithnya
396
00:14:53,600 --> 00:14:54,780
artinya kan tetap ada development
397
00:14:54,920 --> 00:14:55,500
di monolithnya
398
00:14:55,500 --> 00:14:57,660
jadi microservicenya yang jalan
399
00:14:57,660 --> 00:14:59,240
nah yang paling ribet lagi sebenarnya
400
00:14:59,240 --> 00:15:01,740
maintain konsistensi data ya
401
00:15:01,740 --> 00:15:02,640
jadi gimana caranya
402
00:15:02,640 --> 00:15:04,560
data yang masuk ke microservice
403
00:15:04,560 --> 00:15:07,100
di sistem yang monolith harus bisa kelihatan juga
404
00:15:07,100 --> 00:15:09,360
ya karena kan sebagian halaman
405
00:15:09,360 --> 00:15:11,320
mungkin sebagian aplikasi
406
00:15:11,320 --> 00:15:13,560
itu masih ngambil datanya ke monolithnya
407
00:15:13,560 --> 00:15:15,160
jadi itu memang banyak
408
00:15:16,040 --> 00:15:17,940
tantangannya ya ketika kita migrasi
409
00:15:19,580 --> 00:15:21,580
oke blibli.com mulai membuat
410
00:15:21,580 --> 00:15:23,900
service-service sesuai dengan domainnya masing-masing
411
00:15:23,900 --> 00:15:24,900
ada yang dibuatkan
412
00:15:24,920 --> 00:15:26,040
buat langsung independen
413
00:15:26,040 --> 00:15:28,140
ada yang dibuat terintegrasi dengan sistem lama
414
00:15:28,140 --> 00:15:30,180
ada juga yang hanya sebagai refer
415
00:15:30,180 --> 00:15:31,200
untuk sistem lama
416
00:15:31,200 --> 00:15:33,320
hal ini terus dilakukan sampai akhirnya sistem lama
417
00:15:33,320 --> 00:15:34,800
benar-benar tidak diperlukan lagi
418
00:15:34,800 --> 00:15:37,300
oke jadi tadi ya strateginya
419
00:15:37,300 --> 00:15:38,640
ini strateginya namanya sebenarnya
420
00:15:38,640 --> 00:15:39,780
strangler patterns
421
00:15:39,780 --> 00:15:41,040
teman-teman bisa cari
422
00:15:41,040 --> 00:15:42,580
namanya strangler patterns ya
423
00:15:42,580 --> 00:15:44,840
jadi intinya itu kayak strangler patterns itu
424
00:15:44,840 --> 00:15:45,840
kayak pohon
425
00:15:45,840 --> 00:15:46,620
ada pohon
426
00:15:46,620 --> 00:15:47,420
teman-teman bisa lihat
427
00:15:47,420 --> 00:15:49,020
suka ada benalu ya di pohonnya itu
428
00:15:49,020 --> 00:15:51,460
nah benalu itu anggap aja microservice
429
00:15:51,460 --> 00:15:53,460
jadi kita bikin banyak benalu di pohonnya
430
00:15:53,460 --> 00:15:54,840
sampai akhirnya pohon tersebut
431
00:15:54,920 --> 00:15:56,220
tertutupi sama benalunya
432
00:15:56,220 --> 00:15:58,480
jadi udah gak kelihatan lagi si monolithnya
433
00:15:58,480 --> 00:16:00,060
jadi semuanya udah microservice
434
00:16:00,060 --> 00:16:01,960
akhirnya ya pohonnya mati
435
00:16:01,960 --> 00:16:03,480
microservicenya kita matikan
436
00:16:03,480 --> 00:16:05,820
jadi tinggal ya microservicenya ini gitu ya
437
00:16:05,820 --> 00:16:07,540
jadi pohon-pohon benalunya itu
438
00:16:07,540 --> 00:16:10,080
jadi simplenya adalah yaudah
439
00:16:10,080 --> 00:16:11,340
sedikit-sedikit gitu ya
440
00:16:11,340 --> 00:16:12,620
kita pisahin
441
00:16:12,620 --> 00:16:13,920
keluarin jadi microservice
442
00:16:13,920 --> 00:16:15,300
nanti kalau udah selesai semua
443
00:16:15,300 --> 00:16:16,360
ya baru dimatikan
444
00:16:16,360 --> 00:16:18,880
makanya ini butuh waktu yang lama contohnya
445
00:16:18,880 --> 00:16:19,980
seperti ini butuh waktu
446
00:16:19,980 --> 00:16:21,800
2 tahun
447
00:16:23,740 --> 00:16:25,220
pada masa transisi
448
00:16:25,220 --> 00:16:26,340
jangan terlalu berharap
449
00:16:26,340 --> 00:16:27,180
dengan sistem yang ideal
450
00:16:27,180 --> 00:16:28,740
kadang kita punya ego
451
00:16:28,740 --> 00:16:30,040
bahwa saat rewrite system
452
00:16:30,040 --> 00:16:32,640
semua harus berjalan ideal
453
00:16:32,640 --> 00:16:34,380
kenyataannya tidak seperti itu
454
00:16:34,380 --> 00:16:35,600
ada kalanya bahkan
455
00:16:35,600 --> 00:16:37,240
kita harus membuat sistem baru
456
00:16:37,240 --> 00:16:39,320
yang menembak database sistem baru
457
00:16:39,320 --> 00:16:41,160
dan sistem lama secara bersamaan
458
00:16:41,160 --> 00:16:43,660
padahal mungkin ini hal yang menjijikan kelihatannya
459
00:16:43,660 --> 00:16:46,620
jadi saat kita migrasi ya
460
00:16:46,620 --> 00:16:48,300
dari monolith ke microservice tadi ya
461
00:16:48,300 --> 00:16:49,160
yang paling ribet itu adalah
462
00:16:49,160 --> 00:16:51,720
gimana caranya maintain konsistensi datanya
463
00:16:52,780 --> 00:16:54,480
ada 2 teknik sebenarnya ya
464
00:16:54,480 --> 00:16:56,220
oke berarti kalau ada data masuk
465
00:16:56,220 --> 00:16:57,600
ke sistem baru gitu ya
466
00:16:57,600 --> 00:16:58,880
kita akan kirim datanya
467
00:16:58,880 --> 00:17:00,220
dari sistem baru ke sistem lama
468
00:17:00,220 --> 00:17:01,840
caranya banyak sebenarnya
469
00:17:01,840 --> 00:17:04,040
mau kirim langsung API call
470
00:17:04,040 --> 00:17:04,860
problemnya adalah
471
00:17:04,860 --> 00:17:06,340
kalau kita ngirim API call
472
00:17:06,340 --> 00:17:08,640
dari sistem lama ke sistem baru misalnya ya
473
00:17:08,640 --> 00:17:10,480
nah problemnya di sistem lama
474
00:17:10,480 --> 00:17:11,880
kita harus bikin API juga
475
00:17:11,880 --> 00:17:13,600
nah ini lumayan ribet
476
00:17:13,600 --> 00:17:15,220
apalagi kalau sistem lamanya
477
00:17:15,220 --> 00:17:16,600
udah berantakan gitu ya
478
00:17:16,600 --> 00:17:17,360
udah susah di develop
479
00:17:17,360 --> 00:17:19,060
cara yang paling gampang adalah
480
00:17:19,060 --> 00:17:19,920
dari sistem lama
481
00:17:20,660 --> 00:17:21,780
kita tembakan
482
00:17:21,780 --> 00:17:22,500
aja database nya
483
00:17:22,500 --> 00:17:23,440
jadi dari sistem baru
484
00:17:23,440 --> 00:17:24,760
ketika masuk data baru
485
00:17:24,760 --> 00:17:26,500
kita langsung kirim ke sistem lama
486
00:17:26,500 --> 00:17:27,720
langsung ke database nya
487
00:17:27,720 --> 00:17:29,260
jadi nanti sistem lama itu
488
00:17:29,260 --> 00:17:30,200
gak perlu di develop lagi
489
00:17:30,200 --> 00:17:31,120
nah ini
490
00:17:31,120 --> 00:17:32,180
cara yang
491
00:17:32,960 --> 00:17:34,520
bisa juga dilakukan ya
492
00:17:34,520 --> 00:17:34,800
jadi
493
00:17:34,800 --> 00:17:36,580
satu aplikasi microservice itu
494
00:17:36,580 --> 00:17:37,680
nembak ke database nya
495
00:17:37,680 --> 00:17:39,900
sama nembak ke database sistem yang lama
496
00:17:39,900 --> 00:17:41,280
ya memang kelihatannya kayak
497
00:17:41,980 --> 00:17:42,740
jelek banget
498
00:17:42,740 --> 00:17:44,060
tapi ya itu harus dilakukan
499
00:17:44,060 --> 00:17:45,400
karena itu masa transisi
500
00:17:45,400 --> 00:17:47,280
sampai semuanya sudah selesai
501
00:17:47,280 --> 00:17:48,120
ya baru nanti di
502
00:17:48,120 --> 00:17:49,220
hilangkan
503
00:17:51,820 --> 00:17:53,820
API first development
504
00:17:53,820 --> 00:17:56,500
awal blibli.com migrasi ke microservice
505
00:17:56,500 --> 00:17:58,560
konsep yang digunakan oleh blibli.com
506
00:17:58,560 --> 00:18:00,560
hampir sama dengan semua perusahaan kebanyakan
507
00:18:00,560 --> 00:18:02,220
yaitu API first development
508
00:18:02,220 --> 00:18:04,960
dimana pada saat melakukan development system
509
00:18:04,960 --> 00:18:07,060
setiap produk akan membuat API
510
00:18:07,060 --> 00:18:09,460
biasanya menggunakan RESTful web service
511
00:18:09,460 --> 00:18:11,220
untuk semua fitur
512
00:18:11,220 --> 00:18:12,800
yang dimiliki produk tersebut
513
00:18:12,800 --> 00:18:14,460
dan produk yang membutuhkan data
514
00:18:14,460 --> 00:18:16,120
atau layanan dari produk tersebut
515
00:18:16,120 --> 00:18:18,420
hanya butuh menembak API tersebut
516
00:18:18,420 --> 00:18:20,420
jadi ini udah lumrah ya
517
00:18:20,420 --> 00:18:21,220
jadi kalau misalnya kita
518
00:18:21,220 --> 00:18:21,760
biasanya bisa membuat API tersebut
519
00:18:21,780 --> 00:18:22,360
kita bikin microservice
520
00:18:22,360 --> 00:18:24,680
pasti microservice itu akan bikin API-nya
521
00:18:24,680 --> 00:18:25,360
jadi nanti
522
00:18:25,360 --> 00:18:27,760
microservice manapun yang butuh gitu ya
523
00:18:27,760 --> 00:18:29,860
ya dia akan manggil si API-nya
524
00:18:29,860 --> 00:18:31,360
jadi kalau misalnya oke saya
525
00:18:32,640 --> 00:18:33,720
buka halaman
526
00:18:33,720 --> 00:18:35,280
misalnya homepage gitu ya
527
00:18:35,280 --> 00:18:37,020
di dalam homepage saya butuh data produk
528
00:18:37,020 --> 00:18:39,280
saya akan manggil produk microservice
529
00:18:39,280 --> 00:18:40,680
saya butuh data member
530
00:18:40,680 --> 00:18:42,780
ya ngambil member microservice
531
00:18:42,780 --> 00:18:44,380
saya butuh data misalnya
532
00:18:44,380 --> 00:18:46,740
banner ya kita akan
533
00:18:46,740 --> 00:18:49,360
panggil misalnya banner microservice kayak gitu
534
00:18:49,360 --> 00:18:50,640
nah ini
535
00:18:50,640 --> 00:18:51,760
arsitekturnya
536
00:18:51,780 --> 00:18:52,780
kurang lebih seperti ini ya
537
00:18:52,780 --> 00:18:54,320
jadi ini API gateway-nya
538
00:18:54,320 --> 00:18:56,380
jadi ini request-nya masuk misalnya
539
00:18:56,380 --> 00:18:57,900
nah lalu kalau misalnya
540
00:18:58,600 --> 00:19:00,840
API gateway ada pengecekan dulu ya
541
00:19:00,840 --> 00:19:01,980
authentication gitu ya
542
00:19:01,980 --> 00:19:03,220
nah seperti itu
543
00:19:03,220 --> 00:19:05,580
atau disini kalau mau dapetin data member
544
00:19:05,580 --> 00:19:08,180
member ternyata butuh data password
545
00:19:08,180 --> 00:19:09,120
sorry bukan password
546
00:19:09,120 --> 00:19:10,560
username, email gitu ya
547
00:19:10,560 --> 00:19:11,540
kredensial ya kita
548
00:19:11,540 --> 00:19:14,200
manggil ke authentication service contohnya
549
00:19:14,200 --> 00:19:16,660
atau misalnya kalau ada request ke card
550
00:19:16,660 --> 00:19:18,520
card itu butuh bikin order
551
00:19:18,520 --> 00:19:20,380
nah nanti dia akan bikin ke order
552
00:19:20,380 --> 00:19:21,500
contohnya seperti itu
553
00:19:21,780 --> 00:19:24,080
nah contohnya ada wishlist gitu ya
554
00:19:24,080 --> 00:19:25,500
kalau misalnya wishlist kan butuh
555
00:19:25,500 --> 00:19:26,440
tampilkan data produk
556
00:19:26,440 --> 00:19:28,540
maka dia akan panggil data produknya
557
00:19:28,540 --> 00:19:29,980
jadi ini udah biasa ya
558
00:19:29,980 --> 00:19:30,640
yang kita lakukan
559
00:19:30,640 --> 00:19:33,260
kalau bikin microservice berbasis API
560
00:19:33,260 --> 00:19:34,860
jadi siapa yang butuh
561
00:19:34,860 --> 00:19:36,600
tinggal panggil si microservice-nya
562
00:19:38,340 --> 00:19:40,220
tidak ada permasalahan ya
563
00:19:40,220 --> 00:19:43,140
dengan API first development
564
00:19:43,140 --> 00:19:44,760
sampai pada akhirnya
565
00:19:44,760 --> 00:19:47,140
jika lo kita lihat secara melebar
566
00:19:47,140 --> 00:19:49,120
artinya sistem pada microservice tersebut
567
00:19:49,120 --> 00:19:51,080
akan terlalu bergantung
568
00:19:51,080 --> 00:19:51,600
dengan sistem lain
569
00:19:51,780 --> 00:19:53,460
hal ini agak menyulitkan
570
00:19:53,460 --> 00:19:55,280
akhirnya ketika sebuah sistem
571
00:19:55,280 --> 00:19:56,900
terlalu bergantung kepada sistem lain
572
00:19:56,900 --> 00:19:59,060
yang paling sulit ketika menggunakan
573
00:19:59,060 --> 00:20:00,420
API first development adalah
574
00:20:00,420 --> 00:20:02,340
saat sebuah service harus mengirim data
575
00:20:02,340 --> 00:20:03,320
ke beberapa service
576
00:20:03,320 --> 00:20:05,760
jika lo pada suatu waktu
577
00:20:05,760 --> 00:20:08,380
ada service baru yang membutuhkan data tersebut
578
00:20:08,380 --> 00:20:10,120
maka tim yang memegang service producer
579
00:20:10,860 --> 00:20:12,340
harus melakukan perubahan
580
00:20:12,340 --> 00:20:13,880
untuk menembak service yang barunya
581
00:20:13,880 --> 00:20:16,300
oke jadi contohnya kayak gini misalnya ya
582
00:20:18,940 --> 00:20:19,820
problemnya adalah
583
00:20:19,820 --> 00:20:21,760
kalau misalnya API first development
584
00:20:21,780 --> 00:20:23,240
dia sangat tergantung
585
00:20:23,240 --> 00:20:24,240
dengan service yang lainnya
586
00:20:24,240 --> 00:20:26,400
jadi contohnya kalau saya buka wishlist
587
00:20:26,400 --> 00:20:28,220
itu kan manggil wishlist service
588
00:20:28,220 --> 00:20:30,460
tapi untuk wishlist service kan perlu
589
00:20:30,460 --> 00:20:32,320
ngebalikan data produknya ya
590
00:20:32,320 --> 00:20:33,600
jadi dia harus
591
00:20:34,220 --> 00:20:36,400
manggil si data produk service-nya
592
00:20:36,400 --> 00:20:38,560
ketika ada masalah di product service
593
00:20:38,560 --> 00:20:40,620
contohnya product service-nya lagi mati gitu ya
594
00:20:40,620 --> 00:20:43,220
atau lagi down atau lagi maintenance gitu ya
595
00:20:43,220 --> 00:20:44,880
maka semua yang memanggil
596
00:20:44,880 --> 00:20:46,620
product service itu ikutan maintenance juga
597
00:20:46,620 --> 00:20:48,620
ex-wishlist contohnya
598
00:20:48,620 --> 00:20:50,000
service-wishlist ini gak bisa juga
599
00:20:50,000 --> 00:20:51,760
karena dia butuh data produknya
600
00:20:51,780 --> 00:20:53,620
akhirnya dia gak bisa nampilin data produknya
601
00:20:53,620 --> 00:20:56,700
nah contohnya misalnya ada order service misalnya ya
602
00:20:56,700 --> 00:20:58,720
order service itu butuh data produknya
603
00:20:58,720 --> 00:21:00,260
karena dia manggil data produk misalnya
604
00:21:00,260 --> 00:21:02,780
maka otomatis tidak bisa menampilkan produknya
605
00:21:02,780 --> 00:21:05,240
padahal produknya ini yang lagi maintenance
606
00:21:05,240 --> 00:21:06,900
nah ini beberapa problem
607
00:21:06,900 --> 00:21:11,300
kalau kita menggunakan API first development ya
608
00:21:11,300 --> 00:21:13,220
jadi semuanya bergantung menggunakan API
609
00:21:13,220 --> 00:21:14,620
contohnya kayak gini
610
00:21:14,620 --> 00:21:16,200
kalau saya mau nambahin ke
611
00:21:17,180 --> 00:21:18,460
ngebikin order
612
00:21:18,460 --> 00:21:20,000
itu kan lewat card misalnya
613
00:21:20,000 --> 00:21:21,760
nah tapi karena ordernya lagi mati
614
00:21:21,780 --> 00:21:23,420
lagi masalah ya gak bisa jalan gitu ya
615
00:21:23,420 --> 00:21:26,160
karena ordernya lagi masalah
616
00:21:26,160 --> 00:21:28,240
jadi cardnya pun ikutan kena masalahnya juga
617
00:21:28,240 --> 00:21:31,320
jadi benar-benar sangat tergantung ya
618
00:21:31,320 --> 00:21:33,440
kalau kita menggunakan API first development
619
00:21:37,440 --> 00:21:40,080
oke blipi.com versi 3.0
620
00:21:40,080 --> 00:21:41,460
event first development
621
00:21:42,240 --> 00:21:43,780
selain API first development
622
00:21:43,780 --> 00:21:46,280
salah satu konsep microservice yang populer
623
00:21:46,280 --> 00:21:47,560
adalah event first development
624
00:21:47,560 --> 00:21:49,140
atau sekarang mungkin lebih populer
625
00:21:49,140 --> 00:21:51,280
dengan nama event driven architecture ya
626
00:21:51,280 --> 00:21:53,740
nah berbeda dengan API first development
627
00:21:54,300 --> 00:21:55,300
pada event first development
628
00:21:55,300 --> 00:21:57,720
semua integrasi antar servicenya
629
00:21:57,720 --> 00:21:58,680
itu menggunakan event
630
00:21:58,680 --> 00:22:00,400
atau via message broker
631
00:22:00,400 --> 00:22:02,020
hal ini mengakibatkan
632
00:22:02,020 --> 00:22:03,760
service tidak perlu lagi membuat API
633
00:22:03,760 --> 00:22:05,280
melainkan service hanya perlu
634
00:22:05,280 --> 00:22:07,700
mempublish event ke message brokernya
635
00:22:07,700 --> 00:22:10,260
kalau misalnya ingin membagikan datanya
636
00:22:10,260 --> 00:22:11,460
atau mengirim datanya
637
00:22:12,980 --> 00:22:14,640
pada akhir tahun 2017
638
00:22:14,640 --> 00:22:17,120
dari blip.com itu melakukan inisiatif
639
00:22:17,120 --> 00:22:17,980
untuk menguji
640
00:22:17,980 --> 00:22:20,120
menguji coba implementasi
641
00:22:20,120 --> 00:22:22,060
event first development di blip.com
642
00:22:22,060 --> 00:22:24,000
dimulai dari sistem-sistem baru
643
00:22:24,000 --> 00:22:24,580
yang didevelop
644
00:22:24,580 --> 00:22:26,860
akhirnya setelah kurang lebih 3 bulan
645
00:22:26,860 --> 00:22:27,880
mengembangkan sistem baru
646
00:22:27,880 --> 00:22:29,680
dan beberapa bulan menghadapi
647
00:22:29,680 --> 00:22:31,180
beberapa permasalahan yang terjadi
648
00:22:31,180 --> 00:22:32,360
di event driven development
649
00:22:32,360 --> 00:22:35,060
tim blip.com berhasil untuk mengimplementasikan
650
00:22:35,060 --> 00:22:37,720
konsep event first development di blip.com
651
00:22:37,720 --> 00:22:40,140
nah tantangan dan permasalahan
652
00:22:40,140 --> 00:22:41,920
yang kita hadapi di event first development
653
00:22:41,920 --> 00:22:43,620
nanti akan di share di artikel berbeda
654
00:22:43,620 --> 00:22:45,520
oke artikelnya sudah pernah saya bikin ya
655
00:22:45,520 --> 00:22:47,820
namanya event driven development
656
00:22:47,820 --> 00:22:49,280
event driven architecture
657
00:22:49,280 --> 00:22:52,000
kalau nggak salah nanti kita bikin lagi deh ya
658
00:22:53,000 --> 00:22:53,680
reactionnya
659
00:22:54,000 --> 00:22:54,680
oke
660
00:22:54,680 --> 00:22:56,920
jadi yang sebelumnya itu
661
00:22:56,920 --> 00:22:58,320
tiap service itu
662
00:22:58,320 --> 00:22:59,660
manggil service yang lain ya
663
00:22:59,660 --> 00:23:01,240
kalau ini kan manggil service yang lain nih
664
00:23:01,240 --> 00:23:03,040
jadi saling ketergantungan
665
00:23:03,040 --> 00:23:03,980
problemnya adalah
666
00:23:03,980 --> 00:23:06,940
kalau yang ketergantungan itu masalah
667
00:23:06,940 --> 00:23:08,920
maka yang bergantung ke service itu
668
00:23:08,920 --> 00:23:10,740
otomatis kena masalahnya semua
669
00:23:10,740 --> 00:23:12,700
nah akhirnya berubah
670
00:23:12,700 --> 00:23:13,600
arsitekturnya menjadi
671
00:23:14,840 --> 00:23:16,880
arsitektur event first development
672
00:23:16,880 --> 00:23:18,060
nah seperti ini
673
00:23:18,060 --> 00:23:19,820
jadi event first development
674
00:23:19,820 --> 00:23:21,080
kurang lebih seperti ini
675
00:23:21,080 --> 00:23:23,120
jadi nanti service itu
676
00:23:23,120 --> 00:23:23,980
tidak ada kompetensi
677
00:23:24,000 --> 00:23:25,960
dari service satu ke service yang lain
678
00:23:25,960 --> 00:23:27,020
jadi contohnya disini
679
00:23:27,020 --> 00:23:29,740
ada request masuk ke API gateway
680
00:23:29,740 --> 00:23:32,640
API gateway kirimkan ke service yang ditujunya
681
00:23:32,640 --> 00:23:34,680
nah untuk pertukaran datanya
682
00:23:34,680 --> 00:23:36,140
itu menggunakan yang namanya
683
00:23:36,140 --> 00:23:37,940
ini message broker ya
684
00:23:37,940 --> 00:23:39,780
jadi perantara message broker disini
685
00:23:39,780 --> 00:23:41,600
nah contohnya disini di blibli.co
686
00:23:41,600 --> 00:23:42,540
menggunakan kafka
687
00:23:42,540 --> 00:23:45,160
jadi kalau contohnya oke data merchant itu
688
00:23:45,160 --> 00:23:47,520
saya butuh data member gitu ya
689
00:23:47,520 --> 00:23:50,080
maka dia akan ngambil data membernya dari kafka
690
00:23:50,080 --> 00:23:51,520
dimana data member itu
691
00:23:51,520 --> 00:23:53,520
dikirimkan oleh si member disini
692
00:23:54,000 --> 00:23:55,080
jadi setiap ada perubahan
693
00:23:55,080 --> 00:23:56,980
data member dikirimkan ke kafka
694
00:23:56,980 --> 00:23:58,380
nanti semuanya akan diterima
695
00:23:58,380 --> 00:24:00,340
dan disimpan secara duplikat
696
00:24:00,340 --> 00:24:01,580
di dalam si merchantnya
697
00:24:01,580 --> 00:24:04,760
nah atau kalau saya mau ngirim notifikasi gitu ya
698
00:24:04,760 --> 00:24:07,000
jadi nanti kalau misalnya ada transaksi di core
699
00:24:07,000 --> 00:24:08,540
transaksi di core misalnya
700
00:24:08,540 --> 00:24:10,240
akan kirim ada transaksi baru
701
00:24:10,240 --> 00:24:13,180
nanti diambil datanya oleh notification
702
00:24:13,180 --> 00:24:15,120
nanti notificationnya ngirim email
703
00:24:15,120 --> 00:24:16,500
ngirim SMS misalnya
704
00:24:16,500 --> 00:24:17,940
ngirim WA gitu ya
705
00:24:17,940 --> 00:24:19,820
nah semua dilakukan seperti itu
706
00:24:19,820 --> 00:24:21,140
nah jadi
707
00:24:21,140 --> 00:24:23,820
sekarang integrasinya bukan lagi ke
708
00:24:24,000 --> 00:24:25,780
dari service ke service
709
00:24:25,780 --> 00:24:27,420
melainkan menggunakan event ya
710
00:24:27,420 --> 00:24:29,720
dimana eventnya dikirim ke message broker
711
00:24:29,720 --> 00:24:32,180
yaitu adalah kafka ini
712
00:24:33,620 --> 00:24:36,320
nah saat ini kita sedang menjalani
713
00:24:36,320 --> 00:24:38,180
masa transisi dari API first development
714
00:24:38,180 --> 00:24:39,620
ke event first development
715
00:24:39,620 --> 00:24:41,780
pastinya masa transisi ini akan berjalan lama
716
00:24:41,780 --> 00:24:43,680
dimana ratusan service
717
00:24:43,680 --> 00:24:46,340
sudah berjalan di productionnya blibli.com
718
00:24:46,340 --> 00:24:47,920
jadi saat ini
719
00:24:47,920 --> 00:24:49,780
progres migrasi yang kita lakukan
720
00:24:49,780 --> 00:24:52,020
diutamakan untuk service baru terlebih dahulu
721
00:24:52,020 --> 00:24:53,940
dan juga service yang belum
722
00:24:54,000 --> 00:24:54,700
di improve
723
00:24:54,700 --> 00:24:57,340
nah jadi ini kurang lebih
724
00:24:57,340 --> 00:24:58,860
evolusi yang terjadi ya
725
00:24:58,860 --> 00:25:01,660
ini sampai 2017 sampai 2018 ya
726
00:25:01,660 --> 00:25:04,120
nah jadi sekarang udah lewat
727
00:25:04,120 --> 00:25:06,100
berapa tahun? hampir 5 tahun ya
728
00:25:06,100 --> 00:25:08,000
jadi ini 5 tahun yang lalu evolusinya
729
00:25:08,000 --> 00:25:10,120
dari versi 1 dari monolith
730
00:25:10,120 --> 00:25:11,480
habis itu
731
00:25:11,480 --> 00:25:13,760
ke microservice ya versi 2 nya
732
00:25:13,760 --> 00:25:14,940
dan versi 3 nya
733
00:25:14,940 --> 00:25:17,980
versi 2 nya itu microservice yang API
734
00:25:17,980 --> 00:25:20,080
dan versi 3 nya itu
735
00:25:20,080 --> 00:25:21,640
microservice yang event
736
00:25:21,640 --> 00:25:23,000
first development
737
00:25:24,000 --> 00:25:26,360
artikelnya ada sih nanti saya bikin reaction lagi
738
00:25:26,360 --> 00:25:28,600
nah kita akan coba lihat beberapa komentar
739
00:25:28,600 --> 00:25:29,620
mungkin ada yang menarik
740
00:25:36,500 --> 00:25:37,580
mau nanya mas
741
00:25:37,580 --> 00:25:40,680
ini event base nya hanya antar microservice ya
742
00:25:40,680 --> 00:25:41,960
jika lo dengan client side
743
00:25:41,960 --> 00:25:43,840
apps atau mobile browser apakah tetap
744
00:25:43,840 --> 00:25:45,480
press API atau ada approach lainnya
745
00:25:45,480 --> 00:25:47,740
iya kalau event base nya itu memang
746
00:25:48,920 --> 00:25:49,480
pake
747
00:25:50,400 --> 00:25:51,420
antar service ya
748
00:25:51,420 --> 00:25:53,080
tapi kalau untuk interaksi keluar
749
00:25:53,080 --> 00:25:55,500
contohnya ke mobile gitu ya ke browser
750
00:25:55,500 --> 00:25:56,600
ya tetap menggunakan API
751
00:25:56,600 --> 00:25:58,420
karena kan mereka gak bisa
752
00:25:58,420 --> 00:25:59,380
connectnya
753
00:25:59,400 --> 00:26:00,580
connect langsung ke Kafka gitu ya
754
00:26:00,580 --> 00:26:02,640
karena Kafka itu ada di internal sistemnya
755
00:26:06,470 --> 00:26:08,050
yang kayak gini cocok banget
756
00:26:08,050 --> 00:26:10,090
buat nentuin desain pattern apa yang cocok
757
00:26:10,090 --> 00:26:11,330
untuk pengembangan startup
758
00:26:12,250 --> 00:26:13,890
ini maksudnya desain pattern apa ya
759
00:26:13,890 --> 00:26:15,450
harusnya sih gak ini ya
760
00:26:15,450 --> 00:26:16,790
gak ini juga
761
00:26:16,790 --> 00:26:18,250
kalau desain pattern itu lebih ke
762
00:26:18,250 --> 00:26:19,850
scope nya lebih kecil lagi gitu ya
763
00:26:19,850 --> 00:26:21,710
dari arsitektur dari aplikasinya
764
00:26:21,710 --> 00:26:24,910
bukan arsitektur dari seluruh sistemnya
765
00:26:29,600 --> 00:26:31,200
programming nya lebih banyak pake apa
766
00:26:31,200 --> 00:26:33,260
nah kalau di blib itu kebanyakan pake Java
767
00:26:40,230 --> 00:26:42,190
oh iya jika kalau Kafka nya down
768
00:26:42,190 --> 00:26:44,630
apa yang terjadi apakah world system will be down
769
00:26:44,630 --> 00:26:46,330
penasaran programming lain
770
00:26:46,330 --> 00:26:47,870
di blib di versi 3 tetap pake Java
771
00:26:47,870 --> 00:26:49,330
atau sudah pake yang lain
772
00:26:49,330 --> 00:26:51,770
kalau di blib sampai sekarang sih
773
00:26:51,770 --> 00:26:53,970
pake Java ya kebanyakan ya
774
00:26:53,970 --> 00:26:55,810
nah pertanyaannya mungkin ini menarik nih
775
00:26:55,810 --> 00:26:58,290
kalau misalnya down gimana Kafka nya
776
00:26:58,290 --> 00:26:59,990
ya kalau Kafka nya down otomatis semua
777
00:27:00,850 --> 00:27:02,090
interaksi di antar
778
00:27:02,090 --> 00:27:03,750
microservice nya akan mati gitu ya mati total
779
00:27:04,310 --> 00:27:06,330
maka dari itu saat kita pilih
780
00:27:06,330 --> 00:27:08,290
message broker pastikan message broker nya
781
00:27:08,290 --> 00:27:10,030
yang memang scalable ya
782
00:27:10,230 --> 00:27:12,070
dan memang terbukti dengan baik gitu ya
783
00:27:12,070 --> 00:27:14,570
contohnya Kafka itu memang terbukti dengan baik gitu ya
784
00:27:16,070 --> 00:27:18,510
banyak perusahaan perusahaan gede itu pake Kafka
785
00:27:18,510 --> 00:27:22,230
makanya waktu itu dipilihnya Kafka ya
786
00:27:22,230 --> 00:27:23,910
jadi kenapa enggak message broker yang lain
787
00:27:23,910 --> 00:27:26,350
jadi lebih pilih ke stabilitas gitu ya
788
00:27:26,350 --> 00:27:30,850
scalable nya bagus dan ya sudah proven di industri
789
00:27:30,850 --> 00:27:32,450
makanya dipilihnya Kafka
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment