Mengapa menggunakan pendekatan layanan mikro untuk membuat aplikasi
Bagi pengembang perangkat lunak, memfaktorkan aplikasi menjadi bagian komponen bukanlah hal baru. Biasanya, pendekatan bertingkat digunakan, dengan penyimpanan ujung belakang, logika bisnis tingkat menengah, dan antarmuka pengguna (UI) ujung depan. Apa yang telah berubah selama beberapa tahun terakhir adalah pengembang membuat aplikasi terdistribusi untuk cloud.
Berikut adalah beberapa perubahan keperluan bisnis:
- Layanan yang dibuat dan dioperasikan dalam skala besar untuk menjangkau pelanggan di wilayah geografis baru.
- Pengiriman fitur dan kemampuan yang lebih cepat untuk merespons permintaan pelanggan dengan cara yang gesit.
- Utilisasi sumber daya yang lebih baik untuk mengurangi biaya.
Keperluan bisnis ini memengaruhi cara kami membuat aplikasi.
Untuk informasi selengkapnya tentang pendekatan Azure untuk layanan mikro, lihat Layanan mikro: Revolusi aplikasi yang didukung oleh cloud.
Pendekatan desain monolitik vs. layanan mikro
Aplikasi berkembang seiring waktu. Aplikasi yang berhasil berkembang dengan menjadi berguna untuk orang-orang. Aplikasi yang tidak berhasil tidak berkembang dan akhirnya dihentikan. Inilah pertanyaannya: seberapa banyak Anda tahu tentang keperluan Anda hari ini dan apa yang akan mereka dapatkan di masa depan? Contohnya, Anda sedang membuat aplikasi pelaporan untuk departemen di perusahaan Anda. Anda yakin aplikasi hanya berlaku dalam lingkup perusahaan Anda dan laporan tidak akan disimpan lama. Pendekatan Anda akan berbeda dari itu, katakanlah, membuat layanan yang memberikan konten video ke puluhan juta pelanggan.
Terkadang, mengeluarkan sesuatu sebagai bukti konsep adalah faktor pendorong. Anda tahu aplikasi dapat didesain ulang nantinya. Tidak ada gunanya merekayasa berlebihan sesuatu yang tidak pernah digunakan. Di sisi lain, ketika perusahaan membuat cloud, harapannya adalah pertumbuhan dan penggunaan. Pertumbuhan dan skala tidak dapat diprediksi. Kami ingin membuat prototipe dengan cepat sembari juga mengetahui bahwa kami berada di jalur yang dapat menangani kesuksesan di masa depan. Ini adalah pendekatan startup yang dirampingkan: bangun, ukur, pelajari, dan iterasi.
Selama era klien/server, kami cenderung fokus pada membuat aplikasi bertingkat dengan menggunakan teknologi khusus di setiap tingkatan. Istilah aplikasi monolitik telah muncul untuk menjelaskan pendekatan ini. Antarmuka cenderung berada di antara tingkatan, dan desain yang digabungkan lebih erat digunakan antar komponen dalam setiap tingkatan. Pengembang mendesain dan memfaktorkan kelas yang dikompilasi ke dalam pustaka dan ditautkan bersama menjadi beberapa file dan DLL yang dapat dijalankan.
Terdapat keuntungan dari pendekatan desain monolitik. Aplikasi monolitik seringkali lebih sederhana untuk didesain, dan panggilan antar komponen lebih cepat karena panggilan ini sering melalui komunikasi antarproses (IPC). Selain itu, setiap orang menguji satu produk, yang cenderung menjadi penggunaan sumber daya manusia yang lebih efisien. Kelemahannya adalah ada penggabungan yang erat antar lapisan bertingkat, dan Anda tidak dapat menskalakan komponen individu. Jika Anda perlu melakukan perbaikan atau peningkatan, Anda harus menunggu orang lain menyelesaikan pengujian mereka. Lebih sulit menjadi gesit.
Layanan mikro mengatasi kelemahan ini dan lebih selaras dengan persyaratan bisnis sebelumnya. Tetapi layanan mikro juga memiliki keuntungan dan kewajiban. Keuntungan layanan mikro adalah setiap layanan biasanya merangkum fungsionalitas bisnis yang lebih sederhana, yang dapat Anda skalakan masuk atau keluar, uji, terapkan, dan kelola secara independen. Salah satu keuntungan penting dari layanan mikro adalah tim didorong oleh skenario bisnis daripada oleh teknologi. Tim yang lebih kecil mengembangkan layanan mikro berdasarkan skenario pelanggan dan menggunakan teknologi apa pun yang ingin mereka gunakan.
Dengan kata lain, organisasi tidak perlu menstandarkan teknologi untuk mempertahankan aplikasi layanan mikro. Tim individu yang memiliki layanan dapat melakukan apa yang masuk akal bagi mereka berdasarkan keahlian tim atau apa yang paling tepat untuk menyelesaikan masalah. Dalam praktiknya, kumpulan teknologi yang disarankan, seperti penyimpanan NoSQL atau framework aplikasi web tertentu, lebih disukai.
Kelemahan dari layanan mikro adalah Anda harus mengelola entitas yang lebih terpisah dan menangani penyebaran dan penerapan versi yang lebih kompleks. Lalu lintas jaringan antar layanan mikro meningkat, seperti halnya latensi jaringan yang sesuai. Banyak layanan yang ramai, dan terperinci dapat menyebabkan mimpi buruk kinerja. Tanpa alat untuk membantu Anda melihat dependensi ini, sulit untuk melihat keseluruhan sistem.
Standar membuat pendekatan layanan mikro berfungsi dengan menentukan cara mengkomunikasikan dan mentolerir hanya hal-hal yang Anda perlukan dari layanan, daripada kontrak yang kaku. Hal ini penting untuk menentukan kontrak ini diawal dalam desain karena layanan diperbarui secara independen satu sama lain. Deskripsi lain yang diciptakan untuk mendesain dengan pendekatan layanan mikro adalah "arsitektur berorientasi layanan yang terperinci (SOA)".
Sederhananya, pendekatan desain layanan mikro adalah tentang federasi layanan yang dipisahkan, dengan perubahan independen untuk masing-masing dan standar yang disepakati untuk komunikasi.
Dengan semakin banyaknya aplikasi cloud yang diproduksi, orang-orang telah menemukan bahwa dekomposisi dari keseluruhan aplikasi ini menjadi layanan independen yang berfokus pada skenario adalah pendekatan jangka panjang yang lebih baik.
Perbandingan antar pendekatan pengembangan aplikasi
Aplikasi monolitik berisi fungsionalitas khusus domain dan biasanya dibagi menjadi lapisan fungsional seperti web, bisnis, dan data.
Anda menskalakan aplikasi monolitik dengan mengkloningnya pada beberapa server/komputer virtual/kontainer.
Aplikasi layanan mikro memisahkah fungsionalitas menjadi layanan terpisah yang lebih kecil.
Pendekatan layanan mikro menskalakan dengan menerapkan setiap layanan secara independen, membuat instans dari layanan ini di seluruh server/komputer virtual/kontainer.
Mendesain dengan pendekatan layanan mikro tidak sesuai untuk semua proyek, tetapi lebih selaras dengan tujuan bisnis yang dijelaskan sebelumnya. Memulai dengan pendekatan monolitik mungkin masuk akal jika Anda tahu Anda akan memiliki kesempatan untuk mengerjakan ulang kode nantinya menjadi desain layanan mikro. Lebih umum, Anda mulai dengan aplikasi monolitik dan perlahan-lahan memecahnya secara bertahap, dimulai dengan area fungsional yang perlu lebih terskala atau gesit.
Ketika Anda menggunakan pendekatan layanan mikro, Anda menyusun aplikasi Anda dari banyak layanan kecil. Layanan ini berjalan dalam kontainer yang diterapkan ke seluruh klaster komputer. Tim yang lebih kecil mengembangkan layanan yang berfokus pada skenario dan secara independen menguji, membuat versi, menerapkan, dan menskalakan setiap layanan sehingga seluruh aplikasi dapat berkembang.
Apa itu layanan mikro?
Terdapat definisi yang berbeda dari layanan mikro. Tetapi sebagian besar karakteristik layanan mikro ini diterima secara luas:
- Merangkum skenario pelanggan atau bisnis. Masalah apa yang Anda pecahkan?
- Dikembangkan oleh tim teknik kecil.
- Ditulis dalam setiap bahasa pemrograman, menggunakan framework apa pun.
- Terdiri dari kode dan secara opsional menyatakan, yang keduanya secara independen diversi, diterapkan, dan diskalakan.
- Berinteraksi dengan layanan mikro lainnya melalui antarmuka dan protokol yang terdefinisi dengan baik.
- Memiliki nama unik (URL) yang digunakan untuk menentukan lokasinya.
- Tetap konsisten dan tersedia saat ada kegagalan.
Singkatnya:
Aplikasi layanan mikro terdiri dari layanan kecil, yang diversikan secara independen, dan dapat diskalakan dengan berfokus pada pelanggan yang berkomunikasi satu sama lain melalui protokol standar dengan antarmuka yang terdefinisi dengan baik.
Ditulis dalam setiap bahasa pemrograman, menggunakan kerangka kerja apa pun.
Sebagai pengembang, kami ingin bebas memilih bahasa atau kerangka kerja, tergantung pada keterampilan kami dan kebutuhan layanan yang kami buat. Untuk beberapa layanan, Anda mungkin menghargai keuntungan kinerja C++ di atas segalanya. Bagi yang lain, kemudahan pengembangan terkelola yang Anda dapatkan dari C# atau Java mungkin lebih penting. Dalam beberapa kasus, Anda mungkin perlu menggunakan pustaka mitra khusus, teknologi penyimpanan data, atau metode untuk mengekspos layanan kepada klien.
Setelah Anda memilih teknologi, Anda perlu mempertimbangkan manajemen operasional atau siklus hidup dan penskalaan layanan.
Mengizinkan kode dan status untuk secara independen diversikan, diterapkan, dan diskalakan
Tidak peduli bagaimana Anda menulis layanan mikro Anda, kode, dan secara opsional statusnya, harus secara independen menerapkan, meningkatkan, dan menskalakan. Masalah ini sulit dipecahkan karena bermuara pada pilihan teknologi Anda. Untuk penskalaan, memahami cara memartisi (atau shard) antara kode dan status, keduanya itu menantang. Saat kode dan status menggunakan teknologi yang berbeda, yang umum hari ini, skrip penyebaran untuk layanan micro Anda harus dapat menskalakan keduanya. Pemisahan ini juga tentang kelincahan dan fleksibelitas, jadi Anda dapat memperbarui beberapa layanan mikro tanpa harus memperbarui semuanya sekaligus.
Mari kita kembali ke perbandingan pendekatan layanan mikro dan monolitik sejenak. Diagram berikut menunjukkan perbedaan pendekatan untuk menyimpan status:
Penyimpanan status untuk dua pendekatan
Pendekatan monolitik, pada bagian kiri, memiliki database tunggal dan tingkat teknologi tertentu.
Pendekatan layanan mikro, pada bagian kanan ,memiliki grafik layanan mikro yang saling terhubung dimana keadaan biasanya tercakup dalam layanan mikro dan berbagai teknologi yang digunakan.
Pada pendekatan monolitik, aplikasi biasanta menggunakan database tunggal. Keuntungan penggunaan database tunggal adalah terdapat pada satu lokasi, yang membuatnya mudah disebarkan. Setiap komponen dapat memiliki tabel tunggal untuk menyimpan statusnya. Tim perlu memisahkan status secara ketat, yang mana itu sangat menantang. Pasti, seseorang akan tergoda untuk menambahkan kolom pada table pelanggan yang ada, gabungkan antar tabel, dan buatlah dependensi pada lapisan penyimpanan. Setelah hal ini terjadi, Anda tidak dapat menskalakan konponen individual.
Pada pendekatan layanan mikro, setiap layanan mengelola dan meyimpan statusnya sendiri. Setiap layanan bertanggung jawa untuk menskalakan kode dan status bersama untuk memenuhi tuntutan layanan. kelemahannya adalah saat Anda perlu membuat tampilan, kueri, pada data aplikasi, Anda perlu untuk mengkuerikan melewati beberapa penyimpanan status. Masalah ini biasanya dipecahkan dengan layanan mikro terpisah yang membuat tampilan melewati koleksi layanan mikro. Jika Anda perlu menjalankan beberapa kueri dadakan pada data, Anda harus mempertimbangkan menulis setiap data layanan mikro ke layanan warehouse untuk analisis offline.
Layanan mikro berversi Mungkin bagi berbagai versi layanan mikro untuk berjalan berdampingan. Versi layanan mikro yang lebih baru dapat gagal selama pembaruan dan perlu kembali ke versi sebelumnya. Penerapan versi juga berguna untuk pengujian A/B, yang mana pengguna berbeda merasakan versi layanan yang berbeda. Contoh, hal umum untuk memperbarui layanan mikro untuk rangkaian pelanggan tertentu untuk menguji fungsionalitas baru sebelum meluncurkannya lebih luas.
Berinteraksi dengan layanan mikro lain melalui interface dan protokol yang terdefinisi dengan baik.
Selama 10 tahun terakhir, informasi ekstensif telah di terbitkan menunjukkan pola komunikasi pada arsitektur berorientasi layanan. Umumya, layanan komunikasi menggunakan pendekatan REST dengan protokol HTTP dan TCP dan XML atau JSON sebagai format serialisasi. Dari prespective interface, ini tentang pendekatan desain web. Tapi tidak ada yang dapat memberhentikan Anda menggunakan protokol biner atau format data Anda sendiri. Ketahuilah bahwa orang akan kesulitan menggunakan layanan mikro Anda jika protokol dan format ini tidak tersedia secara terbuka.
(URL) memiliki nama yang unik yang digunakan untuk mengatasi lokasinya
Layanan mikro Anda perlu di tangani dimanapun ia berjalan. Jika Anda berpikir tentang mesin yang menjalankan layanan mikro tertentu, hal akan menjadi buruk dengan cepat.
Dengan cara yang sama DNS mengatasi URL tertentu terhadap mesin tersentu, layanan mikro Anda perlu nama unik sehingga lokasinya saat ini dapat ditemukan. Layanan mikro perlu nama yang dapat diatasi yang independen dari infrastruktur yang mereka jalankan. Ini menyiratkan hawa terdapat interaksi antara cara layanan Anda disebarkan dan di temukan, karena perlu ada layanan registri. Saat mesin gagal, layanan registri akan memberitahu Anda dimana layanan dipindahkan.
Tetap konsisten dan tersedia jika terjadi kegagalan.
Berurusan dengan kegagalan yang tidak diharapkan mmerupakan satu dari masalah yang sulit dipecahkan, khususnya dalam sistem terdistribusi. Sebagian besar kode yang kami tulis sbeagai pengembang adalah untuk menangani pengecualian. Selama pengujian, kami juga membutuhkan sebagian besar waktu pada penanganan pengecualian. Proses ini juga lebih terlibat dari pada menulis kode untuk menangani kegagalan. Apa yang terjadi ketika mesin dimana layanan mikro berjalan gagal? Anda perlu mendeteksi kegagalan, yang merupakan masakah sulit sendiri. Namun Anda juga perlu merestart layanan mikro Anda.
Untuk ketersediaan, layanan mikro harus tahan terhadap kegagalan dan dapat merestart pada mesin lain. Selain persyaratan ketahanan ini, data tidak boleh hilang, juga data harus konsisten.
Ketahanan memang sulit dicapai saat kegagalan terjadi selama pembaruan aplikasi. Layanan mikro bekerja dengan sistem penyebaran, tidak membutuhkan pemulihan. Perlu menentukan apakah itu dapat terus bergerak maju ke versi yang lebih baru atau kembali ke versi sebelumnya untuk untuk mempertahankan keadaan yang konsisten. Anda perlu mempertimbangkan beberapa pertanyaan, sepeti apakah cukup mesin yang tersedia untuk terus bergerak maju dan cara memulihkan versi sebelumnya pada layanan mikro. Untuk membuat keputusan ini, Anda perlu layanan mikro untuk mengeluarkan info kesehatan.
Diagnosa dan laporan kesehatan
Mungkin terlihat jelas, dan seringkali diabalikan, tapu layna mikro perlu melaporkan diagnosa dan laporan kesehatannya. Jika tidak, Anda memiliki kekurangan sedikit wawasan tentang kesehatannya dari prespektif operasi. Berkolerasi acara diagnostik melalui rangkaian layanan independen, dan berurusan dengan jam mesin condong untuk memahami urutan acara, itu menantang. Dengan cara yangs ama Anda berinteraksi dengan layanan mikro melalui protokol dan format data, Anda perlu menstandarkan cara mencatat peristiwa kesehatan dan diagnostik yang pada akhirnya akan berakhir di penyimpanan peristiwa untuk kueri dan tampilan. Dengan pendekatan layanan mikro, tim berbeda perlu menyepakati format pencatatan tunggal. Perlu ada pendekatan konsisten untuk melihat peristiwa dalam aplikasi secara keseluruhan.
Kesehatan berbeda dengan kesehatan. Kesehatan tentang laporan layanan mikro skeadaannya saat ini untuk mengambil tindakan yang tepat. Contoh yang baik bekerja dengan mekanisme pembaruan dan penyebaran untuk menjaga ketersediaan. Meskipun layanan saat ini mungkin tidak sehat karena proses crash atau reboot mesin, layanan ini masih mungkin beroperasi. Hal terakhir yang Anda butuhkan adalah membuat situasi lebih buruk dengan memulai peningkatan. Pendekatan terbaik adalah menyelidiki terlebih dahulu atau memberikan waktu layanan mikro untuk pulih. Acara kesehatan dari layanan mikro membantu kami membuat keputusan berdasarkan informasi, dan efeknya, membantu menciptakan layanan penyembuhan sendiri.
Panduan untuk mendesain layanan mikro di Azure
Kunjungi pusat arsitektur Azure untuk panduan di mendesain dan membuat layanan mikro di Azure.
Service Fabric sebagai paltform layanan mikro
Azure Service Fabric muncul saat Microsoft beralih dari pengiriman kotak produk, yang biasanya monolitik, ke layanan pengiriman. pengalaman membangun dan mengoperasikan layanan besar, seperti Azure SQL Database dan Azure Cosmos DB, berbentuk Service Fabric. Platform ini berebolusi dari waktu ke waktu karena lebih banyak layanan yang mngadopsinya. Service Fabric harus menjalankan tidak hanya di Azure tapi juga di penyebaran Windows Server mandiri.
Tujuan Service Fabric adalah mengatasi masalah sulit tentang pembuatan dan penjalanan layanan dan untuk menggunakan sumber daya infrastruktur secara efisien, sehingga tim dapat mengatasi masalah bisni dengan menggunakan pendekatan layanan mikro .
Service afbric membantu Anda membuat aplikasi yang menggunakan pendekatan layanan mikro dengan menyediakan:
- Platform yang menyediakan layanan system untuk menyebarkan, meningkatkan, mendeteksi, merestart ayanan yang gagal, menemukan layanan, merutekan pesan, mengelola status, dan memantau kesehatan.
- Kemampuan menyebarkan aplikasi baik berjalan di kontainer atau sebagai proses. Service Afbric adalah orkestrator proses dan kontainer.
- API pemrograman produktif membantu Anda membangun aplikasi sebagai layanan mikro: ASP.NET Core, Reliable Actors, and Reliable Services. Contohnya, Anda dapat mendapatkan informasi kesehatan dan diagnosanya, atau Anda juga dapat memanfaatkan ketersediaan tinggi bawaan.
Service Fabric adalah agnostik tentang cara Anda membuat layanan dan Anda dapat menggunakan teknologi apapun. Tapi ia menyediakan API pemrograman yang membuatnya lebih mudah dalam membuat layanan mikro.
Migrasi aplikasi yang ada ke Service Fabric
Service Fabric memungkinkan Anda untuk Menggunakan ulanh kode yang ada dan memoderenisasinya dengan layanan mikro baru. Teradapat lima tahap untuk moderenisasi aplikasi, Anda dapat merestart dan berhenti di tahap manapun. Tahapannya adalah:
- Mulailah dengan aplikasi monolitik tradisional.
- Migrasi. Gunakan kontainer atau tamu yang dapat dieksekusi untuk menghosting kode yang ada pada Service Fabric.
- Memoderenisasi Tambahkan layanan mikro baru bersama kode kontainer yanga ada.
- Berinovasilah Pecahkan aplikasi monolitik ke layanan mikro berdasarkan kebutuhan.
- Ubah aplikasi menjadi layanan mikro. Ubah aplikasi monolitik yang ada atau buatlah aplikasi greenfield baru.
Ingat, Anda Memulai dan berhenti ditahap manapun. Anda tidak perlu melanjutkan ke tahap selanjutnya.
Mari lihat contoh dari setiap tahapan berikut:
Migrate
Untuk dua alasan, banyak perusahaan yang bermigrasi dari aplikasi monolitik yang ada ke kontainer.
- Pengurangan biaya, baik karena konsolidasi dan penghapusan peragkat keras yang ada atau karena menjalankan aplikasi pada kepadatan yang lebih tinggi.
- Kontrak penyebaran konsisten antara pengembangan dan operasi.
Penurunan biaya itu mudah. Pada Microsoft, banyak aplikasi yang ada yang sedang di kontainer, mengarah ke jutaan dolar dalam tabungan. Penyebaran konsisten lebih susah dievaluasi tapi sama pentingnya. Itu berarti bahwa pengembang dapat memilih teknologi yang sesuai dengan mereka, tapi operasi akan menerima hanya pada metode tunggal untuk penyebaran dan pengelolaan aplikasi. Ini dapat mengurangi operasi akrena harus berurusan dengan kompleksitas pendukungan teknologi yang berbeda tanpa memaksa pengembang untuk memilih hanya pada tertentu. Pada dasarnya, setiap aplikasi di kontainer ke dalam gambar penyebaran sendiri.
Banyak organisasi yang ebrhenti disini. Mereka telah mendapatkan keuntungan dari kontainer, dan Service Fabric menyediakan pengalaman manajemen yang lengkap, termasuk penyebaran, peningkatan, penerapan versi, pembatalan, dan pantauan kesehatan.
Moderenisasi
Moderenisasi adalah layanan tambahan baru bersama kontainer yang ada. Jika Anda akan menulis kode baru, sangat baik untuk mengambil langkah kecil menyusuri alur layanan mikro. Hal ini berarti menambahkan titik akhir API REST baru atau logika bisnis baru. Dengan cara ini, Anda memulai proses pembuatan layanan mikro baru dan berlatih mengembangkan dan menyebarkannya.
Inovasi
Pendekatan layanan mikro mengakomodasi perubahan kebutuhan bisnis. Pada tahap ini, Anda perlu menentukan apakah memulai membagi aplikasi monolitik ke layanan atau berinovasi. Contoh klasik disini adakalah saat database yang Anda gunakan sebagai antrean alur kerja menjadi hambatan pemrosesan. Seiring jumlah permintaan alur kerja meningkat, pekerjaan tersebut perlu didistribusikan untuk skala. ambil bagian tertentu dari aplikasi yang tidak diskalakan, atau yang perlu diperbarui lebih sering, dan pisahkan sebagai layanan mikro dan inovasi.
Mengubah aplikasi ke layanan mikro
Pada tahap ini, aplikasi Anda terdiri sepenuhnya (atau terbagi ke) layanan mikro. Unutk mencapain titik ini, Anda telah membuat perjalanan layanan mikro. Anda dapat memulainya disini, tapi lakukan juga tanpa platform layanan mikro untuk membantu anda membutuhkan investasi yang signifikan.
Apakah laynaan mikro tepat untuk aplikasi saya?
Mungkin. Pada Microsoft, lebih banyak tim yang mulai membuat cloud untuk alasan bisnis, banyak dari mereka yang menyadari manfaat penggunaan pendekatan layanan mikro ini. Bing, contohnya, telah menggunakan layanan mikro selama bertahun-tahun. Untuk tim lain, pendekatan layanan mikro merupakan hal baru. Tim menemukan bahwa terdapat masalah yang sulit untuk dipecahkan diluar inti kekuatan mereka. Hal ini sebabnya Service Fabric mendapatkan daya tarik sebagai teknologi untuk membuat layanan.
Objektif dari Service Fabric adalah untuk mengurangi kompleksitas pembuatan aplikasi layanan mikro sehingga Anda tidak harus melakukan desain ulang yang mahal. Mulailah layanan kecil, diskalakan jika dibutuhkan, penghentian layanan, tambahkan layanan baru, dan berevolusi dengan penggunaan pelanggan. Kita juga tahu bahwa terdapat banyak masalah lain yang belum dipecahkan untuk membuat layanan mikro lebih mudah didekati bagi sebagian besar pengembang. Kontainer dan model pemrograman aktor merupakan contoh dari kangkah kecil ke arah itu. Kita yakin lebih banyak inovasi akan muncul untuk membuat pendekatan layanan mikro lebih mudah.