24 puan yazan jujumilk3 2022-06-21 | 13 yorum | WhatsApp'ta paylaş

Erken aşamadaki startup'lar Kubernetes'i aceleyle benimsememeli.
Çoğu durumda bunun için henüz çok erken.

Küçük ölçekli ekiplerin (1~10 kişi) serverless container service kullanması daha iyi olur.
(AWS ECS - Fargate, GCP'de Google Cloud Run)

13 yorum

 
sungwoo 2022-07-04

k8s artık bir tercih meselesinden ziyade bir hayatta kalma meselesi değil mi?
Bence AWS'yi bilmeseniz de k8s'i bilmeniz gereken bir duruma gelindi.

 
bravomylife 2022-06-26

Ben bu görüşe katılmıyorum.

Bence k8s'in tek dezavantajı yalnızca öğrenme eğrisi.

Ekip 5 kişi civarında olsa bile başlangıçta zor olabilir, ancak k8s konusunda belli bir seviyenin üzerine çıkıldığında artık eskiye dönmek mümkün değil. Bunun getirdiği üretkenlik artışı kıyas kabul etmez.

ci/cd, gitops, kanarya dağıtımı gibi şeyler k8s olmadan da yapılabilir, ancak bunları k8s üzerinde birlikte yapmak hem anlaması daha kolay hem de yönetmesi daha pratiktir.

Geçiş sürecini bizzat yaşamış biri olarak, bunun için hâlâ erken demek bana
aws cloud yabancı geldiği için benimsemekte tereddüt edilen on-premise dönemini hatırlatıyor.

 
pppqqq 2022-06-21

"İşinize odaklanın" gibi genel ilkesel bir düzeyde söylenmiş bir şey değil bu; daha çok belirli bir teknolojiye kilitlenmeye yol açan kararları kabul etmekte zorlanıyorum.
beanstalk/app engine/heroku gibi PaaS'lerin aktif olarak kullanılmasını savunan bir yazı olsaydı buna güçlü biçimde katılırdım, ancak bugünlerde küçük ekiplerin ECS/cloud run/docker swarm'ı seçerek elde ettiği avantajlar neredeyse yok denecek kadar az. 4-5 yıl önce olsaydı belki.

 
jjpark78 2022-06-21

Maliyet açısından bakarsak serverless ezici biçimde avantajlı.

 
tribela 2022-06-21

Ben de katılıyorum. Çoğu durumda docker-swarm ya da docker-compose fazlasıyla yeterli oluyor.

 
kbumsik 2022-06-21

Hacker News yorumlarında da çok sık dile getirilen bir görüş ama..... [1]
Yazı, "Kubernetes zordur" ön kabulü üzerine kurulu olduğu için biraz kafa karıştırıcı görünüyor.

Bugünlerde Kubernetes ekosistemi epey gelişti; on-prem ortamda Kubernetes’i doğrudan kendiniz kurmadığınız sürece o kadar da zor değil.
Ayrıca Kubernetes işletiminde karmaşıklık seviyesini bir ölçüde kendiniz belirleyebilirsiniz; temel bir yapı kurmak o kadar zor değil. Sonradan oraya buraya çeşitli eklentiler bağlarsanız tabii ki zorlaşır.
Benim gibi daha kariyerin başında dağıtım ortamını EKS ile deneyimlemiş pek çok kişi de var.

Açık konuşmak gerekirse, temel bir k8s Deployment ve Ingress yapısını kurmanın (tabii DB ayrı bir managed service olacak şekilde), o yazıda bahsedilen AWS ECS Fargate’i doğrudan yapılandırmaktan neden daha zor sayıldığını pek anlayamıyorum.
Sonuçta her ikisinde de VPC, cluster, CDN ve load balancer yapılandırması yapmak gerekiyor... Hatta yorumlarda ECS’nin daha kullanışsız olduğuna dair çok sayıda yazı da var.

[1] https://news.ycombinator.com/item?id=31795160

 
colus001 2022-06-23

Katılıyorum. Temel kurulumun o kadar da zor olmadığını ve bakım zorluğunun da çok yüksek olmadığını düşünüyorum. Bulutta karmaşık bir kurulumu alıp Kubernetes yml kurulumu olarak aktarmanın da tam olarak neyi daha iyi yaptığını söyleyemem.

 
sixmen 2022-06-22

Şirketimizde geliştirici sayısı 100’ü aşınca buna ihtiyaç duyulduğunu hissedip ECS -> EKS geçişi yapıyoruz, ancak bazen biraz pişmanlık da duyuyoruz.

"Kubernetes operasyonunda karmaşıklık düzeyini bir ölçüde kendiniz belirleyebilirsiniz" deniyor ama konuya çok hakim olmayan birinin gözünden bakınca, Kubernetes ekosisteminde adı geçen her şey herhalde gerekli diye düşünüp hepsini ekleme eğilimi oluyor.

Load balancer yapılandırması yapmanın sonuçta aynı şey olduğu söylenmiş ama bence sadece ALB’yi bilmekle ALB + Ingress’i de bilmek zorunda olmak arasında fark var.

Küçük ölçekte MSA’ya ihtiyaç olmaması gibi, Kubernetes de düşünüldüğünden daha fazla şey bilmeyi gerektiriyor; bu yüzden "uygulamaya odaklanılması gereken ölçekte" over-spec olduğu görüşüne katılıyorum.

Yine de biri Kubernetes ortamını iyi kurmuşsa, onun üzerinde uygulama dağıtmak buluttan bağımsız bir ifade biçimiyle tanımlandığı için vendor lock-in etkisinin daha az olabileceğini düşündüm.

 
kbumsik 2022-06-22

Söylediklerinizi duyunca gerçekten de böyle yönler olabileceğini düşünüyorum. Ben Kubernetes kullanırken öğrendiklerimi biraz fazla doğal karşılamışım gibi görünüyor.
Ayrıca son zamanlarda Kubernetes ekosisteminde çıkan eklentilerin çok fazla olması nedeniyle hangilerini seçip hangilerini eleyeceğine karar vermenin zor olduğunu da kabul ediyorum.

Benim ECS -> EKS gibi bir migration deneyimim olmadığı için... acaba lock-in etkisi gibi şeyler dışında, geçişten sonra daha iyi hale gelen noktalar oldu mu diye merak ediyorum.

 
kbumsik 2022-06-21

Bu arada deneyimimin EKS bazlı olduğunu belirteyim. On-prem’de k8s’i doğrudan kurup etcd, Control Plane’i bizzat işletmekten oldukça farklı tabii :)

k8s ile başlamış biri olarak yazıyı okurken aklımdan tam tersi geçti: Acaba gerçekten de zaman harcayıp ECS öğrenmek gerekli mi...?
Neyse, illa böyle resmî bir standart belirlemeye gerek olmadan, önce ekip hangi yöntemi rahat buluyorsa onu kullanmak daha doğru değil mi diye düşünüyorum.

 
525hm 2022-06-22

K8s'e başlama yaklaşımına katılıyorum.

 
mrchypark 2022-06-21

Buna çok katılıyorum.

Sadece 10 kişilik şirketler değil, belli bir büyüklüğe ulaşmış şirketlerde de k8s benimsenmesine ben olumsuz bakıyorum.

Bunun ancak bulut sağlayıcısına bağımlılık kritik bir seviyeye geldiğinde ya da on-prem gibi altyapıların birlikte kullanıldığı bir düzeye ulaşıldığında anlamlı olabileceğini düşünüyorum.

 
jujumilk3 2022-06-21

Kurumsal ölçekli şirketlerin teknoloji yığınlarını ataletten takip etme gibi bir yanımız olduğunu düşünüyordum.
Tam da bunun yazıya dökülmüş hali Hacker News'te karşıma çıkınca paylaşmak istedim.