Apa yang dimaksud dengan layanan mikro?

Layanan mikro, atau arsitektur layanan mikro, adalah pendekatan arsitektur cloud native dengan satu aplikasi yang terdiri dari banyak komponen atau layanan yang lebih kecil dan digabungkan secara fleksibel serta dapat diterapkan secara independen.

Layanan mikro biasanya:

• Memiliki tumpukan teknologi mereka sendiri, termasuk database dan model manajemen data.
  
• Berkomunikasi satu sama lain melalui kombinasi API representational state transfer (REST), streaming peristiwa, dan perantara pesan.
  
• Disusun berdasarkan kemampuan bisnis, dengan garis pemisah layanan yang sering disebut sebagai konteks terbatas.

Meskipun sebagian besar diskusi tentang layanan mikro berkisar pada definisi dan karakteristik arsitektural, nilainya dapat lebih mudah dipahami melalui manfaat bisnis dan organisasi yang cukup sederhana:

• Kode dapat diperbarui dengan lebih mudah—fitur atau fungsionalitas baru dapat ditambahkan tanpa menyentuh seluruh aplikasi.
  
• Tim dapat menggunakan tumpukan yang berbeda dan bahasa pemrograman yang berbeda untuk komponen yang berbeda.
  
• Komponen dapat diskalakan secara independen dari satu sama lain, sehingga mengurangi pemborosan dan biaya yang terkait dengan keharusan menskalakan seluruh aplikasi karena satu fitur mungkin menghadapi terlalu banyak beban.

Layanan mikro juga dapat dipahami berbeda dengan dua arsitektur aplikasi sebelumnya: arsitektur monolitik dan arsitektur berorientasi layanan (SOA).

Perbedaan antara layanan mikro dan arsitektur monolitik adalah bahwa layanan mikro menyusun satu aplikasi dari banyak layanan yang lebih kecil dan digabungkan secara fleksibel dibandingkan dengan pendekatan monolitik dari aplikasi besar yang digabungkan secara ketat.

Perbedaan antara layanan mikro dan SOA bisa sedikit kurang jelas. Sementara perbedaan teknis dapat ditarik antara layanan mikro dan SOA, terutama di sekitar peran bus layanan perusahaan, lebih mudah untuk mempertimbangkan perbedaan sebagai salah satu ruang lingkup. SOA adalah upaya seluruh perusahaan untuk menstandarkan cara semua layanan web dalam sebuah organisasi untuk berbicara dan berintegrasi satu sama lain, sedangkan arsitektur layanan mikro bersifat spesifik untuk aplikasi.

Layanan mikro cenderung setidaknya sama populernya dengan eksekutif dan pemimpin proyek seperti halnya pengembang. Ini adalah salah satu karakteristik layanan mikro yang tidak biasa karena antusiasme arsitektur biasanya diperuntukkan bagi tim pengembangan perangkat lunak. Alasannya adalah karena layanan mikro lebih mencerminkan cara yang diinginkan oleh banyak pemimpin bisnis dalam menyusun dan menjalankan tim dan proses pengembangan mereka.

Dengan kata lain, layanan mikro adalah model arsitektur yang memfasilitasi model operasional yang diinginkan dengan lebih baik. Dalam survei IBM tahun 2021 terhadap lebih dari 1.200 pengembang dan eksekutif TI, 87% pengguna layanan mikro setuju bahwa adopsi layanan mikro sepadan dengan biaya dan usaha.

Berikut adalah beberapa manfaat perusahaan dari layanan mikro:

Mungkin satu-satunya karakteristik yang paling penting dari layanan mikro adalah karena layanan ini lebih kecil dan dapat digunakan secara independen. Ini tidak lagi memerlukan tindakan sangat sulit untuk mengubah baris kode atau menambahkan fitur baru dalam aplikasi.

Layanan mikro menjanjikan organisasi suatu penawar terhadap rasa frustrasi mendalam yang terkait dengan perubahan kecil yang memerlukan waktu dalam jumlah besar. Tidak diperlukan gelar Ph.D. dalam ilmu komputer untuk melihat atau memahami nilai dari pendekatan yang lebih memfasilitasi kecepatan dan ketangkasan.

Namun kecepatan bukanlah satu-satunya manfaat dari merancang layanan dengan cara ini. Model organisasi yang kini sedang tren adalah menyatukan tim lintas fungsi berdasarkan masalah bisnis, layanan, atau produk. Model layanan mikro sangat cocok dengan tren ini. Model ini memungkinkan organisasi untuk membuat tim kecil lintas fungsi di sekitar satu layanan atau kumpulan layanan dan membuat mereka beroperasi dengan cara yang tangkas.

Penggabungan layanan mikro yang fleksibel juga membangun tingkat isolasi kesalahan dan ketahanan yang lebih baik ke dalam aplikasi. Dan ukuran layanan yang kecil, dikombinasikan dengan batasan dan pola komunikasi yang jelas, memudahkan anggota tim baru untuk memahami basis kode dan berkontribusi dengan cepat, sebuah manfaat yang jelas dalam hal kecepatan dan moral karyawan.

Dalam pola arsitektur n-tier tradisional, aplikasi biasanya berbagi tumpukan teknologi umum, dengan database relasional besar yang mendukung seluruh aplikasi. Pendekatan ini memiliki beberapa kelemahan yang jelas—yang paling signifikan adalah bahwa setiap komponen aplikasi harus berbagi tumpukan teknologi, model data, dan database yang sama meskipun ada alat yang jelas dan lebih baik untuk pekerjaan untuk elemen-elemen tertentu. Hal ini menghasilkan arsitektur yang buruk, dan membuat frustrasi para pengembang yang selalu menyadari bahwa cara yang lebih baik dan lebih efisien untuk membangun komponen-komponen ini telah tersedia.

Sebaliknya, dalam model layanan mikro, komponen diterapkan secara independen dan berkomunikasi melalui beberapa kombinasi REST, streaming peristiwa, dan perantara pesan, sehingga memungkinkan tumpukan setiap layanan dioptimalkan untuk layanan tersebut. Teknologi berubah setiap saat, dan aplikasi yang terdiri dari beberapa layanan yang lebih kecil akan lebih mudah dan lebih murah untuk berkembang dengan teknologi yang lebih diinginkan saat tersedia.

Dengan layanan mikro, layanan individual dapat diterapkan secara individual — tetapi mereka juga dapat diskalakan secara individual. Manfaat yang dihasilkan sangat jelas: jika dilakukan dengan benar, layanan mikro membutuhkan infrastruktur yang lebih sedikit daripada aplikasi monolitik karena memungkinkan penskalaan yang tepat hanya untuk komponen yang memerlukannya, bukan seluruh aplikasi dalam kasus aplikasi monolitik.

Manfaat signifikan dari layanan mikro juga disertai dengan tantangan yang signifikan. Beralih dari monolith ke layanan mikro berarti lebih banyak kompleksitas manajemen - lebih banyak layanan, yang dibuat oleh lebih banyak tim, yang diterapkan di lebih banyak tempat. Masalah dalam satu layanan dapat menyebabkan, atau disebabkan oleh, masalah pada layanan lain. Pencatatan data (digunakan untuk pemantauan dan penyelesaian masalah) lebih banyak, dan bisa jadi tidak konsisten di seluruh layanan. Versi baru dapat menyebabkan kompatibilitas dengan masalah versi sebelumnya. Aplikasi melibatkan lebih banyak koneksi jaringan, yang berarti lebih banyak peluang untuk masalah latensi dan konektivitas. Pendekatan DevOps dapat mengatasi banyak masalah ini, tetapi adopsi DevOps juga memiliki tantangannya sendiri.

Namun demikian, tantangan ini tidak menghentikan bukan pengadopsi untuk mengadopsi layanan mikro, atau pengadopsi untuk memperdalam komitmen layanan mikro mereka. Data survei IBM yang disebutkan di atas mengungkapkan bahwa 56% bukan pengguna saat ini kemungkinan atau sangat mungkin untuk mengadopsi layanan mikro dalam dua tahun ke depan. Akibatnya, 78% pengguna layanan mikro saat ini kemungkinan akan meningkatkan waktu, uang, dan usaha yang mereka investasikan dalam layanan mikro.

Arsitektur layanan mikro sering digambarkan sebagai dioptimalkan untuk DevOps dan integrasi berkelanjutan atau penyediaan berkelanjutan. Dalam konteks layanan kecil yang dapat sering digunakan, alasannya mudah dipahami.

Tetapi cara lain untuk melihat hubungan antara layanan mikro dan DevOps adalah bahwa arsitektur layanan mikro membutuhkan DevOps agar berhasil. Meskipun aplikasi monolitik memiliki berbagai kekurangan yang telah dibahas sebelumnya dalam artikel ini, aplikasi ini memiliki keuntungan karena tidak menjadi sistem terdistribusi yang kompleks dengan banyak bagian yang bergerak dan tumpukan teknologi yang independen. Sebaliknya, mengingat peningkatan besar dalam kompleksitas, bagian yang bergerak, dan ketergantungan yang menyertai layanan mikro, tidak bijaksana untuk melakukan pendekatan terhadap layanan mikro tanpa investasi yang signifikan dalam penerapan, pemantauan, dan otomatisasi siklus hidup.

Rosalind Radcliffe memberikan penjelasan lebih mendalam tentang DevOps dalam video:

Meskipun hampir semua alat atau bahasa modern dapat digunakan dalam arsitektur layanan mikro, ada beberapa alat inti yang telah menjadi sangat penting dan menjadi batas definitif untuk layanan mikro:

Salah satu elemen kunci dari layanan mikro adalah ukurannya kecil. Tidak ada jumlah kode yang menentukan apakah sesuatu itu layanan mikro atau bukan, tetapi "mikro" ada di namanya.

Ketika Docker menghadirkan era kontainer modern pada tahun 2013, platform ini juga memperkenalkan model komputasi yang akan menjadi paling erat terkait dengan layanan mikro. Karena kontainer individu tidak memiliki overhead sistem operasi mereka sendiri, kontainer ini lebih kecil dan lebih ringan daripada mesin virtual tradisional dan dapat meningkatkan dan menurunkan skala lebih cepat, menjadikannya pasangan yang sempurna untuk layanan dengan bobot yang lebih kecil dan lebih ringan yang ditemukan dalam arsitektur layanan mikro.

Dengan menjamurnya layanan dan kontainer, mengatur dan mengelola kelompok besar kontainer dengan cepat menjadi salah satu tantangan penting. Kubernetes, platform orkestrasi kontainer sumber terbuka, telah muncul sebagai salah satu solusi orkestrasi paling populer karena ia melakukan pekerjaan itu dengan sangat baik.

Layanan mikro sering kali berkomunikasi melalui API, terutama saat pertama kali menetapkan statusnya. Meskipun benar bahwa klien dan layanan dapat berkomunikasi satu sama lain secara langsung, API gateway sering kali merupakan lapisan perantara yang berguna, terutama karena jumlah layanan dalam suatu aplikasi bertambah seiring waktu. API Gateway berfungsi sebagai proxy terbalik bagi klien dengan merutekan permintaan, menyebarkan permintaan ke beberapa layanan, dan menyediakan keamanan serta autentikasi tambahan.

Ada beberapa teknologi yang dapat digunakan untuk mengimplementasikan API Gateway. Di antara teknologi ini adalah platform API management, tetapi jika arsitektur layanan mikro diimplementasikan menggunakan kontainer dan Kubernetes, gateway biasanya diimplementasikan menggunakan Ingress atau, baru-baru ini, Istio.

Meskipun praktik terbaiknya adalah merancang layanan tanpa status, status tetap ada dan layanan harus menyadarinya. Dan meskipun panggilan API sering kali merupakan cara yang efektif untuk menetapkan status awal untuk layanan tertentu, ini bukanlah cara yang efektif untuk tetap mendapatkan informasi terbaru. Sebuah jajak pendapat konstan, pendekatan “apakah kita sudah sampai?” untuk menjaga layanan tetap terkini tidak praktis.

Sebagai gantinya, perlu untuk memasangkan panggilan API yang menetapkan status dengan pengiriman pesan atau streaming peristiwa sehingga layanan dapat menyiarkan perubahan status. Dengan cara ini, pihak lain yang berkepentingan dapat mendengarkan perubahan tersebut dan menyesuaikannya. Pekerjaan ini kemungkinan paling cocok untuk perantara pesan tujuan umum, tetapi ada kasus di mana platform streaming peristiwa, seperti Apache Kafka, mungkin cocok. Dan dengan menggabungkan layanan mikro dengan arsitektur berbasis peristiwa, pengembang dapat membangun sistem terdistribusi, sangat dapat diskalakan, toleran kesalahan, dan dapat diperluas yang dapat mengkonsumsi dan memproses sejumlah besar peristiwa atau informasi secara real-time.

Arsitektur nirserver membawa beberapa pola inti cloud dan layanan mikro ke kesimpulan logisnya. Dalam kasus nirserver, unit eksekusi bukan hanya sebuah layanan kecil, tetapi sebuah fungsi yang sering kali hanya berupa beberapa baris kode. Garis yang memisahkan fungsi nirserver dari layanan mikro adalah garis yang kabur, tetapi fungsi umumnya dipahami lebih kecil daripada layanan mikro.

Ketika arsitektur nirserver dan platform function-as-a-service  memiliki afinitas yang sama dengan layanan mikro, keduanya cenderung membuat unit penerapan yang lebih kecil dan melakukan penskalaan secara tepat sesuai permintaan.

Layanan mikro tidak selalu hanya relevan dengan komputasi cloud. Namun, ada beberapa alasan penting mengapa keduanya begitu sering digunakan bersamaan, alasan yang lebih dari sekadar layanan mikro yang menjadi gaya arsitektur populer untuk aplikasi baru dan cloud yang menjadi tujuan hosting populer untuk aplikasi baru.

Beberapa manfaat utama arsitektur layanan mikro adalah manfaat penggunaan dan biaya yang terkait dengan menerapkan dan menskalakan komponen secara individual. Meskipun manfaat ini sampai batas tertentu akan terdapat pada infrastruktur on premises, kombinasi komponen kecil yang dapat diskalakan secara independen serta infrastruktur pay-per-use sesuai permintaan adalah tempat pengoptimalan biaya yang sebenarnya dapat ditemukan.

Kedua, dan mungkin yang lebih penting, manfaat utama lainnya dari layanan mikro adalah bahwa setiap komponen individu dapat mengadopsi tumpukan yang paling sesuai dengan pekerjaan spesifiknya. Tumpukan yang tumbuh pesat dapat menyebabkan kompleksitas dan overhead yang serius ketika Anda mengelolanya sendiri, tetapi menggunakan tumpukan pendukung sebagai layanan cloud dapat meminimalkan tantangan manajemen dengan signifikan. Dengan kata lain, meskipun bukan tidak mungkin untuk meluncurkan infrastruktur layanan mikro Anda sendiri, itu tidak disarankan, terutama ketika baru memulai.

Dalam arsitektur layanan mikro, ada banyak pola desain, komunikasi, dan integrasi yang umum dan berguna yang membantu mengatasi beberapa tantangan dan peluang yang lebih umum, termasuk:

Pola ini menyisipkan lapisan antara pengalaman pengguna dan sumber daya yang dibutuhkan oleh pengalaman tersebut. Misalnya, aplikasi yang digunakan di desktop akan memiliki ukuran layar, tampilan, dan batas kinerja yang berbeda dari perangkat mobile. Pola BFF memungkinkan pengembang untuk membuat dan mendukung satu jenis backend per antarmuka pengguna menggunakan opsi terbaik untuk antarmuka tersebut, daripada mencoba mendukung backend generik yang berfungsi dengan antarmuka apa pun tetapi dapat berdampak negatif pada kinerja frontend.

Entitas adalah objek yang dibedakan oleh identitasnya. Misalnya, di situs e-commerce, objek produk dapat dibedakan berdasarkan nama produk, jenis, dan harga. Agregat adalah kumpulan entitas terkait yang harus diperlakukan sebagai satu unit. Jadi, untuk situs e-commerce, pesanan akan menjadi koleksi (agregat) produk (entitas) yang dipesan oleh pembeli. Pola ini digunakan untuk mengklasifikasikan data dengan cara yang berarti.

Pola ini membantu aplikasi dan layanan menemukan satu sama lain. Dalam arsitektur layanan mikro, instance layanan berubah secara dinamis karena penskalaan, peningkatan, kegagalan layanan, dan bahkan penghentian layanan. Pola ini menyediakan mekanisme penemuan untuk mengatasi perubahan sementara ini. Penyeimbangan beban dapat menggunakan pola penemuan layanan menggunakan pemeriksaan kesehatan dan kegagalan layanan sebagai pemicu untuk menyeimbangkan kembali lalu lintas.

Pikirkan pola adaptor dengan cara Anda memikirkan adaptor steker yang Anda gunakan saat bepergian ke negara lain. Tujuan dari pola adaptor adalah untuk membantu menerjemahkan hubungan antar kelas atau objek yang tidak kompatibel. Aplikasi yang bergantung pada API pihak ketiga mungkin perlu menggunakan pola adaptor untuk memastikan aplikasi dan API dapat berkomunikasi.

Pola-pola ini membantu mengelola refactoring aplikasi monolitik menjadi aplikasi layanan mikro. Nama yang penuh warna ini mengacu pada bagaimana tanaman merambat (layanan mikro) secara perlahan dan seiring waktu menyalip dan mencekik pohon (aplikasi monolitik).

Meskipun ada banyak pola untuk melakukan layanan mikro dengan baik, ada sejumlah pola yang sama pentingnya yang dapat dengan cepat membuat tim pengembangan mengalami masalah. Beberapa di antaranya — disebut sebagai 'jangan' layanan mikro — adalah sebagai berikut:

Lebih tepatnya, jangan memulai dengan layanan mikro. Layanan mikro adalah cara untuk mengelola kompleksitas setelah aplikasi menjadi terlalu besar dan berat untuk diperbarui dan dipelihara dengan mudah. Namun ketika Anda merasa masalah dan kompleksitas dalam arsitektur monolitik mulai muncul, ada baiknya Anda mulai mempertimbangkan cara untuk memfaktorkan ulang aplikasi menjadi layanan yang lebih kecil. Jika belum muncul masalah, berarti arsitektur monolitik Anda belum memerlukan pemfaktoran ulang.

Membangun layanan mikro berarti membangun sistem terdistribusi, dan sistem terdistribusi itu sulit, dan akan lebih sulit lagi jika Anda membuat pilihan yang membuatnya semakin sulit. Mencoba melakukan layanan mikro tanpa otomatisasi penerapan dan pemantauan yang tepat, atau layanan cloud terkelola untuk mendukung infrastruktur Anda yang sekarang luas dan heterogen, akan menimbulkan banyak masalah yang tidak perlu. Hindari masalah ini sehingga Anda dapat menghabiskan waktu untuk mengkhawatirkan keadaan.

Jika Anda menerapkan layanan mikro secara berlebihan, Anda akan menghadapi biaya overhead dan kompleksitas yang lebih besar daripada keuntungan keseluruhan dari arsitektur layanan mikro. Lebih baik condong ke layanan yang lebih besar, kemudian memecahnya ketika mulai muncul masalah dengan karakteristik yang dapat diatasi oleh layanan mikro—yaitu bahwa penerapan perubahan menjadi sulit dan lambat, model data umum menjadi terlalu rumit, atau bahwa bagian yang berbeda dari layanan memiliki persyaratan beban/skala yang berbeda.

Layanan mikro dan SOA sering dicampuradukkan satu sama lain, mengingat bahwa pada tingkat yang paling dasar, keduanya tertarik untuk membangun komponen individual yang dapat digunakan kembali yang dapat dikonsumsi oleh aplikasi lain. Perbedaan antara layanan mikro dan SOA adalah bahwa proyek layanan mikro biasanya melibatkan refactoring aplikasi sehingga lebih mudah dikelola, sedangkan SOA berkaitan dengan perubahan cara kerja layanan IT di seluruh perusahaan. Proyek layanan mikro yang berubah menjadi proyek SOA kemungkinan akan melengkung karena bobotnya sendiri.

Netflix adalah salah satu pelopor awal arsitektur layanan mikro ketika membangun dan mengelola aplikasi yang menyumbang sepertiga dari semua lalu lintas internet. Semacam badai sempurna yang mengharuskan mereka membangun banyak kode dan layanan khusus yang tidak diperlukan untuk aplikasi pada umumnya. Anda jauh lebih baik memulai dengan kecepatan yang dapat Anda tangani, menghindari kerumitan, dan menggunakan sebanyak mungkin alat siap pakai yang tersedia.

Jika Anda siap mempelajari lebih lanjut tentang cara menggunakan layanan mikro, atau jika Anda perlu mengembangkan skill layanan mikro, cobalah salah satu dari tutorial berikut ini:

• Pengantar layanan mikro
  
• Lab cepat: Buat layanan mikro aplikasi web yang sangat dapat diskalakan dengan Node.js
• Mulai penggunaan layanan mikro Java menggunakan Spring Boot dan Cloudant
  
• Buat, jalankan, dan terapkan layanan mikro Spring dalam lima menit
• Layanan mikro, SOA, dan API: Teman atau musuh?