Jangan Gunakan Kubernetes Dulu
(matt-rickard.com)Startup tahap awal sebaiknya jangan tergesa-gesa mengadopsi Kubernetes.
Dalam kebanyakan kasus, itu masih terlalu dini.
Tim kecil (1~10 orang) lebih baik menggunakan layanan container serverless.
(AWS ECS - Fargate, Google Cloud Run dari GCP)
13 komentar
Bukankah k8s sekarang sudah bukan lagi soal suka atau tidak suka, melainkan soal bertahan hidup?
Saya rasa, mungkin tidak harus AWS, tetapi kita sudah berada dalam situasi di mana wajib memahami k8s.
Saya tidak setuju dengan pendapat ini.
kekurangan satu-satunya yang dimiliki k8s menurut saya hanyalah learning curve.
Bahkan jika anggota tim hanya sekitar 5 orang, awalnya memang akan sulit, tetapi setelah tingkat pemahaman terhadap k8s naik melewati level tertentu, Anda sama sekali tidak bisa kembali ke cara sebelumnya. Peningkatan produktivitas yang dihasilkannya tidak bisa dibandingkan.
ci/cd, gitops, canary deployment, dan sebagainya memang bisa dilakukan tanpa k8s, tetapi melakukannya bersama di atas k8s lebih mudah dipahami dan lebih sederhana untuk dikelola.
Sebagai orang yang pernah mengalami langsung proses migrasi, mengatakan bahwa ini masih terlalu dini
mengingatkan saya pada masa on-premise ketika orang ragu mengadopsi aws cloud hanya karena masih terasa asing.
Ini bukan sekadar argumen normatif seperti "fokus pada bisnis", tetapi saya sulit setuju dengan keputusan yang mengunci kita ke teknologi khusus tertentu.
Kalau ini adalah tulisan yang menganjurkan untuk secara aktif memanfaatkan PaaS seperti beanstalk/app engine/heroku, saya akan sangat setuju, tetapi untuk tim kecil, keuntungan yang didapat dari memilih ECS/cloud run/docker swarm belakangan ini nyaris tidak ada. Mungkin lain ceritanya kalau 4~5 tahun lalu.
Dari sisi biaya, serverless jelas jauh lebih unggul.
Saya juga setuju. Dalam kebanyakan kasus,
docker-swarmataudocker-composesudah lebih dari cukup.Ini juga pendapat yang sangat banyak muncul di komentar Hacker News..... [1]
Saya agak bingung karena tulisan itu berangkat dari premis bahwa "Kubernetes itu sulit".
Akhir-akhir ini ekosistem Kubernetes sudah berkembang pesat, jadi kecuali Anda memasang Kubernetes sendiri secara langsung di on-prem, itu tidak sesulit itu.
Selain itu, dalam operasional Kubernetes kita bisa menentukan sendiri sampai tingkat tertentu tingkat kompleksitasnya, dan untuk membuat konfigurasi dasar saja tidaklah sulit. Tentu nanti akan jadi sulit kalau mulai menambahkan berbagai addon.
Sekarang juga sudah banyak orang yang sejak masih junior mengalami environment deployment mulai dari EKS.
Kalau mau bicara secara spesifik,, saya tidak paham apakah menyusun
k8s Deployment,Ingressdasar (tentu saja DB memakai managed service terpisah) benar-benar lebih sulit daripada menyusun AWS ECS Fargate secara langsung seperti yang dibahas di tulisan itu.Pada akhirnya, di kedua sisi kita sama-sama harus menyiapkan VPC, cluster, CDN, dan load balancer... Di komentar bahkan banyak juga yang bilang ECS justru lebih tidak nyaman.
[1] https://news.ycombinator.com/item?id=31795160
Saya setuju. Menurut saya, setup dasarnya tidak terlalu sulit, dan tingkat kesulitan pemeliharaannya juga bukan termasuk yang tinggi. Di cloud, entah memindahkan satu setup yang rumit ke setup Kubernetes
yml, saya juga tidak bisa bilang apa yang sebenarnya lebih baik.Di perusahaan kami, setelah jumlah developer melewati 100 orang, kami merasa ini diperlukan sehingga sedang melakukan transisi dari ECS -> EKS, tetapi kadang kami juga sedikit menyesal.
Memang dibilang bahwa "operasional Kubernetes bisa menentukan sendiri sampai tingkat mana kompleksitasnya", tetapi dari sudut pandang orang yang belum terlalu paham, ada kecenderungan untuk berpikir bahwa semua hal yang dibicarakan di ekosistem Kubernetes pasti diperlukan, lalu akhirnya memasukkan semuanya.
Memang dikatakan bahwa konfigurasi load balancer tetap perlu dilakukan, tetapi menurut saya ada perbedaan antara cukup tahu ALB saja vs harus memahami ALB + Ingress.
Seperti halnya MSA tidak dibutuhkan pada skala kecil, Kubernetes ternyata punya lebih banyak hal yang harus dipelajari daripada yang dibayangkan, jadi menurut saya untuk skala yang "harus fokus pada aplikasi", ini memang over-spec.
Namun, jika ada seseorang yang sudah membangun lingkungan Kubernetes dengan baik, menerapkan aplikasi di atasnya memang terasa punya efek lock-in yang lebih kecil karena didefinisikan dengan cara yang lebih independen terhadap cloud.
Dari penjelasan Anda, sepertinya memang ada sisi-sisi seperti itu. Sepertinya saya terlalu menganggap hal-hal yang saya pelajari saat memakai Kubernetes sebagai sesuatu yang sudah sewajarnya.
Dan saya juga mengakui bahwa belakangan ini ada terlalu banyak add-on yang muncul di Kubernetes, jadi memang sulit untuk menentukan mana yang perlu dipilih.
Karena saya belum punya pengalaman migrasi seperti ECS -> EKS... saya jadi penasaran, selain efek lock-in, apakah ada hal yang terasa membaik setelah beralih?
Oh ya, sebagai catatan, pengalaman saya ini berdasarkan EKS. Ini cukup berbeda dengan memasang k8s sendiri di on-prem lalu mengelola
etcddan Control Plane secara langsung haha.Dari sudut pandang orang yang memulai dari k8s, saat membaca tulisan itu saya justru kepikiran kebalikannya: apa memang perlu meluangkan waktu untuk mempelajari ECS...?
Bagaimanapun, menurut saya tidak harus sampai ditetapkan resmi seperti itu; bukankah yang benar adalah memakai cara yang terlebih dahulu dirasa nyaman oleh tim?
Saya setuju dengan pandangan untuk mulai dengan k8s.
Saya sangat setuju.
Saya juga cenderung negatif terhadap penerapan k8s bukan hanya di tim beranggotakan 10 orang, tetapi juga di perusahaan dengan ukuran yang lumayan.
Menurut saya, itu baru bermakna jika vendor lock-in cloud sudah berada pada tingkat yang kritis atau infrastruktur seperti on-prem juga digunakan bersama.
Saya sempat merasa memang ada kecenderungan untuk secara inersia mengikuti tech stack perusahaan kelas enterprise.
Kebetulan ada tulisan yang merangkumnya dan muncul di Hacker News, jadi saya bagikan.