Kubernetes’e 11 haftalık geçişin ardından şirket varlık nedenini unuttu (2020)

 (theolognion.com)
1 puan yazan GN⁺ 2024-03-02 | 1 yorum | WhatsApp'ta paylaş
  • Silikon Vadisi girişimi Xenobroom Inc., 2020 Mayıs’ında pandemi sırasında günlük kullanım hızla artınca mevcut sunucu altyapısını Kubernetes’e taşımaya karar verdi
  • Geçiş, basit bir dağıtım iyileştirmesinin ötesine geçerek bash scriptleri ve VPS tabanlı yapının yeniden gözden geçirilip yeniden tasarlandığı uzun vadeli bir çalışmaya dönüştü
  • Bağımlılık ve kütüphane yükseltmeleri, PostgreSQL’in bir bölümünün dağıtık KV depolamaya dönüştürülmesi ve AWS esnekliğinden yararlanılması da sürece eklenince kapsam sürekli genişledi
  • Mevcut staging sunucusu ve develop branch tabanlı günlük dağıtımın yerini production-only CI iş akışı, dinamik yönlendirme, A/B testleri ve bölgesel bağımlılık desteği aldı
  • Geçişin bittiği sanılan noktada ekipte kimse ürünün amacını hatırlamıyordu; kullanıcılar ve yatırımcılar da orijinal ürünü anlamadıklarını kabul edince geri yükleme fiilen imkansız hale geldi

Kubernetes geçişiyle büyüyen iş kapsamı

  • Xenobroom Inc., 2020 Mayıs’ında sunucu altyapısını yükseltmeye başladı
    • CEO’nun günlük notları ve CTO’nun mühendislik notlarına göre, pandemi sırasında günlük kullanım keskin biçimde arttı
    • Bunun ardından mevcut altyapının Kubernetes’e taşınmasına karar verildi
  • Çalışma beklenenden uzun sürdü
    • Basit bash scriptleri ve VPS makinelerinin yeniden kurulması, gözden geçirilmesi ve yeniden mühendislikten geçirilmesi gerekti
    • Şirket içinde bunun yazılım bağımlılıklarını ve kütüphaneleri de yükseltmek için bir fırsat olduğu düşünüldü
  • Altyapı değişikliği daha büyük bir yapısal dönüşüme yol açtı
    • Tek bir makinede çalışan PostgreSQL veritabanının büyük bir bölümünün dağıtık KV depolamaya çevrilebileceğine karar verildi
    • Buna AWS’nin esnekliğinden yararlanma gerekçesi de eklendi
    • develop branch’ten her gün dağıtım yapılan basit staging sunucusu ortadan kalktı
    • Onun yerine dinamik yönlendirmeye sahip, A/B testlerini ve bölgesel bağımlılıkları sorunsuz destekleyen production-only CI iş akışı devreye alındı

Ürünün amacının kaybolması ve dışarıdan yardım

  • Geçiş süreci tamamlanmış gibi göründüğünde, şirket içinde hiç kimse ürünün amacını hatırlamıyordu
  • Kullanıcılar ve yatırımcılar da durumu çözemedi
    • Her iki grup da aslında ürünü en başından beri tam olarak anlamadıklarını açıkça kabul etti
    • Haftalar süren kesintinin ardından ürünün anlamını yeniden kurmak fiilen imkansız hale geldi
  • CEO, Phutar Afrayughum adlı bir medyum ve duyular ötesi algı uzmanından yardım istedi
    • Kendisi, Google’ın mesajlaşma uygulaması pazar payını artırmasına yardımcı olmuş ve Material Design framework’ünün geliştirilmesinde yer almış biri olarak tanıtıldı
    • Ancak bu yardım “allegedly” olarak aktarıldı; yani doğrulanmış bir gerçek olarak sunulmadı

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-02
Hacker News yorumları

  • Şu yazı daha komik: Orta kademe yöneticilerin %20’si işten çıkarılınca geliştirici üretkenliği tesadüfen 3 kat arttı diyor
    https://www.theolognion.com/p/company-accidentally-increased...

    • Buna hiciv demek bile zor

  • Bizim $dayjob’da da böyle bir geçiş işi yapılıyor; 2 yıl önce başladı ama hâlâ %30’u bile bitmedi
    Eskiden “Kubernetes’e geçmeliyiz, monoliti öldürmeliyiz” diye en yüksek sesle bağıranlar, şimdi LLM’lerle oyalanmaktan Kubernetes’i unutmuş durumda
    Bazı insanlar kavram kanıtlarını ve parlak yeni şeyleri gerçekten seviyor; o rolün de kendi içinde bir faydası var gibi

    • Yeni ve parlak teknolojiler üzerinden iş tatmini elde edilen bir yapı bu
      Bu yüzden zeki insanların etik dışı dev teknoloji şirketlerinde, reklam şirketlerinde ve gözetim şirketlerinde bile gayet memnun çalışıyor gibi görünmesi mümkün
      Şirketin neden var olduğu ya da kendi bilgisayarlarının dışında gerçekte ne yaptığı pek önemli değil; önemli olan teknoloji ve yeninin peşinden gitme özgürlüğü
      Şirket de bu insanların ürettiği üretkenliği ve tutkuyu seviyor, onlara iyi de ödeme yapıyor
      Genelde bu tür geliştiricilerin de vicdanı oluyor; ama o vicdan çoğu zaman şirket dostu iyi niyetli sosyal hareketler biçiminde soğurulup sergileniyor
    • Bu, kapsam genişlemesinden çok kasıtlı CV odaklı geliştirmeye yakın
      Birileri “X’i yaptım” diyebilmek için kutucukları tek tek işaretliyor
      Küçük ekiplerde bu yaklaşım üretkenliği gerçekten hızlı durdurabilir ve çoğu zaman her sorunu çözme isteğiyle paketlenir
      Ama sonuçta hiçbir sorun çözülmez; aksine daha fazla yeni sorun ortaya çıkar
    • FAANG’a yakın şirketlerde terfi etmek çok zor ve seviye sistemi yüzünden maaşı artırmanın tek yolu çoğu zaman terfi oluyor
      Terfi için bir terfi paketi gerekir; terfi paketi için de büyük ve ağır bir proje gerekir
      Sonunda çözülmeye çalışılan asıl sorun iş ihtiyacı değil terfi olunca, sorun arayan dev projeler ortaya çıkıyor
    • Şirket parasını yakmak açısından işe yarayabilir belki
      Anlattığınız şey kavram kanıtı bile değil gibi. Kavram kanıtının temel şartı en azından çalışmasıdır; bu ise sürüyü takip edip meşgul görünmek için bir kurgu üretmeye daha yakın
      Çalışan açısından da uzun süre kalmak için iyi bir ortam gibi durmuyor
    • Böyle insanların aslında en çok terfi alan kişiler olması muhtemel. Gerçekten çarpık bir düzen

  • O blogda daha komik yazılar da çok. Özellikle şunu sevdim:
    https://www.theolognion.com/p/dev-builds-perfect-note-taking...
    Bir de bu var:
    https://www.theolognion.com/p/ai-solves-all-political-econom...

  • Şaka olduğunu biliyorum ama bir olay sonrası analiz yapılacak olsa, başarısızlığın nedeni muhtemelen şu olurdu: “Şirket içinde birçok kişi bu fırsatla yazılım bağımlılıklarını ve kütüphaneleri de yükseltelim diye düşündü. Tek makinede çalışan PostgreSQL veritabanının büyük bölümlerinin de AWS’in muazzam esnekliğinden yararlanılarak dağıtık bir anahtar-değer deposuna dönüştürülebileceğini sandılar”
    Kapsama sadık kalmak gerekir

    • Bu da zaten şakanın özüne oldukça yakın
      Dünyada, yaptıkları üründen çok kullandıkları teknolojiye odaklanan çok insan var
      Ürüne odaklanmak, kapsamı bilmek ve çok erken aşırı tasarım yapmamak demek
      Şaka Kubernetes’e odaklanıyor ama aynı şey sunucu tarafı render, AI, $modernFrontendLib, $modernLanguage ile de yapılabilir
    • Şirketin kapsamına da sadık kalmak gerekir
      İşiniz bulut altyapısı satmak değilse hazır bulut sağlayıcısı kullanın
      Zaten bir bulut sağlayıcısına para ödüyorsanız, özellikle Kubernetes kullanmamak daha iyidir

  • Gerçekte 11 haftalık bir Kubernetes geçişi büyük başarı sayılırdı

    • Aslında 11 ay sürerdi ve artık “cloud native” gibi bir durumda olurdunuz
      Tabii veritabanı işletmek biraz zor olmuş olurdu. Çünkü Kubernetes depolama ayarlarını düzgün yapmayı unuttuğunuz için pod aniden başka yere taşınınca veriler kaybolurdu
    • Zaten Docker kullanıyorsanız bu kadar uzun sürmesi için pek neden yok
      Docker bile kullanmıyorduysanız, benzer bir geçişte sorunun Kubernetes’in kendisi olmama ihtimali yüksek

  • Sistem işletmek hiç bugünkü kadar kolay ve ucuz olmamıştı
    Ama mühendisler bir pizza teslim etmek için keşif ekibi kurmayı, Everest’e tırmanmayı, zirvede pizzanın fotoğrafını çekmeyi, sonra tekrar uçakla eve getirmeyi, Lamborghini kiralayıp Moğol Rallisi’ni koşmayı ve 18 ay sonra o pizzayı teslim etmeyi tercih ediyor
    Oysa ucuz bir scooter’a binip sokağın aşağısına inmek kazanmak için yeterli

    • Mühendislerin enjekte ettiği karmaşıklığın, yönetimin enjekte ettiği karmaşıklıkla boy ölçüşebildiği bir yerde hiç çalışmadım

  • Karmaşık bir teknolojiyse önce öğrenmek gerekir. Önce küçük ve kritik olmayan bir serviste denemek gerekir
    Her seferinde tek bir şey yapmalı ve basit başlamalı
    Ben servislerimizi sorunsuz biçimde Kubernetes’e taşıdım ama küçük servisleri taşıyarak öğrenmek ve denemek 2 yıl sürdü
    Birkaç yaklaşımı denedikten sonra en uygun yönteme ulaştık; bu, internette hemen bulabileceğiniz türden bir yöntem değildi
    GitOps kullanıyoruz ama otomasyon yapmıyoruz; gereken şeyler için sadece kubectl apply -k çalıştırıyoruz. Çünkü o sırada flux’ın başlamak için gereksiz karmaşık olduğuna karar vermiştik
    Artık onlarca servisimiz ve yeterli anlayışımız olduğu için flux’a geçmeyi düşünüyoruz

  • 1977'de saatlik ücretle faturalandırma yapan bir hukuk bürosunda genç bir duruşma avukatı olarak çalışıyordum
    Hangi dava için ne yaptığımızı kâğıda kaydediyorduk; büro personeli de tamamlanmış kâğıttan koparılabilir şeritleri kesip her davanın kâğıt klasörünün içindeki panoya yapıştırıyordu
    1979'da bir RadioShack Tandy I aldım ve kısa süre sonra evde DOS tabanlı veritabanı programı Foxbase'e derinlemesine daldım. Daha sonra FoxPro oldu ve 1990'ların başında Microsoft tarafından satın alındı
    1981'de kendi hukuk büromu açtım; o dönemde ofis üretkenliğindeki en son yenilikler faks ile tek satırlık ekranı, belleği ve form saklamak için küçük bir diski olan elektrikli daktiloydu. Şirketler henüz kişisel bilgisayar kullanmıyordu
    Hukuk bürom kısa sürede yaklaşık 10 avukat ve 12 destek personeli büyüklüğüne ulaştı; tüm sekreterlere Compaq bilgisayar aldım
    Elle şerit yapıştırmanın yerini alacak bir zaman ve faturalandırma programı yazmak için çok zaman harcadım; ağ kurmayı da öğrenip kurulumu kendim yaptım
    Tanıdığım diğer hukuk bürolarının hiçbirinde bilgisayar yoktu; bizde ise destek personeli için 10'dan fazla, müşterilere göndermeden önce faturaları inceleyecek avukatlar için de 4-5 “taşınabilir” Compaq vardı
    Aynı zamanda işimi batırıyordum. Başkalarında tek bir bilgisayar bile yokken dünya çapında teknolojiye sahiptik; ama avukatlık işine ya da kurumsal müşteri satışına odaklanmak yerine kapımı kapatıp sadece programlama yapıyordum
    Sonunda 1994'te hukuk bürosunu kapattım
    Yine de heyecan verici bir dönemdi. Kısa süre sonra tüm hukuk büroları kelime işlem için bilgisayar sahibi oldu ama ticari faturalandırma programları hâlâ yoktu
    Yaklaşık 24 ay boyunca birlikte çalıştığım diğer hukuk bürolarındaki avukatların hepsi benim faturalandırma programımı istiyordu
    Ama dava işleri altında ezilirken bile eğlenceli olan programlamaya gömülmüştüm; kendi hukuk pratiğim de program için mükemmel bir laboratuvardı. Ne yazık ki o programlama işimi batırdı

    • O koparılabilir şerit yöntemi gerçekten ilginç. O dönemde zaman takibi için yaygın bir yöntem miydi merak ediyorum
      Eğer fotoğrafı kaldıysa görmek isterim

  • Benim alanımda “Kubernetes” yerine GraphQL/React/Next koysanız da aynen geçerli
    Üstelik bu, kusursuz çalışan bir uygulamayı, hem de çoğunlukla CRUD olan bir uygulamayı taşımak için yapılıyor
    GraphQL'in ya da etkileşimli frontend'in getirdiği ödünlere hiç ihtiyaç olmadığı hâlde bunu yapıyorlar
    Bu sektörde ne kadar uzun kalırsam, sorumluluk sahibi pozisyonlardaki insanların çoğu zaman ne yaptıklarını bilmediğini o kadar çok görüyorum

    • İnsanlar bir şeyleri sürekli düzgün çalışır hâlde tutmak için ödüllendirilmiyor
      Değişim için ödüllendiriliyorlar; yeter ki bu değişimin sonuç verdiğini ya da en azından bir gün sonuç verecekmiş gibi göründüğünü iddia edebilsinler

  • Kendi barındırdığımız MinIO'dan yönetilen blob depolamaya 500 bin blob taşımak için 4 aydır gece gündüz uğraşıyorum; siyaset ve bürokrasi dışında gerçekten üretken iş 1 haftayı bile bulmaz
    Bu yüzden 11 haftalık bir Kubernetes geçişi büyük başarı gibi geliyor