Mengapa Ekosistem Pengembang Kubernetes Membutuhkan PaaS

  • Whatsapp
Lapisan Abstrak


Platform as a Service (PaaS) adalah salah satu model pengiriman cloud publik yang pertama. Jika Infrastructure as a Service (IaaS) memberikan kontrol kepada administrator, PaaS menargetkan pengembang dengan tepat melalui kesederhanaan, produktivitas, dan skala.

Bacaan Lainnya

Pada tahun 2008, Google meluncurkan App Engine, sebuah platform yang memungkinkan pengembang untuk menyebarkan dan menskalakan aplikasi web Java. Amazon menambahkan Elastic Beanstalk ke infrastruktur komputasi pada tahun 2012 sebagai penawaran PaaS. Windows Azure, avatar awal dari cloud publik Microsoft, semuanya tentang PaaS. Baru pada tahun 2013, Azure mendapat dukungan untuk Linux dan Windows VM untuk menghadirkan IaaS yang lengkap.

Dekade terakhir melihat munculnya PaaS dalam bentuk Cloud Foundry, Heroku, Halaman Mesin, dan Red Hat OpenShift.

Janji paling signifikan dari PaaS adalah kemampuan untuk membawa kode sumber dan berjalan pergi dengan URL yang mengarah ke aplikasi. Pengembang tidak perlu khawatir tentang penyediaan infrastruktur, penginstalan OS, atau konfigurasi dan pengamanan infrastruktur. Mereka hanya “mendorong” kode dan meninggalkan sisanya ke platform.

PaaS juga akan menskalakan dan menskalakan aplikasi secara otomatis tanpa intervensi manual. Pendekatan ini membebaskan pengembang dari menangani operasi sehari-hari sehingga memberi mereka lebih banyak waktu untuk fokus pada kode daripada infrastruktur. PaaS mengarah pada integrasi berkelanjutan dan penyebaran berkelanjutan (CI / CD), yang telah menjadi norma saat ini. Teknik penyebaran lanjutan seperti penerapan biru / hijau, peralihan versi, rilis canary semuanya dimungkinkan oleh PaaS.

Demokratisasi kontainer yang dipimpin oleh Docker dan kebangkitan Kubernetes mengubah dinamika infrastruktur dan platform modern. Kontainer dengan cepat menjadi unit dasar penerapan dan Kubernetes muncul sebagai orkestrator untuk mengelola puluhan ribu kontainer. Segera penyedia cloud publik mulai menawarkan penawaran Kubernetes terkelola, Containers as a Service (CaaS) yang menjadi alternatif dari IaaS dan PaaS.

Dengan semakin populernya Kubernetes, PaaS telah menggunakan Kubernetes untuk memungkinkan developer menggunakan kembali blok penyusun – container. App Engine Flex, Layanan Aplikasi Azure, Cloud Foundry dan OpenShift dapat menjalankan aplikasi dalam container.

Red Hat adalah salah satu perusahaan platform pertama yang menyadari kekuatan Kubernetes, yang menghasilkan OpenShift menjadi distribusi Kubernetes yang sepenuhnya patuh dan sesuai untuk perusahaan.

Tidak seperti IaaS, di mana hanya administrator dan operator yang diharapkan untuk membangun dan menyediakan mesin virtual, Containerization membawa tanggung jawab untuk mengemas kode dan membangun gambar kontainer kepada pengembang. Jika aplikasi di-deploy ke Kubernetes, developer juga dipaksa untuk mempelajari blok penyusun mesin orkestrasi untuk membungkus gambar container dalam pod, menerapkannya, lalu memaparkannya sebagai layanan.

Dengan container dan Kubernetes, garis antara pengembangan dan operasi menjadi kabur sepenuhnya. Terlepas dari persona – pengembang atau operator – setiap anggota tim diharapkan mempelajari segala sesuatu tentang infrastruktur dan manajemen siklus hidup aplikasi.

Terima kasih kepada Cloud Native Computing Foundation (CNCF) mengelola proyek open source, dan ekosistem yang dinamis, Kubernetes telah ada standar untuk mengekspos API yang terdefinisi dengan baik. Dokumentasi dan sumber daya membuat teknologi dapat diakses oleh sejumlah besar pengembang dan operator. Tidak seperti PaaS, Kubernetes menghadirkan kejelasan dan transparansi yang ekstrem pada manajemen siklus hidup aplikasi.

Namun, satu hal yang dirindukan developer di Kubernetes adalah kesederhanaan PaaS. Mari pertimbangkan alur kerja Cloud Foundry untuk menerapkan aplikasi.

Setelah pengembang menguji aplikasi di mesin lokalnya, dia hanya akan memanggil alat baris perintah untuk menerapkan aplikasi dan konfigurasi terkait. Di balik layar, Cloud Foundry melakukan segalanya mulai dari menyediakan sumber daya komputasi, meluncurkan atau mengaitkan layanan tambahan seperti database dan cache, dan terakhir, menyerahkan URL aplikasi kepada pengembang.

Di Kubernetes, semuanya dimulai dengan mengemas kode ke dalam gambar container, yang selanjutnya dibungkus ke dalam pod atau objek penerapan. Layanan tambahan seperti database mengikuti alur kerja yang sama. Pengembang perlu membuat peta konfigurasi dan rahasia untuk aplikasi web agar dapat berbicara dengan database dengan aman. Untuk mempertahankan catatan database, dia juga perlu membuat klaim volume dan volume. Terakhir, database diekspos sebagai layanan internal ke aplikasi web sementara aplikasi publik dihubungkan ke penyeimbang beban.

Seperti yang Anda lihat, pengembang menangani lebih dari selusin objek Kubernetes untuk mengonfigurasi dan menerapkan aplikasi web dua tingkat sederhana.

Ini bukan hanya proses penerapan jangka panjang dan kurva pembelajaran yang curam, tetapi perhatian sebenarnya adalah seberapa banyak pengembang perlu memahami sebelum menerapkan aplikasi. Dalam lingkungan IaaS atau PaaS tradisional, sebagian besar akan ditangani oleh operator.

Kubernetes tidak secara jelas membedakan antara developer dan operator. Terlepas dari persona tersebut, setiap pengguna diharapkan mengetahui cara kerja bagian dalam mesin orkestrasi.

Ekosistem asli cloud sangat memahami tantangan ini. Vendor platform telah mengambil tiga pendekatan berbeda untuk menambahkan kapabilitas platform ke Kubernetes.

Pendekatan pertama adalah membangun platform aplikasi open source yang diberdayakan oleh Kubernetes. Red Hat adalah salah satu perusahaan platform pertama yang mengadopsi strategi ini. OpenShift, platform kontainer paling populer, menambahkan manajemen siklus hidup aplikasi yang kuat ke Kubernetes. Ini meniru alur kerja PaaS melalui pembuat kontainer terintegrasi, registri gambar, dan router aplikasi.

Mekanisme kedua adalah mem-porting PaaS yang ada ke Kubernetes dengan tetap menjaga kompatibilitas dengan alat dan alur kerja. Cloud Foundry untuk Kubernetes melewati rute ini untuk membawa alur kerja PaaS yang sudah dikenal ke pengembang.

Pendekatan ketiga membangun lapisan buram di atas Kubernetes yang sepenuhnya menyembunyikan dasar mesin orkestrasi. Render.com dan Platform Aplikasi DigitalOcean adalah contoh implementasi ini.

Namun, masing-masing pendekatan ini memiliki tantangan dan keterbatasannya sendiri-sendiri. Red Hat OpenShift dan mitra komunitasnya, OKD, terlalu berat untuk dipasang. Anda memerlukan setidaknya lima mesin untuk menjalankan aplikasi hello world dasar di OpenShift. Cloud Foundry relatif baru untuk developer cloud native. Ini memiliki potensi untuk menjadi lapisan platform yang disukai, tetapi masih terlalu dini untuk sampai pada kesimpulan ini. Implementasi PaaS komersial seperti Render.com dan Platform Aplikasi DigitalOcean tidak open source dan portabel.

Beberapa kontributor utama Kubernetes telah membangun berbagai blok penyusun yang memudahkan pembuatan platform. Google, IBM, VMware dan Red Hat berkontribusi pada Knative, sebuah proyek open source yang menghadirkan platform tanpa server dan berbasis peristiwa ke Kubernetes. Microsoft sedang mengerjakan Waktu Proses Aplikasi Terdistribusi (DAPR) dan Kubernetes Event-Driven Autoscaling (KEDA) untuk menyederhanakan pengembangan, penerapan, dan penskalaan aplikasi native cloud.

Knative, Dapr, dan KEDA bukanlah implementasi PaaS yang lengkap. Sebaliknya, mereka adalah fondasi untuk membangun platform di atas Kubernetes. Sebagai contoh, Google Cloud Run, platform kontainer tanpa server, didasarkan pada Knative. Namun, Cloud Run bukanlah proyek open source yang eksklusif untuk Google Cloud.

Dengan batasan antara pengembangan dan operasi yang semakin kabur, developer cloud native memerlukan lapisan abstrak yang menyederhanakan pengelolaan siklus proses aplikasi.

Ada peluang yang jelas untuk membangun platform portabel, konsisten, dan ramah pengembang untuk Kubernetes. Ekosistem developer memerlukan pilihan implementasi PaaS cloud native open source yang dapat diinstal di cluster Kubernetes mana pun, termasuk CaaS yang dikelola di cloud publik atau di Minikube yang dijalankan di laptop.



Source

Pos terkait

Tinggalkan Balasan

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