Figma’nın 12 Ay İçinde K8s’e Nasıl Geçtiği
(figma.com)- Figma, zaten konteynerleştirilmiş olan temel servislerini ECS’den EKS tabanlı Kubernetes’e taşıyarak, kesinti olmadan uzun vadeli platform sınırlamalarını azaltmayı hedefledi
- ECS’de StatefulSets’in olmaması, Helm chart tabanlı OSS işletiminin zorluğu ve node izolasyonu kısıtları önemli sorunlardı; Kubernetes ise CNCF ekosistemi ile Keda, Karpenter ve Istio gibi seçeneklerin önünü açtı
- Migrasyonun kapsamı, servis çalıştırma, dağıtım ve araç soyutlamalarını koruyup yalnızca orkestrasyonu değiştirecek şekilde daraltıldı; Bazel tabanlı servis tanımı ve 3 EKS cluster kurulumu başlangıç kapsamına dahil edildi
- Geçiş sürecinde yük testi, Weighted DNS tabanlı kademeli trafik aktarımı, gerçek servislerin erken taşınması, ham YAML’ın gizlenmesi ve servis sahipleriyle işbirliği sayesinde rollback imkânı güvence altına alındı
- 2024 Ocak ayına kadar en yüksek öncelikli servislerin çoğu EKS’e taşındı; aşırı provisioning maliyetlerinde düşüş, güvenilirlik artışı ve geliştirici deneyimi iyileştirmesi sağlandıktan sonra logging, otomatik ölçekleme ve Graviton geçişi sürdürülüyor
ECS’den Kubernetes’e geçme nedeni
- Figma, 2023 başında zaten tüm servislerini container olarak çalıştırıyordu ve orkestrasyon platformu olarak AWS Elastic Container Service(ECS) kullanıyordu
- Yeni nesil compute platformunu değerlendirirken, ECS’in üzerine inşa etmeye devam etmenin uzun vadede istenen özellikleri geliştirmeyi zorlaştıracağını düşündü
- Figma, binlerce mikroservis işleten bir şirket olmadığı için Kubernetes’e geçişin kapsamını gerçekçi biçimde yönetebildi
- İzolasyon veya performans nedeniyle yeni servis gereken durumlar olsa da, temel servisler temel modülerlik ve trafik izolasyonu sağlıyor
- Yeni ürünler de çoğu zaman yeni servis oluşturmak yerine mevcut temel servislerin içine mantık eklenerek destekleniyor
ECS’de eksik kalan özellikler
- ECS, Kubernetes’in StatefulSets özelliğini desteklemediği için etcd gibi güçlü tutarlılığa sahip konsensüs veri depolarını işletmek zordu
- Figma, etcd container’ı başlarken cluster üyeliğini dinamik olarak güncelleyen özel kodla bunu aştı
- Bu yöntem kırılgandı ve bakımı zordu; Kubernetes’te StatefulSets’in stateful ağ atamalarını kullanmak yaygın bir yaklaşımdır
- ECS’de Helm charts ile tanımlanan servis paketlerini çalıştırmak zordu
- ECS on EC2’de sorunlu tek bir EC2 makinesini zarif biçimde kapatmak da zahmetliydi
- EKS’de kötü bir node cordon edilirse API server kapatma prosedürüne saygı göstererek Pod’ları başka makinelere taşıyabilir
CNCF ekosistemi ve platform seçimi
- ECS’i kullanmaya devam etmek, Cloud Native Computing Foundation(CNCF) ekosistemindeki açık kaynak teknolojilerden yararlanmayı zorlaştırıyordu
- Otomatik ölçekleme, yeni nesil compute platformunda önemli bir ilgi alanıydı
- O dönemde Figma, container’laştırılmış servislere otomatik ölçekleme uygulamıyordu
- Gece ve hafta sonu gibi trafiğin düşük olduğu zamanlarda bile servisler pik yükü kaldırabilecek şekilde provision edildiğinden gereksiz maliyet oluşuyordu
- Kubernetes ekosistemindeki Keda, yalnızca CPU kullanımına değil AWS SQS kuyruk uzunluğu ve Datadog custom metriklerine dayalı ölçeklemeyi de destekliyor
- Service mesh’in de uzun vadede gerekli olma ihtimali vardı
- Mevcut servisler arası trafik AWS Application Load Balancers(ALB) ve Network Load Balancers(NLB) üzerinden yönlendiriliyordu
- NLB, yeni target kaydı ve mevcut target kaldırma için birkaç dakika gerektirerek acil dağıtım hızını düşürüyor ve olaylarda ortalama toparlanma süresini artırıyordu
- Envoy daha yüksek özelleştirilebilirlik ve custom filter çalıştırma olanağı sunuyor
- Figma, zaten önemli servislerin önüne proxy olarak bağımsız Envoy makine cluster’ları koymuş ve olaylar sırasında yükü azaltan custom filter’lar kullanmıştı
- EKS’de Istio gibi birçok açık kaynak seçenek bulunurken, ECS’de benzer işlevlerin yeniden şirket içinde yapılması gerekiyordu
Popüler bir platformun operasyonel avantajları
- Figma herhangi bir servis veya yazılımın en büyük kullanıcısı olmak istemiyor
- En büyük kullanıcılar pürüzlü noktalara ve ölçek sınırlarına en erken çarpma eğilimindedir
- Kubernetes, birçok büyük şirket tarafından devasa compute platformlarında kullanıldığı için Figma onun yanında çok daha küçük bir kullanıcı konumunda
- Kubernetes vendor lock-in’i azaltmaya yardımcı oluyor
- EKS, vendor tarafından desteklenen control plane’in avantajlarını sağlıyor
- Servisler genel Kubernetes üzerinde çalışacak şekilde yazıldığından, başka vendor destekli Kubernetes platformlarına veya self-hosted platformlara geçişin yükü büyük olmuyor
- Kubernetes deneyimi olan mühendisleri işe almak daha kolay
- Mevcut deneyime sahip mühendisler hızlıca uyum sağlayabiliyor ve Figma için yeni karar alanları olabilecek konularda bağlam sunabiliyor
Migrasyon kapsamını belirleme ilkeleri
- Büyük migrasyonlarda yalnızca değiştirilmek istenen çekirdek sistemi değiştirmek, platform kullanıcılarının gördüğü soyutlamaları ise mümkün olduğunca korumak daha güvenlidir
- Figma, ECS yerine EKS üzerinde çalışacak şekilde taşınmayı; ancak servis çalıştırma biçimini, dağıtım yöntemini ve servis etkileşim araçlarını değiştirmemeyi tercih ederek kapsamı daralttı
- Özellik değişikliği gibi görünmeyen işler bile ikincil etkiler yaratabildiğinden, büyük ölçekli migrasyon takvimleri kolayca büyüyebilir
- İki istisna vardı
- Yeni sistemin eski sistem gibi davranmasını sağlamak için aşırı ek çalışma gerekiyorsa, ikincil etkiler göze alınarak yeni yöntem tercih edilebilir
- Daha sonra değiştirilmesi zor veya maliyetli olan one-way door kararlarında yeni yöntem en baştan uygulanabilir
Kapsama dahil edilen iyileştirmeler
-
Geliştirici deneyimi
- Mevcut ECS servis tanımları ağırlıklı olarak Terraform ile oluşturulup değiştiriliyordu
- Terraform apply ile 0 instance’lı ECS task set şablonu oluşturuluyor, ardından dağıtım sürecinde şablon kopyalanıp image hash’i değiştiriliyor ve instance sayısı 0 olmayan task set ECS’e dağıtılıyordu
- Tek bir ortam değişkeni eklemek için bile Terraform yazmak ve apply etmek, ardından dağıtımı çalıştırmak gerekiyordu; sıra korunmazsa ortam değişkeni kodda güvenli şekilde kullanılamıyor ve bug oluşuyordu
- EKS’de servis tanımlarını tek yerde tutup değişiklikleri tek adımda dağıtacak şekilde değiştirildi
- Figma, servisleri Bazel yapılandırma dosyasıyla tanımlayan basit bir dahili yöntem oluşturdu ve servis tanımı YAML ile Ingress gibi yapılandırma YAML’larını otomatik üretti
- YAML, kod commit edildiğinde CI aracı tarafından üretiliyor ve şirket içi dağıtım sistemi üzerinden uygulanıyor
-
Güvenilirlik
- Her servis için 3 EKS cluster Pod çalıştıracak ve trafik alacak şekilde yapılandırıldı
- Tüm operasyonlar cluster düzeyinde gerçekleşirse, tam bir arızanın etkisi servisin üçte birine indirilebilir
- Retry istekleri veya asenkron işleme yapabilen servislerde kullanıcı kesintisi çoğu zaman minimuma iner
- Bu yapılandırma dağıtım pipeline’ı gibi operasyonel karmaşıklığı ciddi biçimde artırdı, ancak daha sonra eklemektense migrasyon sırasında uygulamanın değerli olduğuna karar verildi
-
Maliyet verimliliği
- Karmaşık maliyet optimizasyonu işleri migrasyon kapsamına fazla alınmadı, ancak node otomatik ölçekleme en baştan desteklendi
- ECS on EC2 servislerinde dağıtım sırasında yaşanan ani artışları karşılamak için makineler aşırı provision ediliyordu
- EKS’de Karpenter kullanılarak node’lar talebe göre dinamik biçimde büyütülüp küçültülüyor
Kapsam dışında bırakılan işler
- Mevcut logging pipeline’ı karmaşıktı
- Tüm log’lar önce CloudWatch’a yazılıyordu
- Lambda log’ları okuyup belirli pattern’leri silme ve tag ekleme gibi dönüşümler yapıyordu
- Ardından Datadog ve Snowflake’e yazılıyordu
- Ara depolama olan CloudWatch maliyeti büyüyordu
- Figma, EKS stack’inde log’ları sidecar olarak işleyip iletebilen CNCF projesi Vector’ı devreye almayı planladı
- Ancak log forwarder mantığını Vector yapılandırmasına port etmenin ikincil etkilerini göze almaya değmeyeceğini düşünerek bunu migrasyon kapsamı dışında bıraktı
- Pod düzeyinde otomatik ölçekleme de migrasyona dahil edilmedi
- Karmaşıklığının çok yüksek olduğu değerlendirildi
- Daha sonra kolayca eklenebilecek bir iş olarak görüldü
- Hariç tutulan işler daha sonra takip çalışmalarına dönüştü ve diğer servislerin EKS’e taşınmasıyla paralel ilerlerken iyileştirmeler sunabildi
Güvenli yürütme biçimi
- Mevcut ECS stack’i nispeten stabil olduğu için yeni EKS stack’i ve geçiş sürecinin de en az onun kadar güvenilir olması gerekiyordu
-
Yük testi
- Figma bir “Hello, World” servisi oluşturdu ve Figma’nın en büyük servisiyle aynı sayıda Pod çalışacak şekilde ölçekledi
- Bu test, tüm platformu destekleyen temel compute servislerinin boyutlandırılıp ölçeklenmesi gerektiğini ortaya çıkardı
- Kyverno bir cluster güvenlik doğrulama aracı olarak, yeterince büyük yapılandırılmazsa yeni Pod başlangıcını yavaşlatabiliyordu
-
Kademeli rollout
- Weighted DNS kayıtları kullanılarak trafik mevcut ECS servisinden EKS karşılığına azar azar taşındı
- İnce ayarlı trafik geçişi ve geri alma kontrolü güvenli migrasyonun temeliydi
- Beklenmedik etkiler bilinmeyen kırılma noktalarında ortaya çıkabileceğinden, etki alanını azaltmak ve hızlı rollback yapabilmek gerekiyordu
-
Gerçek servisleri erken çalıştırma
- Gerçek workload’u sisteme koymak, yalnızca staging ile öğrenilemeyecek pek çok şeyi öğretir
- Figma, staging ortamını tamamlamadan önce bile bir servisi taşımıştı
- Bu erken taşıma, workload çalıştırma yeteneğini uçtan uca doğrulamaya ve darboğazlarla bug’ları bulmaya yardımcı oldu
-
YAML soyutlaması
- Kullanıcılara servisleri doğrudan ham Kubernetes YAML ile tanımlatmak kafa karıştırıcı olabilir
- Figma kullanıcılara bir golden path sundu ve yalnızca özel durumlarda özelleştirme yapmalarına izin verdi
- Kullanıcıların neyi özelleştirebileceğini ve özelleştirmesi gerektiğini netleştirirken varsayılan tutarlılığı zorunlu kılarak bakım ve gelecekteki değişiklikleri basitleştirdi
-
Servis sahipleriyle işbirliği ve personel planlaması
- Yeni servis ayarlarını platform ekibi üstlendi; monitoring ve alert güncellemeleri ise servis durumunu en iyi bilen servis sahipleriyle yakın işbirliği içinde yapıldı
- Migrasyon başlamadan önce de servis sahipleriyle seçenekler ve trade-off’lar kapsamlı biçimde tartışıldı
- Büyük ölçekli migrasyonlar beklenmedik sorunlar, karmaşık etkileşimler ve sıradan bug’lar yaratabileceğinden derin teknik uzmanlığa ve debugging becerisine sahip bir ekip gerekiyordu
Gerçek migrasyon takvimi ve sonuçlar
- 2023’ün 1. çeyreğinde plan oluşturuldu ve migrasyonun ilerlemesi için onay alındı
- 2023’ün 2. çeyreğinde staging ortamı oluşturuldu ve tek bir servis taşındı
- 2023’ün 3. çeyreğinde production’a hazırlama, yük testi ve ek servis taşımalarına hazırlığa odaklanıldı
- 2023’ün 4. çeyreğinden 2024 Ocak ayının ilk haftasına kadar servis trafiği yavaşça geçirildi
- 2024 Ocak ayına kadar en yüksek öncelikli servislerin çoğu yeni EKS cluster’larına taşındı
- Temel iş mantığını içeren monolith
- Figma dosya düzenlemenin multiplayer tarafını işleyen karmaşık servis
- Tüm client’lara gerçek zamanlı güncellemeler push eden Livegraph 100x bileşen servisleri
- Sonuç olarak dağıtım için yapılan aşırı provisioning maliyetleri azaltıldı, 3 cluster’da çalıştırma ile güvenilirlik artırıldı ve geliştirici kullanılabilirliği iyileştirildi
- Tüm çalışma küçük olaylar ve düşük müşteri etkisiyle ilerledi
- Bir operatörün production cluster’larından birinde yanlışlıkla CoreDNS’i yok edip yeniden oluşturduğu bir olay yaşandı
- Önceki yapılandırmada bu tam bir kesintiye dönüşebilirdi
- 3 cluster yapılandırmasında etki isteklerin üçte biriyle sınırlı kaldı
- Downstream servislerin çoğu istekleri retry ederek sonunda başarılı oldu
Yayın sonrası araç iyileştirmeleri
- Figma, servis sahiplerinin cluster’da olup biteni debug edebilmesi için araçlar geliştirdi
- Çalışan instance sayısını kontrol etme
- Container shell erişimi
- Acil ölçekleme gibi operasyonel işleri gerçekleştirme
- Yayından hemen sonra bu erişim aracının yeterince kullanıcı dostu olmadığı yönünde geri bildirim alındı
- Karmaşıklığın iki nedeni vardı
- 3 cluster’a geçiş nedeniyle kullanıcıların birden fazla cluster üzerinde komut çalıştırması ve her komuta cluster adını eklemesi gerekiyordu
- Kubernetes RBAC rollerinden yararlanarak daha ayrıntılı yetkiler sağlandığı için kullanıcıların kendilerinde hangi rollerin olduğunu ve belirli bir işlem için hangi rolün gerektiğini anlaması gerekiyordu
- Figma diğer işleri hemen durdurdu ve aracın uygun cluster ile rolü otomatik çıkarsayacağı şekilde düzenleme yaptı
- Kullanıcılar özellikle gece yarısı acil durumlarda rol aramak için zaman kaybetmek zorunda kalmıyor
Sonraki adımlar
- Kalan servislerin taşınmasına devam edilirken yeni compute platformundaki iyileştirmeler paralel biçimde yürütülüyor
- Mevcut odak alanları şunlar
- Logging pipeline tasarımını basitleştirme
- Keda üzerinden yatay Pod otomatik ölçeklemeyi destekleme
- Figma’da maliyeti en yüksek servisleri Graviton işlemcilere taşıyarak maliyetleri azaltma ve gelecekte diğer servislerin de Graviton üzerinde çalışması için yol açma
- Henüz derin yatırım yapılmamış alanların da keşfedilmesi planlanıyor
- Service mesh tekliflerini inceleyerek networking stack’inin güvenilirliğini ve gözlemlenebilirliğini iyileştirme
- AWS Controllers for Kubernetes(ACKs) ile daha fazla kaynağı yöneterek Terraform bağımlılığını azaltma ve stack’i basitleştirip birleştirme
- Servislerin geliştirme ortamında çalıştırılma biçimiyle diğer ortamlarda çalıştırılma biçimini birleştirmek için geliştirici deneyimi ekibiyle çalışma
1 yorum
Hacker News görüşleri
Şahsen Kubernetes'i seviyorum. Küçük ama karmaşık, özel yapım birkaç e-ticaret mağazası işletiyorum; pazarlama, finans ve müşteri desteğini de birlikte üstleniyorum.
Eskiden özel sunucularda çalıştırıyordum; stack oldukça karmaşık olduğu için dağıtım bir kâbustu ve sonunda dağıtım yükü küçük şirketin hızını yavaşlatıyordu.
Kubernetes'i öğrenip taşınmak bir ay sürdü; frontend, ürün yöneticisi, lojistik panosu, teslimat rotası optimizasyonu, OSRM, ERP, öneri motoru, arama vb. yaklaşık 25 servis çalıştırıyorum.
Küme yapılandırmasını tek yerde toplayınca tekrarlanabilir bir yapıya oturttum ve her servisin durumunu ve çalışan sürümünü tam olarak bilebilir hale geldim. Kesintisiz rolling deployment da mümkün oldu; karmaşık, ama programcılar zaten karmaşık şeylerle uğraşır. Nginx yapılandırma dosyaları da karmaşık.
Derine indikçe Kubernetes mimarisinin neden mantıklı olduğunu anlıyorsunuz ve 12-factor'a sıkı sıkıya uymaya zorluyor. Geliriniz stack'in erişilebilirliği ve kararlılığıyla doğrudan bağlantılıysa yüksek erişilebilirlik yalnızca “olsa iyi olur”dan fazlasıdır. Barındırma maliyeti de ayda yaklaşık 400 dolar, o kadar pahalı değil.
Kubernetes'e inananlardanım, ama gerçekten karmaşık. Zor sorunları çözen bir araç. Multi-cloud ise düşünmeye gerek yok; yerelle 1:1 karşılığı olan karmaşık bir altyapı istiyorsanız iyi uyar.
Ama 100'den az geliştiriciniz varsa ve AWS'ye yalnızca konteyner dağıtıyorsanız, 2024'te ECS + Fargate yerine EKS kullanmak bana akıl kârı gelmiyor.
Altyapı temelini iyileştirmeye yönelik migration'ın kendisi iyi. Ancak motivasyonlardan birinin ekiplerin Terraform'a dönüştürmek yerine Helm chart kullanmasını sağlamak olması şaşırtıcıydı.
Pratikte rastgele bir Helm chart'ı değişiklik yapmadan güvenilir şekilde kullanan pek görmedim; kullanımı teşvik ederseniz ekipler sonunda chart'ları fork'layıp değiştirmeye başlıyor. Helm o kadar berbat bir araç ki kendi özel Helm chart'larımı bakımda tutmak istemem.
Bence Terraform ile yeniden yazmak, yerel bir sürümü bakımda tutmayı kolaylaştırıyor. Aksi yönde örnek varsa duymak isterim. Belki bugünlerde Helm'in
indent 4çılgınlığı ve çok aşamalı string template sorunları ortadan kalkmıştır.Kubernetes workload'larını Terraform ile yönetmek de mümkün ama önermem. Kubernetes'in kendi state'i var; Terraform da state tutunca Terraform + Kubernetes kombinasyonu can yakıcı hale geliyor. Helm Kubernetes için yapıldı, Terraform değil.
Bu, Helm'i sevdiğim anlamına da gelmiyor. Template'leştirilmiş YAML hoşuma gitmiyor ve
indent 4çılgınlığı hâlâ var. Kustomize basitken iyi ama uygulama karmaşıklaştığında bence Helm'den daha kötü. Örneğin birden fazla ortam için Ingress, TLS sertifikası ve external-dns içeren bir uygulama dağıtacaksanız, tek bir değişkeni üç yerde kullanmak yeterliyken kaynakları üç kez patch'lemeniz gerekiyor.Helm de Terraform da çok popüler olduğu için sık anılıyor; ama sonunda bu ikisinin yerini alacak, henüz yaygınlaşmamış bir aracın çıkacağını düşünüyorum.
Terraform'un sorunu, workspace başına önerilen kaynak sayısı olan yaklaşık 100–200'ü aşmayacak şekilde workspace tasarlamak zorunda olmanız. Aksi halde hiç dokunmadığınız ve dokunmayı da düşünmediğiniz veritabanlarını veya ağları bile kontrol ettiği için plan ciddi şekilde yavaşlıyor ve dağıtım süresi uzuyor.
Gerçekte birbirini tetikleyen bir Terraform workspace kafesi oluşturuyorsunuz; bunu düzgün destekleyen iyi bir açık kaynak araç şu anda yok.
Şu an görünen en iyi yaklaşım, Terraform'un ArgoCD gibi bir sürekli dağıtım aracını altyapının bir parçası olarak kurması, günlük dağıtımları ise CD aracının üstlenmesi. Ve çoğu CD aracı dağıtımı Helm gibi bir şeyle paketlemenizi istiyor.
Ama o kadar çok tuzak var ki, diğer mühendislerin yaptığı işleri yeniden yapmak ve debug etmek için zaman harcamama neden oluyor.
timoniadlı yeni aracın ivme kazanmasını umuyorum. Helm'le ilgili neredeyse tüm şikâyetlerimi çözüyor. Daha iyi bir çözüm arıyorsanız timoni'ye bakmaya değer.Biz public Helm chart'ları olduğu gibi kullanıp özelleştirmeyi
kustomize —enable-helmile yapma yolunu seçtik.Bizim durumda makul varsayılanlar sağlayan tek bir uygulama/servis tabanlı Helm chart'ımız var ve tüm dağıtımlar bunu genişletiyor. Kullanıcı tarafında gereken Helm values ayarı minimum ve kendi template'lerimizi eklememiz gereken durum neredeyse hiç olmadı; çünkü temel chart yeterli ayar noktalarını açıyor.
Üçüncü taraf chart'ların önemli bir kısmını olduğu gibi dağıtabildik; bazen gereken özellikleri upstream'e PR olarak ekledik. Nadiren wrap etmek veya fork'lamak zorunda kaldık, ama olduğu gibi dağıttığımız üçüncü taraf chart sayısı çok daha fazla.
Özel chart'ları bakımda tutarken helm unittest (https://github.com/helm-unittest/helm-unittest) regresyonlardan kaçınmada çok yardımcı oluyor.
Terraform ile ArgoCD dâhil birkaç Kubernetes kaynağını yönetiyoruz, ama genel olarak Helm chart'ları ArgoCD üzerinden dağıtmak çok daha yönetilebilir ve üretken oldu.
HN’de bu kadar çok Kubernetes karşıtı duygu olmasına şaşırıyorum. Yorum yapanların çoğu Heroku, fly.io, render.com gibi servislere alışkın geliştiriciler olduğu için mi, yoksa uygulamaları VM’lerde çalıştırdıkları için mi merak ediyorum.
Bu, belirli bir örnekle sınırlı bir sorun değil; sektör genelindeki ciddi biçimde yanlış hizalanmış teşviklerin ve bir ölçüde düşük faiz dönemi altına hücumunun yarattığı bir sorun.
Açıkçası şu anki hâliyle başka alanlarda epey işe yaramaz zanaatkârlar gibi görüneceğimizi düşünüyorum. Araçlara ve meta işlere sağlıksız biçimde takıntılıyız; belirli bir aracı kullanmak uğruna makul kaynak kullanımını sürekli pencereden atıyoruz. Bir tür “geçici olarak zor duruma düşmüş FAANG mühendisi” durumu.
AWS’te seçilebilecek dağıtım modelleri, örneğin EC2’de VM imajları, Elastic Beanstalk, ECS/Fargate, Lambda yerine Kubernetes üzerinde kurunca ne kadar daha uzun süreceğini, ne kadar daha fazla uzmanlık gerektireceğini, ne kadar daha kırılgan olacağını ve ne kadar daha pahalıya mal olacağını anlatmak zor.
Kendi ELK stack’imi ya da Prometheus’u kurup bakımını yapmak istemiyorum. CNI eklentileriyle, Kafka’yla, yüksek erişilebilirlikli Postgres’le, Argo’yla, Helm’le, control plane yükseltmeleriyle boğuşmak da istemiyorum. AWS’in karşılık gelen servisleriyle neredeyse anında başlayabiliyorsunuz, bakım neredeyse yok ve maliyet de genellikle sıfıra yakın bir noktadan doğrusal olarak başlıyor.
İş problemini çok daha hızlı ve verimli çözebilirsiniz. Beklentileri büyük ölçüde aşabileceğiniz bir durumla tüm ekibin birkaç çeyrek geriye düşmesi arasındaki fark bu.
Ancak gerçekten multi-cloud ya da on-premises gereksinimi varsa Kubernetes dışında bir şey kullanmak istemem. Kubernetes’i anlayan çok sayıda deneyimli mühendisin olduğu büyük bir şirkette bu o kadar da kötü olmayabilir. En azından benim çalıştığım yerler böyle değildi.
Şirketlerin ağırlıklı olarak açık kaynak altyapıya geçtiğini görmek güzel. Bunların hatırı sayılır bir kısmı CNCF (https://landscape.cncf.io), ASF ve GitHub’daki çeşitli projelerden geliyor.
kata-containers bu endişeyi giderebilir ve Kubernetes’ten keyif almamı sağlayabilir gibi geliyor.
Genel olarak Kubernetes’te kişisel olarak havalı bulduğum bir şey yok. Container’ları, load balancer’ları, megabaytlarca YAML’ı zaten gördüm; denemeye değecek kadar ilginç gelmiyor.
Bu ölçekte bir şirket için normal olabilir ama böyle devasa migration’ların ya da teknik projelerin karar süreçlerini takip etmek zor. Çünkü karar kullanıcıların ya da şirketin ihtiyaçlarından çıkmış gibi görünmüyor.
Figma’nın daha önce veritabanıyla ilgili yayımladığı benzer yazıda da aynı hissi almıştım.
Örneğin Kubernetes’e geçmek istemenin nedeni ECS’te etcd/Helm kullanamamaksa, önce neden etcd/Helm kullanmak istediğini sormak gerekir. Bu gerçekten o kadar önemli mi? Şirketin hedeflerine ulaşmanın yolu gerçekten tam olarak bu yöntem mi?
Karar kullanıcı ihtiyaçlarına dayanıyorsa alt kararların makul olup olmadığını doğrulamak kolaydır; ama teknik isteklere dayanıyorsa, bu alt kararlar o teknik isteğin bağlamında mantıklı görünse bile kullanıcı bağlamında hâlâ geçerli olup olmadıkları belirsizdir.
Ya ben bu ölçekteki organizasyonları anlamıyorum ya da bu ölçekteki organizasyonların değerli işleri tespit edip bunlar hakkında akıl yürütmesi temelden zor; ikisinden biri gibi geliyor.
Biz özünde bir platform ekibiyiz ve çoğu zaman gerçek ürün deneyimini oluşturan Figma geliştiricilerini destekleyen araçları yapan başka platform ekipleri için araçlar yapıyoruz. Son kullanıcıdan uzaklaştıkça doğru kararları akıl yürütmeyle bulmak zorlaşıyor ama aynı zamanda büyük bir kaldıraç da ortaya çıkıyor.
Platformu doğru inşa ederseniz etkisi, diğer tüm mühendislerin verimli ve etkili çalışma becerisini etkiler. Bu etkilerin çoğu dolaylıdır.
etcd ve Helm’i destekleyemeyeceğimize göre başka geçici çözümler bulun demek elbette bir seçenekti. Ancak bu ikisi, Compute platformunu yanlış temel yapı taşları üzerinde işlettiğimiz sonucuna bizi iten ek veri noktalarıydı.
Akıl yürütmek zor olsa da bunu iyi yapmaya çalışmak çok değerli. Çünkü bir platform ekibi olarak en iyi platforma ulaşmak için doğru şeyleri yapıp yapmadığımızdan emin olmanın yolu bu. Bu yüzden bu kararı vermek için çok zaman harcadık ve yazıya dökmek için ilginç bir konu olduğunu düşündüm.
Büyük şirketlerdeki Kubernetes migration’larının önemli bir kısmı muhtemelen multi-cloud ya da on-premises hibrit isteği, maliyet/erişilebilirlik/lock-in riskini azaltma motivasyonuyla ilerliyor.
VM yükseltmelerini, sertifikaları, yedekleri, log rotation’ı vb. hepsini uyumlu tutmanız gerekir.
Kubernetes’te herkese namespace, policy, volume verirsiniz; DaemonSet ve Kubernetes/cloud native stack sayesinde otomatik log toplama da mümkündür.
Self-healing gibi şeyler de var; ne kadar daha iyi olduğunu anlatmak zor.
Örneğin dağıtık ortamda
.piddosyasının karşılığı olarak kullanılabilecek, yüksek erişilebilirlikli ve tutarlı veri depoları pek yok. Aklıma Zookeeper geliyor; o da operasyon tarafında gerçekten acı verici, eski JVM sürümleri istiyor ve buna rağmen genel olarak istikrarsız.Terraform kodu uygulandığında 0 instance’lı bir ECS task set oluşturup hizmet şablonunu ayağa kaldırmaları; ardından geliştirici hizmeti dağıtırken bu şablon task set’i kopyalayıp bir dizi manuel işlem yapmak zorunda kalması, ECS’in sorunundan çok Terraform + ECS dağıtım yönetim biçimini aşırı karmaşık hâle getirmişler gibi geliyor
Gerçek dağıtımdan önce doğrulamak için şablon oluşturma kısmını anlıyorum. Ama bu biraz muğlak
Bu yüzden bu maddeyi bilinçli olarak migrasyon sürecine dahil etmeye karar verdiğimiz bir iş olarak sınıflandırdım; migrasyona başlamamızın temel nedenleri arasına koymadım
Yine de bu yöntemin gerekli hâle gelebileceği birkaç senaryo hayal edebiliyorum. Örneğin ECS’e dağıtılmış çok sayıda hizmet varsa Terraform state boyutu büyüyebilir. O zaman plan ve apply ciddi ölçüde yavaşlar; yapılandırmayı şablon tabanlı olarak birebir kopyalayıp Terraform state’i shard’lamak çok daha güvenli olabilir
Tek yaptığımız ortam değişkenlerini Terraform dosyasına eklemek, merge etmek ve ardından CI’ın dağıtmasını sağlamaktı. Yaptığımız çoğu yapılandırma değişikliği bu süreçle hallediliyordu
“Kubernetes’e geçmek yıllar sürebilir” derken ben ne okuyorum acaba
Kimin için böyle? Şirketlerin bu tür migrasyonlara neden giriştiğini de pek anlamıyorum. İş değeri nerede, müşteriye faydası nerede? Figma’nın yapabildiği için yaptığı bir “sanat için sanat” projesi mi bu?
Yaklaşık 30 yıllık, bunun getirdiği yükleri olan, çok oturmuş bir şirkette bile biz Kubernetes’e çok daha kısa sürede geçtik. Ama her şeyi Kubernetes’e taşımaya çalışmadık; sadece fayda görecekleri taşıdık
Önerimiz kabaca şuydu: Kubernetes’e geçerseniz yıl sonunda planlanan veri merkezi taşınmasında kontroller dışında hiçbir şey yapmanız gerekmeyecek. Aksi hâlde uygulamaları yeni makinelere ya da VM’lere yeniden dağıtmanız ve bunun getirdiği her türlü baş ağrısıyla uğraşmanız gerekecek. Zaten container’laştırılmamışsa şimdi container’laştırın, gerisini biz hallederiz
Çoğu ekip geçti ve sonuçtan çok memnun kaldı. Buna karşılık gecikmeye duyarlı ya da yüksek performanslı hesaplama alanındaki hizmetleri zorla taşımanın bir anlamı yoktu; uydurmaya da çalışmadık
Buradan çıkmak ne kadar sürer acaba?
Uygulama zaten mikroservislere ayrılmışsa geri dönmek de kolay değil
Görünüşte basit bir işlevi elde etmek için adını ilk kez duyduğum havalı isimli 6 CNCF projesinden rahatça bahseden bir blog yazısı okuyunca kendimi çağın gerisinde kalmış hissediyorum
Profesyonel yazılım geliştirmede yaşlanıp sahneden çekilme vaktim mi geldi diye ciddi ciddi merak ediyorum
Sadece organizasyonu ölçeklendirmenin bir yaklaşımına, yani platform ekibinin donanımı, loglamayı, retry’ları vb. soyutladığı tarza aşina olmadığın anlamına geliyor
Tek yaklaşım bu değil; başka yöntemlere aşina olabilirsin
Bu yazının Kubernetes’ten elde edilecek faydaları ve nedenleri açık ve tutarlı biçimde açıklamasını beğendim
Birçok ekip ne kazanacağını, hatta buna baştan ihtiyaç duyup duymadığını bilmeden atlıyor; burada sunulan nedenler makul görünüyor
Diğer yorumlar zaten bu noktayı gündeme getirmiş: https://news.ycombinator.com/item?id=41194506 https://news.ycombinator.com/item?id=41194420
Tamamen meraktan soruyorum: Aklı başında birinin 1 yıl içinde migrate ettik diye övünebileceği başka hangi modern sistem ya da hizmet var?
Kubernetes gibi sistemler genelde altyapının merkezinde yer alır ve çalışan her şeyi etkiler. Buna yazıda belirtilen ekip kısıtlarını da eklerseniz 1 yıl kulağa o kadar kötü gelmiyor
Aklıma hemen gelen örnek, Amazon’un eskiden Oracle’dan tamamen Amazon/açık kaynak ilişkisel veritabanlarına geçmesiydi. Ancak bunun birkaç yıl sürdüğünü hatırlıyorum. 1 yıl içinde bitirmiş olsalardı kesinlikle bununla övünürlerdi
Çoğu zaman mesele teknolojinin kendisinden çok teknik borç, entegrasyon karmaşıklığı ve ayrılan insan gücü oluyor