Bagikan melalui

Menyempurnakan platform aplikasi Anda untuk menyederhanakan pengembangan dan manajemen infrastruktur

Bagian besar dari meningkatkan praktik rekayasa platform organisasi Anda adalah mengevaluasi platform aplikasi Anda. Platform aplikasi mencakup semua alat dan layanan yang digunakan untuk mendukung pengembangan, penyebaran, dan manajemen aplikasi di organisasi Anda.

Menyederhanakan dan menstandarkan

Infrastruktur sebagai kode (IaC) dan alat otomatisasi dapat dikombinasikan dengan templat untuk menstandarkan infrastruktur dan penyebaran aplikasi. Untuk mengurangi beban platform khusus pada pengguna akhir, Anda dapat mengabstraksi detail platform dengan memecah pilihan menjadi konvensi penamaan yang dapat direlatable, misalnya:

  • Kategori jenis sumber daya (komputasi tinggi, memori tinggi)
  • Kategori ukuran sumber daya (misalnya, ukuran t-shirt dalam ukuran kecil, sedang, dan besar)

Templat harus mewakili persyaratan umum yang telah diuji dengan konfigurasi prasetel, sehingga tim dev dapat segera memulai dengan menyediakan parameter minimal dan tanpa perlu meninjau opsi. Namun, ada kesempatan di mana tim perlu mengubah lebih banyak opsi pada templat yang diterbitkan daripada yang tersedia atau diinginkan. Misalnya, desain yang disetujui mungkin memerlukan konfigurasi tertentu yang berada di luar default templat yang didukung. Dalam hal ini, operasi atau tim teknik platform dapat membuat konfigurasi satu kali, lalu memutuskan apakah templat perlu menggabungkan perubahan tersebut sebagai default.

Anda dapat melacak perubahan menggunakan alat IaC dengan fitur deteksi penyimpangan yang dapat secara otomatis memulihkan penyimpangan (GitOps). Contoh alat ini adalah Terraform dan alat cloud-native IaC (misalnya, Cluster API, Crossplane, Azure Service Operator v2). Di luar deteksi penyimpangan alat IaC, ada alat konfigurasi cloud yang dapat mengkueri konfigurasi sumber daya, seperti Azure Resource Graph. Ini dapat berfungsi sebagai dua manfaat; untuk memantau perubahan di luar kode infrastruktur, dan meninjau konfigurasi preset yang diubah. Untuk menghindari terlalu kaku, Anda dapat menerapkan toleransi dalam penyebaran juga dengan batas yang telah ditentukan sebelumnya. Misalnya, Anda dapat menggunakan Azure Policy untuk membatasi jumlah simpul Kubernetes dalam suatu penyebaran.

Dikelola sendiri atau dikelola?

Di cloud publik Anda memiliki pilihan untuk menggunakan perangkat lunak sebagai layanan (Saas), platform as a service (PaaS), atau infrastruktur sebagai layanan (IaaS). Untuk mempelajari selengkapnya tentang SaaS, PaaS, dan IaaS, lihat modul pelatihan Menjelaskan jenis layanan cloud. Layanan PaaS menawarkan pengalaman pengembangan yang efisien tetapi lebih preskriptif dengan model aplikasi mereka. Pada akhirnya, ada trade-off antara kemudahan penggunaan dan kontrol yang perlu Anda evaluasi.

Selama desain platform, evaluasi dan prioritaskan kebutuhan layanan organisasi Anda. Misalnya, apakah Anda membuat aplikasi langsung di Azure Kubernetes Service (AKS) atau melalui Azure Container Apps tergantung pada kebutuhan Anda untuk layanan dan pada kapasitas dan set keterampilan internal Anda. Hal yang sama berlaku untuk layanan gaya fungsi seperti Azure Functions atau Azure App Service. Aplikasi Kontainer, Fungsi, dan App Service mengurangi kompleksitas, sementara AKS memberikan lebih banyak fleksibilitas dan kontrol. Model aplikasi yang lebih eksperimental seperti proyek inkubasi Radius OSS mencoba memberikan keseimbangan antara keduanya, tetapi umumnya dalam tahap kematangan sebelumnya daripada layanan cloud dengan dukungan penuh dan kehadiran dalam format IaC yang mapan.

Masalah yang Anda identifikasi selama perencanaan akan membantu Anda mengevaluasi akhir skala ini yang tepat untuk Anda. Pastikan untuk memperhitungkan kumpulan keterampilan internal Anda sendiri yang ada saat Anda membuat keputusan.

Sumber daya bersama versus khusus

Dalam organisasi Anda, ada sumber daya yang dapat dibagikan oleh beberapa aplikasi untuk meningkatkan pemanfaatan dan efektivitas biaya. Setiap sumber daya bersama memiliki serangkaian pertimbangannya sendiri. Misalnya, ini adalah pertimbangan untuk berbagi kluster Kubernetes, tetapi beberapa berlaku untuk jenis sumber daya lainnya:

  • Organisasi: Berbagi sumber daya seperti kluster di dalam batas organisasi, daripada di seluruh batas, dapat meningkatkan bagaimana mereka selaras dengan arah, persyaratan, dan prioritas organisasi.
  • Penyewaan aplikasi: Aplikasi dapat memiliki persyaratan isolasi penyewaan yang berbeda; Anda perlu meninjau keamanan aplikasi individual dan kepatuhan terhadap peraturan jika dapat hidup berdampingan dengan aplikasi lain. Misalnya, di Kubernetes, aplikasi dapat menggunakan isolasi namespace. Tetapi Anda juga harus mempertimbangkan penyewaan aplikasi untuk berbagai jenis lingkungan. Misalnya, seringkali yang terbaik adalah menghindari pencampuran aplikasi pengujian dengan aplikasi produksi pada kluster yang sama untuk menghindari dampak yang tidak terduga karena kesalahan konfigurasi atau masalah keamanan. Atau Anda mungkin memilih untuk terlebih dahulu menguji dan menyetel kluster Kubernetes khusus untuk melacak masalah ini sebelum penyebaran pada kluster bersama sebagai gantinya. Terlepas dari itu, konsistensi dalam pendekatan Anda adalah kunci untuk menghindari kebingungan dan kesalahan.
  • Konsumsi sumber daya: Pahami penggunaan sumber daya dan kapasitas cadangan setiap aplikasi, dan lakukan proyeksi untuk memperkirakan apakah berbagi layak. Anda juga harus mengetahui batas sumber daya yang digunakan (kapasitas pusat data atau batas langganan). Tujuannya adalah untuk menghindari pemindahan aplikasi dan dependensi Anda karena kendala sumber daya di lingkungan bersama, atau memiliki insiden situs langsung saat kapasitas habis. Gunakan batas sumber daya, pengujian representatif, peringatan pemantauan, dan pelaporan untuk mengidentifikasi konsumsi sumber daya dan melindungi dari aplikasi yang mengonsumsi terlalu banyak sumber daya.
  • Optimalkan konfigurasi bersama: Sumber daya bersama seperti kluster bersama memerlukan pertimbangan dan konfigurasi tambahan. Pertimbangan ini termasuk pengisian silang, alokasi sumber daya, manajemen izin, kepemilikan beban kerja, berbagi data, koordinasi peningkatan, penempatan beban kerja, pembentukan, pengelolaan, dan iterasi konfigurasi dasar, manajemen kapasitas, dan penempatan beban kerja. Sumber daya bersama memiliki manfaat, tetapi jika konfigurasi standar terlalu ketat dan tidak berevolusi, maka konfigurasi tersebut menjadi usang.

Menerapkan strategi tata kelola

Tata kelola adalah bagian penting dari mengaktifkan layanan mandiri dengan batas kendali, tetapi menerapkan aturan kepatuhan dengan cara yang tidak memengaruhi waktu untuk mencapai nilai bisnis aplikasi adalah tantangan umum. Ada dua bagian tata kelola:

  • Kepatuhan penyebaran awal (mulai kanan): Ini dapat dicapai dengan templat IaC standar yang tersedia melalui katalog, dengan manajemen izin dan kebijakan untuk memastikan hanya sumber daya dan konfigurasi yang diizinkan yang dapat disebarkan.
  • Mempertahankan kepatuhan (tetap benar): Alat berbasis kebijakan dapat mencegah atau memperingatkan Anda saat ada perubahan sumber daya. Di luar infrastruktur inti Anda, pertimbangkan alat juga mendukung kepatuhan di dalam sumber daya seperti Kubernetes bersama dengan OS yang digunakan dalam kontainer atau VM Anda. Misalnya, Anda mungkin ingin menerapkan konfigurasi OS yang dikunci atau menginstal alat perangkat lunak keamanan seperti Kebijakan Grup Windows, SELinux, AppArmor, Azure Policy, atau Kyverno. Jika pengembang hanya memiliki akses ke repositori IaC, Anda dapat menambahkan alur kerja persetujuan untuk meninjau perubahan yang diusulkan dan mencegah akses langsung ke sarana kontrol sumber daya seperti Azure.

Mempertahankan kepatuhan memerlukan alat untuk mengakses, melaporkan, dan menindaklanjuti masalah. Misalnya, Azure Policy dapat digunakan dengan banyak layanan Azure untuk audit, pelaporan, dan remediasi. Ini juga memiliki mode yang berbeda seperti Audit, Tolak, dan DeployIfNotExists tergantung pada kebutuhan Anda.

Meskipun kebijakan dapat memberlakukan kepatuhan, kebijakan juga dapat merusak aplikasi secara tak terduga. Oleh karena itu, pertimbangkan untuk berkembang ke praktik kebijakan sebagai kode (PaC) saat beroperasi dalam skala besar. Sebagai bagian penting dari pendekatan mulai dengan benar dan tetap benar, PaC menyediakan:

  • Standar yang dikelola secara terpusat
  • Pengaturan versi untuk kebijakan Anda
  • Pengujian dan validasi otomatis
  • Mengurangi waktu untuk diluncurkan
  • Penempatan Berkelanjutan

PaC dapat membantu meminimalkan radius ledakan kebijakan yang berpotensi buruk dengan kemampuan seperti:

  • Definisi kebijakan disimpan sebagai kode di repositori yang ditinjau dan disetujui
  • Otomatisasi untuk memberikan pengujian dan validasi
  • Peluncuran kebijakan dan remediasi bertahap berbasis cincin pada sumber daya yang ada membantu meminimalkan radius ledakan dari kebijakan yang berpotensi buruk
  • Tugas remediasi memiliki keamanan terintegrasi, dengan pengendalian seperti penghentian tugas remediasi jika lebih dari 90 persen implementasi gagal

Menerapkan observabilitas dan pencatatan log berbasis peran

Untuk mendukung aplikasi dan infrastruktur, Anda memerlukan pengamatan dan pengelogan di seluruh tumpukan Anda.

Cuplikan layar dasbor Grafana memperlihatkan pengamatan dan pengelogan.

Persyaratan berbeda per peran. Misalnya, tim rekayasa dan operasi platform memerlukan dasbor untuk meninjau kesehatan dan kapasitas infrastruktur dengan pemberitahuan yang sesuai. Pengembang memerlukan metrik, log, dan jejak aplikasi untuk memecahkan masalah dan menyesuaikan dasbor yang menunjukkan kesehatan aplikasi dan infrastruktur. Salah satu masalah yang mungkin dihadapi salah satu peran ini adalah kelebihan beban kognitif dari terlalu banyak informasi atau kesenjangan pengetahuan karena kurangnya informasi yang berguna.

Untuk mengatasi tantangan ini, pertimbangkan hal berikut:

  • Standar: Terapkan standar pengelogan untuk mempermudah pembuatan dan penggunaan kembali dasbor standar, dan menyederhanakan pemrosesan penyerapan melalui sesuatu seperti kerangka kerja pengamatan OpenTelemetry.
  • Izin: Berikan dasbor tingkat tim atau aplikasi menggunakan sesuatu seperti Grafana untuk menyediakan data yang digulung bagi siapa saja yang tertarik, bersama dengan fasilitas bagi anggota tepercaya tim aplikasi untuk mendapatkan akses ke log dengan aman saat diperlukan.
  • Retensi: Mempertahankan log dan metrik bisa mahal, dan dapat menciptakan risiko atau pelanggaran kepatuhan yang tidak diinginkan. Tetapkan default retensi dan terbitkan sebagai bagian dari panduan awal yang sesuai.
  • Memantau batas sumber daya: Tim operasi harus dapat mengidentifikasi dan melacak batasan apa pun untuk jenis sumber daya tertentu. Batasan ini harus diperhitungkan ke dalam templat atau kebijakan IaC menggunakan alat seperti Azure Policy. Operasi kemudian harus secara proaktif memantau menggunakan dasbor dalam sesuatu seperti Grafana dan memperluas sumber daya bersama di mana penskalaan otomatis tidak dimungkinkan atau diaktifkan. Misalnya, pantau jumlah node kluster Kubernetes untuk kapasitas saat aplikasi di-onboarding dan dimodifikasi dari waktu ke waktu. Peringatan diperlukan, dan definisi ini harus disimpan sebagai kode sehingga dapat ditambahkan secara terprogram ke sumber daya.
  • Identifikasi kapasitas utama dan metrik kesehatan: Pantau dan beri tahu OS dan sumber daya bersama (misalnya, CPU, memori, dan penyimpanan) agar terhindar dari kelangkaan, dengan pengumpulan metrik yang menggunakan Prometheus atau pemantauan Kubernetes dalam Azure Monitor. Anda dapat memantau soket/port yang digunakan, konsumsi bandwidth jaringan aplikasi yang cerewet, dan jumlah aplikasi stateful yang dihosting di kluster.

Membangun keamanan dengan prinsip hak istimewa paling sedikit, manajemen keamanan terpadu, dan deteksi ancaman

Keamanan diperlukan di setiap lapisan, dari kode, kontainer, kluster, dan cloud/infrastruktur. Ini adalah langkah-langkah keamanan minimum yang direkomendasikan:

  • Ikuti prinsip hak istimewa paling sedikit.
  • Menyatukan manajemen keamanan DevOps Anda di beberapa alur.
  • Pastikan wawasan kontekstual untuk mengidentifikasi dan mengatasi risiko Anda yang paling kritis terlihat.
  • Aktifkan deteksi dan respons terhadap ancaman modern di seluruh beban kerja cloud Anda saat runtime.

Untuk membantu mengatasi masalah di area ini, Anda memerlukan alat untuk mengevaluasi alat yang berfungsi di seluruh sistem, sumber daya, dan layanan teknik dan aplikasi Anda di seluruh cloud dan hibrid (misalnya, Pertahanan Microsoft untuk Cloud). Di luar keamanan aplikasi, evaluasi:

Persyaratan izin dapat berbeda menurut lingkungan. Misalnya, di beberapa organisasi, tim individual tidak diizinkan untuk mengakses sumber daya produksi dan aplikasi baru tidak dapat disebarkan secara otomatis hingga tinjauan selesai. Namun, penyebaran dan akses sumber daya dan aplikasi otomatis ke kluster untuk pemecahan masalah mungkin diizinkan di lingkungan pengembangan dan pengujian.

Mengelola akses identitas ke layanan, aplikasi, infrastruktur dalam skala besar bisa menjadi tantangan. Penyedia identitas membuat, memelihara, dan mengelola informasi identitas. Paket Anda harus menyertakan layanan autentikasi untuk aplikasi dan layanan, dan layanan tersebut harus berintegrasi dengan sistem otorisasi kontrol akses berbasis peran (RBAC) dalam skala besar. Misalnya, Anda dapat menggunakan ID Microsoft Entra untuk memberikan autentikasi dan otorisasi dalam skala besar untuk layanan Azure seperti Azure Kubernetes Service tanpa perlu menyiapkan izin langsung pada setiap kluster individu.

Aplikasi mungkin memerlukan akses ke identitas untuk mengakses sumber daya cloud seperti penyimpanan. Anda perlu meninjau persyaratan sistem dan menilai bagaimana IdP Anda dapat mendukung ini dengan cara paling aman yang mungkin. Misalnya, dalam Azure Kubernetes Service, aplikasi cloud native dapat menggunakan identitas beban kerja yang terhubung dengan Microsoft Entra ID untuk memungkinkan beban kerja kontainer mengautentikasi. Pendekatan ini memungkinkan aplikasi mengakses sumber daya cloud tanpa pertukaran rahasia dalam kode aplikasi.

Mengurangi biaya dengan mengidentifikasi pemilik beban kerja dan melacak sumber daya

Mengelola biaya adalah bagian lain dari rekayasa platform. Untuk mengelola platform aplikasi dengan benar, Anda memerlukan cara untuk mengidentifikasi pemilik beban kerja. Anda ingin cara untuk mendapatkan inventaris sumber daya yang terkait dengan pemilik untuk sekumpulan metadata tertentu. Misalnya, dalam Azure, Anda dapat menggunakan Label AKS, tag Azure Resource Manager, bersama dengan konsep seperti proyek di Lingkungan Penyebaran Azure untuk mengelompokkan sumber daya Anda di tingkat yang berbeda. Agar ini berfungsi, metadata yang dipilih harus menyertakan properti wajib (menggunakan sesuatu seperti Azure Policy) saat menyebarkan beban kerja dan sumber daya. Ini membantu dengan alokasi biaya, pemetaan sumber daya solusi, dan pemilik. Pertimbangkan untuk menjalankan pelaporan rutin untuk melacak sumber daya yang terputus.

Di luar pelacakan, Anda mungkin perlu menetapkan biaya ke tim aplikasi individual untuk penggunaan sumber daya mereka menggunakan metadata yang sama ini dengan sistem manajemen biaya seperti Microsoft Cost Management. Meskipun metode ini melacak sumber daya yang disediakan oleh tim aplikasi, metode ini tidak mencakup biaya sumber daya bersama seperti penyedia identitas Anda, penyimpanan pengelogan dan metrik, dan konsumsi bandwidth jaringan. Untuk sumber daya bersama, Anda dapat membagi biaya operasional secara merata oleh masing-masing tim atau menyediakan sistem khusus (misalnya, penyimpanan pengelogan) di mana ada konsumsi nonuniform. Beberapa jenis sumber daya bersama mungkin dapat memberikan wawasan tentang konsumsi sumber daya. Misalnya, Kubernetes memiliki alat seperti OpenCost atau Kubecost dan dapat membantu.

Anda juga harus mencari alat analisis biaya tempat Anda dapat meninjau pengeluaran saat ini. Misalnya, di portal Microsoft Azure, ada pemberitahuan biaya dan pemberitahuan anggaran yang dapat melacak konsumsi sumber daya dalam grup dan mengirim pemberitahuan saat Anda mencapai ambang batas prasetel.

Memutuskan kapan dan di mana harus berinvestasi

Jika Anda memiliki lebih dari satu platform aplikasi, mungkin sulit untuk memutuskan kapan dan di mana harus berinvestasi dalam perbaikan yang memecahkan masalah seperti biaya tinggi atau pengamatan yang buruk. Jika Anda memulai dari awal, Azure Architecture Center memiliki beberapa pola potensial untuk Anda evaluasi. Tetapi di luar itu, berikut adalah beberapa pertanyaan yang perlu dipertimbangkan saat Anda mulai merencanakan apa yang ingin Anda lakukan:

Pertanyaan Tips
Apakah Anda ingin menyesuaikan platform aplikasi yang ada, memulai dari awal, atau menggunakan kombinasi pendekatan ini? Bahkan jika Anda senang dengan apa yang Anda miliki sekarang atau memulai dari awal, Anda ingin berpikir tentang cara beradaptasi dengan perubahan seiring waktu. Perubahan langsung jarang berhasil. Platform aplikasi Anda adalah target yang bergerak. Sistem ideal Anda berubah seiring waktu berlalu. Anda ingin memasukkan pemikiran yang ada dan rencana migrasi terkait ke dalam desain ke depan Anda.
Jika Anda ingin mengubah apa yang Anda lakukan hari ini, produk, layanan, atau investasi apa yang Anda senangi? Seperti pepatah mengatakan, "jika tidak rusak, jangan perbaiki." Jangan mengubah sesuatu tanpa alasan untuk melakukannya. Namun, jika Anda memiliki solusi yang dikembangkan sendiri, pertimbangkan apakah sudah waktunya untuk beralih ke produk yang sudah ada untuk menghemat pemeliharaan jangka panjang. Misalnya, jika Anda mengoperasikan solusi pemantauan Anda sendiri, apakah Anda ingin menghapus beban tersebut dari tim ops Anda dan bermigrasi ke produk terkelola baru?
Di mana Anda melihat perubahan terbanyak terjadi dari waktu ke waktu? Apakah salah satu dari ini di area yang umum untuk semua (atau sebagian besar) jenis aplikasi organisasi Anda? Area yang Anda atau pelanggan internal Anda tidak puas dan jarang berubah adalah tempat yang baik untuk memulai. Ini memiliki pengembalian investasi terbesar selama jangka panjang. Ini juga dapat membantu Anda memperjelas bagaimana Anda akan memfasilitasi migrasi ke solusi baru. Misalnya, model aplikasi cenderung cairan, tetapi alat analisis log cenderung memiliki umur simpan yang lebih lama. Anda juga dapat fokus pada proyek dan aplikasi baru untuk memulai sementara Anda mengonfirmasi bahwa perubahan arah memiliki pengembalian yang diinginkan.
Apakah Anda berinvestasi dalam solusi kustom di area dengan nilai tambah tertinggi? Apakah Anda merasa kuat bahwa kemampuan platform infrastruktur aplikasi yang unik adalah bagian dari keunggulan kompetitif Anda? Jika Anda telah mengidentifikasi celah, sebelum melakukan sesuatu yang khusus, pertimbangkan area mana yang kemungkinan besar akan mendapatkan investasi dari vendor dan alihkan perhatian untuk solusi khusus Anda ke area lainnya. Mulailah dengan memikirkan diri Anda sebagai integrator daripada infrastruktur aplikasi kustom atau penyedia model aplikasi. Apa pun yang Anda bangun perlu dirawat, yang mana biaya perawatannya dalam jangka panjang jauh lebih besar dibandingkan biaya di muka. Jika Anda merasa kebutuhan mendesak untuk membangun solusi khusus di area yang Anda duga akan dicakup oleh vendor jangka panjang, rencanakan untuk sunsetting atau dukungan jangka panjang. Pelanggan internal Anda biasanya akan sama senangnya (atau bahkan lebih) dengan produk siap pakai dibandingkan dengan produk kustom.

Mengadaptasi investasi platform aplikasi yang ada bisa menjadi cara yang baik untuk melaju. Saat Anda membuat pembaruan, pertimbangkan untuk memulai dengan aplikasi baru untuk menyederhanakan ide pilot sebelum segala jenis peluncuran. Pertimbangkan perubahan ini melalui Infrastructure as Code (IaC) dan templating aplikasi. Berinvestasi dalam solusi kustom untuk kebutuhan unik Anda di area berdampak tinggi dan bernilai tinggi. Jika tidak, cobalah untuk menggunakan solusi siap pakai. Seperti halnya sistem rekayasa, fokus pada mengotomatiskan provisi, pelacakan, dan penyebaran alih-alih berpegang pada satu jalur kaku untuk mempermudah Anda dalam mengelola perubahan seiring waktu.

Konten terkait

  • Last updated on