Masa depan infrastruktur akan dijalankan dalam container

Meskipun sebagian besar perusahaan dan startup teknologi saat ini menggunakan cloud, banyak yang belum menyadari semua manfaatnya. Jika Anda menggunakan cloud tetapi tidak menggunakan Kubernetes, Anda mungkin memanfaatkan solusi eksklusif berbagai perusahaan sambil membangun dan memelihara alat kustom tambahan Anda sendiri. Anda juga menjadi kurang efisien, menjalankan workload sendiri pada virtual machine (VM) yang kurang dimanfaatkan, dan berpotensi membuat Anda ketergantungan pada teknologi tertentu. 

Berapa banyak alat yang Anda gunakan saat ini untuk mengelola dan mem-patch VM? Bagaimana Anda meng-upgrade aplikasi? Dan seperti apa pemanfaatan VM Anda? Apa yang Anda miliki saat ini mungkin tidak seefisien itu. Banyak hal yang bermasalah (pemadaman, masalah skalabilitas, dll.) karena kelemahan dalam arsitektur VM Anda, atau biaya melonjak tak terkendali, atau infrastruktur tidak disiapkan untuk mendukung banyak hal yang perlu dilakukan bisnis Anda:

• Memfaktorkan ulang/merancang ulang MVP menjadi solusi yang skalabel
• Memperluas ke penyedia cloud tambahan untuk memenuhi peraturan atau harapan pelanggan
• Memperluas operasi bisnis ke lebih banyak wilayah untuk mengurangi latensi dan memberikan pengalaman yang lebih baik ke basis pelanggan yang lebih luas
• Meningkatkan postur keamanan end-to-end Anda
• Meningkatkan pengalaman pelanggan (misalnya, ketersediaan layanan)

Sistem lama dan utang teknis dapat memperlambat Anda. Itulah alasan kami melihat perpindahan yang besar menuju Kubernetes. Arsitektur modern yang terdiri dari container terkelola memberi Anda akses ke pola yang telah terbukti dapat menjalankan infrastruktur yang andal dan aman. Anda dapat mempercepat waktu penyiapan produk dan meningkatkan produktivitas tanpa mengorbankan stabilitas dan keamanan, dengan manfaat tambahan untuk membantu Anda menarik karyawan teknis terbaik untuk mengerjakan inovasi.

Anda juga sebaiknya tidak menutup diri dari komunitas Kubernetes dan ekosistem sekitarnya, karena inovasinya yang stabil menentukan standar industri dan praktik terbaik saat ini. Pada akhirnya—dan ini bahkan lebih penting mengingat tantangan perekrutan karyawan saat ini—Anda harus memutuskan dalam hal apa para engineer sebaiknya menghabiskan waktu mereka: memelihara infrastruktur dan membangun serta memelihara alat kustom, atau melakukan tugas-tugas dalam daftar prioritas Anda untuk memajukan bisnis. Apa yang Anda miliki saat ini mungkin bermanfaat, tetapi rencana Anda mungkin mencakup item yang tidak Anda sukai, seperti membayar utang teknis dan mengisi kekurangan platform terkait beberapa hal berikut:

• Enkripsi end-to-end
• Kemampuan observasi (log, metrik, logging otomatis)
• Pengelolaan dan penegakan kebijakan
• Ketersediaan tinggi dan failover otomatis
• Pengurangan biaya

Kubernetes bersifat open source dan platform-agnostic, yang menawarkan semua alat umum siap pakai untuk mengamankan dan mempercepat setiap tahap siklus proses build dan deploy. Ini merupakan hasil dari semua skrip bash dan praktik terbaik yang digabungkan sebagian besar administrator sistem dari waktu ke waktu, lalu disajikan sebagai satu sistem di balik serangkaian API deklaratif. Semuanya bersifat otomatis, detailnya disembunyikan, dan siap digunakan. Kubernetes dapat menghilangkan sebagian besar infrastruktur sebagai kode sambil mengalihkan platform Anda ke infrastruktur sebagai data. Anda tidak perlu menulis atau mempertahankan kode; Anda memberi tahu Kubernetes apa yang Anda inginkan, bukan apa yang harus dilakukan. Ini akan sangat menghemat waktu dalam hal beban pengelolaan. 

Jika ingin menjalankan workload tradisional, Anda dapat melakukannya di platform modern dengan Kubernetes dengan memisahkan aplikasi dari VM dan memasukkannya ke dalam container. Mengadopsi image container untuk mengemas software Anda akan mempermudah upgrade VM Anda. Anda sekarang dapat memisahkan pengelolaan siklus proses VM dan pengelolaan siklus proses aplikasi, serta menyederhanakan VM dengan menghapus semua hal seperti Ruby, Python, dan Java. Dan dengan memindahkannya ke tempatnya—di samping aplikasi developer—Anda dapat mengontrol semuanya di satu tempat dan menjaga mesin Anda tetap sebagai server bare metal.

Platform komputasi terkelola mengubah layanan cloud menjadi platform as a service, memberi Anda daya dan fleksibilitas container serta kenyamanan serverless. Tidak ada server, tidak ada konfigurasi cluster, dan tidak ada pemeliharaan, yang berarti Anda dapat memperoleh manfaat yang luar biasa sambil tetap memegang kendali.

Untuk workload yang tidak memerlukan banyak kontrol atas konfigurasi cluster, Anda dapat membiarkan layanan menyediakan dan mengelola infrastruktur dasar cluster, termasuk node dan kumpulan node, sementara Anda hanya membayar workload-nya, bukan cluster tersebut. Dengan cara ini, Anda dapat menghilangkan administrasi cluster sambil mengoptimalkan keamanan dan menghemat uang dalam jumlah besar.

Untuk aplikasi berbasis cloud lainnya, model serverless melakukan hal yang sama dengan lebih sedikit pekerjaan, meniadakan infrastruktur dasar, serta berfungsi sebagai host menyeluruh untuk aplikasi, data, dan bahkan analisis Anda. Dengan platform serverless, Anda dapat mulai menjalankan container ke lingkungan yang terkelola sepenuhnya dengan kompleksitas minimal dan keamanan, performa, skalabilitas, dan praktik terbaik yang disertakan.

Mari kita lihat potensi implikasinya untuk bisnis Anda, dan bagaimana Anda dapat menjaga organisasi Anda agar tetap terdepan dalam kurva efisiensi.

Beberapa bisnis merasa perlu untuk beroperasi di banyak cloud. Gravitasi data itu nyata, dan jika Anda memiliki basis pelanggan global, Anda pasti akan melayani pelanggan yang ingin meminimalkan latensi serta biaya jaringan dengan menjaga komputasi mereka tetap berada dekat dengan lokasi data mereka.

Dalam kasus seperti ini, multicloud dapat memperluas target pasar Anda, dan pada akhirnya Anda akan mendukung layanan serta data terkelola pada penyedia lain. Perusahaan lain menilai multicloud sebagai strategi mitigasi risiko. Dalam kedua situasi tersebut, kuncinya adalah mengadopsi multicloud dengan benar, dan solusi standar industri dapat memberikan solusi.

Pertama: pastikan Anda dapat memanfaatkan kembali sebanyak mungkin alur kerja untuk menyelesaikan pekerjaan. Yang kami maksud dengan alur kerja adalah mengaktifkan otomatisasi tugas untuk membuat arsitektur dataflow antara database dan komputasi. Di sinilah open source berperan penting. Jika Anda memilih database yang tidak terbuka, Anda akan kesulitan menerapkan otomatisasi dan arsitektur dataflow. Sebaiknya gunakan sesuatu seperti protokol Postgres (misalnya Cloud Spanner) atau database Postgres terkelola (misalnya Cloud SQL) di penyedia cloud mana pun. 

Kedua: di sisi komputasi, Kubernetes menghemat banyak waktu dalam deployment dan otomatisasi. Jadi saat Anda memilih kumpulan teknologi, pastikan teknologi ini dapat bekerja melintasi batasan yang ditetapkan oleh penyedia Anda. Batasan dapat berupa region atau zona yang berbeda, project atau akun yang berbeda, dan bahkan infrastruktur lokal atau cloud. Jangan membuang waktu untuk membangun dan memelihara infrastruktur terpisah bagi setiap penyedia cloud (misalnya satu di AWS, satu di Google, dan satu di Azure). Engineer Anda akan terlalu sibuk mengelola semua infrastruktur ini dalam waktu bersamaan. Jika Anda membangun sekali dan men-deploy di beberapa cloud, update dapat dilakukan secara terpusat dan konsisten. Stack komputasi seperti Kubernetes memberikan keuntungan besar bagi pelanggan yang serius menggunakan multicloud dengan cara yang efisien dan tidak perlu melakukan semuanya dari awal setiap kali Anda ingin menggunakan penyedia cloud baru.

Ketiga: manajemen risiko. Memiliki kemampuan untuk menjalankan stack Anda di lingkungan lain akan membantu memitigasi risiko penyedia cloud Anda mengalami periode nonaktif atau mulai bersaing dengan bisnis Anda. Untuk mematuhi peraturan, organisasi akan memilih penyedia untuk memastikan kelangsungan bisnisnya. Misalnya, jika Anda kehilangan operasi di satu region, Anda tidak akan mengalami periode nonaktif dengan penyedia cadangan.

Migrasi multicloud yang cenderung bekerja dengan baik adalah yang memanfaatkan standar terbuka. Misalnya Kubernetes yang menawarkan API provider-agnostic untuk menjalankan, mengonfigurasi, dan men-deploy aplikasi, serta mengintegrasikan hal-hal seperti kebijakan keamanan, jaringan, dan lainnya. Bayangkan Kubernetes sebagai sebuah sistem operasi multicloud; setelah menjadi lapisan abstraksi Anda, biasanya Anda dapat menyembunyikan perbedaan antara sebagian besar penyedia cloud utama.

Saat memutuskan untuk menggunakan Kubernetes, Anda memiliki pilihan. Anda pasti bisa menjalankannya sendiri. Kubernetes adalah project open source, sehingga Anda dapat mendownloadnya dan menghabiskan waktu bertahun-tahun untuk mengintegrasikannya ke penyedia cloud atau lingkungan pilihan Anda.

Tetapi jika ini terlalu lama bagi Anda, Anda dapat menggunakan penawaran Kubernetes terkelola. Jika Anda menggunakan AWS, itu berarti EKS. Jika Anda menggunakan Azure, itu berarti AKS. Dan jika Anda menggunakan Google Cloud, itu berarti Google Kubernetes Engine (GKE). Semua opsi tersebut akan memberi Anda Kubernetes API umum. Jadi saat tim Anda membuat alat dan alur kerjanya, Anda dapat menggunakannya kembali di berbagai penyedia.

Namun, tidak semua penawaran layanan terkelola itu sama. Kubernetes hanya akan sebagus infrastruktur yang mendasarinya, dan sebagai layanan orkestrasi Kubernetes yang matang dan terkelola sepenuhnya, GKE akan mengisi kekurangan yang dimiliki Kubernetes. GKE menawarkan IaaS terintegrasi penuh mulai dari penyediaan VM Tau VM dengan rasio harga-performa 42% lebih baik dibandingkan dengan penawaran tujuan umum yang sebanding,¹ penskalaan otomatis di berbagai zona dan upgrade, hingga membuat dan mengelola GPU, TPU untuk machine learning, volume penyimpanan, serta kredensial keamanan sesuai permintaan. Yang harus Anda lakukan hanyalah memasukkan aplikasi Anda ke dalam container dan memilih sistem berdasarkan kebutuhan.

Bagaimana jika Anda memilih AWS sebagai penyedia cloud untuk VM? Apakah Anda tetap perlu menggunakan EKS? Pada dasarnya, Kubernetes setara di semua penyedia cloud, dan Anda akan menggunakan Kubernetes API. Namun, di bawah API tersebut terdapat cluster, worker node, kebijakan keamanan, semuanya, dan di sinilah GKE unggul.

Misalnya, jika Anda masih memerlukan cluster lain tersebut, Anda dapat menghubungkannya ke GKE Connect, yang akan memberi Anda satu tempat untuk mengelola, melihat, memecahkan masalah, dan men-debug semuanya, sekaligus mengelola hal-hal seperti kredensial secara terpusat. GKE adalah Kubernetes terbaik karena pengelolaannya yang menyeluruh, bukan hanya karena bidang kontrolnya atau ketersediaan tinggi pada multi-region atau multi-zona. GKE juga dapat memanfaatkan load balancer global menggunakan Multi Cluster Ingress yang dikelola secara terpusat di beberapa cluster dan beberapa region.

Bagaimana jika Anda menginginkan Kubernetes API tetapi tidak dengan tanggung jawab penyediaan, penskalaan, dan upgrade cluster? Untuk sebagian besar workload, GKE Autopilot telah mengelola infrastruktur dasar cluster, termasuk node dan node pool, dan Anda hanya membayar untuk workload tersebut. GKE Autopilot memberi Anda Kubernetes API standar dengan semua default keamanan yang kuat, sehingga Anda dapat berfokus pada workload dan bukan cluster.

__________________________

¹ Hasil didasarkan pada perkiraan SPECrate®2017_int_base yang dijalankan di VM produksi dari dua vendor cloud terkemuka lainnya dan Tau VM Google Cloud praproduksi yang menggunakan compiler yang direkomendasikan vendor. SPECrate adalah merek dagang dari Standard Performance Evaluation Corporation. Informasi selengkapnya tersedia di www.spec.org.

Kubernetes memindahkan organisasi dari VM ke kumpulan abstraksi baru yang memungkinkan Anda mengotomatiskan operasi dan fokus pada aplikasi Anda. Namun, untuk workload yang lebih spesifik (misalnya aplikasi web dan seluler, backend REST API, pemrosesan data, otomatisasi alur kerja), Anda dapat lebih menyederhanakan dan mengoptimalkan deployment dengan memanfaatkan model serverless.

Mungkin Anda menggunakan AWS Lambda, platform serverless populer yang memungkinkan Anda menulis functions as a service dan menghubungkannya ke semua jenis peristiwa. Tetapi karena Anda akhirnya terhubung ke database dan menangani masalah keamanan, fungsi ini cenderung bertambah kompleks, beberapa menjadi lebih besar dari aplikasi normal. Jadi, apa yang terjadi jika Anda memiliki aplikasi yang melampaui kesederhanaan function as a service, atau aplikasi yang sudah ada yang ingin Anda jalankan dengan model serverless?

Tidak seperti platform serverless tradisional yang mengharuskan Anda menulis ulang aplikasi, Cloud Run menawarkan pendekatan yang membantu Anda menggunakan kembali aplikasi dalam container yang ada. Meskipun GKE adalah layanan terkelola, Anda tetap harus membuat beberapa keputusan penting: di zona mana GKE harus dijalankan, di mana tempat menyimpan log, bagaimana cara mengelola traffic antara berbagai versi aplikasi, nama domain terdaftar, dan mengelola sertifikat SSL.

Cloud Run meniadakan semua keputusan tersebut, sehingga Anda dapat menjalankan workload yang lebih tradisional dan menghindari cold start dengan menonaktifkan penskalaan hingga nol. Jika aplikasi Anda harus selalu berjalan, Cloud Run juga mendukungnya, bersama dengan persyaratan tradisional lainnya seperti integrasi NFS, WebSockets, dan VPC. Namun, seperti kebanyakan platform serverless tradisional, Cloud Run menawarkan fitur yang dinilainya penting seperti pengelolaan traffic bawaan dan penskalaan otomatis.

Misalkan Anda tidak menggunakan container sama sekali dan ingin tahu harus mulai dari mana. Berikut pendekatan pragmatis untuk mengadopsi containerization.

Alasan pertama untuk mengadopsi container adalah memecahkan masalah pengemasan. Ada banyak pekerjaan yang dilakukan saat ini seputar pembuatan artefak yang dapat direproduksi dan memahami apa yang sebenarnya ada di dalam software kami; atau, sebagaimana industri menyebutnya, “supply chain software yang aman.” Kami yakin cara yang ideal untuk melakukannya adalah dengan memanfaatkan image container yang menyimpan kode aplikasi dan runtime beserta dependensinya. Salah satu manfaat container adalah dapat di-deploy ke VM, sehingga mengurangi kompleksitas deployment dan mempertahankan software di seluruh mesin Anda.

Alasan kedua untuk mengadopsi container adalah orkestrasi. Mengelola VM disertai dengan banyak beban pengelolaan dan pemeliharaan. Jika perusahaan Anda seperti kebanyakan perusahaan lainnya, tim Anda menjalankan puluhan atau ratusan langkah untuk mengelola infrastruktur Anda, dan bahkan jika langkah-langkah tersebut otomatis, alat otomatisasi tersebut masih memerlukan pemeliharaan berkelanjutan. Dan itu dengan asumsi Anda menggunakan alat otomatisasi standar industri seperti Terraform, Puppet, Chef, dan Ansible. Beban pemeliharaan bahkan lebih buruk untuk alat buatan sendiri atau kustom.

Alasan ketiga untuk mengadopsi container adalah efisiensi. Selain beban pemeliharaan, sebagian besar organisasi hanya mencapai 5%-10% pemakaian CPU, belum lagi memori dan penyimpanan. Artinya, banyak resource yang terbuang. Banyak tim yang membuat lebih banyak alat kustom untuk menutupi kekurangan ini dengan menerapkan hal-hal seperti penskalaan otomatis dan pengemasan, sehingga menyia-nyiakan lebih banyak waktu operasional. Hal ini menyebabkan pengeluaran yang berlebihan dan tagihan cloud yang sangat tinggi.

Sangat sedikit organisasi yang berhasil membangun platform orkestrasi mereka sendiri. Itulah sebabnya memanfaatkan platform open source seperti Kubernetes, Mesos, atau Nomad adalah pilihan yang umum. Tetapi jika Anda menginginkan platform yang membantu Anda mewujudkan manfaat seperti pengurangan pemeliharaan, praktik terbaik standar industri, dan integrasi mendalam dengan penyedia cloud lainnya, sebaiknya Anda menggunakan layanan terkelola seperti GKE untuk memaksimalkan nilai potensial container Anda.

Pada tahap ini Anda mungkin bertanya: apakah migrasi ke container sama saja dengan periode nonaktif yang lama dan tidak memiliki nilai? Hal terakhir yang ingin Anda lakukan adalah menjeda pengembangan pada masa mendatang, bukan?

Untuk menjawabnya, mari kita telusuri cara melakukannya dengan benar dengan memanfaatkan pengalaman cloud Anda hingga saat ini.

Memigrasikan aplikasi dari VM dan ke dalam container mungkin tampak menyulitkan, terutama jika itu berarti memindahkan semua komputasi Anda ke penyedia cloud baru. Namun kenyataannya, Anda tidak harus melakukannya sekaligus. Anda dapat memigrasikan satu aplikasi pada satu waktu, dimulai dengan VM dan memindahkan satu atau dua aplikasi ke Kubernetes, tempat aplikasi tersebut dapat berjalan berdampingan di jaringan yang sama dan berkomunikasi dengan VM. Anda tidak harus melakukan seluruh transisi sekaligus; Anda dapat berpindah secara perlahan dari satu platform ke platform lainnya.

Tetap menggunakan VM mungkin masuk akal untuk beberapa aplikasi, seperti database berukuran besar dan berat yang tidak banyak mendapat manfaat dari Kubernetes. Dan hal tersebut tidak masalah, Anda dapat memadupadankan sesuai kebutuhan. Namun, yang kami lihat adalah bahwa sebagian besar pelanggan mendapatkan banyak keuntungan dengan memindahkan aplikasi dan project open source mereka ke lanskap Kubernetes. Prioritaskan aplikasi yang akan menghasilkan keuntungan terbesar dengan berpindah ke GKE; Anda tidak perlu memindahkan semuanya sekaligus.

Kubernetes masih berjalan di atas VM Linux yang sama yang mungkin Anda gunakan saat ini. Yang akan Anda dapatkan adalah alur kerja yang lebih sederhana dan konsisten yang menggabungkan banyak hal yang seharusnya ada di rencana infrastruktur Anda, bukan kumpulan skrip dan otomatisasi buatan sendiri. Orientasi anggota tim baru juga menjadi jauh lebih mudah saat Anda menggunakan alat standar industri seperti Kubernetes dibandingkan harus mengajari mereka semua cara kustom yang dilakukan perusahaan Anda.

Pada tahap ini, Anda memiliki jalur untuk mengadopsi container secara perlahan namun pragmatis, sehingga menghemat waktu tim Anda dalam hal biaya administrasi dan menghemat uang perusahaan Anda untuk biaya komputasi.

Kita telah membahas banyak hal tentang container dan migrasi cloud—baik Anda sepenuhnya menggunakan Kubernetes dan mencari penawaran yang lebih baik, atau menginginkan pendekatan berbeda yang sesuai dengan aplikasi dan rencana Anda yang sudah ada.

Apa pun jalur pengembangan aplikasi Anda, opsi container terkelola meminimalkan biaya infrastruktur sekaligus memaksimalkan kemampuan tim Anda untuk fokus membuat produk yang bagus. Masa depan infrastruktur adalah containerization. Saatnya untuk memastikan engineer dan bisnis Anda disiapkan agar meraih kesuksesan semaksimal mungkin. 

Kubernetes ke Solusi Berbasi Cloud: Mulai perjalanan Anda dalam melakukan pengembangan di GKE

Container di Cloud - Cara yang lebih baik untuk mengembangkan dan men-deploy aplikasi

Masa lalu, masa kini, dan masa depan Kubernetes bersama Eric Brewer

Merancang ulang ke solusi berbasis cloud: pendekatan evolusioner untuk meningkatkan produktivitas developer dalam skala besar