Penilaian dan kesiapan layanan mikro
Arsitektur layanan mikro dapat memberikan banyak manfaat untuk aplikasi Anda, termasuk kelincahan, skalabilitas, dan ketersediaan tinggi. Seiring dengan manfaat ini, arsitektur ini menghadirkan tantangan. Saat Anda membangun aplikasi berbasis layanan mikro atau mengubah aplikasi yang ada menjadi arsitektur layanan mikro, Anda perlu menganalisis dan menilai situasi Anda saat ini untuk mengidentifikasi area yang perlu ditingkatkan.
Panduan ini akan membantu Anda memahami beberapa pertimbangan yang perlu diingat ketika Anda pindah ke arsitektur layanan mikro. Anda dapat menggunakan panduan ini untuk menilai kematangan aplikasi, infrastruktur, DevOps, model pengembangan, dan banyak lagi.
Untuk mulai mengevaluasi arsitektur layanan mikro, Anda harus terlebih dahulu memahami prioritas inti bisnis Anda. Prioritas inti mungkin terkait dengan kelincahan, perubahan adopsi, atau pengembangan yang cepat, misalnya. Anda perlu menganalisis apakah arsitektur Anda cocok untuk prioritas inti Anda. Perlu diingat bahwa prioritas bisnis dapat berubah dari waktu ke waktu. Misalnya, inovasi adalah prioritas utama untuk startup, tetapi setelah beberapa tahun, prioritas inti mungkin keandalan dan efisiensi.
Berikut adalah beberapa prioritas yang perlu dipertimbangkan:
- Inovasi
- Keandalan
- Efisiensi
Dokumentasikan SLA yang selaras dengan berbagai bagian aplikasi Anda untuk memastikan komitmen organisasi yang dapat berfungsi sebagai panduan penilaian Anda.
Arsitektur layanan mikro membantu tim menjadi otonom. Tim dapat membuat keputusan mereka sendiri tentang teknologi, metodologi, dan komponen infrastruktur, misalnya. Namun, pilihan-pilihan ini harus menghormati prinsip-prinsip yang disepakati secara resmi yang dikenal sebagai tata kelola bersama, yang menyatakan perjanjian di antara tim tentang cara mengatasi strategi yang lebih luas untuk layanan mikro.
Pertimbangkan faktor-faktor ini:
- Apakah tata kelola bersama di tempat?
- Apakah Anda melacak keputusan dan trade-off mereka dalam jurnal arsitektur?
- Dapatkah tim Anda dengan mudah mengakses jurnal arsitektur Anda?
- Apakah Anda memiliki proses untuk mengevaluasi alat, teknologi, dan kerangka kerja?
Anda harus memiliki struktur tim yang tepat untuk menghindari komunikasi yang tidak perlu di seluruh tim. Arsitektur layanan mikro mendorong pembentukan tim kecil, fokus, lintas fungsi dan membutuhkan perubahan pola pikir, yang harus didahului oleh restrukturisasi tim.
Pertimbangkan faktor-faktor ini:
- Apakah tim Anda dibagi berdasarkan subdomain, mengikuti prinsip desain berbasis domain (DDD)?
- Apakah tim Anda berfungsi silang, dengan kapasitas yang cukup untuk membangun dan mengoperasikan layanan mikro terkait secara independen?
- Berapa banyak waktu yang dihabiskan dalam aktivitas dan tugas ad hoc yang tidak terkait dengan proyek?
- Berapa banyak waktu yang dihabiskan dalam kolaborasi lintas tim?
- Apakah Anda memiliki proses untuk mengidentifikasi dan meminimalkan utang teknis?
- Bagaimana pelajaran dipelajari dan pengalaman dikomunikasikan di seluruh tim?
Tujuan mendasar memilih arsitektur layanan mikro adalah untuk memberikan nilai lebih cepat dan adaptif terhadap perubahan dengan mengikuti praktik yang tangkas. Metodologi aplikasi Twelve-Factor menyediakan panduan untuk membangun aplikasi yang dapat dipertahankan dan dapat diskalakan. Panduan ini mempromosikan atribut seperti kekekalan, ephemeralitas, konfigurasi deklaratif, dan otomatisasi. Dengan menggabungkan panduan ini dan menghindari jebakan umum, Anda dapat membuat layanan mikro yang digabungkan secara longgar dan mandiri.
Mengubah aplikasi monolitik menjadi arsitektur layanan mikro membutuhkan waktu. Mulailah dengan layanan tepi. Layanan Edge memiliki lebih sedikit dependensi pada layanan lain dan dapat dengan mudah diurai dari sistem sebagai layanan independen. Kami sangat merekomendasikan pola seperti Strangler Fig dan Anti-corruption Layer untuk menjaga aplikasi monolitik dalam keadaan kerja sampai semua layanan terurai menjadi layanan mikro terpisah. Selama pemisahan, prinsip-prinsip DDD dapat membantu tim memilih komponen atau layanan dari aplikasi monolitik berdasarkan subdomain.
Misalnya, dalam sistem e-niaga, Anda mungkin memiliki modul ini: kelopak, manajemen produk, manajemen pesanan, harga, pembuatan faktur, dan pemberitahuan. Anda memutuskan untuk memulai transformasi aplikasi dengan modul pemberitahuan karena tidak memiliki dependensi pada modul lain. Namun, modul lain mungkin bergantung pada modul ini untuk mengirim pemberitahuan. Modul pemberitahuan dapat dengan mudah diurai menjadi layanan mikro terpisah, tetapi Anda harus membuat beberapa perubahan dalam aplikasi monolitik untuk memanggil layanan pemberitahuan baru. Anda memutuskan untuk mengubah modul pembuatan faktur berikutnya. Modul ini dipanggil setelah pesanan dibuat. Anda dapat menggunakan pola seperti Strangler dan Anti-korupsi untuk mendukung transformasi ini.
Sinkronisasi data, multi-tulis ke antarmuka monolitik dan layanan mikro, kepemilikan data, dekomposisi skema, gabungan, volume data, dan integritas data mungkin membuat perincian data dan migrasi sulit. Ada beberapa teknik yang dapat Anda gunakan, seperti menyimpan database bersama antara layanan mikro, memisahkan database dari sekelompok layanan berdasarkan kemampuan bisnis atau domain, dan mengisolasi database dari layanan. Solusi yang direkomendasikan adalah menguraikan setiap database dengan setiap layanan. Dalam banyak keadaan, itu tidak praktis. Dalam kasus tersebut, Anda dapat menggunakan pola seperti pola Tampilan Database dan pola Layanan Pembungkusan Database.
Saat Anda pindah ke arsitektur layanan mikro, penting untuk menilai kompetensi DevOps Anda. Arsitektur layanan mikro dimaksudkan untuk memfasilitasi pengembangan tangkas dalam aplikasi untuk meningkatkan kelincahan organisasi. DevOps adalah salah satu praktik utama yang harus Anda terapkan untuk mencapai kompetensi ini.
Saat Anda mengevaluasi kemampuan DevOps untuk arsitektur layanan mikro, ingatlah poin-poin ini:
- Apakah orang-orang di organisasi Anda mengetahui praktik dasar dan prinsip DevOps?
- Apakah tim memahami alat kontrol sumber dan integrasi mereka dengan alur CI/CD?
- Apakah Anda menerapkan praktik DevOps dengan benar?
- Apakah Anda mengikuti praktik tangkas?
- Apakah integrasi berkelanjutan diterapkan?
- Apakah pengiriman berkelanjutan diterapkan?
- Apakah penyebaran berkelanjutan diterapkan?
- Apakah pemantauan berkelanjutan diterapkan?
- Apakah Infrastruktur sebagai Kode (IaC) di tempat?
- Apakah Anda menggunakan alat yang tepat untuk mendukung CI/CD?
- Bagaimana konfigurasi penahapan dan lingkungan produksi dikelola untuk aplikasi?
- Apakah rantai alat memiliki dukungan komunitas dan model dukungan serta menyediakan saluran dan dokumentasi yang tepat?
Arsitektur layanan mikro fleksibel dan dapat disesuaikan. Selama penilaian, dorong diskusi di organisasi untuk menentukan area yang menurut kolega Anda akan sering berubah. Membangun layanan mikro memungkinkan tim merespons perubahan yang diminta pelanggan dengan cepat dan meminimalkan upaya pengujian regresi. Dalam aplikasi monolitik, perubahan dalam satu modul memerlukan banyak tingkat pengujian regresi dan mengurangi kelincahan dalam merilis versi baru.
Pertimbangkan faktor-faktor ini:
- Apakah layanan dapat disebarkan secara independen?
- Apakah layanan mengikuti prinsip DDD?
- Apakah layanan mengikuti prinsip SOLID?
- Apakah database bersifat privat ke layanan?
- Apakah Anda membangun layanan dengan menggunakan pola sasis layanan mikro yang didukung?
Ketika Anda beralih ke arsitektur layanan mikro, kesiapan infrastruktur adalah titik penting untuk dipertimbangkan. Performa, ketersediaan, dan skalabilitas aplikasi akan terpengaruh jika infrastruktur tidak disiapkan dengan benar atau jika layanan atau komponen yang tepat tidak digunakan. Terkadang aplikasi dibuat dengan semua metodologi dan prosedur yang disarankan, tetapi infrastrukturnya tidak memadai. Ini menghasilkan performa dan pemeliharaan yang buruk.
Pertimbangkan faktor-faktor ini saat Anda mengevaluasi kesiapan infrastruktur Anda:
- Apakah infrastruktur memastikan skalabilitas layanan yang disebarkan?
- Apakah infrastruktur mendukung provisi melalui skrip yang dapat diotomatisasi melalui CI/CD?
- Apakah infrastruktur penyebaran menawarkan SLA untuk ketersediaan?
- Apakah Anda memiliki rencana pemulihan bencana (DR) dan jadwal latihan rutin?
- Apakah data direplikasi ke wilayah yang berbeda untuk DR?
- Apakah Anda memiliki rencana pencadangan data?
- Apakah opsi penyebaran didokumentasikan?
- Apakah infrastruktur penyebaran dipantau?
- Apakah infrastruktur penyebaran mendukung penyembuhan mandiri layanan?
Layanan mikro adaptif untuk berubah dan memanfaatkan pengembangan yang gesar untuk mempersingkat siklus rilis dan membawa nilai bagi pelanggan lebih banyak. Pertimbangkan faktor-faktor ini saat Anda mengevaluasi siklus rilis Anda:
- Seberapa sering Anda membuat dan merilis aplikasi?
- Seberapa sering rilis Anda gagal setelah penyebaran?
- Berapa lama waktu yang dibutuhkan untuk memulihkan atau memulihkan masalah setelah pemadaman?
- Apakah Anda menggunakan penerapan versi semantik untuk aplikasi Anda?
- Apakah Anda mempertahankan lingkungan yang berbeda dan menyebarluaskan rilis yang sama secara berurutan (misalnya, pertama untuk penahapan dan kemudian ke produksi)?
- Apakah Anda menggunakan penerapan versi untuk API Anda?
- Apakah Anda mengikuti panduan penerapan versi yang tepat untuk API?
- Kapan Anda mengubah versi API?
- Apa pendekatan Anda untuk menangani penerapan versi API?
- Penerapan versi jalur URI
- Penerapan versi parameter kueri
- Penerapan versi tipe konten
- Penerapan versi header kustom
- Apakah Anda memiliki praktik untuk penerapan versi peristiwa?
Layanan mikro adalah layanan mandiri yang berkomunikasi satu sama lain di seluruh batas proses untuk mengatasi skenario bisnis. Untuk mendapatkan komunikasi yang andal dan dapat diandalkan, Anda perlu memilih protokol komunikasi yang sesuai.
Pertimbangkan faktor-faktor ini:
- Apakah Anda mengikuti pendekatan API-first, di mana API diperlakukan sebagai warga negara kelas satu?
- Apakah Anda memiliki operasi rantai panjang, di mana beberapa layanan berkomunikasi secara berurutan melalui protokol komunikasi sinkron?
- Apakah Anda mempertimbangkan komunikasi asinkron di mana saja dalam sistem?
- Sudahkah Anda menilai teknologi broker pesan dan kemampuannya?
- Apakah Anda memahami throughput pesan yang diterima dan diproses layanan?
- Apakah Anda menggunakan komunikasi klien-ke-layanan langsung?
- Apakah Anda perlu menyimpan pesan di tingkat broker pesan?
- Apakah Anda menggunakan pola Tampilan Terwujud untuk mengatasi perilaku layanan mikro yang cerewet?
- Apakah Anda menerapkan Retry, Circuit Breaker, Exponential Backoff, dan Jitter untuk komunikasi yang andal? Cara umum untuk menangani ini adalah dengan menggunakan pola Duta Besar.
- Apakah Anda telah menentukan peristiwa domain untuk memfasilitasi komunikasi antara layanan mikro?
Gateway API adalah salah satu komponen inti dalam arsitektur layanan mikro. Secara langsung mengekspos layanan ke klien menciptakan masalah dalam hal pengelolaan, kontrol, dan komunikasi yang dapat diandalkan. Gateway API berfungsi sebagai server proksi, mencegat lalu lintas dan merutekannya ke layanan back-end. Jika Anda perlu memfilter lalu lintas berdasarkan alamat IP, otorisasi, respons tiruan, dan sebagainya, Anda dapat melakukannya di tingkat gateway API tanpa membuat perubahan apa pun pada layanan.
Pertimbangkan faktor-faktor ini:
- Apakah layanan langsung dikonsumsi oleh klien?
- Apakah ada gateway API yang bertindak sebagai fasad untuk semua layanan?
- Dapatkah gateway API menyiapkan kebijakan seperti batas kuota, respons tiruan, dan pemfilteran alamat IP?
- Apakah Anda menggunakan beberapa gateway API untuk mengatasi kebutuhan berbagai jenis klien, seperti aplikasi seluler, aplikasi web, dan mitra?
- Apakah gateway API Anda menyediakan portal tempat klien dapat menemukan dan berlangganan layanan, seperti portal pengembang di Azure API Management?
- Apakah solusi Anda menyediakan kemampuan penyeimbangan beban L7 atau Web Application Firewall (WAF) bersama dengan gateway API?
Transaksi terdistribusi memfasilitasi eksekusi beberapa operasi sebagai satu unit kerja. Dalam arsitektur layanan mikro, sistem diurai menjadi banyak layanan. Satu kasus penggunaan bisnis ditangani oleh beberapa layanan mikro sebagai bagian dari satu transaksi terdistribusi. Dalam transaksi terdistribusi, perintah adalah operasi yang dimulai ketika peristiwa terjadi. Kejadian ini memicu operasi dalam sistem. Jika operasi berhasil, operasi mungkin memicu perintah lain, yang kemudian dapat memicu peristiwa lain, dan sebagainya sampai semua transaksi selesai atau digulung balik, tergantung pada apakah transaksi berhasil.
Pertimbangkan pertimbangan berikut:
- Berapa banyak transaksi terdistribusi yang ada di sistem?
- Apa pendekatan Anda untuk menangani transaksi terdistribusi? Mengevaluasi penggunaan pola Saga dengan orkestrasi atau koreografi.
- Berapa banyak transaksi yang mencakup beberapa layanan?
- Apakah Anda mengikuti model transaksi ACID atau BASE untuk mencapai konsistensi dan integritas data?
- Apakah Anda menggunakan operasi rantai panjang untuk transaksi yang mencakup beberapa layanan?
Salah satu manfaat terbesar arsitektur layanan mikro adalah keragaman teknologi. Sistem berbasis layanan mikro memungkinkan tim mengembangkan layanan dengan menggunakan teknologi yang mereka pilih. Dalam pengembangan aplikasi tradisional, Anda dapat menggunakan kembali kode yang ada saat membuat komponen baru, atau membuat kerangka kerja pengembangan internal untuk mengurangi upaya pengembangan. Penggunaan beberapa teknologi dapat mencegah penggunaan kembali kode.
Pertimbangkan faktor-faktor ini:
- Apakah Anda menggunakan templat layanan untuk memulai pengembangan layanan baru?
- Apakah Anda mengikuti metodologi aplikasi Twelve-Factor dan menggunakan basis kode tunggal untuk layanan mikro, mengisolasi dependensi, dan konfigurasi eksternalisasi?
- Apakah Anda menyimpan konfigurasi sensitif di brankas kunci?
- Apakah Anda membuat kontainer layanan Anda?
- Apakah Anda mengetahui persyaratan konsistensi data Anda?
Pendekatan penyebaran Anda adalah metode Anda untuk merilis versi aplikasi Anda di berbagai lingkungan penyebaran. Sistem berbasis layanan mikro memberikan kelincahan untuk merilis versi lebih cepat dari yang Anda bisa dengan aplikasi tradisional.
Saat Anda menilai rencana penyebaran, pertimbangkan faktor-faktor ini:
- Apakah Anda memiliki strategi untuk menyebarkan layanan Anda?
- Apakah Anda menggunakan alat dan teknologi modern untuk menyebarkan layanan Anda?
- Kolaborasi seperti apa yang diperlukan di antara tim saat Anda menyebarkan layanan?
- Apakah Anda menyediakan infrastruktur dengan menggunakan Infrastruktur sebagai Kode (IaC)?
- Apakah Anda menggunakan kemampuan DevOps untuk mengotomatiskan penyebaran?
- Apakah Anda menyebarluaskan build yang sama ke beberapa lingkungan, seperti yang disarankan oleh metodologi aplikasi Dua Belas Faktor?
Skalabilitas adalah salah satu keuntungan utama arsitektur layanan mikro. Itu karena layanan mikro dipetakan ke domain bisnis, sehingga setiap layanan dapat diskalakan secara independen. Aplikasi monolitik disebarkan sebagai satu unit pada platform hosting dan perlu diskalakan secara holistik. Hal ini menghasilkan waktu henti, risiko penyebaran, dan pemeliharaan. Aplikasi monolitik Anda mungkin dirancang dengan baik, dengan komponen yang menangani domain bisnis individual. Tetapi karena kurangnya batas proses, potensi melanggar prinsip-prinsip tanggung jawab tunggal menjadi lebih sulit. Ini akhirnya menghasilkan kode spaghetti. Karena aplikasi ini terdiri dan disebarkan sebagai proses hosting tunggal, skalabilitas sulit.
Layanan mikro memungkinkan tim untuk memilih platform hosting yang tepat untuk mendukung kebutuhan skalabilitas mereka. Berbagai platform hosting tersedia untuk mengatasi tantangan ini dengan menyediakan kemampuan seperti penskalaan otomatis, provisi elastis, ketersediaan yang lebih tinggi, penyebaran yang lebih cepat, dan pemantauan yang mudah.
Pertimbangkan faktor-faktor ini:
- Platform hosting apa yang Anda gunakan untuk menyebarkan layanan Anda (komputer virtual, kontainer, tanpa server)?
- Apakah platform hosting dapat diskalakan? Apakah mendukung autoscaling?
- Berapa lama waktu yang dibutuhkan untuk menskalakan platform hosting Anda?
- Apakah Anda memahami SLA yang disediakan berbagai platform hosting?
- Apakah platform hosting Anda mendukung pemulihan bencana?
Pemantauan adalah elemen penting dari aplikasi berbasis layanan mikro. Karena aplikasi dibagi menjadi sejumlah layanan yang berjalan secara independen, kesalahan pemecahan masalah dapat menakutkan. Jika Anda menggunakan semantik yang tepat untuk memantau layanan Anda, tim Anda dapat dengan mudah memantau, menyelidiki, dan menanggapi kesalahan.
Pertimbangkan faktor-faktor ini:
- Apakah Anda memantau layanan yang disebarkan?
- Apakah Anda memiliki mekanisme pengelogan? Alat apa yang Anda gunakan?
- Apakah Anda memiliki infrastruktur pelacakan terdistribusi di tempat?
- Apakah Anda merekam pengecualian?
- Apakah Anda mempertahankan kode kesalahan bisnis untuk identifikasi cepat masalah?
- Apakah Anda menggunakan pemeriksaan kesehatan untuk layanan?
- Apakah Anda menggunakan pengelogan semantik? Apakah Anda telah menerapkan metrik utama, ambang batas, dan indikator?
- Apakah Anda menutupi data sensitif selama pengelogan?
Dalam arsitektur layanan mikro, aplikasi terdiri dari berbagai layanan mikro yang dihosting secara independen, berinteraksi satu sama lain untuk melayani berbagai kasus penggunaan bisnis. Saat aplikasi berinteraksi dengan layanan back-end untuk melakukan operasi, Anda dapat menetapkan nomor unik, yang dikenal sebagai token korelasi, ke permintaan. Kami menyarankan agar Anda mempertimbangkan untuk menggunakan token korelasi, karena token tersebut dapat membantu Anda memecahkan masalah kesalahan. Mereka membantu Anda menentukan akar penyebab masalah, menilai dampak, dan menentukan pendekatan untuk memulihkan masalah.
Anda dapat menggunakan token korelasi untuk mengambil jejak permintaan dengan mengidentifikasi layanan mana yang berisi token korelasi dan yang tidak. Layanan yang tidak memiliki token korelasi untuk permintaan tersebut gagal. Jika kegagalan terjadi, Anda nantinya dapat mencoba kembali transaksi. Untuk menerapkan idempotensi, hanya layanan yang tidak memiliki token korelasi yang akan melayani permintaan.
Misalnya, jika Anda memiliki rantai operasi panjang yang melibatkan banyak layanan, meneruskan token korelasi ke layanan dapat membantu Anda menyelidiki masalah dengan mudah jika salah satu layanan gagal selama transaksi. Setiap layanan biasanya memiliki database sendiri. Token korelasi disimpan dalam catatan database. Jika terjadi pemutaran ulang transaksi, layanan yang memiliki token korelasi tertentu dalam database mereka mengabaikan permintaan. Hanya layanan yang tidak memiliki token yang melayani permintaan.
Pertimbangkan faktor-faktor ini:
- Pada tahap mana Anda menetapkan token korelasi?
- Komponen mana yang menetapkan token korelasi?
- Apakah Anda menyimpan token korelasi dalam database layanan?
- Apa format token korelasi?
- Apakah Anda mencatat token korelasi dan informasi permintaan lainnya?
Kerangka kerja sasis layanan mikro adalah kerangka kerja dasar yang menyediakan kemampuan untuk masalah lintas-pemotongan seperti pengelogan, penanganan pengecualian, pelacakan terdistribusi, keamanan, dan komunikasi. Saat Anda menggunakan kerangka kerja sasis, Anda lebih fokus pada penerapan batas layanan daripada berinteraksi dengan fungsionalitas infrastruktur.
Misalnya, Anda sedang membangun layanan manajemen kelir. Anda ingin memvalidasi token masuk, menulis log ke database pengelogan, dan berkomunikasi dengan layanan lain dengan memanggil titik akhir layanan tersebut. Jika Anda menggunakan kerangka kerja sasis layanan mikro, Anda dapat mengurangi upaya pengembangan. Dapr adalah salah satu sistem yang menyediakan berbagai blok bangunan untuk menerapkan kekhawatiran lintas-pemotongan.
Pertimbangkan faktor-faktor ini:
- Apakah Anda menggunakan kerangka kerja sasis layanan mikro?
- Apakah Anda menggunakan Dapr untuk berinteraksi dengan masalah lintas pemotongan?
- Apakah bahasa kerangka kerja sasis Anda agnostik?
- Apakah kerangka kerja sasis Anda umum, sehingga mendukung semua jenis aplikasi? Kerangka kerja sasis tidak boleh berisi logika khusus aplikasi.
- Apakah kerangka kerja sasis Anda menyediakan mekanisme untuk menggunakan komponen atau layanan yang dipilih sesuai kebutuhan?
Secara tradisional, pengujian dilakukan setelah pengembangan selesai dan aplikasi siap untuk diluncurkan ke pengujian penerimaan pengguna (UAT) dan lingkungan produksi. Saat ini ada pergeseran dalam pendekatan ini, memindahkan pengujian lebih awal (kiri) dalam siklus hidup pengembangan aplikasi. Pengujian shift-left meningkatkan kualitas aplikasi karena pengujian dilakukan selama setiap fase siklus hidup pengembangan aplikasi, termasuk fase desain, pengembangan, dan pasca-pengembangan.
Misalnya, saat membuat aplikasi, Anda mulai dengan merancang arsitektur. Saat Anda menggunakan pendekatan shift-left, Anda menguji desain untuk kerentanan dengan menggunakan alat seperti Pemodelan Ancaman Microsoft. Saat memulai pengembangan, Anda dapat memindai kode sumber dengan menjalankan alat seperti pengujian keamanan aplikasi statis (SAST) dan menggunakan penganalisis lain untuk mengungkap masalah. Setelah menyebarkan aplikasi, Anda dapat menggunakan alat seperti pengujian keamanan aplikasi dinamis (DAST) untuk mengujinya saat dihosting. Pengujian fungsi, pengujian chaos, pengujian penetrasi, dan jenis pengujian lainnya terjadi nanti.
Pertimbangkan faktor-faktor ini:
- Apakah Anda menulis rencana pengujian yang mencakup seluruh siklus hidup pengembangan?
- Apakah Anda menyertakan penguji dalam rapat persyaratan dan di seluruh siklus hidup pengembangan aplikasi?
- Apakah Anda menggunakan desain berbasis pengujian atau desain berbasis perilaku?
- Apakah Anda menguji cerita pengguna? Apakah Anda menyertakan kriteria penerimaan dalam cerita pengguna Anda?
- Apakah Anda menguji desain anda dengan menggunakan alat seperti Microsoft Threat Modeling?
- Apakah Anda menulis tes unit?
- Apakah Anda menggunakan penganalisis kode statis atau alat lain untuk mengukur kualitas kode?
- Apakah Anda menggunakan alat otomatis untuk menguji aplikasi?
- Apakah Anda menerapkan praktik Secure DevOps ?
- Apakah Anda melakukan pengujian integrasi, pengujian aplikasi end-to-end, pengujian beban/performa, pengujian penetrasi, dan pengujian chaos?
Perlindungan layanan, akses aman, dan komunikasi yang aman adalah salah satu pertimbangan terpenting untuk arsitektur layanan mikro. Misalnya, sistem berbasis layanan mikro yang mencakup beberapa layanan dan menggunakan validasi token untuk setiap layanan bukanlah solusi yang layak. Sistem ini akan memengaruhi kelincahan sistem keseluruhan dan potensi memperkenalkan penyimpangan implementasi di seluruh layanan.
Masalah keamanan biasanya ditangani oleh gateway API dan firewall aplikasi. Gateway dan firewall mengambil permintaan masuk, memvalidasi token, dan menerapkan berbagai filter dan kebijakan, seperti menerapkan prinsip OWASP Top 10 untuk mencegat lalu lintas. Akhirnya, mereka mengirim permintaan ke layanan mikro back-end. Konfigurasi ini membantu pengembang fokus pada kebutuhan bisnis daripada kekhawatiran keamanan lintas pemotongan.
Pertimbangkan faktor-faktor ini:
- Apakah autentikasi dan otorisasi diperlukan untuk layanan?
- Apakah Anda menggunakan gateway API untuk memvalidasi token dan permintaan masuk?
- Apakah Anda menggunakan SSL atau mTLS untuk memberikan keamanan untuk komunikasi layanan?
- Apakah Anda memiliki kebijakan keamanan jaringan untuk memungkinkan komunikasi yang diperlukan di antara layanan?
- Apakah Anda menggunakan firewall (L4, L7) jika berlaku untuk memberikan keamanan untuk komunikasi internal dan eksternal?
- Apakah Anda menggunakan kebijakan keamanan di API Gateway untuk mengontrol lalu lintas?
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Ovais Mehboob Ahmed Khan | Arsitek Solusi Cloud Senior - Teknik
- Nabil Siddiqui | Arsitek Solusi Cloud - Inovasi Digital & Aplikasi
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.