Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Layanan mandiri dengan pagar pembatas adalah prinsip memberdayakan tim pengembangan untuk membuat keputusan mereka sendiri dalam serangkaian parameter yang terdefinisi dengan baik, atau pagar pembatas. Pagar pembatas didirikan dan disetujui oleh para pemangku kepentingan utama. Pemangku kepentingan dapat mencakup keamanan, operasi, tim arsitektur di seluruh organisasi.
Dengan menggunakan layanan mandiri dengan pagar pembatas, tim pengembangan mempertahankan otonomi untuk membuat keputusan pengembangan secara independen. Otomatisasi dan kebijakan membantu pemangku kepentingan memastikan bahwa keamanan, kepatuhan, operasi, standar, dan biaya dikelola dengan benar. Mengaktifkan otomatisasi ini memerlukan kolaborasi di seluruh lini tim sehingga pengembang, operator, dan spesialis dapat melakukan lebih banyak hal, tanpa mengorbankan tata kelola yang diperlukan. Pengembang kemudian dapat fokus untuk memberikan nilai bisnis secepat mungkin.
[Kami memberi tahu pengembang,] jangan khawatir tentang cara kerjanya, cukup nyalakan atau matikan, isi, masukkan string sesuai kebutuhan Anda dan pada dasarnya bersifat layanan mandiri di mana mereka memiliki file readme serta input dan output, dan mereka dapat memasukkan apa saja yang mereka inginkan. - Daniel, insinyur cloud, perusahaan media Fortune 500
Tujuan memberikan pengalaman layanan mandiri untuk jalur beraspal Anda adalah untuk mengurangi toil pengembang sekaligus memberikan visibilitas kepada tim pengembangan, operasi, dan manajemen. Idenya adalah Anda membuat pengalaman untuk tugas tertentu yang memiliki kurva pembelajaran minimal, berkat kemampuan otomatisasi dan agregasi data yang mendasarnya. Di luar aktivitas seperti penyediaan infrastruktur, pengalaman ini dapat memberikan akses ke kemampuan penting untuk pengamatan, kebijakan, manajemen insiden, dan banyak lagi. Ide ini meluas ke penemuan dan berbagi API internal, SDK, bersama dengan alat dan layanan bersama. Pengalaman ini mengurangi overhead sehingga tim pengembangan dapat fokus pada menyelesaikan berbagai hal.
Platform pengembang internal memberdayakan pengembang untuk bertindak seperti pelanggan etalase digital
Platform pengembang internal menyediakan kemampuan yang mirip dengan etalase digital bisnis ke bisnis. Toko digital dirancang secara inheren untuk membantu pelanggan mereka melayani diri sendiri. Mereka dapat menangani lebih banyak throughput daripada etalase tradisional karena mereka menyediakan cara untuk menemukan dan memenuhi item yang menarik tanpa harus berbicara dengan siapa pun. Dengan menggunakan analogi ini, pengembang adalah pelanggan dan platform pengembang internal memberikan pengalaman layanan mandiri yang serupa. Operator, insinyur platform, dan peran lainnya kemudian menyiapkan katalog item yang dapat diminta pengembang yang dirancang untuk mengakomodasi pagar pembatas organisasi.
Misalnya, Anda dapat memikirkan pengembang yang meminta akses ke alat baru seolah-olah mereka membuat pesanan etalase digital. Seperti pesanan, setelah permintaan dikirimkan, pengembang ingin dapat melacak kemajuan dan mengetahui kapan selesai. Di balik layar, permintaan harus secara otomatis dirutekan ke penyedia pemenuhan yang benar untuk memenuhi kebutuhan. Anda dapat menganggap salah satu sistem integrasi dan pengiriman berkelanjutan (CI/CD) Anda sebagai satu penyedia pemenuhan, alat GitOps , atau platform aplikasi preskriptif sebagai yang kedua, dan alat otomatisasi alur kerja untuk proses manual sebagai yang ketiga. Dalam semua kasus, pengembang dapat melayani sendiri item dari katalog yang ditentukan dengan baik dengan cara yang sama.
Gunakan semuanya sebagai pola kode
Menggunakan infrastruktur sebagai kode (IaC) melalui alur pengiriman berkelanjutan (CD) dan alat GitOps adalah bagian penting untuk mengaktifkan layanan mandiri. IaC dengan CD memungkinkan Anda menggunakan Bicep, Terraform, bagan Helm, dan alat lainnya untuk membuat dan menghancurkan sumber daya cloud sesuai permintaan. Karena konfigurasi infrastruktur cloud Anda dikelola seperti kode di repositori kode sumber, Anda dapat menerapkan semua manfaat repositori git seperti keamanan dan auditabilitas.
Penyediaan infrastruktur dan alat umum bukanlah satu-satunya keuntungan dari pendekatan IaC. Anda dapat menyesuaikan pola IaC untuk skenario lain, termasuk keamanan sebagai kode dan kebijakan sebagai kode (melalui alat seperti Azure Policy dan Open Policy Agent). Mengikuti teknik ini, file konfigurasi, biasanya YAML atau JSON, didorong ke repositori, yang memicu alur kerja yang memproses file. File-file ini mungkin merupakan repositori aplikasi seperti dependabot.yml atau CODEOWNERS, atau file tersebut mungkin dipertahankan di repositori pusat terpisah. Anda bahkan dapat memperluas ini ke dalam skenario Anda sendiri untuk benar-benar membuat semuanya sebagai kode (EaC) menjadi kenyataan.
Pengembang dapat mereferensikan masing-masing templat EaC ini dengan katalog pusat yang mendukung pengalaman layanan mandiri Anda dan mendorong praktik terbaik secara default.
Membuat templat mulai dengan benar dan menetapkan tata kelola yang konsisten
Dalam pengembangan perangkat lunak, kami bertujuan untuk enkapulasi, modularitas, dan komposabilitas saat merancang aplikasi. Anda sebaiknya menerapkan cara berpikir yang sama dalam rekayasa platform melalui penggunaan templat. Misalnya, Anda dapat membuat dan menggunakan sekumpulan templat IaC yang aman dan dapat digunakan kembali secara terpusat sebagai blok penyusun untuk infrastruktur.
Kami akan membangun modul untuk [pengembang] kami... jadi alih-alih harus menulis atau khawatir tentang salah satu back end itu sendiri, yang perlu mereka lakukan adalah khawatir tentang kode aplikasi mereka. - Daniel, insinyur cloud, perusahaan media Fortune 500
Gabungkan templat IaC, EaC, dan aplikasi ke dalam solusi semua sebagai kode (EaC) yang dibuat khusus dan diperluas untuk mencakup aktivitas lain seperti membuat repositori kode sumber, menyemai kode sampel, atau menyediakan konfigurasi dan kode sampel untuk alat observabilitas yang direkomendasikan. Templat iaC, EaC, dan aplikasi ini kemudian dapat disimpan atau direferensikan dari lokasi terpusat dan aman seperti repositori, katalog di Lingkungan Penyebaran Azure, atau Azure Container Registry untuk cloud native.
Saat templat mulai dengan benar dikombinasikan dengan konfigurasi tata kelola, pemindaian, dan kebijakan otomatis, pengembang tetap di jalur yang benar sejak hari pertama.
Templat menyederhanakan pengembangan dengan praktik otomatis dan aman
Gunakan templat aplikasi untuk mem-bootstrap jalur beraspal yang ditentukan untuk beberapa keputusan dan tindakan utama yang diambil pengembang selama proyek. Templat mulai yang tepat menetapkan praktik pengembangan yang aman dan diatur, dan memungkinkan pengembang untuk memulai dengan cepat dengan mengaktifkan otomatisasi yang menyediakan akses ke alat yang mereka butuhkan, mengonfigurasi pipeline CI/CD, menyediakan infrastruktur dan tumpukan aplikasi, serta mengonfigurasi repositori lengkap dengan kode sumber template yang mencakup SDK yang diperlukan atau referensi ke API.
Dengan membuat templat aplikasi ini merujuk kepada templat terpusat lainnya (misalnya, templat IaC), masing-masing blok bangunan individu ini menjadi templat dasar mereka sendiri. Templat ini adalah pusat untuk mengaktifkan pengalaman layanan mandiri karena tidak hanya menentukan output, tetapi juga opsi yang tersedia yang dipilih pengembang.
Templat memastikan tata kelola, keamanan, dan pengoptimalan biaya
Namun, templat harus melakukan lebih dari sekadar memulai usaha pengembangan. Mereka juga harus menetapkan kontrol dan tata kelola dengan memanfaatkan pemindaian terhadap kebijakan dan keamanan yang diperlukan untuk tetap berada pada jalur yang benar selama siklus hidup proyek. Sebagai contoh lain, templat dapat menyiapkan aturan perlindungan cabang yang mencegah penggabungan yang tidak sah ke dalam produksi. Karena templat menangkap praktik terbaik dan konfigurasi umum, templat tersebut adalah salah satu teknik utama untuk mengoptimalkan biaya di seluruh alat, vendor, dan tim.
Jalankan kampanye yang benar untuk membangun komunikasi dua arah
Akhirnya, ketika keyakinan Anda pada jalur beraspal meningkat, Anda dapat menggunakan blok bangunan individual yang mendasar yang Anda rakit ke dalam templat aplikasi Anda untuk memindahkan aplikasi yang ada ke jalur yang diaspal. Karena pelanggan internal Anda sudah akan melihat nilai jalur beraspal yang dipiloti, Anda dapat menjalankan kampanye get right internal untuk membuat dialog dua arah dengan tim aplikasi lain. Pengembang dapat mempelajari cara memigrasikan aplikasi mereka sementara tim teknik platform secara bersamaan mempelajari lebih lanjut tentang cara meningkatkan platform untuk mereka.
Buat bagan perjalanan Anda sendiri
Mengingat luasnya pengalaman yang dapat dicakup oleh kemampuan layanan mandiri Anda, ini adalah fokus penting untuk upaya investasi Anda dan Merencanakan dan memprioritaskan sehingga platform pengembang internal Anda memberikan nilai secara bertahap. Perjalanan setiap organisasi dalam menciptakan platform pengembang internal mereka berbeda, dan mengikuti pola pikir produk membantu Anda menargetkan tempat paling penting yang membutuhkan pengalaman layanan mandiri terlebih dahulu.