Mempercepat awan: Peralihan ke awan asli

Artikel ini adalah bahagian ketiga siri pengkomputeran "mempercepatkan awan" Ampere Computing. Anda boleh membaca bahagian pertama dan kedua di sini.

Seperti yang kami tunjukkan di bahagian kedua siri ini, memancarkan aplikasi ke platform pengkomputeran awan asli sering merupakan proses yang agak mudah. Contohnya, Momento menggambarkan pengalaman penempatan semula sebagai "lebih kurang kerja daripada yang kami harapkan

Sudah tentu, aplikasi itu boleh menjadi rumit, dengan banyak komponen dan kebergantungan. Semakin kerumitan, semakin banyak masalah yang mungkin anda miliki. Dari perspektif ini, pengalaman Momento dalam memulihkan Cache Pelikan kepada pemproses asli Ampere Cloud memberikan banyak pandangan. Syarikat itu telah membina seni bina yang kompleks yang mereka mahu mengautomasikan segala -galanya sebanyak mungkin. Proses penempatan semula memberi mereka peluang untuk mencapai matlamat ini.

Aplikasi yang sesuai untuk pemprosesan asli awan

Perkara pertama yang perlu dipertimbangkan adalah untuk menentukan bagaimana permohonan anda mendapat manfaat daripada penempatan semula pada platform pengkomputeran awan asli. Kebanyakan aplikasi awan sesuai untuk pemprosesan asli awan. Untuk memahami aplikasi mana yang boleh memberi manfaat paling banyak dari pendekatan awan asli, kami dengan teliti melihat seni bina pemproses awan ampere.

Untuk mencapai kecekapan pemprosesan yang lebih tinggi dan penggunaan kuasa yang lebih rendah, Ampere telah mengadopsi pendekatan yang berbeza untuk mereka bentuk teras kami-kami memberi tumpuan kepada keperluan pengkomputeran sebenar aplikasi awan dari segi prestasi, kuasa dan fungsi. Ciri-ciri pemproses ditambah kepada kes penggunaan tanpa awan. Sebagai contoh, skala vektor berskala berguna apabila aplikasi perlu mengendalikan sejumlah besar grafik 3D atau jenis pemprosesan pengkomputeran berprestasi tinggi, tetapi membawa perdagangan dari segi penggunaan kuasa dan ketumpatan teras. Bagi aplikasi yang memerlukan SVE, seperti permainan Android di awan, penyedia perkhidmatan awan mempunyai pilihan untuk memasangkan pemproses Ampere dengan GPU untuk mempercepat prestasi 3D.

Untuk beban kerja awan asli, mengurangkan penggunaan kuasa dan peningkatan ketumpatan teras di teras ampere bermakna aplikasi berjalan pada prestasi yang lebih tinggi sambil memakan kuasa yang kurang dan menghilangkan kurang haba. Singkatnya, bagi kebanyakan aplikasi, platform pengkomputeran awan boleh memberikan prestasi yang lebih baik, kecekapan tenaga yang lebih tinggi, dan ketumpatan pengiraan yang lebih tinggi semasa mengurangkan kos operasi.

Ampere khusus dalam aplikasi berasaskan microservice dengan banyak komponen bebas. Aplikasi sedemikian boleh mendapat manfaat daripada ketersediaan lebih banyak teras, Ampere menawarkan ketumpatan teras tinggi sebanyak 128 teras pada cip tunggal dan sehingga 256 teras dalam casis 1U dengan dua slot.

Malah, apabila anda skala secara mendatar (iaitu mengimbangi beban di banyak keadaan), anda benar -benar dapat melihat kelebihan Ampere. Kerana skala ampere secara linear dengan beban, setiap teras yang anda tambah akan membawa manfaat langsung. Membandingkan ini dengan seni bina x86, di mana manfaat setiap kernel baru dikurangkan dengan cepat (lihat Rajah 1).

Rajah 1: Kerana skala ampere secara linear dengan beban, setiap teras ditambah membawa manfaat langsung. Membandingkan ini dengan seni bina x86, di mana manfaat setiap kernel baru dikurangkan dengan cepat.

Ketergantungan proprietari

Salah satu cabaran yang dihadapi penempatan aplikasi adalah mengenal pasti kebergantungan proprietari. Di mana sahaja dalam rantaian bekalan perisian yang menggunakan fail binari atau pakej perisian berasaskan x86 yang berdedikasi perlu diambil notis. Kebanyakan kebergantungan ini boleh didapati dengan mencari kod yang mengandungi "x86" dalam nama fail. Proses penggantian biasanya mudah diselesaikan: Gantikan pakej x86 dengan versi berasaskan ARM yang sesuai, atau mengkompilasi semula pakej yang tersedia untuk platform asli Ampere Cloud jika anda mempunyai akses ke kod sumber.

Sesetengah kebergantungan akan menyebabkan masalah prestasi, tetapi tidak mempunyai masalah. Pertimbangkan rangka kerja pembelajaran mesin yang menggunakan kod yang dioptimumkan untuk platform x86. Rangka kerja ini masih boleh dijalankan di platform asli awan, tetapi ia tidak begitu cekap kerana ia berjalan pada platform berasaskan x86. Penyelesaiannya adalah mudah: mengenal pasti versi yang setara dengan kerangka kerja yang dioptimumkan untuk ARM ISA, seperti yang termasuk dalam Ampere AI. Akhirnya, terdapat beberapa kebergantungan ekosistem. Sesetengah perisian komersil aplikasi anda bergantung, seperti pangkalan data Oracle, mungkin tidak tersedia sebagai versi berasaskan ARM ISA. Sekiranya ini berlaku, ini mungkin bukan aplikasi yang sesuai untuk penempatan semula sehingga versi sedemikian tersedia. Penyelesaian untuk ketergantungan sedemikian, seperti menggantikannya dengan alternatif mesra awan, mungkin mungkin, tetapi ini mungkin memerlukan perubahan ketara pada permohonan anda.

Beberapa kebergantungan berada di luar kod aplikasi, seperti skrip (iaitu PlayBooks dalam Ansible, Resipi dalam Chef, dll.). Jika skrip anda menganggap nama pakej atau skema tertentu, mereka mungkin perlu diubah apabila menggunakan platform komputer awan. Kebanyakan perubahan ini mudah, dan semakan terperinci skrip akan mendedahkan kebanyakan isu ini. Beri perhatian untuk menyesuaikan andaian penamaan yang mungkin dibuat oleh pasukan pembangunan selama bertahun -tahun.

Realiti adalah bahawa masalah ini biasanya mudah ditangani. Anda hanya perlu mengenal pasti mereka dengan teliti dan memprosesnya. Walau bagaimanapun, sebelum menilai kos menangani kebergantungan tersebut, perlu mempertimbangkan konsep hutang teknikal.

Hutang Teknikal

Dalam artikel Forbes "Hutang Teknikal: Sulit untuk Rintangan yang Boleh Diukur dalam Transformasi Digital", Hutang Teknikal ditakrifkan sebagai "pengumpulan pembaikan yang agak cepat dalam sistem, atau pelaburan yang berat tetapi salah diarahkan, mungkin kewangan dalam jangka masa panjang, Dalam jangka panjang. Dari masa ke masa, hutang teknikal meningkatkan kos perubahan dalam sistem perisian, sama seperti pembentukan skala dalam mesin kopi akhirnya akan mengurangkan prestasinya.

Sebagai contoh, apabila momento digunakan semula Cache Pelikan kepada pemproses asli Ampere Cloud, mereka telah memasang kod pembalakan dan pemantauan yang bergantung pada kod sumber terbuka dari 15 tahun yang lalu. Kod berfungsi, jadi ia tidak pernah dikemas kini. Walau bagaimanapun, apabila alat berubah dari masa ke masa, kod perlu dikompilasi semula. Sesetengah kerja diperlukan untuk mengekalkan keserasian ke belakang, mewujudkan kebergantungan pada kod lama. Semua kebergantungan ini telah terkumpul selama bertahun -tahun. Pada satu ketika, apabila mengekalkan kebergantungan ini menjadi terlalu kompleks dan mahal, anda perlu beralih ke kod baru. Hutang teknikal boleh dikatakan pulih.

Apabila memulihkan aplikasi anda ke platform pengkomputeran awan, penting untuk memahami hutang teknikal anda sekarang dan bagaimana ia mendorong keputusan anda. Mengekalkan dan menyesuaikan kod warisan selama bertahun -tahun dapat mengumpul hutang teknikal, yang menjadikan penempatan semula lebih rumit. Walau bagaimanapun, ini sendiri bukan kos penempatan semula. Walaupun anda memutuskan untuk tidak menyerahkan semula ke platform lain, suatu hari anda perlu membuat semua perbaikan cepat dan keputusan lain untuk menangguhkan kemas kini kod anda. Anda belum melakukannya.

Betapa nyata hutang teknikal? Menurut kajian McKinsey (lihat artikel Forbes), 30% daripada CIO dalam kajian itu menganggarkan bahawa lebih daripada 20% daripada anggaran teknikal mereka untuk produk baru sebenarnya digunakan untuk menangani isu -isu yang berkaitan dengan hutang teknikal.

Penyebaran Merah adalah peluang yang baik untuk menangani beberapa hutang teknikal yang terkumpul oleh permohonan selama bertahun -tahun. Bayangkan mengambil sebahagian daripada "20%" hutang teknologi yang digunakan oleh syarikat anda. Walaupun ini boleh meningkatkan masa proses penempatan semula, pengendalian hutang teknikal mempunyai manfaat memudahkan kerumitan menguruskan dan mengekalkan kod dalam jangka masa panjang. Sebagai contoh, anda boleh "menetapkan semula" banyak kebergantungan dengan memindahkan kod anda ke persekitaran pembangunan semasa anda dan bukannya bergantung kepada mereka. Ini adalah pelaburan yang boleh dibayar dengan serta -merta dengan memudahkan kitaran pembangunan anda.

Anton Akhtyamov, pengurus produk di Plesk, menggambarkan pengalamannya dalam penempatan semula. "Selepas memindahkan, kami menemui beberapa batasan. Plesk adalah platform besar yang boleh memasang banyak modul/sambungan tambahan. Ada yang tidak disokong oleh lengan, seperti Dr. Web dan Kaspersky Antivirus. Beberapa sambungan juga tidak tersedia. Kebanyakan sambungan kami sudah disokong menggunakan pakej yang dibina semula oleh vendor untuk lengan. Isu kritikal. "

Untuk lebih banyak contoh praktikal untuk memulihkan aplikasi ke platform awan asli, lihat Porting Takua ke OpenMandriva di ARM dan AMPERE ALTRA.

Di bahagian keempat siri ini, kami akan menyelam ke dalam hasil yang anda boleh harapkan apabila memulihkan aplikasi anda ke platform pengkomputeran awan.

Atas ialah kandungan terperinci Mempercepat awan: Peralihan ke awan asli. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!