5 Tantangan Menuju Cloud-Asli - dan Cara Memecahkannya

Kita hidup di dunia asli-awan. Anda hampir tidak dapat membaca blog teknologi atau pergi ke konferensi tanpa mendengar tentang semua manfaat teknologi atau arsitektur cloud-asli, seperti wadah, layanan mikro dan fungsi tanpa server.

Namun di tengah semua kegembiraan tentang menjadi asli-awan, bisa jadi mudah untuk mengabaikan tantangan yang muncul ketika Anda bermigrasi dari aplikasi monolitik yang lama ke strategi awan-asli. Tantangan-tantangan ini dapat diatasi, tetapi hanya jika Anda mengatasinya sebagai bagian dari strategi migrasi asli-cloud Anda.

Untuk itu, mari kita lihat lima tantangan cloud-asli yang paling umum, bersama dengan strategi untuk mengatasinya.

Apa itu cloud-asli?

Namun, pertama-tama, sepatah kata tentang apa yang dimaksud dengan cloud-asli sebenarnya.

Dengan hype di sekitar segala hal 'cloud', 'cloud-pribumi' kadang-kadang digunakan oleh orang-orang untuk berarti segala jenis teknologi atau strategi yang mereka anggap modern. Dari perspektif itu, cloud-asli berakhir sebagai kata kunci yang relatif tidak berarti.

Di sisi lain, ketika diinvestasikan dengan makna spesifik dan terbatas, cloud-native adalah istilah dan konsep yang berguna. Kami menyukai definisi CNCF, yang menekankan “sistem yang digabungkan secara longgar” dan ketahanan sebagai karakteristik komputasi cloud-asli. Definisi CNCF juga menunjukkan daftar teknologi dan arsitektur yang spesifik dan terbatas - "wadah, jerat layanan, layanan mikro, infrastruktur yang tidak dapat diubah, dan API deklaratif" - sebagai contoh teknologi asli awan.

Untuk keperluan artikel ini, kami akan berpegang teguh pada definisi asli cloudF dari CNCF. Sekarang, mari kita bahas tantangan spesifik yang muncul ketika Anda menggunakan teknologi dan strategi seperti yang dijelaskan di atas.

Tantangan untuk Mengadopsi Cloud Native

1) Penyimpanan data yang persisten

Salah satu tantangan umum dengan banyak teknologi cloud-asli adalah menyimpan data secara terus-menerus. Kontainer, fungsi tanpa server dan aplikasi yang digunakan menggunakan model infrastruktur yang tidak dapat diubah biasanya tidak memiliki cara untuk menyimpan data secara permanen di dalam diri mereka sendiri karena semua data internal dihancurkan ketika aplikasi dimatikan.

Menyelesaikan tantangan ini membutuhkan pemikiran ulang pendekatan untuk penyimpanan data dengan memisahkannya dari aplikasi dan lingkungan host. Alih-alih menyimpan data dalam lingkungan aplikasi, alur kerja cloud-asli menyimpannya secara eksternal dan mengekspos data sebagai layanan. Kemudian, beban kerja yang perlu mengakses data, sambungkan seperti halnya mereka akan terhubung ke layanan lain.

Pendekatan ini - yang diaktifkan oleh berbagai alat, seperti volume di Kubernetes - memiliki dua manfaat. Selain memungkinkan penyimpanan data yang persisten untuk aplikasi yang tidak dirancang untuk persisten, itu juga memudahkan untuk berbagi kumpulan penyimpanan tunggal di antara banyak aplikasi atau layanan.

2) Integrasi layanan

Aplikasi cloud-asli biasanya terdiri dari serangkaian layanan yang berbeda. Sifat terdistribusi inilah yang membantu membuatnya terukur dan fleksibel, dibandingkan dengan monolit.

Tetapi itu juga berarti bahwa beban kerja asli cloud memiliki lebih banyak bagian bergerak yang perlu dihubungkan bersama dengan lancar untuk mencapai kesuksesan.

Sebagian, integrasi layanan merupakan masalah bagi pengembang untuk diatasi karena mereka membangun aplikasi asli cloud. Mereka harus memastikan bahwa setiap layanan berukuran tepat; praktik terbaik adalah membuat layanan yang berbeda untuk setiap jenis fungsi dalam beban kerja, daripada mencoba membuat layanan tunggal melakukan banyak hal. Penting juga untuk tidak menambahkan layanan hanya karena Anda bisa. Sebelum Anda memperkenalkan lebih banyak kompleksitas ke aplikasi Anda dalam bentuk layanan lain, pastikan bahwa layanan tersebut memajukan tujuan tertentu.

Di luar arsitektur aplikasi itu sendiri, integrasi layanan yang efektif juga tergantung pada pemilihan teknik penyebaran yang tepat. Kontainer mungkin merupakan cara yang paling jelas untuk menggunakan beberapa layanan dan menyatukannya ke dalam satu beban kerja, tetapi dalam beberapa kasus, fungsi tanpa server, atau aplikasi yang tidak dipaketkan yang dihubungkan oleh API, mungkin merupakan metode penyebaran layanan yang lebih baik.

3) Manajemen dan pemantauan

Semakin banyak layanan yang Anda jalankan sebagai bagian dari aplikasi, semakin sulit untuk memonitor dan mengelolanya. Ini benar, karena tidak hanya karena banyaknya layanan yang harus Anda lacak, tetapi juga karena menjamin kesehatan aplikasi memerlukan hubungan pemantauan antara layanan, bukan hanya layanan itu sendiri.

Oleh karena itu, pemantauan dan pengelolaan layanan yang berhasil di lingkungan yang asli-awan, memerlukan pendekatan yang dapat memprediksi bagaimana kegagalan dalam satu layanan akan berdampak pada layanan lainnya, serta memahami kegagalan mana yang paling kritis. Baselining dinamis, yang berarti mengganti ambang statis dengan yang terus-menerus menilai kembali lingkungan aplikasi untuk menentukan apa yang normal dan apa yang merupakan anomali, juga penting.

4) Menghindari cloud lock-in

Risiko kunci tidak unik untuk cloud; mereka dapat muncul dari hampir semua jenis teknologi, dan mereka telah menjadi ancaman untuk kelincahan selama beberapa dekade. Namun, dalam hal aplikasi atau arsitektur cloud-asli, ancaman menjadi terlalu bergantung pada penyedia atau layanan cloud tertentu bisa sangat besar, karena kemudahan beban kerja yang dapat dikerahkan sedemikian rupa sehingga mereka memerlukan tertentu layanan dari cloud tertentu.

Untungnya, mengurangi risiko penguncian cloud ini cukup mudah selama Anda rencanakan sebelumnya. Berpegang teguh pada standar berbasis masyarakat (seperti yang dipromosikan oleh OCCI) akan melakukan banyak hal untuk memastikan bahwa Anda dapat dengan mudah memindahkan beban kerja Anda dari satu cloud ke cloud lainnya. Demikian juga, saat Anda merencanakan layanan cloud mana yang akan Anda gunakan untuk cloud-native, pertimbangkan apakah salah satu layanan yang Anda pertimbangkan memiliki fitur yang benar-benar unik dan tidak tersedia dari cloud lain. Jika ya, hindari fitur-fitur itu, karena mereka dapat mengunci Anda.

Sebagai contoh, bahasa dan kerangka kerja spesifik yang didukung oleh platform komputasi tanpa server dari berbagai cloud publik agak berbeda. AWS Lambda mendukung Go, misalnya, tetapi Azure tidak. Karena itu, sebaiknya Anda tidak menulis fungsi serverless di Go. Bahkan jika Anda berencana untuk menggunakan AWS untuk menjadi tuan rumah mereka pada awalnya, ketergantungan ini akan membuat sulit untuk bermigrasi ke cloud yang berbeda di masa depan. Tetap menggunakan bahasa seperti Java, yang dapat Anda pertaruhkan dengan aman akan didukung di mana saja.

5) Membangun aplikasi jaringan pipa pengiriman cloud-asli

Menurut definisi, aplikasi cloud-asli berjalan di cloud. Meskipun cloud dapat berupa cloud publik, atau cloud pribadi, on-prem atau cloud runnnig pada lingkungan organisasi Anda-itu berarti infrastruktur yang tidak dapat diubah dan proses manajemen cloud. Tetapi banyak pipa pengiriman aplikasi sebagian besar masih berjalan pada lingkungan tradisional di tempat yang mungkin tidak berawan atau kikuk ketika diintegrasikan dengan aplikasi dan layanan yang berjalan di cloud publik atau di wadah.

Ini menciptakan tantangan dalam beberapa hal. Salah satunya adalah menyebarkan kode dari lingkungan lokal ke tempat dapat menyebabkan penundaan. Lain adalah bahwa pengembangan dan pengujian secara lokal mempersulit untuk meniru kondisi produksi, yang dapat menyebabkan perilaku aplikasi yang tidak terduga, pasca penempatan.

Cara paling efektif untuk mengatasi rintangan ini adalah dengan memindahkan pipa CI / CD Anda ke lingkungan cloud - tidak hanya untuk mendapatkan manfaat dari infrastruktur yang tidak dapat diubah dan skalabilitas cloud dan manfaat lainnya, tetapi juga untuk meniru kondisi produksi dan membawa pipa Anda lebih dekat - sebanyak mungkin mungkin - ke aplikasi Anda. Dengan begitu, kode ditulis lebih dekat ke tempat dikerahkannya, membuat penyebaran lebih cepat. Ini juga menjadi lebih mudah untuk memintal lingkungan pengujian yang identik dengan lingkungan produksi.

Meskipun pengembangan yang sepenuhnya berbasis cloud bukan untuk semua orang dan beberapa pengembang lebih menyukai keakraban dan ketanggapan dari IDE lokal daripada yang berbasis cloud, cobalah untuk memastikan pipa CI / CD Anda berjalan di lingkungan cloud, sejauh mungkin.

Kesimpulan

Tidak masalah bagaimana Anda memutarnya, cloud-native adalah sulit. Dibandingkan dengan aplikasi lawas, aplikasi cloud-asli lebih kompleks dan memiliki lebih banyak tempat di mana terjadi kesalahan. Yang mengatakan, tantangan komputasi cloud-asli dapat diatasi - dan menerapkan strategi yang dapat mengatasi tantangan adalah kunci untuk membuka kelincahan, keandalan, dan skalabilitas yang hanya dapat diberikan oleh arsitektur asli cloud.