Dokumen tersebut membahas tentang transformasi organisasi menjadi cloud native dengan menggunakan pendekatan microservice. Dokumen tersebut menjelaskan tentang apa itu cloud native dan manfaatnya, metrik untuk mengukur kesiapan organisasi berpindah ke cloud native, dan beberapa best practice untuk mengimplementasikan microservice seperti dekomposisi layanan, komunikasi antar layanan, dan manajemen data.

1. Cloud Native
Transformation
Microservice Implementation
PT. Pegadaian 2020

2. Siapa Saya?
https://medium.com/the-legend

3. Cloud Native
Transformation
01
Seberapa Siap Organisasi Kita
Berpindah Ke Cloud Native

4. Apa itu Cloud Native?
Cloud-Native adalah pendekatan untuk membangun
dan menjalankan aplikasi yang memanfaatkan
keuntungan dari cloud computing delivery model. Cloud-
native juga dikenal dengan cara bagaimana aplikasi
dapat dibuat dan di deploy.

5. Cloud native ini bukan hanya sekadar kumpulan
teknologi dan tools yang kita gunakan. Tetapi juga
merupakan pendekatan filosofis untuk membangun
aplikasi yang sepenuhnya memanfaatkan cloud
computing. Paradigma baru ini tidak hanya merangkul
teknologi baru tetapi juga cara kerja yang baru. Jadi,
singkatnya transformasi ke cloud native membutuhkan
new way of thinking dan new way of working.

6. Keuntungan dari cloud native?

7. 1. Cloud computing memiliki keunggulan sangat kompetitif.
2. Team dapat fokus pada pembuatan aplikasi yang berkualitas
dan tangguh
3. Flexibility yang lebih tinggi
4. Lebih aman
5. Faster time to market
6. Lebih dapat mensupport business lebih bagus
7. Cost optimization

9. Metrix Kesiapan Organisasi

10. Area Kondisi Organisasi
Area No Process
Rush first thinking
later
Area Waterfall
Have process but
long term result
Area Agile
Better process but
still high cost
Area Cloud Native
Ideal process, cost
efficient and effective
01
03 04
02

11. Area Kondisi Organisasi
Area 1- No Process
Area pertama adalah area sebuah organisasi yang berjalan dengan
tidak ada proses yang digunakan atau saya suka menyebutnya area
bar-bar. Rata-rata mereka rush dahulu baru berpikir.

12. Area Kondisi Organisasi
Area 2 Waterfall Process
Sudah ada proses yang lebih baik, terencana, dan terukur akan tetapi
proses dan hasilnya lama baru bisa dilihat. Proses ini sudah tidak
relevan untuk kondisi sekarang.

13. Area Kondisi Organisasi
Area 3 Agile Process
Proses yang digunakan sudah lebih baik. Proses dan hasil bisa dilihat
secepat mungkin dan bisa beradaptasi dengan segala keadaan. Akan
tetapi, masih banyak hal yang membuat semua proses tidak bergerak
dengan cepat dan cenderung high cost atau biaya masih sangat tinggi.

14. Area Kondisi Organisasi
Area 4 Cloud-Native Process
Merupakan proses yang sangat ideal yang mesti kita capai dan gunakan
untuk kondisi sekarang ini. Semua proses berjalan efektif dan efisien. Cost
juga sudah sangat significant meningkat efisiensinya. Hal ini terjadi
karena semua proses sudah saling mendukung satu sama lain dan
bersinergi. Ciri utama adalah terjadinya automation pada beberapa hal
yang dulunya dilakukan secara manual.

15. Culture atau Habit
Pada bagian ini kita dapat menjelaskannya sebagai
bagaimana seorang individu di dalam sebuah organisasi
berinteraksi satu sama lain. Biasanya hal ini menjadi ciri
khas dalam suatu organisasi. Bagian ini juga menjadi
modal dasar untuk bagian-bagian lainnya bisa berjalan
dengan baik dan lancar.

16. Product dan Service Design
Area ini didefinisikan sebagai “bagaimana sebuah
keputusan dibuat di dalam sebuah organisasi, dan
apa yang harus dilakukan berikutnya”. Misalnya,
produk apa yang harus dibuat selanjutnya, dan fitur
apa yang harus ditambahkan.

17. Team (Engineering)
Area ini didefinisikan sebagai “bagaimana tanggung
jawab, komunikasi dan kolaborasi antar tim berjalan
di dalam sebuah organisasi”.

18. Proses
Area ini didefinisikan sebagai “bagaimana sebuah
organisasi melakukan pembagian tugas, dan
mengeksekusi sebuah project, product, atau task”

19. Architecture
Area ini didefinisikan sebagai “struktur keseluruhan
sistem dan teknologi” yang saat ini kita adopsi”

20. Maintenance dan Operations
Area ini didefinisikan sebagai “bagaimana sebuah aplikasi di-
deploy dan berjalan di production environment termasuk
monitoring dan operasi menjaga sistem atau aplikasi tetap
berjalan dengan baik.

21. Delivery
Area ini didefinisikan sebagai “bagaimana dan kapan
aplikasi yang dikembangkan di-deploy di production
environment”

22. Provisioning
Area ini didefinisikan sebagai “proses dimana kita
membuat atau memperbaharui sistem di production
environment”.

23. Infrastructure
Area ini didefinisikan sebagai “physical servers dimana
production environment berada (apa bentuknya,
dimana lokasinya, dan bagaimana mereka di-
manage)”

24. Infrastructure
Area ini didefinisikan sebagai “physical servers dimana
production environment berada (apa bentuknya,
dimana lokasinya, dan bagaimana mereka di-manage)”

25. Metrix Kesiapan Organisasi

26. Pattern Family

27. Strategi dan Risk Reduksi Pattern
Pola-pola yang secara khusus membentuk dan
menerapkan strategi keseluruhan dalam organisasi
Cloud Native: mengurangi risiko dan membangun
untuk kesuksesan jangka panjang, baik selama
transformasi dan kemudian menjadi apapun yang
terjadi selanjutnya.
https://www.cnpatterns.org/strategy-risk-reduction.

28. Organisasi dan Cultural Pattern
Pola untuk memandu evolusi organisasi:
mengurangi ketergantungan dan memberdayakan
tim untuk mandiri, proaktif, dan mandiri sambil
memberikan dengan cepat dan berulang.
https://www.cnpatterns.org/organization-culture

29. Development dan Design Pattern
Pola untuk mengetahui bagaimana merancang,
membangun, dan memberikan produk /
layanan dalam paradigma baru ini: arsitektur
dan proses yang mendukung Cloud Native,
pengiriman dinamis yang cepat dan responsif.
https://www.cnpatterns.org/development-design.

30. Infrastruktur dan Cloud Pattern
Pola yang membantu dalam menemukan dan
memilih infrastruktur yang tepat, sambil
menghindari jebakan umum seperti vendor lock-in
dan membangun custom solusi yang tidak perlu.
https://www.cnpatterns.org/infrastructure-cloud.

31. Referensi
1. https://medium.com/the-legend/transformasi-ke-
cloud-native-82a8afed31e0
2. https://www.cnpatterns.org

32. —Deni Husni FR
“Keep in mind that API not only
runs from server to server but also
from people to people.”

33. Microservice
Best Practice

34. Apa itu Microservice?
Microservice Arsitektur adalah software arsitektur berorientasi
pada cara pembuatan aplikasi yang terdiri dari service-service
kecil. Service-service ini terhubung satu sama lain dan bekerja
sama membentuk satu kesatuan. Hubungan dan ketergantungan
satu service dengan service lainnya tidak terlalu ketat bahkan
cukup longgar. Dengan demikian masing-masing service terbebas
dari service-service lainya. Kita sering menyebutnya dengan
istilah loosely coupled.

35. Scale Cube dan Microservice

36. Arah-X, biasanya dilakukan untuk scalling sistem
monolit. Load balancer diperlukan untuk membagi
jumlah permintaan yang masuk ke sistem dan
mendistribusikannya ke semua salinan aplikasi. Ini
adalah cara terbaik untuk meningkatkan kapasitas dan
ketersediaan aplikasi.

37. Y-direction , cara untuk scale up sama dengan arah X-
direction, yaitu dengan membuat beberapa instance dan
membagi beban menggunakan load balancer. Namun,
dalam arah y, setiap instance aplikasi hanya akan
melayani sekelompok data. Teknik scale up ke arah Y
merupakan cara terbaik untuk meningkatkan kinerja
aplikasi dalam menangani peningkatan jumlah transaksi
dan data.

39. Z-direction, cara untuk scalling dengan membagi aplikasi
monolit menjadi beberapa layanan yang lebih kecil
berdasarkan fungsionalitas. Arah x dan arah y belum
dapat menjadi solusi untuk masalah peningkatan
jumlah kode dan kompleksitas, dengan arah z ini
permasalahan tersebut dapat diselesaikan dengan baik.

43. Why!
Hal-hal penting yang harus diperhatikan ketika migrasi ke
Microservice

44. Decomposition Strategy
1. Ukuran seberapa kecil service yang dibuat relatif dan banyak
kondisi. Jangan terlalu kecil atau terlalu besar. Terlalu kecil menjadi
terlalu banyak call antar service. Terlalu besar jatuhnya masih
monolith atau monolith terdistribusi.
1. Service sekecil mungkin yang dapat di handle atau di deploy sama
sedikit developer. (4-6 developer)
1. Dibagi berdasarkan business model bukannya fungsional /
teknikal.

46. Antar Service Komunikasi
Big Problem pada microservice adalah latency dan blocking process
1. Semua komunikasi harus lewat API, tidak ada jalan belakang atau
share database. Kecuali Redis, Elasticsearch
1. HTTP/2 atau Grpc
1. Messaging , Pub/ Subscribe, Kafka, Rabbit MQ
1. Reactive Programming (Asynchronous dan non blocking)

47. Data Management
Big Problem pada microservice Data konsistensi
1. Database Perservice
1. Bounded Context
1. Saga Pattern

51. Proses Migration
Big problem pada microservice data migrasi
1. Rewrite seluruhnya dari nol (not recommended)
1. Sebagian-sebagian menggunakan metode Strangler Pattern

52. Strangler Pattern

54. Side Car Service
1. Api Gateway
2. Client Side Load Balancing
3. Service Discovery
4. Circuit Breaker
5. Monitoring dan Alreting (New Relic, Grafana, ELK)
6. Distributed Logging dan Tracing (Zipkin)
Kubernetes dan docker, GoMicro, Spring Cloud Microservice, AWS dan GCP

55. Pertanyaan ???

56. Alternative Resources
https://medium.com/the-legend

57. CREDITS: This presentation template was created by Slidesgo, including
icons by Flaticon, infographics & images by Freepik and illustrations by
Stories
Thanks!
Do you have any questions?
dhfr123@gmail.com
+62 82117419014
https://medium.com/the-legend
https://www.linkedin.com/in/deni-husni-fahri-rizal-76954235/