Bagikan melalui

Pendekatan arsitektur untuk sarana kontrol dalam solusi multipenyewa

  • Artikel

Sarana kontrol adalah bagian penting dari perangkat lunak sebagai layanan (SaaS) dan solusi multipenyewa, terutama untuk membantu mengelola solusi dalam skala besar. Biasanya, ada dua komponen utama yang membentuk sarana kontrol:

  • Katalog penyewa, yang menyimpan informasi penting tentang penyewa Anda, seperti:
    • Konfigurasi penyewa.
    • SKU yang disebarkan untuk sumber daya penyewa.
    • Stempel penyebaran mana yang dialokasikan untuk penyewa.
  • Proses untuk mengelola perubahan pada lingkungan, yang dipicu oleh peristiwa siklus hidup penyewa. Misalnya, onboarding penyewa, offboarding penyewa, dan pemeliharaan reguler yang diperlukan.

Sarana kontrol adalah aplikasi itu sendiri. Anda perlu memikirkan sarana kontrol Anda dengan hati-hati dan merancangnya dengan ketelitian yang sama dan perawatan yang Anda gunakan dengan bagian lain dari solusi Anda. Untuk informasi selengkapnya tentang apa itu sarana kontrol, mengapa Anda harus menggunakannya, dan pertimbangan untuk mendesainnya, lihat Pertimbangan untuk sarana kontrol multipenyewa.

Artikel ini menjelaskan beberapa pendekatan yang dapat Anda pertimbangkan untuk merancang dan membuat sarana kontrol. Daftar pendekatan yang dijelaskan di sini tidak komprehensif. Meskipun semua pendekatan valid, ada arsitektur lain yang valid.

Pendekatan dan pola yang perlu dipertimbangkan

Tabel berikut ini meringkas perbedaan antara beberapa pendekatan yang dapat Anda pertimbangkan untuk sarana kontrol. Pendekatan manual, kode rendah, dan kustom dibandingkan.

Pertimbangan Manual Kode rendah Adat
Overhead operasional Sangat Penting Sedang rendah Kurang Penting
Frekuensi peristiwa siklus hidup pendekatan cocok untuk Jarang Sesekali sering Sering
Waktu dan kompleksitas untuk diimplementasikan Kurang Penting Medium Sangat Penting
Tanggung jawab pemeliharaan sarana kontrol Kurang Penting Medium Sangat Penting
Kemampuan untuk diuji Kurang Penting Medium Sangat Penting
Risiko inkonsistensi Sangat Penting Sedang-rendah Kurang Penting

Proses manual

Tidak selalu penting untuk membangun sarana kontrol yang sepenuhnya otomatis, terutama ketika Anda memulai dan hanya memiliki sejumlah kecil penyewa.

Anda mungkin menyimpan katalog penyewa Anda di suatu tempat yang terletak di pusat, seperti dalam buku kerja Excel atau file JSON yang disimpan di tempat yang dapat diakses tim Anda. Terlepas dari formatnya, ada baiknya menyimpan informasi dengan cara terstruktur sehingga Anda dapat dengan mudah bekerja dengan data secara terprogram.

Catatan

Sarana kontrol manual adalah cara yang bagus untuk mulai mengelola aplikasi multipenyewa Anda, tetapi hanya cocok untuk sejumlah kecil penyewa (kurang dari 5-10). Overhead administratif dan risiko inkonsistensi meningkat dengan setiap penyewa yang Anda onboarding secara manual. Anda hanya boleh menggunakan pendekatan ini jika Anda hanya memiliki beberapa penyewa dan Anda tidak memerlukan onboarding otomatis atau layanan mandiri.

Untuk proses seperti onboarding penyewa dan aktivitas pemeliharaan:

  • Buat skrip atau alur otomatis sedapat mungkin, bahkan jika Anda menjalankannya secara manual. Dengan menggunakan skrip atau alur, Anda memastikan bahwa langkah-langkah berjalan secara konsisten untuk setiap penyewa.
  • Untuk tugas yang awalnya tidak dapat Anda skrip, dokumentasikan proses secara menyeluruh dan secara eksplisit. Dokumentasikan bagaimana serta alasannya. Jika seseorang akhirnya mengotomatiskan tugas di masa depan, mereka harus memiliki pemahaman yang baik tentang keduanya.

Diagram berikut mengilustrasikan salah satu cara untuk menggunakan proses manual untuk sarana kontrol awal:

Diagram yang menunjukkan salah satu cara untuk menggunakan skrip dan proses manual lainnya untuk sarana kontrol.

Unduh file Visio arsitektur ini.

Keuntungan dari pendekatan manual

  • Ringan: Dokumentasi, skrip, dan alur mudah dikembangkan dan dimodifikasi. Ini membuatnya tepat ketika Anda mencari tahu proses Anda karena Anda dapat dengan cepat melakukan iterasi dan mengembangkannya.
  • Biaya rendah: Mempertahankan dan menjalankan pendekatan manual tidak mahal.
  • Memvalidasi proses Anda: Bahkan jika Anda akhirnya berniat untuk menggunakan pendekatan yang lebih otomatis, dimulai dengan pendekatan manual sebagai bukti konsep adalah cara yang baik untuk memvalidasi strategi pemeliharaan Anda sebelum Anda menginvestasikan waktu dalam mengembangkan otomatisasi yang lebih kuat.

Kerugian dari pendekatan manual

  • Kurangnya kontrol: Pendekatan ini bergantung pada semua orang yang terlibat melakukan hal yang benar. Seseorang mungkin menyimpang dari proses yang ditentukan, baik secara tidak sengaja atau sengaja. Setiap variasi dalam proses meningkatkan risiko inkonsistensi di lingkungan Anda, yang membuat manajemen yang sedang berlangsung jauh lebih sulit.
  • Tantangan kontrol akses: Ketika Anda menggunakan pendekatan ini, Anda biasanya perlu memberikan akses yang luas dan sangat permisif kepada siapa pun yang mengoperasikan solusi Anda, yang membuatnya sulit untuk mengikuti praktik terbaik untuk segmentasi akses.
  • Skalabilitas: Pekerjaan yang diperlukan untuk menjalankan skala proses manual dengan jumlah penyewa yang perlu Anda kelola.
  • Kemampuan uji: Proses manual sulit divalidasi dan diuji.

Kapan harus mempertimbangkan untuk menjauh dari pendekatan manual

  • Ketika tim Anda tidak dapat mengikuti jumlah pekerjaan yang perlu mereka lakukan untuk mempertahankan aplikasi. Misalnya, ketika jumlah penyewa Anda menskalakan di luar titik kritis, yang untuk sebagian besar tim adalah antara 5 dan 10 penyewa.
  • Ketika Anda mengantisipasi pertumbuhan penyewa di luar jumlah penyewa yang penting dan Anda perlu mempersiapkan pekerjaan yang terlibat dalam mengelola jumlah penyewa tersebut.
  • Ketika Anda perlu mengurangi risiko inkonsistensi. Misalnya, Anda mungkin mengamati beberapa kesalahan yang terjadi karena seseorang tidak mengikuti proses dengan benar, atau karena ada terlalu banyak ambiguitas dalam proses. Risiko inkonsistensi biasanya tumbuh karena lebih banyak penyewa di-onboarding secara manual, dan saat tim Anda tumbuh.

Sarana kontrol kode rendah

Sarana kontrol kode rendah atau tanpa kode dibangun di platform yang dirancang untuk mengotomatiskan proses bisnis dan melacak informasi. Ada banyak platform yang memungkinkan Anda melakukan tugas-tugas ini tanpa menulis kode kustom.

Microsoft Power Platform adalah contoh salah satu platform ini. Jika Anda menggunakan Power Platform, Anda mungkin menyimpan katalog penyewa di Dynamics 365, Dataverse, atau Microsoft 365. Anda juga dapat mempertimbangkan untuk menyimpan katalog penyewa yang sama dengan yang Anda gunakan untuk proses manual Anda, jika Anda tidak ingin sepenuhnya berkomitmen untuk mengotomatiskan semuanya pada awalnya.

Untuk onboarding dan pemeliharaan penyewa, Anda dapat menggunakan Power Automate untuk menjalankan alur kerja yang melakukan manajemen penyewa, mengonfigurasi penyewa, memicu alur atau panggilan API, dan sebagainya. Anda dapat menggunakan Power Automate untuk melihat perubahan pada katalog penyewa Anda, jika data berada di suatu tempat yang dapat diakses oleh Power Automate. Jika Anda menggunakan katalog penyewa manual, alur kerja Power Automate juga dapat dipicu secara manual. Anda mungkin memutuskan untuk menyertakan langkah-langkah persetujuan manual dalam alur kerja Anda jika Anda memerlukan seseorang dari tim Anda untuk memverifikasi sesuatu atau melakukan langkah-langkah tambahan yang tidak dapat sepenuhnya otomatis.

Pendekatan ini juga memungkinkan Anda untuk menyediakan pendaftaran layanan mandiri kepada pelanggan Anda dengan memungkinkan aplikasi web Anda untuk langsung menambahkan catatan ke katalog penyewa Anda tanpa intervensi manusia.

Diagram berikut mengilustrasikan bagaimana Anda dapat membuat sarana kontrol dengan pendaftaran layanan mandiri dengan menggunakan Microsoft Power Platform:

Diagram yang memperlihatkan salah satu cara untuk menggunakan Power Automate dan Dataverse sebagai sarana kontrol kode rendah.

Unduh file Visio arsitektur ini.

Keuntungan dari pendekatan kode rendah

  • Ringan: Seringkali cepat dan murah untuk membuat serangkaian alur kerja kode rendah dan menghubungkannya ke sistem di sekitarnya.
  • Menggunakan alat platform: Anda dapat menggunakan fitur platform asli untuk menyimpan data, membuat portal administratif untuk digunakan tim Anda, dan memantau alur kerja saat berjalan. Dengan menggunakan fitur platform asli, Anda menghindari membangun banyak komponen sendiri.
  • Dapat disesuaikan: Jika Anda memerlukan lebih banyak penyesuaian, Anda biasanya dapat menambah alur kerja Anda dengan kode dan proses kustom. Misalnya, Anda mungkin menggunakan Power Automate untuk memicu alur kerja penyebaran di GitHub Actions, atau Anda mungkin memanggil Azure Functions untuk menjalankan kode Anda sendiri. Ini juga membantu memfasilitasi implementasi bertahap.
  • Overhead rendah: Layanan kode rendah biasanya dikelola sepenuhnya, sehingga Anda tidak perlu mengelola infrastruktur.

Kerugian dari pendekatan kode rendah

  • Keahlian yang diperlukan: Untuk menggunakan platform kode rendah untuk membuat proses, dan untuk menggunakan platform ini secara efektif, Anda biasanya memerlukan pengetahuan kepemilikan. Banyak organisasi sudah menggunakan alat-alat ini, sehingga tim Anda mungkin sudah memiliki keahlian yang diperlukan, tetapi mungkin tidak. Anda harus mempertimbangkan apakah Anda perlu melatih tim Anda untuk menggunakan platform ini secara efektif.
  • Manajemen: Mungkin sulit untuk menangani manajemen konfigurasi kode rendah dalam jumlah besar.
  • Kemampuan uji: Pertimbangkan cara menguji dan mempromosikan perubahan pada sarana kontrol Anda. Dalam platform terkelola, membuat proses DevOps yang khas untuk menguji dan mempromosikan perubahan lebih sulit, karena perubahan biasanya dilakukan melalui konfigurasi, bukan melalui kode.
  • Desain: Pikirkan dengan cermat tentang cara memenuhi persyaratan non-fungsi seperti keamanan dan keandalan. Persyaratan ini sering dikelola untuk Anda di platform kode rendah.

Kapan harus mempertimbangkan untuk menjauh dari pendekatan kode rendah

  • Akhirnya, persyaratan Anda mungkin menjadi sangat kompleks sehingga Anda tidak dapat memasukkannya dengan sensitif dalam solusi kode rendah. Ketika Anda perlu mengatasi batasan alat untuk memenuhi kebutuhan Anda, mungkin masuk akal untuk menjauh dari solusi terkelola dan menuju sarana kontrol kustom.

Sarana kontrol kustom

Anda juga dapat mempertimbangkan untuk membuat sarana kontrol anda sendiri yang sepenuhnya disesuaikan. Opsi ini memberikan fleksibilitas dan daya terbanyak, tetapi juga membutuhkan pekerjaan paling banyak. Katalog penyewa biasanya disimpan dalam database. Anda tidak bekerja langsung dengan katalog dalam hal ini, tetapi sebaliknya mengelolanya melalui antarmuka administratif, yang mungkin merupakan aplikasi kustom atau sistem seperti aplikasi manajemen hubungan pelanggan (CRM) organisasi Anda.

Anda biasanya membuat sekumpulan komponen sarana kontrol yang dirancang di sekitar semua fungsi administratif penyewa Anda. Komponen-komponen ini mungkin mencakup portal administratif atau antarmuka pengguna lainnya, API, dan komponen pemrosesan latar belakang. Jika Anda perlu melakukan hal-hal seperti menyebarkan kode atau infrastruktur saat peristiwa siklus hidup penyewa terjadi, alur penyebaran mungkin juga membentuk sarana kontrol Anda.

Pastikan bahwa pemrosesan jangka panjang menggunakan alat yang sesuai. Misalnya, Anda dapat menggunakan Durable Functions atau Azure Logic Apps untuk komponen yang mengatur onboarding atau penyebaran penyewa, atau untuk komponen yang perlu berkomunikasi dengan sistem eksternal.

Seperti pendekatan kode rendah, pendekatan ini memungkinkan Anda untuk menyediakan pendaftaran layanan mandiri kepada pelanggan Anda dengan memungkinkan aplikasi web Anda untuk langsung menambahkan catatan ke katalog penyewa Anda tanpa intervensi manusia.

Diagram berikut menunjukkan salah satu cara untuk membuat sarana kontrol kustom dasar yang menyediakan pendaftaran layanan mandiri:

Diagram yang mengilustrasikan sarana kontrol yang dibuat dengan Durable Functions, database SQL, dan bus layanan.

Unduh file Visio arsitektur ini.

Keuntungan dari pendekatan kustom

  • Fleksibilitas penuh dan penyesuaian: Anda memiliki kontrol penuh atas apa yang dilakukan sarana kontrol Anda dan dapat mengubahnya jika persyaratan Anda berubah.
  • Kemampuan pengujian: Anda dapat menggunakan siklus hidup pengembangan perangkat lunak standar (SDLC) untuk aplikasi sarana kontrol Anda dan menerapkan pendekatan normal untuk pengujian dan penyebaran, seperti yang Anda lakukan untuk aplikasi utama Anda.

Kerugian dari pendekatan kustom

  • Tanggung jawab pemeliharaan: Pendekatan ini membutuhkan lebih banyak overhead pemeliharaan karena Anda perlu membuat semuanya sendiri. Sarana kontrol sama pentingnya dengan bagian lain dari aplikasi Anda. Anda perlu berhati-hati dalam mengembangkan, menguji, dan mengoperasikan sarana kontrol Anda untuk memastikan sarana kontrol Anda dapat diandalkan dan aman.

Pendekatan hybrid

Anda juga dapat mempertimbangkan untuk menggunakan pendekatan hibrid. Anda mungkin menggunakan kombinasi sistem manual dan otomatis, atau Anda dapat menggunakan platform terkelola seperti Microsoft Power Platform dan menambahnya dengan aplikasi kustom. Pertimbangkan untuk menerapkan pendekatan hibrid jika Anda memerlukan penyesuaian sarana kontrol kustom tetapi tidak selalu ingin membangun dan memelihara sistem kustom sepenuhnya. Perlu diingat bahwa, pada titik tertentu, kustomisasi otomatis Anda ke proses manual atau platform terkelola Anda mungkin menjadi serumit sistem yang sepenuhnya disesuaikan. Titik tip berbeda untuk setiap organisasi, tetapi jika pendekatan hibrid Anda rumit untuk dipertahankan, Anda harus mempertimbangkan untuk pindah ke sistem yang sepenuhnya kustom.

Implementasi bertahap

Bahkan jika Anda tahu bahwa Anda ingin akhirnya mengotomatiskan sarana kontrol Anda, Anda tidak perlu memulai dengan pendekatan tersebut. Pendekatan umum selama tahap awal pembuatan aplikasi Anda adalah memulai dengan sarana kontrol manual. Saat aplikasi Anda berkembang dan onboard lebih banyak penyewa, Anda harus mulai mengidentifikasi area penyempitan dan mengotomatiskannya seperlunya, pindah ke pendekatan hibrid. Saat Anda mengotomatiskan lebih banyak, Anda mungkin pada akhirnya memiliki sarana kontrol yang sepenuhnya otomatis.

Antipattern yang perlu dihindari

  • Mengandalkan proses manual terlalu lama. Meskipun wajar untuk menggunakan proses manual ketika Anda memulai atau ketika Anda memiliki jumlah penyewa yang rendah dan memerlukan manajemen yang cukup ringan, Anda perlu merencanakan cara menskalakan ke solusi otomatis saat Anda tumbuh. Jika Anda perlu mempekerjakan anggota tim tambahan untuk mengikuti permintaan proses manual Anda, itu adalah pertanda baik bahwa Anda harus mulai mengotomatiskan bagian-bagian dari sarana kontrol Anda.
  • Menggunakan alat yang tidak pantas untuk alur kerja yang berjalan lama. Misalnya, hindari menggunakan fungsi Azure standar, panggilan API sinkron, atau alat lain yang memiliki batas waktu eksekusi untuk melakukan operasi jangka panjang seperti penyebaran Azure Resource Manager atau orkestrasi multi-langkah. Sebagai gantinya, gunakan alat seperti Azure Logic Apps, Durable Functions, dan alat lain yang dapat melakukan alur kerja atau urutan operasi yang berjalan lama. Untuk informasi selengkapnya, lihat Performa dan keandalan Azure Functions dan pola Balasan Permintaan Asinkron.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Kontributor lain:

Langkah berikutnya