Andy Jassy’nin AWS yaklaşımı: “fark yaratmayan ağır işleri” nasıl tanımlayıp tekrarlanabilir bir modele dönüştürdüğü ve ölçeklenebilir yazılım işlerine/ platformlarına nasıl değer yarattığı.

“Fark yaratmayan ağır işler” keskin bir kenarı olan basit bir fikir: yazılımınızı çalıştırmak için yapmanız gereken işler ancak müşterilerin sizi tercih etmesine yol açmayan işler.
Bunlar sunucu sağlama, veritabanı yamalama, kimlik bilgilerini döndürme, izleme kurma, failover yönetimi, kapasite ölçekleme ve ürün yerine altyapı kaynaklı üretim olaylarını kovalama gibi görevleri içerir. Bu işler gerçek, önemli ve çoğu zaman acildir—ama nadiren kullanıcılar için benzersiz bir deneyim yaratırlar.
Bir görev eğer:
…o iş fark yaratmayan ağır iştir.
Kurucular için rahatlatıcıydı: operasyonel çileyi bir onur rozeti gibi görmeyi bırakma izni. Herkes aynı dağıtım betiklerini ve on-call prosedürlerini yeniden icat ediyorsa, bu zanaatkârlık değil—boşa harcanmış odaklanmadır.
Yöneticiler için kaldıraç gördü: bu iş türü pahalıdır, işe alım artışına iyi ölçeklenmez ve risk yaratır. Onu azaltmak marjları, güvenilirliği ve hızı aynı anda iyileştirir.
AWS tekrarlanabilir bir oyun planını popülerleştirdi:
Bu bulut altyapısından daha büyüktür—herhangi bir yazılım işi için uygulanan “platform düşüncesi”dir.
Kavramı kendi ürününüzde ve ekibinizde fark edebileceğiniz pratik sinyallere dönüştüreceğiz, yönetilen servislerin ve dahili platformların operasyonu nasıl bir ürün olarak paketlediğini göstereceğiz ve gerçek takasları (kontrol, maliyet ve kilitlenme) ele alacağız. Hangi işi inşa edip hangisini satın alacağınıza karar vermeniz için bir çerçeveyle ayrılacaksınız—ve fark yaratmayan işleri nasıl katlanan iş değerine dönüştüreceğinizi göreceksiniz.
Andy Jassy, Amazon’un dahili altyapı yeteneklerini AWS’e dönüştürmeye yardımcı olan erken liderlerden biriydi. Onun işi sadece “internet üzerinden sunucu satmak” değildi. Tekrarlanabilir bir müşteri problemini fark edip binlerce ekibe ölçeklenebilecek bir çözüme paketlemekti.
Çoğu yazılım ekibi işletim sistemlerini yamalama, kapasite sağlama, kimlik bilgilerini döndürme veya arızalı bir diskten kurtarma işleri için sabırsızlanarak uyanmaz. Bu işleri yapmak zorundadırlar—aksi halde uygulama çalışmaz.
Jassy’nin temel içgörüsü şuydu: bu işlerin çoğu gerekli ama farklılaştırıcı değil. Bir e-ticaret sitesi, fintech uygulaması veya dahili İK aracı işletiyorsanız, müşterileriniz sizin özelliklerinizi değerli bulur: daha hızlı ödeme, daha iyi dolandırıcılık tespiti, daha pürüzsüz onboarding. Mükemmel ayarlanmış bir sunucu filosunu koruduğunuz için nadiren ekstra ödüllendirilirsiniz.
Bu nedenle altyapıya “bebek bakıcılığı” vergisi uygulanır:
Bu fikir, taleplerin her yönden yükseldiği bir anda ortaya çıktı:
Prensip “her şeyi buluta taşı” değildi. Daha basitti: tekrarlayan operasyonel yükleri kaldırın ki müşteriler enerjilerini onları farklı kılanlara harcasın. Bu kayma—zaman ve dikkatin yeniden inşa etmeye dönmesi—bir platform işinin temelini oluşturdu.
İlk adım taban gereksinim işi (kredibil bir ürünü çalıştırmak için gereken) ile farklılaştırma (müşterilerin sizi seçme nedenleri) arasındaki ayrımı yapmaktır.
Taban gereksinimler “önemsiz” değildir. Genellikle güvenilirlik ve güven için kritiktir. Ama tek başına tercih oluşturmazlar—özellikle rakipler aynı tabanı sağlayabildiğinde.
Hangi işlerin fark yaratmayan kategoride olduğunu bilmiyorsanız, şu işlere bakın:
Yazılım ekiplerinde bu genellikle şunları içerir:
Bunların hiçbiri “kötü” değildir. Soru, bunları kendiniz yapmak ürününüzün değerinin bir parçası mı yoksa sadece oyuna giriş ücreti mi olduğudur.
Pratik bir kural:
“Müşteriler bunun için sizi özel olarak öder mi, yoksa sadece dahil olmasını mı bekler?”
Cevap “sadece eksikse kızacaklarsa” ise, muhtemelen fark yaratmayan ağır işler görüyorsunuz.
İkinci bir test: eğer bu işi yarın yönetilen bir servise geçirerek kaldırırsanız, en iyi müşterileriniz geriye kalanlar için hâlâ sizi değerli bulur mu? Eğer evet ise, bunun dışsallaştırma, otomasyon veya ürüne dönüştürme adayıdır.
Bir şirkette fark yaratmayan bir şey, başka birinde temel IP olabilir. Bir veritabanı sağlayıcısı yedekleme ve replikasyonda farklılaşabilir. Bir fintech ürünü muhtemelen yapmamalıdır. Hedefiniz başkalarının sınırlarını kopyalamak değil—müşterilerinizin özgün olarak neyi ödüllendirdiğine göre kendi sınırlarınızı çizmektir.
Yol haritanızı ve operasyon işlerinizi bu mercekle haritaladığınızda, zaman, yetenek ve dikkatin nerede sadece ayakta kalmak için harcandığını görmeye başlarsınız.
“Fark yaratmayan ağır işler” sadece bir verimlilik hilesi değildir. Bu bir iş modeli: birçok şirketin çözmesi gereken ama kimsenin üzerinde farklılaşmak istemediği bir problemi alıp insanların memnuniyetle ücret ödediği bir servise dönüştürmek.
En iyi adaylar stratejik benzersizliği düşük zorunluluklardır: sunucu sağlama, veritabanı yamalama, kimlik bilgilerini döndürme, kuyrukları ölçekleme, yedekleri yönetme. Her ekip bunlara ihtiyaç duyar, neredeyse her ekip bunları kurmak istemez ve “doğru cevap” şirketler arasında genel olarak benzerdir.
Bu kombinasyon öngörülebilir bir pazar yaratır: yüksek talep, tekrarlayan gereksinimler ve net başarı metrikleri (çalışırlık, gecikme, uyumluluk, kurtarma süresi). Bir platform çözümü standartlaştırıp zaman içinde geliştirebilir.
Operasyonel mükemmellik büyük sabit maliyetlere sahiptir—SRE’ler, güvenlik uzmanları, on-call döngüleri, denetimler, olay araçları ve 7/24 izleme. Her şirket bunları tek başına kurduğunda bu maliyetler defalarca çoğalır.
Bir platform bu sabit yatırımları birçok müşteri arasında yayar. Benimseme arttıkça müşteri başına maliyet düşer, kalite ise sağlayıcı daha derin uzmanlığa yatırım yapabildiği için artabilir.
Bir servis takımı aynı bileşeni birçok müşteri için çalıştırdıkça daha fazla uç vaka görür, kalıpları daha hızlı tespit eder ve daha iyi otomasyon kurar. Olaylar girdi olur: her hata sistemi sertleştirir, çalışma kitapçıklarını geliştirir ve koruyucu mekanizmaları sıkılaştırır.
Güvenlik benzer şekilde fayda sağlar. Özel ekipler tehdit modelleme, sürekli yama ve uyumluluk kontrollerine yatırım yapabilir—tek bir ürün ekibinin sürdürmesi zor olan şeyler.
Platformlar genellikle kullanım bazlı fiyatlama sayesinde fiyatlama gücü kazanır: müşteriler tüketilen değere göre öder ve küçük başlayabilir. Zamanla güven farklılaştırıcı olur—güvenilirlik ve güvenlik servisi “varsayılan güvenli” yapar.
Entegrasyonlar derinleştikçe geçiş maliyetleri de yükselir, ama en sağlıklı versiyon kazanılarak edinilmiş olmalıdır: daha iyi performans, daha iyi araçlar, daha net faturalama ve daha az olay. Bu, müşterilerin alternatifler varken bile yenileme yapmalarını sağlar. Paketleme ve para kazanma biçiminde bunun nasıl göründüğüne dair daha fazla bilgi için: fiyatlandırma.
AWS “internette sunucu” sunarak kazanmadı. Zor bir operasyonel problemi alıp onu daha basit yapı taşlarına böldü, sonra bu blokları AWS’in sizin için day-2 işini yürüttüğü servislere tekrar paketledi.
Bunu olgunluk merdiveni olarak düşünün:
Her adım müşteriden kararları, bakımı ve “saat 03:00’te ne olacak?” planlamasını kaldırır.
AWS aynı deseni temel kategorilerde uyguladı:
Compute: Sanal makinelerle (EC2) başladı. Dağıtım ve ölçeklemenin varsayılan olduğu daha üst düzey compute’a (yönetilen konteyner/serverless stilleri) geçti. Müşteri kod ve kapasite niyetine odaklanır, host bakımıyla uğraşmaz.
Depolama: Disklerden dosya sistemlerine, nesne depolamaya (S3) geçti. Soyutlama “volume yönet” yerine “objeyi koy/oku”ya kayar; dayanıklılık, replikasyon ve ölçek AWS’in problemi olur.
Veritabanları: “VM üzerine veritabanı kur”dan yönetilen veritabanlarına (RDS, DynamoDB) geçildi. Yedekler, yamalar, read replica’lar ve failover artık özel bir çalışma kitabı değil yapılandırmadır.
Mesajlaşma: El yapımı kuyruklardan yönetilen mesajlaşmaya (SQS/SNS) geçiş. Teslim semantiği, yeniden denemeler ve performans ayarları standartlaşır; ekipler altyapı yerine iş akışları inşa eder.
Yönetilen servisler bilişsel yükü iki şekilde azaltır:
Sonuç daha hızlı işe alıştırma, daha az benzersiz çalışma kitabı ve ekipler arasında daha tutarlı operasyonlardır.
AWS’i faydalı okumanın bir yolu: sadece teknoloji satmıyor, operasyon satıyor. “Ürün” sadece bir API uç noktası değildir—o yeteneği güvenli, öngörülebilir ve ölçekte çalıştırmak için gereken her şeydir.
Bir API size yapı taşları verir. Kaynakları sağlayabilirsiniz, ama koruyucuları, hataları izlemeyi, yamaları ve "kim neyi değiştirdi" sorusunu hâlâ siz tasarlarsınız.
Self-service konsollar, şablonlar, mantıklı varsayılanlar ve otomatik sağlama gibi müşterinin bilet açmadan kullanabileceği bir katman ekler. Müşteri hâlâ çoğu day-2 işin sahibi olur, ama daha az manuel.
Tam yönetim sağlayıcı devam eden sorumlulukları (yama, ölçekleme, yedekleme, failover ve birçok olay yanıt sınıfı) üstlendiğinde olur. Müşteriler ne istediklerini yapılandırmaya odaklanır, nasıl çalıştığını sürdürmekle uğraşmaz.
İnsanların günlük olarak güvendiği özellikler nadiren gösterişlidir:
Bunlar yan görev değil. Müşterilerin satın aldığı sözün bir parçasıdır.
Yönetilen bir servisi “gerçek” hissettiren şey operasyon paketidir: net dokümantasyon, öngörülebilir destek kanalları ve açık servis limitleri. İyi doküman destek yükünü azaltır, ama daha da önemlisi müşteri endişesini azaltır. Yayınlanmış limitler ve kota süreçleri sürprizleri bilinen kısıtlara dönüştürür.
Operasyonları bir ürün olarak paketlediğinizde sadece özellik göndermiyorsunuz—güveni de gönderiyorsunuz.
Bir platformun başarılı olup olmaması mimari diyagramlardan çok org tasarımına bağlıdır. Ekiplerin net müşterileri, teşvikleri ve geri bildirim döngüleri yoksa, “platform” fikirler yığınına dönüşür.
Platformu dürüst tutmanın en hızlı yolu dahili ürün ekiplerini ilk—ve en yüksek sesli—müşteriler yapmakdır. Bu şunları gerektirir:
Dogfooding netlik zorlar: kendi ekipleriniz platformdan kaçıyorsa, dış müşteriler de kaçacaktır.
İki org deseni sık görülür:
Merkezi platform ekibi: temel yapı taşlarının (CI/CD, kimlik, gözlemlenebilirlik, runtime, veri primitifleri) tek bir ekip tarafından sahiplenilmesi. Tutarlılık ve ölçek ekonomileri için iyidir, ama darboğaz olma riski taşır.
Federasyonlu model: küçük bir merkezi ekip standartları ve paylaşılan primitifleri belirlerken, domain ekipleri “platform dilimleri”nin sahibi olur (ör. veri platformu, ML platformu). Hız ve domain uyumu artar, ama parçalanmayı önlemek için güçlü yönetişim gerekir.
Faydalı platform metrikleri etkinlik sonuçlarıdır, aktivite değil:
Yaygın tuzaklar arasında teşvik uyumsuzluğu (platform özellik sayısına göre değil benimsemeye göre değerlendirilmeli), aşırı tasarım (varsayımsal ölçek için inşa etmek) ve başarının zorunlulukla değil gönüllü kullanımla ölçülmesi sayılabilir.
Platformlar tekil ürünlerden farklı büyür. Avantajları sadece “daha fazla özellik” değildir—her yeni müşteri platformu çalıştırmayı, geliştirmeyi ve göz ardı etmeyi zorlaştıran bir geri bildirim döngüsü yaratır.
Daha fazla müşteri → daha fazla gerçek kullanım verisi → neyin kırıldığını, neyin yavaş olduğunu, neyin kafa karıştırdığını gösteren daha net kalıplar → daha iyi varsayılanlar ve otomasyon → herkes için daha iyi bir servis → daha fazla müşteri.
AWS bundan faydalandı çünkü yönetilen servisler operasyonel çileyi paylaşılan, tekrarlanabilir bir yeteneğe dönüştürdü. Aynı problemler binlerce ekipte tekrarlandıkça (izleme, yama, ölçekleme, yedekler), sağlayıcı bunları bir kez düzeltebilir ve geliştirmeyi tüm müşterilere dağıtabilir.
Standardizasyon genellikle “daha az esneklik” olarak görülür, ama platformlar için hız çarpanıdır. Altyapı ve operasyonlar tutarlı olduğunda—tek bir API seti, tek bir kimlik yaklaşımı, sistemleri gözlemlemenin tek yolu—kurucular temelleri yeniden icat etmeyi bırakır.
Geri kazanılan zaman daha yüksek düzey yeniliğe dönüşür: daha iyi ürün deneyimleri, daha hızlı deneyler ve platformun üzerine inşa edilen (yanına değil) yeni yetenekler. Standardizasyon aynı zamanda ekiplerin bilişsel yükünü azaltır: daha az karar, daha az arıza modu, daha hızlı işe alıştırma.
Küçük iyileşmeler milyonlarca isteğe ve binlerce müşteriye uygulandığında katlanır. Olay oranında %2 azalma, biraz daha iyi bir otomatik ölçekleme algoritması veya daha net bir varsayılan yapılandırma sadece bir şirketi değil—platformun taban seviyesini yükseltir.
Fark yaratmayan ağır işlerin kaldırılması sadece saatleri kurtarmaz—ekiplerin davranışını değiştirir. "Işıkların açık tutulması" işi küçüldüğünde, yol haritaları bakım işlerinin (sunucu yamaları, anahtar döndürme, kuyruklara bebek bakıcılığı) hakimiyetinden çıkar ve ürün bahislerini yansıtmaya başlar: yeni özellikler, daha iyi UX, daha fazla deney.
Daha az çile zincirleme etki yaratır:
Gerçek hız küçük, öngörülebilir sürümlerin düzenli ritmidir. Karışıklık ise ilerleme olmadan yapılan hareketlerdir: acil hata düzeltmeleri, acil altyapı işleri ve “hızlı” değişikliklerin yeni borç yarattığı durumlar.
Ağır işlerin kaldırılması, planlı teslimatı tekrar tekrar kesintiye uğratan iş kategorilerini ortadan kaldırarak karışıklığı azaltır. Zamanının %40'ını reaktif geçiren bir ekip bu kapasiteyi özelliklere kaydırabilir—ve orada tutabilir.
Kimlik doğrulama: Parola depolamayı, MFA akışlarını, oturum yönetimini ve uyumluluk denetimlerini kendi başınıza sürdürmek yerine yönetilen bir kimlik sağlayıcısı kullanın. Sonuç: daha az güvenlik olayı, daha hızlı SSO dağıtımları ve kimlik kütüphanelerini güncelleme işinde daha az zaman kaybı.
Ödemeler: Ödeme işleme, vergi/VAT yönetimi ve dolandırıcılık kontrollerini özel bir sağlayıcıya devredin. Sonuç: yeni bölgelere daha hızlı genişleme, daha az chargeback sürprizi ve kenar durumlarla uğraşan daha az mühendis zamanı.
Gözlemlenebilirlik: Ev yapımı panolar yerine yönetilen bir log/metrik/izleme yığını standardize edin. Sonuç: daha hızlı hata ayıklama, olay sırasında daha net sahiplenme ve daha sık deploy yapma güveni.
Desen basittir: operasyonlar tüketebileceğiniz bir ürün olduğunda, mühendislik zamanı müşterilerin gerçekten ödediği şeyi inşa etmeye geri döner.
Fark yaratmayan ağır işleri kaldırmak bedava değildir. AWS tarzı yönetilen servisler genellikle günlük emeği daha sıkı bağımlılığa, daha az ayara ve sürpriz faturalarla takas eder.
Tedarikçi kilitlenmesi. Özgün API'lara ne kadar bağımlıysanız (kuyruklar, IAM politikaları, iş akışı motorları), sonra taşınmak o kadar zor olur. Kilitlenme her zaman kötü değildir—hızın bedeli olabilir—ama bilinçli seçilmelidir.
Kontrol kaybı. Yönetilen servisler performansı ayarlama, tam sürüm seçimi veya derin altyapı hata ayıklama yeteneğinizi azaltır. Bir kesinti olduğunda sağlayıcının zaman çizelgesini bekliyor olabilirsiniz.
Maliyet sürprizleri. Tüketim fiyatlaması verimli kullanım ödüllendirir, ama büyümeyi, çok konuşan mimarileri ve "ayarla unut" varsayılanlarını cezalandırabilir. Ekipler genellikle maliyetleri yayına aldıktan sonra keşfeder.
Kendi çözümünüzü inşa etmek (veya self-host) mantıklı olabilir; örneğin özgün gereksinimler (özel gecikme, özel veri modelleri), birim ekonomisinin büyük ölçekle tersine döndüğü durumlar veya yönetilen servislerin karşılayamadığı uyumluluk/veri konumu kısıtları varsa.
Servis sınırları tasarlayın: sağlayıcı çağrılarını kendi arayüzünüzün arkasına sarın ki implementasyonları değiştirebilin.
Taşınabilirlik planı tutun: taşınması en zor olanları belgeleyin ve "asgari yaşanabilir çıkış" yolunu koruyun (yavaş olsa bile).
Maliyet izleme erken ekleyin: bütçeler, uyarılar, etiketleme ve en yüksek harcama yapanların düzenli gözden geçirilmesi.
| Soru | Yönetilen Tercih | İnşa/Self-host Tercih |
|---|---|---|
| Bu müşteri için farklılaştırıcı mı? | Hayır | Evet |
| Sağlayıcı limitlerini/önerilerini tolere edebiliyor muyuz? | Evet | Hayır |
| Özel uyumluluk/kontrol gerekli mi? | Hayır | Evet |
| Pazar hızı en önemli öncelik mi? | Evet | Hayır |
| Kullanım desenimizde maliyet öngörülebilir mi? | Evet | Hayır |
Hyperscale bir bulut işletmeniz olması gerekmez; “fark yaratmayan ağır işleri kaldır” oyun planını kullanmak için. Her yazılım ekibi—SaaS, dahili platformlar, veri ürünleri veya destek ağırlıklı araçlar—tekrarlayan, maliyetli ve hataya açık işlere sahiptir ve bunlar gerçek bir farklılaştırıcı değildir.
Tekrarlayan çileyi listeleyin: Manuel dağıtımlar, bilet triajı, veri yeniden doldurmalar, erişim istekleri, olay devri, kırılgan betikler, “kabile bilgisi” kontrol listeleri gibi tekrar eden işleri yazın.
Nicelendir: Her öğe için sıklık, harcanan zaman ve hata maliyetini tahmin edin. Basit bir skor işe yarar: saat/hafta + hata şiddeti + etkilenen ekip sayısı. Bu belirsiz acıyı sıralanmış bir backlog’a dönüştürür.
İş akışını standartlaştırın: Otomasyona geçmeden önce “en iyi tek yol”u tanımlayın. Bir şablon, golden path veya desteklenen minimum seçenekler seti oluşturun. Varyasyonu azaltmak çoğu zaman en büyük kazandırandır.
Otomatize edin ve paketleyin: Self-serve araçlar (API, UI, runbook-as-code) oluşturun ve bunu bir ürün gibi ele alın: net sahiplik, sürümlendirme, dokümantasyon ve bir destek modeli.
Bu yaklaşıma modern bir örnek “vibe-coding” platformlarıdır; tekrarlayan scaffolding ve day-1 kurulumunu yönlendirilmiş bir iş akışına çevirir. Örneğin Koder.ai ekiplerin sohbet arayüzünden web, backend ve mobil uygulama oluşturmasına (React web, Go + PostgreSQL backend, Flutter mobil) ve sonra kaynak kodu dışa aktarmaya ya da dağıtmaya izin vererek fikirden güvenilir bir temel sağlama darboğazını azaltır.
Yüksek frekanslı, başarısı ölçülebilir tek bir iş akışı seçin—dağıtımlar, veri boru hatları veya destek araçları iyi adaylardır. Hızlı bir kazanım hedefleyin: daha az adım, daha az sayfa, daha az onay, daha hızlı kurtarma.
Andy Jassy’nin AWS stratejisinden çıkarılacak tekrar kullanılabilir ders basit: ortak işleri görünmez kılmakla kazanırsınız. Müşteriler (veya dahili ekipler) kurulum, yama, ölçekleme ve olay bebek bakıcılığına daha az zaman ayırdığında, bu zamanı gerçekten onları farklı kılan şeylere—özelliklere, deneyimlere ve yeni bahislerine—harcarlar.
“Fark yaratmayan ağır işler” sadece “zor işler” değildir. Birçok ekip tarafından tekrar edilen, güvenilir çalışmak için yapılması gereken fakat pazarda nadiren benzersiz kredi kazandıran iştir. Bu işi, özellikle yönetilen bir servis olarak ürüne dönüştürmek iki kat değer yaratır: yazılım çalıştırmanın maliyetini düşürür ve gönderme hızını artırır.
Büyük bir platform yeniden yazımıyla başlamayın. Biletlerde, on-call sayfalarında veya sprint taşmalarında görünen tek tekrarlayan acıyla başlayın. İyi adaylar:
Birini seçin, “bitmiş”i basitçe tanımlayın (ör. “yeni bir servis 15 dakikada güvenli şekilde deploy edilebilmeli”) ve tekrarlayan işi ortadan kaldıran en küçük sürümü yayınlayın.
Daha pratik platform düşüncesi ve yap-vs-satın kararlarıyla ilgili örnekleri görmek isterseniz blog içinde arama yapın. Standartlaştırılacaklarla dahili (veya dış) ücretli yetenek olarak sunulacakları değerlendiriyorsanız, fiyatlandırma paketleme ve katmanları çerçevelemenize yardımcı olabilir.
Bu hafta üç şey yapın: tekrarlayan operasyon işinin nerede zaman kaybettirdiğini denetleyin, frekans × acı × riske göre önceliklendirin ve kademeli teslim edebileceğiniz 3–5 maddelik basit bir platform backlog'u oluşturun.