Apa itu Cloud Native?

Petunjuk / Saran

Konten ini adalah kutipan dari eBook, Merancang Aplikasi .NET Cloud Native untuk Azure, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Hentikan apa yang Anda lakukan dan minta kolega Anda untuk menentukan istilah "Cloud Native". Ada kemungkinan besar Anda akan mendapatkan beberapa jawaban yang berbeda.

Mari kita mulai dengan definisi sederhana:

Arsitektur dan teknologi cloud-native adalah pendekatan untuk merancang, membangun, dan mengoperasikan beban kerja yang dibangun di cloud dan memanfaatkan sepenuhnya model komputasi cloud.

Cloud Native Computing Foundation memberikan definisi resmi:

Teknologi cloud-native memberdayakan organisasi untuk membangun dan menjalankan aplikasi yang dapat diskalakan di lingkungan modern dan dinamis seperti cloud publik, privat, dan hibrid. Kontainer, jala layanan, layanan mikro, infrastruktur yang tidak dapat diubah, dan API deklaratif mencontohkan pendekatan ini.

Teknik ini memungkinkan sistem yang digabungkan secara longgar yang tangguh, dapat dikelola, dan dapat diamati. Dikombinasikan dengan otomatisasi yang kuat, mereka memungkinkan teknisi untuk sering membuat perubahan berdampak tinggi dan dapat diprediksi dengan toil minimal.

Cloud native adalah tentang kecepatan dan kelincahan. Sistem bisnis berkembang dari memungkinkan kemampuan bisnis hingga senjata transformasi strategis yang mempercepat kecepatan dan pertumbuhan bisnis. Sangat penting untuk segera mendapatkan ide-ide baru ke pasar.

Pada saat yang sama, sistem bisnis juga menjadi semakin kompleks dengan pengguna menuntut lebih banyak. Mereka mengharapkan responsivitas yang cepat, fitur inovatif, dan waktu henti nol. Masalah performa, kesalahan berulang, dan ketidakmampuan untuk bergerak cepat tidak lagi dapat diterima. Pengguna Anda akan mengunjungi pesaing Anda. Sistem cloud-native dirancang untuk merangkul perubahan cepat, skala besar, dan ketahanan.

Berikut adalah beberapa perusahaan yang telah menerapkan teknik cloud-native. Pikirkan tentang kecepatan, kelincahan, dan skalabilitas yang telah mereka capai.

Firma	Pengalaman
Netflix	Memiliki 600+ layanan dalam produksi. Menyebarkan 100 kali per hari.
Uber	Memiliki 1.000+ layanan dalam produksi. Menyebarkan beberapa ribu kali setiap minggu.
WeChat	Memiliki 3.000+ layanan dalam produksi. Menyebarkan 1.000 kali sehari.

Seperti yang kamu lihat, Netflix, Uber, dan, WeChat mengekspos sistem cloud-native yang terdiri dari banyak layanan independen. Gaya arsitektur ini memungkinkan mereka merespons kondisi pasar dengan cepat. Mereka secara instan memperbarui area kecil dari aplikasi langsung yang kompleks, tanpa penyebaran ulang penuh. Mereka menskalakan layanan secara individual sesuai kebutuhan.

Pilar cloud native

Kecepatan dan kelincahan cloud asli berasal dari banyak faktor. Yang paling penting adalah infrastruktur cloud. Tetapi ada lebih banyak: Lima pilar dasar lainnya yang ditunjukkan pada Gambar 1-3 juga menyediakan batuan untuk sistem cloud-native.

Gambar 1-3. Fondasi utama cloud-native

Mari kita luangkan waktu untuk lebih memahami signifikansi setiap pilar.

Cloud

Sistem cloud-native memanfaatkan sepenuhnya model layanan cloud.

Dirancang untuk berkembang dalam lingkungan cloud yang dinamis dan tervirtualisasi, sistem ini memanfaatkan infrastruktur komputasi Platform as a Service (PaaS) dan layanan terkelola yang luas. Mereka memperlakukan infrastruktur yang mendasar sebagai sekali pakai - disediakan dalam hitungan menit dan diubah ukurannya, diskalakan, atau dihancurkan sesuai permintaan – melalui otomatisasi.

Pertimbangkan perbedaan antara bagaimana kita memperlakukan hewan peliharaan dan komoditas. Di pusat data tradisional, server diperlakukan sebagai hewan peliharaan: mesin fisik, diberi nama yang bermakna, dan dirawat. Anda menskalakan dengan menambahkan lebih banyak sumber daya ke komputer yang sama (meningkatkan skala). Jika server mengalami gangguan, Anda memulihkannya. Jika server menjadi tidak tersedia, semua orang menyadarinya.

Model layanan komoditas berbeda. Anda menyediakan setiap instans sebagai komputer virtual atau kontainer. Mereka identik dan diberi pengidentifikasi sistem seperti Service-01, Service-02, dan sebagainya. Anda menskalakan dengan membuat lebih banyak instans (perluasan skala). Tidak ada yang menyadari ketika instans tidak bisa diakses.

Model komoditas merangkul infrastruktur yang tidak dapat diubah. Server tidak diperbaiki atau dimodifikasi. Jika gagal atau memerlukan pembaruan, itu dihancurkan dan yang baru disediakan - semua dilakukan melalui otomatisasi.

Sistem cloud-native merangkul model layanan komoditas. Mereka terus berjalan seiring dengan skalanya infrastruktur yang bertambah atau berkurang, tanpa ketergantungan pada mesin tempat mereka berjalan.

Platform cloud Azure mendukung jenis infrastruktur yang sangat elastis ini dengan kemampuan penskalaan otomatis, penyembuhan diri, dan pemantauan.

Desain modern

Bagaimana Anda mendesain aplikasi cloud-native? Seperti apa arsitektur Anda? Untuk prinsip, pola, dan praktik terbaik apa yang akan Anda patuhi? Masalah infrastruktur dan operasional apa yang akan menjadi penting?

Aplikasi Twelve-Factor

Metodologi yang diterima secara luas untuk membangun aplikasi berbasis cloud adalah AplikasiTwelve-Factor. Ini menjelaskan serangkaian prinsip dan praktik yang diikuti pengembang untuk membangun aplikasi yang dioptimalkan untuk lingkungan cloud modern. Perhatian khusus diberikan pada portabilitas di seluruh lingkungan dan otomatisasi deklaratif.

Meskipun berlaku untuk aplikasi berbasis web apa pun, banyak praktisi mempertimbangkan Twelve-Factor fondasi yang kuat untuk membangun aplikasi cloud-native. Sistem yang dibangun berdasarkan prinsip-prinsip ini dapat menyebarkan dan menskalakan dengan cepat dan menambahkan fitur untuk bereaksi dengan cepat terhadap perubahan pasar.

Tabel berikut menyoroti metodologi Twelve-Factor:

Faktor	Penjelasan
1 - Basis Kode	Satu basis kode untuk setiap layanan mikro, disimpan di repositorinya sendiri. Dilacak dengan kontrol versi, dapat disebarkan ke beberapa lingkungan (QA, Penahapan, Produksi).
2 - Dependensi	Setiap layanan mikro mengisolasi dan mengemas dependensinya sendiri, merangkul perubahan tanpa memengaruhi seluruh sistem.
3 - Konfigurasi	Informasi konfigurasi dipindahkan dari layanan mikro dan di luar melalui alat manajemen konfigurasi di luar kode. Penyebaran yang sama dapat menyebar di seluruh lingkungan dengan konfigurasi yang benar diterapkan.
4 - Layanan Dukungan	Sumber daya tambahan (penyimpanan data, cache, broker pesan) harus diekspos melalui URL yang dapat diatasi. Melakukannya memisahkan sumber daya dari aplikasi, memungkinkannya untuk dapat dipertukarkan.
5 - Bangun, Rilis, Jalankan	Setiap rilis harus memberlakukan pemisahan yang ketat di seluruh tahap build, rilis, dan eksekusi. Masing-masing harus ditandai dengan ID unik dan mendukung kemampuan untuk menggulung balik. Sistem CI/CD modern membantu memenuhi prinsip ini.
6 - Proses	Setiap layanan mikro harus dijalankan dalam prosesnya sendiri, terisolasi dari layanan lain yang sedang berjalan. Eksternalisasi status yang diperlukan ke layanan pencadangan seperti cache terdistribusi atau penyimpanan data.
7 - Pengikatan Port	Setiap layanan mikro harus mandiri dengan antarmuka dan fungsionalitasnya yang terekspos pada portnya sendiri. Melakukannya memberikan isolasi dari layanan mikro lainnya.
8 - Konkurensi	Ketika kapasitas perlu meningkat, skalakan layanan secara horizontal di beberapa proses (salinan) yang identik dibandingkan dengan peningkatan skala satu instans besar pada komputer paling kuat yang tersedia. Kembangkan aplikasi untuk melakukan penskalaan secara bersamaan di lingkungan cloud dengan mulus.
9 - Kebisagunaan Sekali Pakai	Instans layanan harus sekali pakai. Mendukung startup cepat untuk meningkatkan peluang skalabilitas dan pematian yang anggun untuk meninggalkan sistem dalam keadaan yang benar. Kontainer Docker bersama dengan orkestrator secara inheren memenuhi persyaratan ini.
10 - Paritas Dev/Prod	Jaga lingkungan di seluruh siklus hidup aplikasi sesama mungkin, menghindari pintasan yang mahal. Di sini, adopsi kontainer dapat sangat berkontribusi dengan mempromosikan lingkungan eksekusi yang sama.
11 - Pengelogan	Perlakukan log yang dihasilkan oleh layanan mikro sebagai aliran peristiwa. Memprosesnya dengan agregator peristiwa. Sebarkan data log ke alat manajemen penambangan/log data seperti Azure Monitor atau Splunk dan akhirnya ke arsip jangka panjang.
12 - Proses Admin	Jalankan tugas administratif/manajemen, seperti pembersihan data atau analitik komputasi, sebagai proses satu kali. Gunakan alat independen untuk memanggil tugas-tugas ini dari lingkungan produksi, tetapi secara terpisah dari aplikasi.

Dalam buku, Beyond the Twelve-Factor App, penulis Kevin Hoffman merinci masing-masing dari 12 faktor asli (ditulis pada 2011). Selain itu, ia membahas tiga faktor tambahan yang mencerminkan desain aplikasi cloud modern saat ini.

Faktor Baru	Penjelasan
13 - API Pertama	Membuat semuanya menjadi layanan. Asumsikan kode Anda akan digunakan oleh klien front-end, gateway, atau layanan lain.
14 - Telemetri	Di stasiun kerja, Anda memiliki visibilitas mendalam ke dalam aplikasi Anda dan perilakunya. Di cloud, Anda tidak. Pastikan desain Anda mencakup pengumpulan data pemantauan, khusus domain, dan kesehatan/sistem.
15 - Autentikasi/Otorisasi	Terapkan identitas sejak awal. Pertimbangkan fitur RBAC (kontrol akses berbasis peran) yang tersedia di cloud publik.

Kita akan merujuk ke banyak dari 12+ faktor dalam bab ini dan di seluruh buku.

Azure Well-Architected Framework (Kerangka Kerja Terencana Azure)

Merancang dan menyebarkan beban kerja berbasis cloud dapat menjadi tantangan, terutama saat menerapkan arsitektur cloud-native. Microsoft menyediakan praktik terbaik standar industri untuk membantu Anda dan tim Anda memberikan solusi cloud yang kuat.

Microsoft Well-Architected Framework menyediakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja cloud-native. Kerangka kerja ini terdiri dari lima pilar keunggulan arsitektur:

Ajaran	Deskripsi
Manajemen biaya	Fokus pada menghasilkan nilai inkremental lebih awal. Terapkan prinsip Build-Measure-Learn untuk mempercepat waktu ke pasar sambil menghindari solusi padat modal. Menggunakan strategi bayar sesuai pemakaian, investasikan saat Anda meluaskan skala, daripada memberikan investasi besar di muka.
keunggulan operasional	Mengotomatiskan lingkungan dan operasi untuk meningkatkan kecepatan dan mengurangi kesalahan manusia. Gulung balik atau teruskan pembaruan masalah dengan cepat. Terapkan pemantauan dan diagnostik sejak awal.
Efisiensi performa	Memenuhi permintaan yang ditempatkan pada beban kerja Anda secara efisien. Mendukung penskalakan horizontal (meluaskan skala) dan merancangnya ke dalam sistem Anda. Terus melakukan pengujian performa dan beban untuk mengidentifikasi potensi hambatan.
Keandalan	Bangun beban kerja yang tangguh dan tersedia. Ketahanan memungkinkan beban kerja pulih dari kegagalan dan terus berfungsi. Ketersediaan memastikan pengguna mengakses beban kerja Anda setiap saat. Merancang aplikasi untuk mengharapkan kegagalan dan pulih darinya.
Keamanan	Terapkan keamanan di seluruh siklus hidup aplikasi, dari desain dan implementasi hingga penyebaran dan operasi. Perhatikan pengelolaan identitas, akses infrastruktur, keamanan aplikasi, serta kedaulatan dan enkripsi data.

Untuk memulai, Microsoft menyediakan serangkaian penilaian online untuk membantu Anda menilai beban kerja cloud Anda saat ini terhadap lima pilar yang dirancang dengan baik.

Layanan mikro

Sistem cloud-native merangkul layanan mikro, gaya arsitektur populer untuk membangun aplikasi modern.

Dibangun sebagai sekumpulan layanan kecil dan independen terdistribusi yang berinteraksi melalui fabric bersama, layanan mikro berbagi karakteristik berikut:

• Masing-masing mengimplementasikan kemampuan bisnis tertentu dalam konteks domain yang lebih besar.

• Masing-masing dikembangkan secara otonom dan dapat disebarkan secara independen.

• Masing-masing mandiri merangkum teknologi penyimpanan data, dependensi, dan platform pemrogramannya sendiri.

• Masing-masing berjalan dalam prosesnya sendiri dan berkomunikasi dengan orang lain menggunakan protokol komunikasi standar seperti HTTP/HTTPS, gRPC, WebSocket, atau AMQP.

• Mereka menyusun bersama-sama untuk membentuk aplikasi.

Gambar 1-4 membedakan pendekatan aplikasi monolitik dengan pendekatan layanan mikro. Perhatikan bagaimana monolit terdiri dari arsitektur berlapis, yang dijalankan dalam satu proses. Biasanya menggunakan database relasional. Pendekatan layanan mikro, bagaimanapun, memisahkan fungsionalitas menjadi layanan independen, masing-masing dengan logika, status, dan datanya sendiri. Setiap layanan mikro menghosting datastore-nya sendiri.

Gambar 1-4. Arsitektur monolitik versus layanan mikro

Perhatikan bagaimana layanan mikro mempromosikan prinsip Proses dari AplikasiTwelve-Factor, yang dibahas sebelumnya dalam bab.

Faktor #6 menentukan "Setiap layanan mikro harus dijalankan dalam prosesnya sendiri, terisolasi dari layanan lain yang sedang berjalan."

Mengapa layanan mikro?

Layanan mikro memberikan kelincahan.

Sebelumnya dalam bab, kami membandingkan aplikasi eCommerce yang dibangun sebagai monolit dengan itu dengan layanan mikro. Dalam contoh, kami melihat beberapa manfaat yang jelas:

• Setiap layanan mikro memiliki siklus hidup otonom dan dapat berkembang secara independen dan sering disebarkan. Anda tidak perlu menunggu rilis triwulanan untuk menyebarkan fitur atau pembaruan baru. Anda dapat memperbarui area kecil aplikasi langsung dengan lebih sedikit risiko mengganggu seluruh sistem. Pembaruan dapat dilakukan tanpa penyebaran ulang penuh aplikasi.

• Setiap layanan mikro dapat menskalakan secara independen. Alih-alih menskalakan seluruh aplikasi sebagai satu unit, Anda hanya memperluas skala layanan yang memerlukan lebih banyak daya pemrosesan untuk memenuhi tingkat performa dan perjanjian tingkat layanan yang diinginkan. Penskalaan terperinci memberikan kontrol yang lebih besar terhadap sistem Anda dan membantu mengurangi biaya keseluruhan saat Anda menskalakan bagian dari sistem Anda, bukan semuanya.

Panduan referensi yang sangat baik untuk memahami layanan mikro adalah Layanan Mikro .NET: Arsitektur untuk Aplikasi .NET Dalam Kontainer. Buku ini mendalami desain dan arsitektur layanan mikro. Ini adalah pendamping untuk arsitektur referensi layanan mikro tumpukan penuh yang tersedia sebagai unduhan gratis dari Microsoft.

Mengembangkan layanan mikro

Layanan mikro dapat dibuat pada platform pengembangan modern apa pun.

Platform Microsoft .NET adalah pilihan yang sangat baik. Gratis dan sumber terbuka, memiliki banyak fitur bawaan yang menyederhanakan pengembangan layanan mikro. .NET adalah lintas platform. Aplikasi dapat dibangun dan dijalankan di Windows, macOS, dan sebagian besar rasa Linux.

.NET sangat berkinerja tinggi dan telah mencetak skor yang baik dibandingkan dengan Node.js dan platform pesaing lainnya. Menariknya, TechEmpower melakukan serangkaian tolok ukur performa yang luas di banyak platform dan kerangka kerja aplikasi web. .NET mencetak skor di 10 teratas - di atas Node.js dan platform pesaing lainnya.

.NET dikelola oleh Microsoft dan komunitas .NET di GitHub.

Tantangan layanan mikro

Meskipun layanan mikro cloud-native terdistribusi dapat memberikan kelincahan dan kecepatan yang sangat besar, mereka menghadirkan banyak tantangan:

Komunikasi

Bagaimana aplikasi klien front-end akan berkomunikasi dengan layanan mikro inti backed-end? Apakah Anda mengizinkan komunikasi langsung? Atau, mungkin Anda mengabstraksi layanan mikro back-end dengan fasad gateway yang memberikan fleksibilitas, kontrol, dan keamanan?

Bagaimana layanan mikro inti back-end akan berkomunikasi satu sama lain? Apakah Anda akan mengizinkan panggilan HTTP langsung yang dapat meningkatkan kopling dan memengaruhi performa dan kelincahan? Atau mungkin Anda mempertimbangkan pesan yang dipisahkan dengan antrean dan teknologi topik?

Komunikasi tercakup dalam bab pola komunikasi cloud-native .

Ketahanan

Arsitektur layanan mikro memindahkan sistem Anda dari komunikasi jaringan dalam proses ke di luar proses. Dalam arsitektur terdistribusi, apa yang terjadi ketika Layanan B tidak merespons panggilan jaringan dari Layanan A? Atau, apa yang terjadi ketika Layanan C menjadi tidak tersedia untuk sementara waktu dan layanan lain yang memanggilnya menjadi diblokir?

Ketahanan tercakup dalam bab ketahanan cloud-native .

Data Terdistribusi

Secara desain, setiap layanan mikro merangkum datanya sendiri, mengekspos operasi melalui antarmuka publiknya. Jika demikian, bagaimana Anda mengkueri data atau menerapkan transaksi di beberapa layanan?

Data terdistribusi tercakup dalam bab pola data cloud-native .

Rahasia

Bagaimana layanan mikro Anda akan menyimpan dan mengelola rahasia dan data konfigurasi sensitif dengan aman?

Rahasia dibahas secara rinci Keamanan cloud-asli.

Mengelola Kompleksitas dengan Dapr

Dapr adalah runtime aplikasi sumber terbuka terdistribusi. Melalui arsitektur komponen yang dapat dicolokkan, secara dramatis menyederhanakan pipa di balik aplikasi terdistribusi. Ini menyediakan lem dinamis yang mengikat aplikasi Anda dengan kemampuan dan komponen infrastruktur bawaan dari runtime Dapr. Gambar 1-5 menunjukkan Dapr dari 20.000 kaki.

Gambar 1-5. Dapr di ketinggian 20.000 kaki.

Di baris atas gambar, perhatikan bagaimana Dapr menyediakan SDK khusus bahasa untuk platform pengembangan populer. Dapr v1 mencakup dukungan untuk .NET, Go, Node.js, Python, PHP, Java, dan JavaScript.

Meskipun SDK khusus bahasa meningkatkan pengalaman pengembang, Dapr adalah agnostik platform. Di bawah tenda, model pemrograman Dapr mengekspos kemampuan melalui protokol komunikasi HTTP/gRPC standar. Platform pemrograman apa pun dapat memanggil Dapr melalui API HTTP dan gRPC aslinya.

Kotak biru di tengah gambar mewakili blok penyusun Dapr. Setiap mengekspos kode pipa bawaan untuk kemampuan aplikasi terdistribusi yang dapat digunakan aplikasi Anda.

Baris komponen mewakili sekumpulan besar komponen infrastruktur yang telah ditentukan sebelumnya yang dapat digunakan aplikasi Anda. Anggap komponen sebagai kode infrastruktur yang tidak perlu Anda tulis.

Baris bawah menyoroti portabilitas Dapr dan lingkungan yang beragam di mana ia dapat berjalan.

Ke depannya, Dapr berpotensi memiliki dampak mendalam pada pengembangan aplikasi cloud-native.

Kontainer

Wajar jika mendengar istilah kontainer yang disebutkan dalam percakapan asli cloud apa pun. Dalam buku, Cloud Native Patterns, penulis Cornelia Davis mengamati bahwa, "Kontainer adalah pengaktif perangkat lunak cloud-native yang hebat." Cloud Native Computing Foundation menempatkan kontainerisasi layanan mikro sebagai langkah pertama dalam Cloud-Native Trail Map mereka - panduan untuk perusahaan yang memulai perjalanan cloud-native mereka.

Kontainerisasi layanan mikro sederhana dan mudah. Kode, dependensinya, dan runtime dipaketkan ke dalam biner yang disebut gambar kontainer. Gambar disimpan dalam registri kontainer, yang bertindak sebagai repositori atau pustaka untuk gambar. Registri dapat ditemukan di komputer pengembangan Anda, di pusat data Anda, atau di cloud publik. Docker sendiri mempertahankan registri publik melalui Docker Hub. Cloud Azure menampilkan registri kontainer privat untuk menyimpan gambar kontainer yang dekat dengan aplikasi cloud yang akan menjalankannya.

Saat aplikasi dimulai atau diskalakan, Anda mengubah gambar kontainer menjadi instans kontainer yang sedang berjalan. Instans berjalan di komputer apa pun yang memiliki mesin runtime kontainer yang terinstal. Anda dapat memiliki sebanyak mungkin instans layanan kontainer sesuai kebutuhan.

Gambar 1-6 menunjukkan tiga layanan mikro yang berbeda, masing-masing dalam kontainernya sendiri, semuanya berjalan pada satu host.

Gambar 1-6. Beberapa kontainer yang berjalan pada host kontainer

Perhatikan bagaimana setiap kontainer mempertahankan serangkaian dependensi dan runtimenya sendiri, yang dapat berbeda satu sama lain. Di sini, kita melihat berbagai versi layanan mikro Produk yang berjalan pada host yang sama. Setiap kontainer berbagi ikatan sistem operasi host, memori, dan prosesor yang mendasar, tetapi terisolasi satu sama lain.

Perhatikan seberapa baik model kontainer merangkul prinsip Dependensi dari AplikasiTwelve-Factor.

Faktor #2 menentukan bahwa "Setiap layanan mikro mengisolasi dan mengemas dependensinya sendiri, merangkul perubahan tanpa memengaruhi seluruh sistem."

Kontainer mendukung beban kerja Linux dan Windows. Cloud Azure secara terbuka merangkul keduanya. Menariknya, itu Linux, bukan Windows Server, yang telah menjadi sistem operasi yang lebih populer di Azure.

Sementara beberapa vendor kontainer ada, Docker telah mengambil pangsa pasar singa. Perusahaan telah mendorong pergerakan kontainer perangkat lunak. Ini telah menjadi standar de facto untuk pengemasan, penyebaran, dan menjalankan aplikasi cloud-native.

Mengapa kontainer?

Kontainer memberikan portabilitas dan menjamin konsistensi di seluruh lingkungan. Dengan merangkum semuanya ke dalam satu paket, Anda mengisolasi layanan mikro dan dependensinya dari infrastruktur yang mendasarinya.

Anda dapat menyebarkan kontainer di lingkungan apa pun yang menghosting mesin runtime Docker. Beban kerja kontainer juga menghilangkan biaya pra-konfigurasi setiap lingkungan dengan kerangka kerja, pustaka perangkat lunak, dan mesin runtime.

Dengan berbagi sistem operasi dan sumber daya host yang mendasar, kontainer memiliki jejak yang jauh lebih kecil daripada komputer virtual penuh. Ukuran yang lebih kecil meningkatkan kepadatan, atau jumlah layanan mikro, bahwa host tertentu dapat berjalan pada satu waktu.

Orkestrasi wadah

Meskipun alat seperti Docker membuat gambar dan menjalankan kontainer, Anda juga memerlukan alat untuk mengelolanya. Manajemen kontainer dilakukan dengan program perangkat lunak khusus yang disebut orkestrator kontainer. Saat beroperasi dalam skala besar dengan banyak kontainer yang berjalan independen, orkestrasi sangat penting.

Gambar 1-7 menunjukkan tugas manajemen yang diotomatiskan orkestrator kontainer.

Gambar 1-7. Apa yang dilakukan orkestrator kontainer

Tabel berikut ini menjelaskan tugas orkestrasi umum.

Tugas	Penjelasan
Penjadwalan	Provisikan instans kontainer secara otomatis.
Afinitas/anti-afinitas	Menyediakan kontainer di dekatnya atau jauh dari satu sama lain, membantu ketersediaan dan performa.
Pemantauan kesehatan	Mendeteksi dan memperbaiki kegagalan secara otomatis.
Pengalihan Cadangan	Provisi ulang instans yang gagal secara otomatis ke komputer yang sehat.
Skalabilitas	Tambahkan atau hapus instans kontainer secara otomatis untuk memenuhi permintaan.
Jaringan	Mengelola overlay jaringan untuk komunikasi kontainer.
Penemuan Layanan	Aktifkan kontainer untuk menemukan satu sama lain.
Peningkatan Bergulir	Koordinasikan peningkatan inkremental dengan penyebaran waktu henti nol. Secara otomatis mengembalikan perubahan bermasalah.

Perhatikan bagaimana orkestrator kontainer merangkul prinsip Disposability dan Concurrency dari AplikasiTwelve-Factor.

Faktor #9 menentukan bahwa "Instans layanan harus sekali pakai, mendukung startup cepat untuk meningkatkan peluang skalabilitas dan pematian yang anggun untuk meninggalkan sistem dalam keadaan yang benar." Kontainer Docker bersama dengan orkestrator secara inheren memenuhi persyaratan ini."

Faktor #8 menentukan bahwa "Layanan meluaskan skala di sejumlah besar proses identik kecil (salinan) dibandingkan dengan meningkatkan skala satu instans besar pada komputer paling kuat yang tersedia."

Meskipun ada beberapa orkestrator kontainer, Kubernetes telah menjadi standar de facto untuk dunia cloud-native. Ini adalah platform portabel, dapat diperluas, sumber terbuka untuk mengelola beban kerja kontainer.

Anda dapat menghosting instans Kubernetes Anda sendiri, tetapi kemudian Anda akan bertanggung jawab untuk menyediakan dan mengelola sumber dayanya - yang bisa rumit. Cloud Azure menampilkan Kubernetes sebagai layanan terkelola. Azure Kubernetes Service (AKS) dan Azure Red Hat OpenShift (ARO) memungkinkan Anda untuk sepenuhnya memanfaatkan fitur dan kekuatan Kubernetes sebagai layanan terkelola, tanpa harus menginstal dan memeliharanya.

Orkestrasi kontainer tercakup secara rinci dalam Penskalhan aplikasi Cloud-Native.

Layanan backing

Sistem cloud-native bergantung pada banyak sumber daya tambahan yang berbeda, seperti penyimpanan data, broker pesan, pemantauan, dan layanan identitas. Layanan ini dikenal sebagai layanan dukungan.

Gambar 1-8 menunjukkan banyak layanan dukungan umum yang dikonsumsi sistem cloud-native.

Gambar 1-8. Layanan dukungan umum

Anda dapat menghosting layanan dukungan Anda sendiri, tetapi kemudian Anda akan bertanggung jawab atas lisensi, provisi, dan pengelolaan sumber daya tersebut.

Penyedia cloud menawarkan berbagai macam layanan dukungan terkelola. Alih-alih memiliki layanan, Anda cukup mengonsumsinya. Penyedia cloud mengoperasikan sumber daya dalam skala besar dan bertanggung jawab atas performa, keamanan, dan pemeliharaan. Pemantauan, redundansi, dan ketersediaan dibangun ke dalam layanan. Penyedia menjamin performa tingkat layanan dan sepenuhnya mendukung layanan terkelola mereka - buka tiket dan mereka memperbaiki masalah Anda.

Sistem cloud-native mendukung layanan dukungan terkelola dari vendor cloud. Penghematan waktu dan tenaga kerja bisa signifikan. Risiko operasional hosting Anda sendiri dan mengalami masalah bisa menjadi mahal dengan cepat.

Praktik terbaik adalah memperlakukan layanan dukungan sebagai sumber daya terlampir, secara dinamis terikat ke layanan mikro dengan informasi konfigurasi (URL dan kredensial) yang disimpan dalam konfigurasi eksternal. Panduan ini dieja dalam AplikasiTwelve-Factor, yang dibahas sebelumnya dalam bab.

Faktor #4 menentukan bahwa layanan pendukung "harus diekspos melalui URL yang dapat diatasi. Melakukannya memisahkan sumber daya dari aplikasi, memungkinkannya untuk dapat dipertukarkan."

Faktor #3 menentukan bahwa "Informasi konfigurasi dipindahkan dari layanan mikro dan di luar melalui alat manajemen konfigurasi di luar kode."

Dengan pola ini, layanan pendukung dapat dilampirkan dan dilepas tanpa perubahan kode. Anda dapat mempromosikan layanan mikro dari QA ke lingkungan penahapan. Anda memperbarui konfigurasi layanan mikro untuk menunjuk ke layanan dukungan dalam penahapan dan menyuntikkan pengaturan ke dalam kontainer Anda melalui variabel lingkungan.

Vendor cloud menyediakan API bagi Anda untuk berkomunikasi dengan layanan dukungan eksklusif mereka. Pustaka ini merangkum pipa dan kompleksitas kepemilikan. Namun, berkomunikasi langsung dengan API ini akan menggabungkan kode Anda dengan erat ke layanan pencadangan tertentu. Ini adalah praktik yang diterima secara luas untuk mengisolasi detail implementasi API vendor. Perkenalkan lapisan perantara, atau API perantara, yang mengekspos operasi generik ke kode layanan Anda dan membungkus kode vendor di dalamnya. Kopling longgar ini memungkinkan Anda menukar satu layanan pendukung untuk layanan lain atau memindahkan kode Anda ke lingkungan cloud yang berbeda tanpa harus membuat perubahan pada kode layanan utama. Dapr, yang dibahas sebelumnya, mengikuti model ini dengan serangkaian blok bangunan bawaannya.

Pada pemikiran akhir, layanan dukungan juga mempromosikan prinsip Statelessness dari AplikasiTwelve-Factor, yang dibahas sebelumnya dalam bab.

Faktor #6 menentukan bahwa, "Setiap layanan mikro harus dijalankan dalam prosesnya sendiri, terisolasi dari layanan lain yang sedang berjalan. Eksternalisasi status yang diperlukan ke layanan pencadangan seperti cache terdistribusi atau penyimpanan data."

Layanan dukungan dibahas dalam pola data cloud-native dan pola komunikasi cloud-native.

Otomatisasi

Seperti yang telah Anda lihat, sistem cloud-native merangkul layanan mikro, kontainer, dan desain sistem modern untuk mencapai kecepatan dan kelincahan. Tapi, itu hanya bagian dari cerita. Bagaimana Anda menyediakan lingkungan cloud tempat sistem ini berjalan? Bagaimana Anda menyebarkan fitur dan pembaruan aplikasi dengan cepat? Bagaimana anda membulatkan gambaran lengkap?

Masukkan praktik Infrastruktur sebagai Kode yang diterima secara luas, atau IaC.

Dengan IaC, Anda mengotomatiskan provisi platform dan penyebaran aplikasi. Anda pada dasarnya menerapkan praktik rekayasa perangkat lunak seperti pengujian dan penerapan versi ke praktik DevOps Anda. Infrastruktur dan penyebaran Anda otomatis, konsisten, dan dapat diulang.

Mengotomatiskan infrastruktur

Alat seperti Azure Resource Manager, Azure Bicep, Terraform dari HashiCorp, dan Azure CLI, memungkinkan Anda untuk secara deklaratif membuat skrip infrastruktur cloud yang Anda butuhkan. Nama sumber daya, lokasi, kapasitas, dan rahasia diparameterkan dan dinamis. Skrip diberi versi dan diperiksa ke kontrol sumber sebagai artefak proyek Anda. Anda memanggil skrip untuk menyediakan infrastruktur yang konsisten dan dapat diulang di seluruh lingkungan sistem, seperti QA, penahapan, dan produksi.

Di bawah tenda, IaC idempogen, yang berarti Bahwa Anda dapat menjalankan skrip yang sama berulang-ulang tanpa efek samping. Jika tim perlu membuat perubahan, mereka mengedit dan menjalankan ulang skrip. Hanya sumber daya yang diperbarui yang terpengaruh.

Dalam artikel, Apa itu Infrastruktur sebagai Kode, Penulis Sam Guckenheimer menjelaskan caranya, "Teams yang menerapkan IaC dapat memberikan lingkungan yang stabil dengan cepat dan dalam skala besar. Mereka menghindari konfigurasi lingkungan manual dan memberlakukan konsistensi dengan mewakili status lingkungan yang diinginkan melalui kode. Penyebaran infrastruktur dengan IaC dapat diulang dan mencegah masalah runtime yang disebabkan oleh penyimpangan konfigurasi atau dependensi yang hilang. Tim DevOps dapat bekerja sama dengan serangkaian praktik dan alat terpadu untuk mengirimkan aplikasi dan infrastruktur pendukungnya dengan cepat, andal, dan dalam skala besar."

Mengotomatiskan penyebaran

AplikasiTwelve-Factor, yang dibahas sebelumnya, memanggil langkah-langkah terpisah saat mengubah kode yang diselesaikan menjadi aplikasi yang sedang berjalan.

Faktor #5 menentukan bahwa "Setiap rilis harus memberlakukan pemisahan yang ketat di seluruh tahap build, rilis, dan eksekusi. Masing-masing harus ditandai dengan ID unik dan mendukung kemampuan untuk menggulung balik."

Sistem CI/CD modern membantu memenuhi prinsip ini. Mereka menyediakan langkah-langkah build dan pengiriman terpisah yang membantu memastikan kode yang konsisten dan berkualitas yang tersedia untuk pengguna.

Gambar 1-9 menunjukkan pemisahan di seluruh proses penyebaran.

Gambar 1-9. Langkah-langkah penyebaran dalam Alur CI/CD

Pada gambar sebelumnya, beri perhatian khusus pada pemisahan tugas:

1. Pengembang membuat fitur di lingkungan pengembangan mereka, melakukan iterasi melalui apa yang disebut "perulangan dalam" kode, eksekusi, dan debug.
2. Setelah selesai, kode tersebut didorong ke repositori kode, seperti GitHub, Azure DevOps, atau BitBucket.
3. Pendorongan memicu tahap build yang mengubah kode menjadi artefak biner. Pekerjaan diimplementasikan dengan alur Integrasi Berkelanjutan (CI ). Ini secara otomatis membangun, menguji, dan mengemas aplikasi.
4. Tahap rilis mengambil artefak biner, menerapkan aplikasi eksternal dan informasi konfigurasi lingkungan, dan menghasilkan rilis yang tidak dapat diubah. Rilis disebarkan ke lingkungan tertentu. Pekerjaan diimplementasikan dengan alur Pengiriman Berkelanjutan (CD ). Setiap rilis harus dapat diidentifikasi. Anda dapat mengatakan, "Penyebaran ini menjalankan Rilis 2.1.1 aplikasi."
5. Terakhir, fitur yang dirilis dijalankan di lingkungan eksekusi yang ditargetkan. Rilis tidak dapat diubah yang berarti bahwa setiap perubahan harus membuat rilis baru.

Menerapkan praktik ini, organisasi telah secara radikal berevolusi bagaimana mereka mengirim perangkat lunak. Banyak yang telah berpindah dari rilis triwulanan ke pembaruan sesuai permintaan. Tujuannya adalah untuk menangkap masalah di awal siklus pengembangan ketika mereka kurang mahal untuk diperbaiki. Semakin lama durasi antara integrasi, semakin mahal masalah yang harus diselesaikan. Dengan konsistensi dalam proses integrasi, tim dapat melakukan perubahan kode lebih sering, yang mengarah ke kolaborasi dan kualitas perangkat lunak yang lebih baik.

Infrastruktur sebagai kode dan otomatisasi penyebaran, bersama dengan GitHub dan Azure DevOps dibahas secara rinci di DevOps.

SebelumnyaBerikutnya