Bugün size, bir teknoloji profesyoneli olarak en sevdiğim eylemlerden birinden bahsetmek istiyorum: “çöpe atmak”. Hayır, hemen aklınıza fiziksel bir sunucuya tekme atmak ya da bir veri tabanını DROP TABLE ile silmek gelmesin. Benim için çöpe atmak, genellikle bir konsepte, bir mimariye, hatta bazen bir yaklaşıma atfettiğim değeri yeniden gözden geçirmek, gereksiz yükü sırtımdan atmak anlamına geliyor.
Kariyerimde öğrendiğim en önemli derslerden biri, her parlak yeni teknolojinin her sorunu çözmediği ve bazen en basit çözümün en iyisi olduğudur. Bu hafta da yine benzer bir durumla karşılaştım ve yıllardır alışkanlık haline getirdiğim bir “veri toplama” yaklaşımını zihnimin çöp kutusuna gönderdim. Bu benim için yeni bir durum değil; 2006’dan beri bu sektördeyim ve bu çöpe atma işlemi sürekli devam eden bir devinim.
Çöp Kutusu Kavramı: Bir Teknoloji Nasıl Gözümden Düşer?
Bir teknolojiyi “çöpe atmak” derken, onu tamamen yok saymaktan bahsetmiyorum. Daha çok, onun benim için olan önceliğini, uygulama senaryosunu ve hatta ona ayırdığım zihinsel kapasiteyi değiştirmekten bahsediyorum. Bir zamanlar “olmazsa olmaz” dediğim bir şeyin, zamanla sadece ek yük yarattığını fark ettiğimde bu eylemi gerçekleştiriyorum.
Örneğin, bir üretim ERP’si üzerinde çalışırken, gerçek zamanlı raporlama için karmaşık bir event-sourcing mimarisi düşünmüştüm. Teoride harika görünüyordu: her operasyon bir event olarak kaydedilecek, dashboard’lar anında güncellenecekti. Ancak sahadaki operatörlerin ve yöneticilerin asıl istediği, gün sonunda doğru rakamları görmek ve basitçe ‘ne kadar ürettik’ sorusuna cevap bulmaktı. Bu durumda, o karmaşık mimarinin gerektirdiği ekstra bakım, debugging ve öğrenme eğrisi, sağladığı ‘gerçek zamanlılık’ avantajından çok daha ağır basıyordu. O mimariyi zihnimin çöp kutusuna attım ve daha basit bir batch processing yaklaşımına döndüm.
Parıldayan Yeniliğin Tuzakları ve Benim Dersim
Sektörde yeni çıkan her şeye bir hevesle atlamak, ne yazık ki sıkça düşülen bir tuzak. “Bu sefer farklı olacak,” diye düşünüp, henüz olgunlaşmamış bir aracı büyük bir projenin kalbine yerleştirdiğim anlar oldu. Bir keresinde, şirket çıkışlarındaki farklı ISP’ler arasında daha dinamik bir routing için yeni bir SD-WAN çözümünü denemiştim. Pazarlama materyalleri harikalar vaat ediyordu. Ancak, daha önce kullandığım BGP tabanlı, kendi yazdığım basit scriptlerle yönettiğim çözümden daha fazla sorun çıkardı. Özellikle MTU/MSS mismatch’leri, DNS resolution sorunları ve VPN tünellerindeki kararsızlıklar canımı çok sıkmıştı.
Bu deneyim bana, özellikle network tarafında, “eğer bozuk değilse tamir etme” kuralının ne kadar değerli olduğunu bir kez daha gösterdi. Yeni bir teknoloji, mevcut bir sorunu çözmek yerine, genellikle beraberinde yeni ve öngörülemeyen sorunlar getirir. O SD-WAN çözümünü de, bir süre sonra “bu bizim için değil” diyerek rafa kaldırdım, yani aslında bir anlamda çöpe attım.
Gerçek Dünya, Gerçek Maliyetler: Bir Karar Anı
Bir teknolojiyi kullanmaya devam etmenin maliyeti, sadece lisans ücreti ya da sunucu parası değildir. En büyük maliyetlerden biri, o teknolojiyi anlamak, bakımını yapmak, sorunlarını gidermek ve ekibinizi eğitmek için harcadığınız insan emeğidir. Bu, zamanla birikerek devasa bir borca dönüşebilir. Benim Android tarafında geliştirdiğim spam blocker uygulamasında, başlangıçta çok fazla üçüncü parti kütüphane kullanmaya meyilliydim. Her küçük özellik için bir kütüphane ekliyordum.
Bir süre sonra fark ettim ki, bu kütüphanelerin her biri kendi bağımlılıklarını, kendi güvenlik açıklarını ve kendi güncelleme döngülerini getiriyor. Uygulama boyutu şişiyor, build süreleri uzuyor, hatta bazı kütüphaneler Play Store politikalarıyla çakışabiliyordu. Bir güncelleme yayınlamaya çalışırken, sırf bir kütüphanenin yeni bir izne ihtiyaç duyması yüzünden uzayıp giden bir metadata reject’i yaşadım. İşte o an, bu yaklaşımı çöpe atmam gerektiğine karar verdim. Çoğu özelliği kendi basit kodumla yeniden yazarak, hem kontrolü ele aldım hem de gereksiz karmaşıklıktan kurtuldum.
20 Yıllık Tecrübenin Süzgeci: Minimalizm ve Pragmatizm
Yirmi yılın sonunda, yeni bir teknolojiye yaklaşımım kökten değişti. Artık ilk sorum “Bu ne kadar harika?” değil, “Bu, elimdeki spesifik sorunu en basit, en güvenilir ve en sürdürülebilir şekilde çözüyor mu?” oluyor. Bu süzgeçten geçemeyen her şey, potansiyel olarak zihnimin çöp kutusuna girmeye adaydır. Örneğin, kendi VPS’imde koşturduğum finansal hesaplayıcılar için yıllarca karmaşık cache stratejileri denedim. Redis, Memcached, hatta custom in-memory cache’ler… Sonunda fark ettim ki, veritabanı sorgularını optimize etmek ve Nginx’in basit disk cache’ini kullanmak, çoğu durumda ihtiyacım olan performansı fazlasıyla sağlıyordu. Daha karmaşık çözümler, sadece daha fazla monitör etme ve bakım maliyeti getiriyordu.
# Nginx basit disk cache ornegi
http {
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m;
server {
location /api/data {
proxy_cache my_cache;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
proxy_cache_revalidate on;
proxy_cache_min_uses 1;
proxy_cache_use_stale error timeout updating http_500 http_503;
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://backend_server;
}
}
}Yukarıdaki gibi basit bir Nginx konfigürasyonu, çoğu zaman “çözüm” diye peşinden koştuğumuz daha büyük ve karmaşık sistemlerden daha iyi iş görüyor. Bu, bir yandan “çöp atma” eyleminin arkasındaki felsefeyi de özetliyor: Fazlalıklardan arınmak, sadeleşmek ve gerçekten işe yarayanı korumak.
Bu hafta çöpe attığım şey, aslında bir teknoloji değil, bir “daha fazlası daha iyidir” yanılgısıydı. Veri toplama ve analizde, gereğinden fazla detay peşinde koşmanın getirdiği operasyonel yüke “dur” dedim. Yılların ardından şunu çok net görüyorum: Bir sistemin karmaşıklığı, çoğu zaman onun kırılganlığıyla doğru orantılıdır.
Peki ya siz? Kariyerinizde hangi teknolojiyi, hangi yaklaşımı ya da hangi fikri “çöpe attınız”? Bu kararı vermenize ne sebep oldu ve bu size ne öğretti? Yorumlarda merakla bekliyorum.