apidays LIVE JAKARTA - Connecting the Digital Stack
Take control of your microservices with App Mesh
Akhmad Makki, Enterprise Solution Strategist at Software AG
Seperti yang mungkin terjadi di organisasi temen-temen sekalian, kita melihat bahwa moving forward secara pelan tapi pasti aplikasi aplikasi baru mulai menggunakan arsitektur microservices dan tidak lagi berupa aplikasi monolith biasa. Mungkin ada yang belum terlalu familiar dengan microservices, Apa itu microservices ? Microservices basically adalah the way kita mengembangkan aplikasi kita menjadi collection dari beberapa services yang lebih fine grained secara scope dan bisa menjadi loosely coupled satu sama lain. Salah satu benefit utama dari microservices adalah scalability, kita bisa scale up atau scale down salah satu services tanpa harus mempengaruhi services yang lain.
Tiap organisasi mempunyai perjalanan masing-masing dalam mentransformasikan arsitektur mereka dari monolith ke microservices. Beberapa contoh enterprise besar antara lain Netflix dimana awalnya mereka menggunakan Java dan sekarang bertransformasi ke microservices. Contoh lain adalah eBay, dimana mereka beralih dari berbagai platform monolitik, yaitu Perl ke C++ kemudian Java dan terakhir adalah microservices.
Another example are Twitter and amazon
Seiring dengan manfaat agility dan flexibility yang dibawa oleh microservices, dimana misalkan kalau ada perubahan di satu microservices tidak perlu memodify dan mendeploy ulang seluruh aplikasi, microservices ternyata mempunyai challenge nya sendiri. Sebagian besar microservice mengimplementasikan semua functionality dari scratch di microservice level, termasuk networking functionality yang sebelum nya dilakukan di level middleware atau service bus.
Contohnya fungsi discovery, bagaimana microservices ini akan menemukan microservices yang lain. Kemudian fungsi fault tolerance misalkan, bagaimana suatu aplikasi tersebut bisa mendetect failure yang terjadi di satu microservices dan kemudian melakukan retry. Kemudian fungsi observasi, bagimana memonitor log dari berbagai microservices dan melakukan tracing terhadap serangkaian service call.
Most of the initial microservices implementations simply ignore the gravity of the network functions offered from a central ESB layer, and they implemented all such functionalities from scratch at each microservice level. Now they have started realizing the importance of having a similar shared functionality as a distributed mesh.
Pertanyaan nya adalah di mana kita akan mengimplementasikan networking fungsionality tersebut ? Apakah di coding di dalam setiap microservices nya sendiri ? Might not be a good idea, karena akan sangat challenging untuk mendevelop komunikasi antar microservice di dalam microservice nya sendiri, karena setiap microservices nya akan menjadi sangat kompleks. Even worse kalau setiap microservice didevelop dengan technology yang berbeda-beda jadi mesti diduplicate juga effort nya across Bahasa pemrograman yang berbeda beda. Dan di sisi lain karena ini sudah microservices kita juga sudah tidak relevan lagi untuk menggunakan kemampuan middleware dalam membuat composite service misalnya.
No longer be able to leverage ESB centralized inbuilt capabilities, for building virtual or composite services and functionalities such as circuit breakers, timeouts, and service discovery
Implementing inter-service network functions (i.e. apply resiliency and stability patterns, service discovery) at the microservices level is nightmare
Even worse if you use multiple technologies to build microservices, then you need to duplicate the same efforts across different languages
Since most of the inter-service communication requirements are considered generic across all microservices implementations, we can think about offloading such tasks to a different layer
Beberapa brand service mesh yang sering kita dengar di market misalkan Istio atau Linkerd menggunakan konsep sidecar dimana ada semacam proxy yang dideploy berpasangan dengan microservices nya. Fungsi fungsi yang biasanya ada di service mesh tersebut antara lain:
Discovery, bagaimana kita melakukan discovery service endpoint dari microservice yang lain
Observability, bagaimana kita melakukan monitoring, logging, dan tracing dari distributed microservices
Fault tolerance, termasuk di sini adalah bagaimana kita melakukan circuit breaking dan handling ketika terjadi fault, mekanisme retries dan timeouts, juga melakukan load balancing dan failover dari microservices sejenis
Routing, bagaimana kita melakukan basic routing antar microservices
Security, misalkan simple access control terhadap microservices, dan menjamin transport layer security
Terus apa solusinya ? Karena requirement inter-communication ini sebenarnya generic across microservices, solusinya adalah dengan mempunyai satu shared functionality, yang mungkin sering kita dengar sebagai Service Mesh. Service Mesh ini adalah distributed layer di antara microservices yang diharapkan bisa mengoffload kompleksitas dari microservices dan menghandle tugas-tugas komunikasi dan networking antar berbagai microservices seperti: service discovery, observability, fault tolerance, routing, security, dan functionality komunikasi dan networking yang lain.
Ok great, jadi setelah mempunyai service mesh layer apakah semua issue sudah tercover ? Yes sudah, di konteks networking functionalities, tapi di konteks aplikasi atau bisnis belum semua bisa tercover. Service mesh tidak cocok untuk memecahkan beberapa masalah misalnya, semua yang terkait business logic, enforcement yang tergantung pada policy di level aplikasi, integrasi multiple services sebagai API, dan lain sebagainya.
service mesh won’t solve any of the business logic related or service integration/composition related problems.
Sebagai komplemen dari Service Mesh, kita masih membutuhkan sebuah layer control plane yang configurable yang bisa memungkinkan beberapa microservices dan API bekerja sama sebagai sebuah aplikasi, yang bisa memberikan konteks business terhadap microservices tanpa harus banyak melakukan perubahan terhadap microservices itu sendiri
Control plane inilah yang kita namakan sebagai App Mesh. App Mesh menambahkan kemampuan di atas Service Mesh untuk
melakukan setup dan meng-enforce policy yang aware terhadap aplikasi
melakukan enablement terhadap beberapa service untuk diintegrasikan sebagai API
memberikan observability di level API dan level aplikasi
Secara arsitektur, app mesh bisa dideploy sebagai microgateway yang akan menjadi another sidecar terhadap si microservices selain service mesh sidecar yang dalam hal ini contoh nya misalkan adalah Envoy proxy dari Istio. Contohnya dalam hal ini definisi dari policy yang akan dienforce dilakukan di API gateway dan kemudian diprovision ke microgateway yang menjadi sidecar terhadap microservice yang terlibat policy. Dari API gateway juga bisa dimonitor performance dari semua microgateway yang dideploy ke microservices atau ke data plane
Secara arsitektur runtime nya, microgateway dari app mesh tidak akan mengubah atau megambil alih existing proxy dari service mesh misalnya Envoy dari Istio, melainkan bekerja sama dalam menambahkan context ke microservices runtime.
Teman-teman sekalian, setelah kita memahami perjalanan arsitektur dari (1) Monolithic ke (2) microservices, kemudian ke (3) Service Mesh, dan terakhir (4) App Mesh, apa yang bisa kita jadikan take away dari App mesh ini ?
Yang pertama, App mesh memberikan kita control untuk mengelompokkan microservices sebagai aplikasi bisnis dan mengenable nya sebagai API
Yang kedua, App mesh memberikan kemampuan untuk menambahkan konteks aplikasi terhadap microservices dan mengaturnya secara terpusat
Yang ketiga, App mesh memungkinkan kita memodify aplikasi kita melalui integrasi API, tanpa harus mengubah existing microservices.