Investasi Cloud Native – beragampengetahuan

 – Beragampengetahuan
6 mins read

Investasi Cloud Native – beragampengetahuan – Beragampengetahuan

Artikel ini adalah Bagian 2 dari seri Ampere Computing Accelerated Cloud. Anda dapat membaca Bagian 1 di sini.

Memanfaatkan platform komputasi cloud-native Ampere membutuhkan waktu dan upaya yang jauh lebih sedikit daripada yang diperkirakan. Ini karena sebagian besar pekerjaan penerapan ulang aplikasi ke server berbasis Arm sudah dilakukan untuk Anda, atau hanya dikompilasi ulang.

Singkatnya, karena prosesor cloud-native Ampere menggunakan arsitektur set instruksi Arm (ISA), perangkat lunak yang berjalan di Arm juga dapat berjalan di Ampere. Dukungan komunitas open source untuk Arm telah tumbuh secara eksponensial selama lima tahun terakhir, menghadirkan beragam perangkat lunak dan layanan baru. Misalnya, aplikasi seperti Redis, NGINX, Memcached, MySQL, dan Cassandra sudah terbukti tersedia versi berbasis ARM.

Artinya bagi pengembang: Sebagian besar perusahaan perangkat lunak yang digunakan sudah berjalan di cloud, atau mungkin sudah berbasis cloud.

sistem operasi (OS): Hampir semua sistem operasi yang tersedia telah diporting ke Arm ISA dan dijalankan pada inti berbasis Arm. Akibatnya, prosesor cloud-native Ampere mendukung versi rilis dari sistem operasi utama yang digunakan di cloud.

Untuk lebih menjamin keandalan dan kinerja, Ampere menguji dan memvalidasi gambar publik dari sistem operasi dan aplikasi yang dikemas sebelumnya pada prosesor cloud-native Ampere. Dengan cara ini, pengembang dapat yakin bahwa aplikasi mereka akan berjalan mulus di Ampere.

kode yang dikemas sebelumnya: Biasanya, sebagian besar aplikasi dibangun menggunakan komponen aplikasi yang dikemas sebelumnya. Gambar publik berbasis lengan untuk sebagian besar aplikasi ini—termasuk MYSQL, PostgreSQL, Cassandra, NGINX, dan Squid—telah diuji dan divalidasi pada prosesor cloud-native Ampere. Oleh karena itu, mempersiapkan bagian aplikasi ini untuk platform komputasi cloud-native relatif sederhana: cukup gunakan gambar berbasis Arm yang sudah ada. Tidak diperlukan porting atau penulisan ulang perangkat lunak yang rumit.

bahasa yang dikompilasi: Secara umum, sebagian besar masalah kritis terkait penerapan ulang server web berasal dari kode yang perlu dikompilasi agar berjalan di Ampere. Untuk kode yang ditulis dalam bahasa seperti Go, C, dan C++, proses redeployment memerlukan langkah ekstra karena binari yang ada dibuat untuk lingkungan x86. Karena sebagian besar bahasa pemrograman tersedia di Arm dan x86, sebagian besar masalah pemindahan hanya melibatkan menjalankan skrip build pada node build Ampere untuk menghasilkan binari yang benar.

Di rumah / adat: Aplikasi khusus dapat dibagi menjadi empat jenis: ditafsirkan, tingkat tinggi, biner, dan khusus perangkat keras.

  • Kode yang ditafsirkan: Kode yang ditulis dalam bahasa interpretasi yang tidak dikompilasi seperti Java atau Python dapat dengan mudah digunakan kembali di platform cloud-native. Karena kode diinterpretasikan, kode dapat berjalan di platform cloud-native computing tanpa perubahan kode. Sebagai gantinya, kode berjalan pada juru bahasa yang dikompilasi untuk Arm daripada x86. Secara umum, men-deploy ulang juru bahasa untuk prosesor cloud-native adalah proses sederhana yang dapat dilakukan dalam hitungan menit jika image belum tersedia.
  • Kode tingkat tinggi: Juga relatif mudah untuk menyiapkan kode yang ditulis dalam bahasa tingkat tinggi (seperti C/C++) untuk platform cloud-native. Dalam banyak kasus, aplikasi hanya perlu dikompilasi ulang untuk Arm ISA. Biasanya ini dapat dikelola hanya dengan mengkonfigurasi ulang kompiler untuk Arm, bukan x86. Jika ada peringatan atau kesalahan yang muncul selama kompilasi, biasanya merupakan proses sederhana untuk menyelesaikannya atau mengonfirmasi bahwa bukan itu masalahnya.
  • Binari: Untuk banyak aplikasi, masalah pemindahan yang paling umum yang muncul adalah penggunaan binari. Binari adalah kode (biasanya pustaka) yang disertakan dalam aplikasi. Ini dapat mencakup produk yang hanya tersedia dalam bentuk biner dan merupakan dependensi aplikasi Anda. Cukup periksa dependensi apa yang dimiliki kode Anda dan pastikan binari yang Anda gunakan berbasis Arm dan bukan berbasis x86 sebelum membangun aplikasi Anda.
  • Kode khusus perangkat keras: Kode yang ditulis untuk prosesor tertentu, atau yang menggunakan fitur prosesor tertentu untuk tujuan kinerja, seperti pustaka grafik, mungkin memerlukan porting terbatas. Ini hanya terjadi jika tidak ada versi khusus Arm yang tersedia. Terlepas dari itu, proses porting biasanya langsung dan memakan waktu paling lama beberapa jam.

Contents

pemindahan dunia nyata

Mari kita lihat apa yang diperlukan untuk men-deploy ulang aplikasi ke prosesor cloud-native Ampere. Ambil Momento, misalnya, yang bertujuan menyediakan layanan untuk mengelola cache dalam skala besar sehingga pengembang tidak perlu melakukannya. Cache Tanpa Server Momento dibangun di atas Pelikan, mesin caching open source yang awalnya dirancang untuk kebutuhan caching khusus Twitter. Pelikan baru-baru ini sepenuhnya ditulis ulang di Rust. Momento ingin menerapkan ulang Pelikan pada mesin virtual Tau T2A berbasis Ampere yang dihosting oleh Google.

Penempatan ulang berlangsung cepat dan lancar, tanpa perubahan kode untuk mengaktifkan dan menjalankan Pelikan dan Momento Serverless Cache. Selain itu, tim Momento dapat menerapkan beberapa pengoptimalan sederhana—tanpa mengutak-atik kode—yang meningkatkan throughput tiga kali lipat dengan cepat. Di Bagian 4 dari seri ini, kita akan melihat lebih dekat manfaat kinerja apa yang bisa Anda peroleh.

Contoh pemindahan lainnya adalah Plesk. Perangkat lunak Plesk memungkinkan orang mengelola infrastruktur jaringan melalui panel kontrol pusat. Lukas Hertig, Wakil Presiden Senior Pengembangan Bisnis dan Aliansi Strategis di Plesk, menjelaskan pengalamannya sendiri selama proses pemindahan. “Memiliki versi Arm awalnya merupakan ide gila saya. Beberapa minggu kemudian, tim teknik saya kembali dan berkata, ‘Oh, sekarang sudah. “Jauh lebih cepat dari biasanya!”

Plesk melayani ruang SMB di mana opsi untuk cloud-native tidak jelas. Namun tak lama setelah pemindahan, Hertig berkata, “kami telah menggunakan 1.000 instans Arm dalam produksi.” Intinya: Arm dan komunitas sumber terbuka telah melakukan pekerjaan yang hebat dalam mengembangkan dan memperluas ekosistem cloud Arm. Tentu saja, kerumitan penerapan ulang aplikasi ke platform komputasi cloud-native tergantung dari mana Anda mendapatkan kode. Namun, secara umum, investasi untuk men-deploy ulang sebagian besar aplikasi ke prosesor cloud-native minimal, karena 80-90% aplikasi hanya perlu dikompilasi ulang.

Di Bagian 3 seri ini, kita akan mempelajari lebih lanjut tentang proses penerapan kembali cloud-native.



rencana pengembangan website



metode pengembangan website

jelaskan beberapa rencana untuk pengembangan website, proses pengembangan website, kekuatan dan kelemahan bisnis pengembangan website
, jasa pengembangan website, tahap pengembangan website, biaya pengembangan website

#Investasi #Cloud #Native #beragampengetahuan

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *