Monolit mi, dağıtık mimari mi?

Bu sorunun tek bir doğru cevabı yok. Çünkü mesele teknoloji değil, hangi tür karmaşıklığı nerede yönetmek istediğiniz.

Monolit: Basit Başlangıç, Artan İç Karmaşa

Monolit bir uygulama ile başladığınızda her şey nettir. Tek bir codebase, tek bir runtime ve merkezi bir iş mantığı vardır. Kod okunabilir, debug etmek kolaydır ve sistem tek parça olarak anlaşılabilir.

Ancak sistem büyüdükçe bu basitlik yerini farklı bir maliyete bırakır. Aynı kod tabanı üzerinde çalışan ekipler zamanla birbirinin alanına girmeye başlar. Merge conflict’ler artar, feature’lar çakışır, code review süreçleri ağırlaşır ve bazı alanlarda derinleşmiş geliştiricilere bağımlılık oluşur.

Monolit bu noktada şunu üretir:

Operasyonel olarak basit ama ekip koordinasyonu açısından pahalı bir sistem.

Cloud-Native: Esneklik, Ama Dağıtılmış Karmaşa

Cloud-native yaklaşım bu problemi çözmek için ortaya çıkar. Sistem küçük parçalara bölünür, Kubernetes üzerinde çalışır, servisler bağımsız deploy edilir ve ihtiyaç halinde farklı teknolojiler kullanılabilir.

Bu yaklaşım ciddi avantajlar sağlar. Yeni bir capability eklemek için mevcut sistemi zorlamak yerine yeni bir servis yazabilirsiniz. Open-source veya SaaS bileşenleri sisteme hızlıca dahil edebilirsiniz. Kaynakları daha verimli kullanabilir ve servisleri bağımsız ölçekleyebilirsiniz.

Ancak burada kritik bir gerçek vardır:

Karmaşa yok olmaz, sadece yer değiştirir.

Kod içinden çıkar ve platform katmanına taşınır.

Asıl Ayrım: Karmaşıklığın Yeri

Bu noktada tartışma “monolit mi, microservice mi” değildir.

Gerçek soru şudur:

Karmaşıklığı nerede yönetmek istiyorum?

Monolitte karmaşıklık codebase içinde birikir. Dağıtık sistemde ise bu karmaşıklık infrastructure, servisler arası iletişim ve operasyon katmanına yayılır.

Bu yüzden iki yaklaşım da aslında bir şeyi optimize ederken başka bir şeyi pahalı hale getirir.

Infra Artık Uygulamanın Kendisi

Dağıtık bir sistem kurduğunuzda artık uygulama sadece yazdığınız kod değildir.

Kubernetes manifestleri, deployment pipeline’ları, gateway kuralları, messaging altyapısı, observability sistemi, config ve secret yönetimi… bunların hepsi uygulamanın ayrılmaz bir parçası haline gelir.

Bu noktada önemli bir zihinsel kırılma yaşanır:

Infrastructure artık operasyon katmanı değil, uygulamanın runtime mimarisidir.

Neden Dağıtık Yaklaşım Tercih Edilir?

Dağıtık mimarinin en güçlü motivasyonlarından biri hata izolasyonudur. Doğru sınırlar çizildiğinde bir servis problemi tüm sistemi etkilemez. Sistem tamamen down olmak yerine kısmi olarak çalışmaya devam eder.

Bu yaklaşım, kullanıcıya yansıyan etkiyi azaltır ve krizleri daha kontrollü yönetilebilir hale getirir. Ancak bu fayda sadece servisleri bölmekle elde edilmez. Timeout, retry, circuit breaker, queue ile ayrıştırma ve idempotency gibi davranışların da doğru kurgulanması gerekir.

Aksi halde sistem dağıtık görünür ama davranış olarak yine tek parça gibi çöker.

Tech Stack Neden Büyür?

Cloud-native yaklaşımda tech stack’in büyümesi bir hata değil, doğal bir sonuçtur. Çünkü artık tek bir framework her problemi çözmez. Logging, tracing, messaging, config ve deployment gibi konular ayrı ayrı ele alınır.

Bu da sistemi güçlü kılar, ancak aynı zamanda öğrenilmesi ve yönetilmesi gereken yüzeyi büyütür.

Eksik Parça: Platform Governance

Cloud-native yaklaşım tek başına yeterli değildir. Eğer kontrol mekanizması eklenmezse sistem kısa sürede parçalanır. Her ekip kendi teknolojisini seçer, servis sınırları ihlal edilir, veri sahipliği bulanıklaşır ve debug süreci zorlaşır.

Bu noktada ortaya çıkan şey modern bir mimari değil, sadece daha karmaşık bir sistemdir.

Çözüm ise şudur:

Platform + Governance

Standartlar merkezi belirlenir, servis sınırları korunur, contract’lar kontrol edilir ve sistem belirli kurallar çerçevesinde çalışır. Ancak burada denge kritiktir. Aşırı kontrol sistemi yavaşlatır, kontrolsüzlük ise kaos üretir.

AI Faktörü

Yeni denklemde önemli bir değişken daha var: AI.

Büyük monolitik codebase’lerde AI bağlamı anlamakta zorlanır ve hatalı ya da tekrarlı kod üretme eğilimi artar. Dağıtık yapılarda ise küçük ve sınırları net servisler AI’nın daha doğru üretim yapmasını sağlar.

Bu önemli bir avantajdır. Ancak burada kritik bir yanlış anlaşılma vardır:

AI kod yazmayı ucuzlatır, sistem yönetimini değil.

Servis yazmak kolaylaşır, ancak o servisin işletilmesi, izlenmesi, güvenliği ve sürdürülebilirliği hâlâ maliyetlidir.

Hangisini Ne Zaman Seçmeliyiz?

Bu noktada tercih teknolojiye göre değil, sistemin doğasına göre yapılmalıdır.

Eğer sisteminiz sürekli değişim içindeyse, her hafta yeni release’ler çıkıyorsa ve bu süreç uzun süre devam edecekse monolit zamanla ciddi bir karmaşa üretir. Aynı codebase sürekli değişir, bağımlılıklar artar ve sistemin evrimi zorlaşır.

Bu senaryoda dağıtık yaklaşım önemli bir avantaj sağlar. Servisler ayrıldıkça değişim etkisi lokal kalır. Hatta birçok servis bir süre sonra hiç dokunulmadan çalışmaya devam eder. Sistem büyür ama her parça aynı hızda değişmek zorunda kalmaz. Bu da karmaşıklığı sabitleyebilir.

Buna karşılık, eğer geliştirdiğiniz uygulama belirli bir noktada stabil hale gelecekse, sürekli değişim gerektirmiyorsa ve planlı bir geliştirme süreci sonrası büyük ölçüde tamamlanacaksa monolit daha mantıklı bir seçenek olabilir. Çünkü operasyonel maliyeti daha düşüktür ve gereksiz dağıtım karmaşası oluşturmaz.

Özetle:

• Sürekli değişim ve evrim → dağıtık yaklaşım
• Stabil, sınırlı geliştirme → monolit

Sonuç

Bu yazının ana fikri basit:

Monolit ve cloud-native birbirinin alternatifi değil, farklı türde karmaşıklıkları yöneten iki yaklaşımdır.

Başarılı sistemler, sadece dağıtık olduğu için değil, doğru sınırlar ve güçlü platform governance ile kurulduğu için başarılı olur.

Ve belki de en kritik gerçek şudur:

Infra artık sadece sistemin çalıştığı yer değil, sistemin kendisidir.

Bugün sektördeki büyük oyuncuların yönü de bu doğrultuda ilerliyor. Kubernetes ve onun etrafında gelişen ekosistem, aslında cloud-native dünyadaki karmaşıklığı basitleştirmek için ortaya çıktı. Monolit dünyasında da benzer problemleri çözmeye çalışan araçlar vardı; metrikler üretilebiliyor, belirli seviyede trace yapılabiliyordu. Ancak scale, failover ve kısmi kesinti gibi durumları kontrol altında tutmak sınırlı kalıyordu.

Bu yüzden dağıtık mimari ve microservice yaklaşımı ortaya çıktı. Fakat ilk aşamada eksik olan şey governance’tı. Bugün geldiğimiz noktada ise organizasyonel olarak tanımlanmış governance ile birlikte, Kubernetes ve çevresindeki araçlar sayesinde karmaşıklık daha görünür, daha izlenebilir ve daha yönetilebilir hale geliyor.

Tabii ki bu yaklaşımın bir maliyeti var. Geniş bir tech stack bilgisi, güçlü bir platform yaklaşımı ve sürekli öğrenme gerektiriyor.

Kendi deneyimlerimde çok fazla kriz yönetmiş biri olarak, sürekli değişen ve potansiyel olarak problem üretebilecek sistemlerde bu maliyeti ödemeyi tercih ediyorum. Daha fazla öğrenmek, başta daha yavaş ilerlemek pahasına; kriz anlarında sistemi ayakta tutabilmek ve kullanıcı etkisini minimize etmek benim için daha değerli.

Buna karşılık, riskin düşük olduğu ve sistemin stabil kalacağı senaryolarda monolit yaklaşımı tercih etmekten çekinmiyorum. Çünkü her problem için en kompleks çözümü seçmek zorunda değiliz.

Eğer risk yoksa, en kolay çözüm çoğu zaman en doğru çözümdür.

Bugün AI genelde 3 amaçla kullanılıyor:

1. Kod yazma
2. Research
3. Eğlence

1. Kod Yazma

AI ile proje başlatmak çok kolaylaştı.
Scaffold, yapı kurma, ilk deployment → ciddi hız kazandırıyor.

Ama asıl problem revizyon sonrası başlıyor.

Problem

İki kritik senaryo var:

a) Projeyi sıfırdan AI ile başlatmak

İlk versiyon:

• Güzel çalışır
• Döküman düzgündür
• Deploy edilir

Ama sonra:

• Yeni ihtiyaçlar gelir
• Revizyonlar başlar
• Context kaybolur

Sonuç:

• Kod dağılır
• Tekrarlar oluşur
• Kodun sahibi kalmaz
• Yönetilemez hale gelir

Çözüm yaklaşımı

• Büyük projeyi parçala
• Küçük servisler yap
• Her servisi ayrı AI context ile yönet

Bu sayede:

• Context küçük kalır
• Müdahale edilebilir olur
• Kod bozulmaz

Omurga sağlam değilse bu yaklaşım da çalışmaz.

b) Mevcut temiz projeyi AI ile bozmak

En tehlikeli senaryo.

Özellikle:

• Custom framework varsa
• Internal library varsa

AI:

• Senin yapını bilmez
• Eski versiyon bilgisi kullanır
• Deprecated config üretir
• Kod tekrarları ekler

Bir süre sonra:

Kendi kodunu tanıyamaz hale gelirsin.

Kritik risk

Eğer koda hakim değilsen:

AI sana “yaptım” der ama:

• ORM yerine raw query yazmış olabilir
• Güvenlik açığı bırakmış olabilir
• Performansı bozmuş olabilir

Ve sen farkında olmazsın.

Bu noktada:

AI değil, sen risk haline gelirsin.

2. Research

Burada risk daha büyük.

AI:

• Eski bilgi verebilir
• Yanlış bilgi verebilir
• Uydurabilir

Sen doğrulamazsan:

Gerçek hayatta:

• Yanlış savunma yaparsın
• Tecrübeli insanlarla çatışırsın
• Güven kaybedersin

Kritik hata

AI’yi:

“Cevap veren sistem” gibi kullanmak

Doğrusu:

“Arama motoru gibi kullanmak”

Yani:

• Sorgula
• Karşılaştır
• Kaynak ara
• Kanıt iste

Gerçek dünya problemi

AI sana der ki:

• “Bunu böyle yapabilirsin”

Ama:

• Servis çalışmaz
• Veri doğru değildir
• Sistem POC seviyesindedir

Sen bunun üstüne ürün kurarsın → patlarsın.

3. Eğlence

Burada sorun yok 🙂
Hatta en sağlıklı kullanım alanı.

Sonuç

AI, sınır koymazsan:

• Kendi kararlarını verir
• Senin yerine mimari kurar
• Senin bilmediğin şeyleri üretir

Ve çoğu zaman:

Senin ihtiyacınla uyuşmaz

En net çıkarım

Eğer:

• Ne yaptığını bilmiyorsan
• Kontrol sende değilse

AI ile çalışmıyorsun, AI seni kullanıyor.

Son söz

Masada değilsen:

Oyunun parçası değilsin, kumarın içindesin.

Referans

Bu yazıyı tamamlayan önceki düşünce yazım: Müşteri mi Operatör mü

In many services there are two types of endpoints:

• Public APIs used by customers or external systems
• Internal APIs used for operations, debugging, maintenance, or service-to-service communication

When all endpoints appear in a single Swagger document, the API surface becomes harder to understand and internal endpoints may accidentally be exposed to consumers.

A simple solution is to publish multiple Swagger documents from the same service.

API Documentation Structure

Instead of a single Swagger definition, we define two:

/swagger/public/swagger.json
/swagger/internal/swagger.json

• Public → Customer-facing APIs
• Internal → Operational or system endpoints

Swagger UI can display both documents separately.

Controller Grouping

Controllers can be assigned to a documentation group using ApiExplorerSettings.

Example:

[ApiController]
[Route("api/internal/[controller]")]
[ApiExplorerSettings(GroupName = "internal")]
public class AdminController : ControllerBase
{
    [HttpGet("health-detail")]
    public IActionResult Get()
    {
        return Ok("internal data");
    }
}

Public endpoints can use a different group:

[ApiController]
[Route("api/[controller]")]
[ApiExplorerSettings(GroupName = "public")]
public class ProductsController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok();
    }
}

Swagger Configuration

Multiple documents are registered in SwaggerGen.

builder.Services.AddSwaggerGen(options =>
{
    options.SwaggerDoc("public", new OpenApiInfo
    {
        Title = "Public API",
        Version = "v1"
    });

    options.SwaggerDoc("internal", new OpenApiInfo
    {
        Title = "Internal API",
        Version = "v1"
    });

    options.DocInclusionPredicate((docName, apiDesc) =>
    {
        var groupName = apiDesc.GroupName;
        return string.Equals(groupName, docName, StringComparison.OrdinalIgnoreCase);
    });
});

And both endpoints are exposed in Swagger UI:

app.UseSwagger();

app.UseSwaggerUI(options =>
{
    options.SwaggerEndpoint("/swagger/public/swagger.json", "Public API");
    options.SwaggerEndpoint("/swagger/internal/swagger.json", "Internal API");
});

Important Note

This approach only separates the documentation, not the access.

Internal endpoints should still be protected using:

• Authentication / Authorization policies
• API gateway rules
• Network restrictions
• Internal service routing

Why This Helps

Separating internal and external APIs improves:

• API clarity for external consumers
• Operational visibility for internal teams
• Safer documentation exposure

In larger platforms, this pattern helps keep operational endpoints from being mixed with the public API surface.

Özellikle yeni mezun ya da kariyerinin başında olan arkadaşlarla sohbet ettiğimde konu çok hızlı bir şekilde aynı yerlere geliyor. Sohbetin başlığı değişiyor ama alt metni hep aynı kalıyor.

Son zamanlarda konuşulan başlıklar genelde şunlar:

• Dünya savaşı çıkar mı?
• Ekonomik kriz daha da derinleşir mi?
• İşsizlik nereye gidiyor?
• Büyük şirketler neden bu kadar insan çıkarıyor?
• Yapay zekâ bizim işleri elimizden alacak mı?

Başlıklar farklı gibi görünse de hepsinin çıktığı yer aynı: gelecek kaygısı.

Ve bu kaygı haksız değil. Aksine, tamamen mantıklı.

Bugün dünyaya biraz olsun bakan, haberleri takip eden, yaşadığı ülkenin ekonomik gerçeklerini bilen birinin kaygısız olması zaten garip olurdu. Hatta şunu net söyleyeyim: Gelecek kaygısı olmayan insan genelde ya gerçekten hiçbir şeyle ilgilenmiyordur ya da kendini kandırıyordur.

Ama burada kritik bir ayrım var.

Mesele gelecek kaygısını yok etmek değil. Mesele bu kaygıyı nereye bağladığımız.

Senin Olanı Sahiplen, Senin Olmayanı Sahiplenme

Antik Yunan’da Epiktetos’un çok temel bir ayrımı vardır: Kontrolümüzde olanlar ve olmayanlar.

Bu ayrım kulağa basit gelir ama uygulaması zor, etkisi derindir.

Bugün benim ağzımdan çıkan hâliyle bu ayrım şuna denk düşüyor:

“Senin olanı sahiplen, senin olmayanı sahiplenme.”

Bu cümle pasiflik değildir. Bu cümle “bana ne” demek değildir. Bu cümle dünyadan kopmak değildir.

Bu cümle, enerjiyi doğru yere bağlama cümlesidir.

Dünya savaşı olabilir mi? Evet. Ekonomik kriz derinleşir mi? Evet. AI bazı işleri bitirir mi? Büyük ihtimalle.

Bunları inkâr etmek safdillik olur.

Ama şu soruyu sormak zorundayız:

Bu yazıyı okuyan herhangi biri, tek başına bunları durdurabilir mi? Hayır.

Bu noktada bu başlıklar bizim değildir.

Yanlış anlaşılmasın: Bunlar yok sayılacak şeyler de değildir.

Bunlar veridir. Risk analizidir. Arka plan bilgisidir.

Ama merkeze alınacak şeyler değildir.

Bu meseleleri merkeze aldığınız anda kaçınılmaz olarak şu duygular gelir:

• Sürekli tetikte olma hâli
• Umutsuzluk
• “Zaten bir şey değişmeyecek” hissi
• Ve sonunda donakalma

Bu psikoloji üretmez. Bu psikoloji hareket ettirmez. Bu psikoloji insanı korumaz.

Yağmuru durduramazsın. Ama şemsiye alabilirsin.

Islanmamayı seçebilirsin. Ya da yağmur altında yürümeyi öğrenebilirsin.

Bu bir teslimiyet değildir. Bu bir stratejidir.

“Ama Bunları Düşünmezsek Saf Olmaz mıyız?”

Bu soru genelde şu korkudan gelir: “Gerçeklerden kopmak istemiyorum.”

Zaten kop demiyoruz.

Ama şunu kabul etmek zorundayız: Sürekli kontrol edemediğin şeyleri düşünmek, seni gerçekçi yapmaz; tüketir.

Gerçekçilik, her riski sırtlanmak değildir. Gerçekçilik, hangi riskin sana ait olduğunu bilmektir.

Gelelim Yeni Mezun Gerçeğine

Bugün AI dalgası gerçekten çok güçlü. Bu seferki teknolojik dönüşüm, önceki “otomasyon” hikâyelerinden farklı.

Eğer yaptığınız iş:

• Standart üretime dayanıyorsa
• Tekrar ediyorsa
• Yorumdan çok çıktı üretiyorsa

ister kod olsun, ister tasarım, ister metin…

Artık bunu sizden daha hızlı, daha ucuz ve daha risksiz yapan sistemler var.

Bu kötü bir haber değil. Bu bir gerçek.

Kendinizi bir işveren yerine koyun ve dürüstçe sorun:

Sizi neden işe almalıyım?

Bu soruya net bir cevabınız yoksa, “Biz nerede tecrübe kazanacağız?” ya da “Siz de bir zamanlar yeni mezundunuz” gibi cümleler kimseyi ikna etmez.

Çünkü gerçek şu: Kimse amme hizmeti olarak maaş ödemez.

Aynı şekilde bir firma size “gel beleş çalış” dese siz de kabul etmezsiniz.

İş hayatı romantik değil. Bu yüzden çözüm de romantik olamaz.

Burada mesele çok net: karşılıklı kazan–kazan.

Sahiplenilmesi Gereken ve Gerekmeyen Şeyler

Şimdi biraz can yakan kısım.

Zengin değiliz. Tecrübeli değiliz. Banka hesabımız kabarık değil. Network’ümüz sınırlı.

Bunlar veri.

Bunlar utanç değildir. Bunlar bahane de değildir.

Ama bunlar sahiplenilecek şeyler değildir.

Sahiplenildiği anda insanın omzuna gereksiz bir yük biner. Ve bu yük ilerletmez.

Sahiplenilmesi gereken tek şey şu sorumluluktur:

Kimse bana bağış yapmak zorunda değil.

Bu kabul edildiği anda zihinsel olarak rahatlama başlar. Çünkü beklenti yer değiştirir.

Bu noktadan sonra sorulması gereken sorular nettir:

• Ben neyim?
• Ne katıyorum?
• Kimin benim sunduğum şeye ihtiyacı var?

Bu CV yazmak değildir. Bu LinkedIn profili parlatmak da değildir.

Bu kendini pazarlamaktır. Ve bu kelimeden rahatsız olanlar genelde gerçeği kaçırır.

Meslek Romantizmine Aldanmayın

LinkedIn’de sürekli şu hikâyeleri görüyoruz:

“Bu işi bıraktım.” “Kurumsalı terk ettim.” “Hayalimin peşinden gittim.” “Şimdi çok mutluyum.”

Davulun sesi uzaktan hoş gelir.

Kimse işin:

• Stresini
• Uykusuzluğunu
• Sorumluluğunu
• Bedelini

paylaşmaz.

Her işin getirisi kadar götürüsü vardır. Önemli olan hangi işi yaptığınız değil; o bedelin sizin karakterinize uygun olup olmadığıdır.

Somut Ama Romantik Olmayan Çıkış Yolu

“Peki ne yapacağız?” kısmına gelince…

Open-source projelere katkı verin. Issue kapatın. Review alın. Hata yapın. Eleştiri görün. Sürtünme yaşayın.

Evet, para kazandırmaz. Ama sizi boşlukta çürütmez.

Beklemek çözüm değildir. “Bir şeyler düzelince” başlamak hiç çözüm değildir.

Boş geçen zamanı sermayeye çevirmek zorundasınız.

Bu bazen bilgi olur. Bazen dayanıklılık olur. Bazen de sadece “ben bunu yaptım” diyebilme gücü olur.

Son Söz

Gelecek kaygısı düşman değil. Yanlış yere bağlanan gelecek kaygısı düşman.

Kontrol edemediklerini düşünce malzemesi yap. Kontrol edebildiklerini ise sahiplen.

Gelecek, dış dünyayı yenerek değil; kendine ne kattığını netleştirerek kurulur.

Bu gerçeği kabul edip planlarımızı ve işlerimizi buna göre şekillendirmek zorundayız.

Peki AI nedir, nasıl çalışır, ne yapar, ne işe yarar? Biraz buradan başlayalım.

AI Nedir? (Basit Ama Doğru)

AI bir “akıl” değildir. Temelde matematiğe dayanan bir tahmin motorudur. Elindeki büyük veri setlerinden yola çıkarak şu soruya cevap arar:

“Bu durumda genelde ne olur?”

Girdi alır, olasılıkları hesaplar ve en makul sonucu üretir. Ürettiği çıktılar kesin doğrular değil, istatistiksel sonuçlardır. Halüsinasyon dediğimiz şey de tam olarak budur: istatistiksel olarak mantıklı ama gerçekte yanlış bir sonucun seçilmesi.

Bu durum AI’yi küçük yapmaz. Tam tersine, henüz olgunlaşmamış ama yönü çok net bir güce işaret eder.

“Henüz Hazır Değil” Yanılgısı

AI için sıkça şu yorum yapılır: “Henüz hazır değil, doğrulanamıyor, başarısız bir ürün.”

Buradaki eleştiri çoğu zaman teknolojiye değil, ürün olgunluğuna yöneliktir. Ama kritik nokta şudur:

Bugün yaptıkları kusurlu olabilir ama yaptıkları şey, yarın yapabileceklerinin doğrudan bir simülasyonudur.

Tarihte hangi büyük dönüşüm ilk gününde kusursuzdu? Telefon ilk çıktığında “herkesin telefonu yokken ne işe yarayacak?” denmeseydi, bugün buraya gelir miydik?

AI bugün zaten bu soruların çok ötesinde bir noktada.

AI Tehlikeli mi?

Evet, tehlikeli olabilir. Ama bu tehlike AI’nin kendisinden değil, nasıl kullanıldığından kaynaklanır.

AI bir araçtır. Bıçak gibi. Yemek yapmak için kullanırsan fayda üretir, zarar vermek için kullanırsan tehlikelidir. Ama kimse bıçak üretimini yasaklamaz.

AI için de durum aynıdır. Aynı araçla:

• sistemleri tarayıp güvenlik açıklarını kapatabilirsin
• ya da aynı taramayı saldırı için kullanabilirsin

Asıl risk şudur:

• AI kötü niyetli değildir
• kötü niyetli kullanım çok hızlı ve ölçeklenebilirdir

Bu yüzden çözüm yasaklamak değil; tanımak, sınırlandırmak, denetlemek ve hazırlıklı olmaktır.

Asıl Soru: Sen Kimsin?

Burada kendimize dürüstçe şu soruyu sormalıyız:

Sen AI için bir müşteri misin, yoksa AI ile üreten bir operatör mü?

Borsadaki “av–avcı” benzetmesi burada birebir geçerlidir. Herkes borsaya girer, hızlı zengin olma hayali kurar. Ama sabır, analiz ve takip gerektiren bu işi gerçekten bilenler kazanır. Diğerleri ise av olur; eğitimler, rehberlikler, analizler satın alır.

AI dünyasında da durum farklı değil.

Tüketici:

• Sunulanı alır
• Kullanır
• Parasını öder
• Sonra “AI hepimizin işini alacak” diye şikâyet eder

Operatör:

• Problemi tanımlar
• Süreci parçalar
• Çıktıyı denetler
• AI’yi kaldıraç olarak kullanır

Neden Hep Resim ve Video Görüyoruz?

İnternette AI denince genelde:

• kaliteli görseller
• videolar
• eğlenceli cevaplar

görürüz. Bunun sebebi basit:

• Görsel üretim gösteriştir
• Operatörlük süreçtir

Gösteriş paylaşılır. Süreç para kazandırır.

Bu yüzden “AI ile nasıl sistem kurulur, nasıl iş yapılır” çok az anlatılır. Ama asıl odaklanmamız gereken yer tam olarak burasıdır.

AI ile Ne Yapabiliriz?

AI ile bugün şunları yapabiliyoruz:

• dil partneri olarak kullanmak
• asistan gibi çalıştırmak
• mülakat pratiği yapmak
• kod yazdırmak
• blog ve içerik üretmek
• analiz ve araştırma yapmak
• L1 müşteri destek süreçleri kurmak
• büyük metinleri özetlemek
• simülasyonlar çalıştırmak
• planlama ve proje tasarımı yapmak
• servislerle entegre edip iş yaptırmak

Ama asıl fark şurada ortaya çıkar:

Bunları ne kadar bilinçli ve derin kullanıyorsun?

Agent nedir? Ne zaman standart model yetmez? Özel veriyle çalışan model neden fark yaratır?

Bu soruları sormuyorsan, hâlâ tüketici tarafındasın.

“AI Yazdı” Küçümsemesi

AI kullananlar sık sık küçümsenir. Çünkü emekle değeri karıştırıyoruz. Zor olanı değerli sanıyoruz. AI hızlandırınca “kolay oldu, değersiz” diyoruz.

Oysa:

• editöryel işi AI yapsın, içeriği ben kurgulayayım
• kodun çerçevesini ben çizeyim, uygulamayı AI yapsın, review’u ben yapayım

Bu tembellik değil. Rol ayrımı.

Zaman çok kıymetli.

Eğitim Üzerine Kısa Bir Not

Belki de artık herkesin algoritma ezberi yapmasına gerek yoktur. Çoğu insan için daha kritik olan şunlardır:

• mantık
• problem parçalama
• sistem düşüncesi

Derin matematik ve model geliştirme elbette alan uzmanlarının işi olmaya devam edecektir. Ama mühendisliğin özü hâlâ aynıdır: doğru problemi tanımlamak.

Sonuç

AI’yi yasaklamak çözüm değil. AI’ye tapmak da çözüm değil.

Çözüm; AI ile müşteri olmaktan operatörlüğe geçmektir.

Bu sadece AI için değil, hayattaki her araç için geçerlidir. Müşteri olmak kolaydır. Operatör olmak emek ister.

Ama gerçek katma değer her zaman oradadır.

Bu cümle teknik olarak yanlış, zihinsel olarak ise çok şey anlatıyor.
Docker ölmedi; Docker kelimesi, container kavramının yerine geçti.
Tıpkı bir dönem her margarinin “Sana yağı” diye anılması gibi.

Docker Neydi, Ne Oldu?

Docker, container teknolojisini icat etmedi.
Ama şunu çok iyi yaptı:

• Karmaşık Linux yeteneklerini tek komutla kullanılabilir hale getirdi
• Image, registry, build, run kavramlarını tek bir modele oturttu
• Developer deneyimini ciddi şekilde sadeleştirdi

Sonuç şu oldu:

Container = Docker

Bu noktadan sonra Docker, bir teknolojiden çok bir marka haline geldi.

Asıl Teknoloji Ne?

Docker konuşurken genelde kaçırılan nokta şu:

Container dediğimiz şey aslında şunların birleşimi:

• Linux namespaces
• cgroups
• Immutable image katmanları
• OCI (Open Container Initiative) standartları

Yani container:

• Bir ürün değil
• Bir firma değil
• Bir binary değil

Bir mimari yaklaşım.

Docker ise bu yaklaşımı paketleyen ilk büyük ekosistemdi.

“Docker Öldü” Algısı Nereden Çıktı?

Bu algının birkaç net sebebi var.

1. Kubernetes Docker’ı “bıraktı” sanıldı

Kubernetes, Docker Engine’i runtime olarak kullanmayı bıraktı.
Ama şunları bırakmadı:

• Docker image formatını
• Container çalışma modelini

Kubernetes bugün ağırlıklı olarak:

• containerd
• CRI-O

kullanıyor.

Docker Engine gitti, container kaldı.

2. Docker Desktop ve lisans gerçeği

Kurumsal dünyada şu başlıklar daha görünür hale geldi:

• Lisans maliyetleri
• Root yetkisi
• Merkezi daemon mimarisi
• Güvenlik ve izolasyon beklentileri

Bu da alternatif araçların önünü açtı.

3. Ekosistem olgunlaştı

Başta her şey Docker’dı:

• Build
• Run
• Push
• Orchestration

Bugün ise her parça kendi alanında uzmanlaştı.

Yeni Düzen Nasıl Çalışıyor?

Bugünkü tablo net:

Image üretimi

• Dockerfile hâlâ standart
• Ama build şu araçlarla yapılabiliyor:
  • BuildKit
  • Podman
  • Buildah
  • Kaniko

Container çalıştırma

• Local ortamda:
  • Docker
  • Podman
• Kubernetes içinde:
  • containerd
  • CRI-O

Orkestrasyon

• Kubernetes artık merkezde
• Docker burada zorunlu bir bileşen değil

Bugün daha doğru ifade şu:

“Docker kullanıyoruz” değil
“OCI uyumlu container image üretiyoruz.”

Podman Bu Hikâyede Nereye Oturuyor?

Podman devrim yapmadı, boşluğu doldurdu:

• Docker CLI’ye çok benzer
• Daemon yok
• Rootless çalışabiliyor
• Kubernetes pod modeline zihinsel olarak daha yakın

Bu yüzden Podman:

• Docker’ın rakibi değil
• Docker sonrası dönemin doğal aracı

Zihinsel Modeli Değiştirme Zamanı

Sorun Docker kullanmak değil.
Sorun Docker’ı merkez sanmak.

Doğru zihinsel model:

• Docker bir marka
• Container bir mimari
• OCI bir standart
• Kubernetes bir gerçeklik

Docker ölmedi.
Ama artık tek doğru cevap da değil.

Tıpkı:

• “Sana yağı”nın margarin olması
• “Selpak”ın kağıt mendil olması

gibi.

Bugün bir sistem tasarlarken sormamız gereken soru şu:

“Docker var mı?” değil
“Bu sistem container standartlarına ne kadar bağımlı?”

Markalar değişir.
Ama iyi oturmuş mimari fikirler kolay kolay ölmez.

Kurumsallık, esneklik, izlenebilirlik, sürdürülebilirlik… Bunlar danışman sunumlarını doldurmak için ortaya çıkmadı. Hepsi tek bir gerçeğin sonucu: İş, insanlara bağımlı kaldığı sürece ölçeklenemez.

Bu gerçek anlaşılmadan yapılan her dijitalleşme hamlesi; ister yazılım alımı olsun, ister ürünleşme, ister CRM/ERP geçişi… işleri kolaylaştırmaz. Mevcut dağınıklığı kalıcılaştırır.

En tehlikeli yanılgı şudur:

“Sisteme geçersek işler düzelir.”

Hayır. Sistem işleri düzeltmez. Sistem, neyseniz onu hızlandırır.

Süreçler net değilse kaosu, sorumluluk belirsizse belirsizliği, kontrol yoksa kontrolsüzlüğü.

Bu yüzden süreçler gerçekten anlaşılmadan, “neden var?” sorusu sorulmadan başlanan her dijitalleşme girişimi aynı yere varır: if = X müşteri if = X ürün buraya özel akış

Başta “esneklik” gibi görünen bu refleks, kısa sürede şuna dönüşür:

• Kimse bütünü yönetemez
• Sistem kimseye ait değildir
• Maliyet görünmez ama artar

Ve kritik bir eşikten sonra geri dönüş ya yoktur ya da şirketin kaldıramayacağı kadar pahalıdır.

Bu noktada kaybedilen teknoloji değildir. Kaybedilen şey kontrol, hız ve güvenilirliktir.

Bu yüzden bu mesele teknoloji meselesi değildir. Bu bir proje yönetimi ve kültür meselesidir.

Dijitalleşme, yazılım seçimi, ürün geliştirme, kurumsallaşma… Bunların tamamı organizasyonun taşıyıcı kolonlarına dokunur. Bu bir depremdir. Hazırlık yoksa, enkaz kaçınılmazdır.

Bunu iki gerçek deneyim çok net anlatır.

İlkinde, tüm işlerini basit araçlarla yürüten bir firma “kurumsallaşmak” için bir sisteme geçer. Teknik olarak her şey doğrudur: veriler taşınır, eğitim verilir. Ama süreçler sorgulanmaz. Kim neyin sahibi belli değildir. Karar noktaları tanımlı değildir.

Bir süre sonra ekip şunu söyler: “Eskiden en azından hareket edebiliyorduk.”

Bugün tablo nettir:

• Ekip yorgundur
• Devir yüksektir
• Bilgi kişilerdedir
• Kimse resmin tamamını görmez

Sistem vardır ama düzen yoktur. Kaos vardır ama sorumluluk yoktur.

İkinci örnekte ise en küçük iş bile yazılır, analiz edilir, planlanır, denenir ve revize edilir. Her işin sahibi bellidir. Her kararın kaydı vardır. Bazı işler çalışmaz, evet. Ama neden çalışmadığı bilinmektedir.

Sonuç: Az kişiyle daha çok iş. Daha az mesaiyle daha yüksek çıktı. Birden fazla ülkede ölçeklenebilen bir yapı.

Aradaki fark yazılım değildir. Disiplindir.

Yanıt aslında şaşırtıcı değildir. Dijitalleşme projelerinde yapılan hataların büyük bölümü tekrar eder ve öngörülebilirdir.

Net iş amacı tanımlanmadan başlanır. Sonuç: Proje sürüklenir, başarı tartışmaya açık kalır. Çözüm: Ölçülebilir hedef yoksa proje yok.

Dijitalleşme IT işi sanılır. Sonuç: Sistem kurulur, iş aynı kalır. Çözüm: Süreç sahipliği iş birimlerinde kalır.

Mevcut süreçler sorgulanmadan taşınır. Sonuç: Eski hatalar dijitalleşir. Çözüm: “Bu adım neden var?” sorusuna cevap yoksa adım yoktur.

“Bize özel” bahanesiyle kontrolsüz özelleştirme yapılır. Sonuç: Sistem kilitlenir, maliyet patlar. Çözüm: Özelleştirme sadece rekabet avantajıysa kabul edilir.

Proje yönetimi tali görülür. Sonuç: Kararlar gecikir, proje sürünür. Çözüm: Tek yetkili, net karar mekanizması.

Zaman ve insan kaynağı hafife alınır. Sonuç: Ekip yanar, kalite düşer. Çözüm: Kritik roller gerçekten projeye ayrılır.

Veri kalitesi sona bırakılır. Sonuç: Yanlış rapor, yanlış karar. Çözüm: Veri işi ayrı, ciddi ve erken başlar.

Eğitim göstermelik yapılır. Sonuç: Sistem kullanılmaz, Excel geri gelir. Çözüm: Rol bazlı, gerçek senaryolu eğitim.

Değişim direnci yok sayılır. Sonuç: Paralel sistemler, gizli kaos. Çözüm: “Neden değişiyoruz?” sorusu netleşmeden geçiş olmaz.

Go-live bitiş sanılır. Sonuç: Değer sessizce erir. Çözüm: Go-live sonrası iyileştirme planı şarttır.

Kalite, süreç yönetimi ve kurumsallık bu yüzden vardır. ISO gibi kavramlar da bu yüzden yanlış anlaşılır. Kağıt üzerinde olan kimseyi büyütmez. Ama gerçek süreç; işi izlenebilir, tekrarlanabilir ve sürdürülebilir kılar.

Kuralsız ve kurallı bir yapı arasındaki fark tam olarak budur. Sistem varsa, az kaynakla büyük etki yaratırsınız. Sistem yoksa, büyüme anı çöküş anıdır.

Dijitalleşme projeleri genelde bir günde batmaz. Sessizce kontrolden çıkar. Maliyet artar, ekip dağılır, sistem kimsenin sahiplenmediği bir yük haline gelir.

Bu yazı “hangi yazılım?” sorusundan önce sorulması gereken asıl soruyu hatırlatmak için yazıldı:

“Biz bu işi nasıl yapıyoruz?” (ve bunu herkes aynı şekilde mi biliyor?)

Bu yazı “neden”den çok “nasıl doğru kullanılır” kısmına odaklanıyor.

Temel URL formatı

https://cdn.jsdelivr.net/gh/<user>/<repo>@<version>/<path>

• <user>: GitHub kullanıcı adı
• <repo>: repository adı
• <version>: commit SHA, tag veya branch
• <path>: repo içindeki dosya yolu

Kritik nokta: version olarak commit SHA kullanın. Branch veya main kullanmak cache sürprizi üretir.

Gerçek örnek (bu blogtaki dosya)

Kaynak dosya (GitHub):

https://github.com/fmarslan/fmarslan.github.io/blob/a3d76ec02081dfc283f20980ef41797978141d7b/assets/js/post-enhancements.js

jsDelivr CDN URL:

https://cdn.jsdelivr.net/gh/fmarslan/fmarslan.github.io@a3d76ec02081dfc283f20980ef41797978141d7b/assets/js/post-enhancements.js

HTML içinde kullanım:

<script src="https://cdn.jsdelivr.net/gh/fmarslan/fmarslan.github.io@a3d76ec02081dfc283f20980ef41797978141d7b/assets/js/post-enhancements.js"></script>

Bu URL:

• Immutable’dır
• CDN cache’i güvenle çalışır
• Dosya değiştiğinde yeni commit = yeni URL demektir

CLI ve runtime örnekleri

curl

curl -L \
"https://cdn.jsdelivr.net/gh/fmarslan/fmarslan.github.io@a3d76ec02081dfc283f20980ef41797978141d7b/assets/js/post-enhancements.js"

Node.js

import fetch from 'node-fetch';

const url =
  'https://cdn.jsdelivr.net/gh/fmarslan/fmarslan.github.io@a3d76ec02081dfc283f20980ef41797978141d7b/assets/js/post-enhancements.js';

const res = await fetch(url);
if (!res.ok) throw new Error(res.statusText);

const content = await res.text();
console.log(content);

İyi uygulamalar (prod için önemli)

• Commit SHA kullan → cache invalidation derdi yok.
• Dosya güncellendiyse → yeni commit, yeni URL.
• jsDelivr sadece public repo sunar.
• Kimlik doğrulama, gizli veri, PII varsa → bu yöntem yanlış.
• Kritik prod yükleri için → S3 + CloudFront / Cloudflare gibi kendi edge çözümünü düşün.

Sık görülen sorunlar

404 alıyorum

• Repo adı, path veya commit SHA yanlış.
• Dosya o commit’te gerçekten var mı kontrol et.

Dosya eski geliyor

• Branch kullanıyorsun.
• Commit SHA’ya geç.

Kurumsal ağda erişim yavaş

• jsDelivr rate-limit veya network politikası.
• Alternatif CDN gerekebilir.

Ne zaman mantıklı, ne zaman değil?

Mantıklı

• Blog, dokümantasyon, statik JS/CSS
• Küçük helper script’ler
• Immutable asset’ler

Mantıksız

• Gizli kod
• Sık değişen runtime bağımlılıkları
• SLA gerektiren kritik prod bileşenleri

Özetle: Eğer public, küçük ve değiştiğinde URL’si de değişsin diyorsan, jsDelivr yeterli. Burada sorun teknik değil; yanlış yerde branch URL kullanmak.

İstersen bir sonraki adımda aynı dosyanın S3 + CloudFront veya Cloudflare Workers karşılığını yan yana koyup farklarını netleştirebiliriz.

Bu durum genellikle bir sorun gibi algılanır.
Oysa regüle ağlarda eventual consistency bir zafiyet değil, bilinçli bir sonuçtur.

Bu yazı, regüle ağlarda neden anlık tutarlılığın değil, zamanla oluşan doğruluğun hedeflendiğini anlamaya odaklanıyor.

Regüle Ağ Ne Demektir?

Regüle bir ağ demek:

• Kimlerin katılabileceğinin belirlendiği
• Roller, yetkiler ve sorumlulukların tanımlandığı
• Kuralların merkezi olarak koyulduğu

ama

• uygulamanın
• performansın
• akışın
• teknik detayların

tek bir merkezden zorlanmadığı ağ demektir.

Yani regüle ≠ merkezi.

Peppol gibi ağlar bu yapıya iyi bir örnektir,
ama bu yaklaşım yalnızca Peppol’a özgü değildir.

Tek Bir “Doğru An” Yoktur

Regüle ağlarda bir işlem:

• tek sistemde tamamlanmaz
• tek aktörle sonuçlanmaz
• tek kontrolle bitmez

Bir doküman:

• gönderilir
• alınır
• ön kontrollerden geçer
• farklı sistemlerde işlenir
• daha derin kontrollerden geçer
• nihai sonuca ulaşır

Bu adımların hepsi aynı anda çalışamaz.

Dolayısıyla:

“Şu an doğru mu?” sorusunun
tek ve evrensel bir cevabı yoktur.

Bu gerçek, eventual consistency’nin temelidir.

Doğruluk Hızdan Daha Değerlidir

Regüle ağların önceliği:

• hızlı cevap vermek değil
• sorumluluğu doğru yerine getirmektir

Bazı kontroller:

• pahalıdır
• zaman alır
• dış sistemlere bağımlıdır
• hukuki sonuçlar doğurur

Bu kontrolleri her zaman senkron yapmak:

• sistemi yavaşlatır
• ağ genelinde gecikme yaratır
• operasyonel olarak sürdürülemez hâle getirir

Bu yüzden regüle ağlarda sıkça şu model görülür:

• önce kabul
• sonra doğrulama

Bu yaklaşım eventual consistency üretir ama sistemi ayakta tutar.

Merkez “Nasıl”ı Zorlayamaz

Regüle ağların merkezi otoritesi:

• hangi kuralların uygulanacağını tanımlar
• kimlerin hangi rolü üstleneceğini belirler

Ama şunu diyemez:

• bu kontrol şu anda çalışacak
• şu sürede cevap verilecek
• bu sırayla uygulanacak

Çünkü:

• ülkeler farklıdır
• kurumlar farklıdır
• teknik altyapılar farklıdır
• hukuki yükümlülükler farklıdır

Bu serbestlik:

• zamanlama farkı
• akış farkı
• davranış farkı

üretir.

Ama kuralın sonunda uygulanmasını garanti eder.

Hata Her Zaman Anında Yakalanamaz

Regüle ağlarda bazı hatalar:

• işlem başladıktan sonra fark edilir
• daha derin kontroller sırasında ortaya çıkar

Bu noktada sistemi tamamen durdurmak:

• pahalı olabilir
• operasyonel olarak mümkün olmayabilir
• bazen hukuken bile yasak olabilir

Bu yüzden sistemler:

• ilerlemeye izin verir
• hatayı daha sonra ele alır
• sonucu sonradan düzeltir

Bu yaklaşım da doğal olarak eventual consistency üretir.

Güven, Anlık Tutarlılıktan Gelmez

Burada kritik bir yanlış algı var:

“Güven = her mesaj anında doğru”

Regüle ağlarda güven şuradan gelir:

• kimlik doğrulama
• sorumluluk tanımı
• izlenebilirlik
• denetlenebilirlik
• yaptırım mekanizması

Yani güven:

• anlık doğruluktan değil
• yanlışın saklanamamasından doğar

Bir hata:

• geç fark edilebilir
• ama kaybolmaz
• iz bırakır
• açıklanabilir olur

Bu yapı eventual consistency ile uyumludur.

Gerçek Dünya Zaten Eventual

Aslında regüle ağlar, gerçek dünyanın dijital karşılığıdır.

• Bankacılık işlemleri
• Ticaret süreçleri
• Hukuki kararlar
• Vergi ve muhasebe akışları

hiçbiri “anında mutlak doğru” çalışmaz.

Regüle ağlar bu gerçeği dijital sistemlere taşır.

Mimari Sonuç

Bu gerçekler kabul edildiğinde entegrasyon yaklaşımı da değişir.

Regüle ağlarda:

• entegrasyon bir çağrı değil, bir süreçtir
• durum takibi merkezîdir
• asenkron akışlar doğaldır
• retry ve replay kaçınılmazdır
• gözlemlenebilirlik kritik hâle gelir

Eventual consistency bu mimarinin yan ürünü değil,
doğal sonucudur.

Sonuç

Regüle ağlarda eventual consistency:

• bir eksik
• bir zayıflık
• bir geçici çözüm

değildir.

Dağıtık sorumluluğun, hukuki gerekliliklerin ve teknik gerçeklerin kaçınılmaz birleşimidir.

Regüle ağlarda hedef:

Anında doğru olmak değil,
zaman içinde yanlış kalmamaktır.

Bu yüzden eventual consistency
kaçınılmazdır.

Başta çok cazip geliyor.
“Bu kütüphane tam istediğim gibi değil.”
“Bunu ben daha temiz yazarım.”
“Bağımlılık az olsun.”
“Kontrol bende olsun.”

Ama sistem büyüdükçe, ekip genişledikçe ve iş gerçek dünyaya çarptıkça şu gerçekle yüzleşiyorsun:
Her şeyi sen yazarsan, her şeyin bakımını da sen yaparsın.

Bu yazı, harici araçlardan neden kaçmamak gerektiğini değil;
nasıl ve ne zaman faydalanmak gerektiğini anlatıyor.

Her Şeyi Kendin Yazma Refleksi Nereden Geliyor?

Çoğu mühendislik ekibinde bu refleks doğal.
Özellikle genç ekiplerde veya erken aşama projelerde sık görülüyor.

Sebebi basit:

• Kontrol hissi
• Hızlı ilerleme algısı
• “Bağımlılık risklidir” düşüncesi
• Dış araca güvenmeme

Ama bu refleks uzun vadede şuna dönüşüyor:

• Kimsenin dokunamadığı özel çözümler
• Güncellenmeyen internal tool’lar
• Dokümansız “bizim framework”ler
• Sadece bir kişinin bildiği kritik parçalar

Ve en kötüsü:
Sistem geliştikçe yavaşlayan ekip.

Asıl Soru Şu: “Bu Problem Gerçekten Bana mı Ait?”

Bir noktadan sonra kendime şu soruyu sormaya başladım:

“Bu problemi gerçekten ben mi çözmeliyim,
yoksa bu zaten başkalarının yıllardır çözdüğü bir konu mu?”

Örnekler çok tanıdık:

• Loglama
• Queue yönetimi
• Retry & backoff
• Authentication
• Configuration management
• Observability
• Deployment orchestration

Bu alanlarda “kendim yazarım” demek,
ürünün ana problemini ertelemek demek.

Çünkü kullanıcı senin logging altyapını değil,
işinin çalışmasını önemsiyor.

Araç Seçimi = Mimari Karar

Bir harici aracı projeye almak, sadece teknik değil mimari bir karardır.

Yanlış araç:

• Sistemi karmaşıklaştırır
• Öğrenme eğrisini yükseltir
• Ekip içinde direnç oluşturur

Doğru araç ise:

• Koddan yük alır
• Ekibin hızını artırır
• Standartlaştırır
• Bakımı paylaşır

Buradaki kritik nokta şu:
Araç, problemi çözmeli; yeni problem üretmemeli.

“En İyi Araç” Yok, “Bu Problem İçin Uygun Araç” Var

Kafka mı RabbitMQ mu?
Redis mi PostgreSQL mi?
Kubernetes mi Nomad mı?
C# mı Python mı Java mı?

Bu soruların tek doğru cevabı yok.
Ama yanlış sorusu çok:

“Herkes bunu kullanıyor, biz de kullanalım.”

Benim yaklaşımım zamanla şuna evrildi:

• Problem ne?
• Yük profili ne?
• Operasyonel karmaşıklık ne?
• Ekip bu aracı tanıyor mu?
• Yarın bu sistemi kim devralacak?

Bazen en “havalı” çözüm değil,
en sıkıcı çözüm en doğru olan oluyor.

Araçtan Korkmamak, Ekosistemi Renklendirmek

Bir dönem şunu fark ettim:
Aynı problemleri çözmek için sürekli aynı araçlara abanıyoruz.

Oysa ekosistem geniş.
Ve bu bir tehdit değil, avantaj.

• Bazı işler için managed servis kullanmak
• Bazı işleri açık kaynak projelere bırakmak
• Bazı yerlerde “as a service” yaklaşımını benimsemek

Bunlar mimariyi zayıflatmaz.
Aksine, odaklanmanı sağlar.

Odak şu olmalı:

“Benim gerçekten katma değer ürettiğim yer neresi?”

Ekip Gerçeği: Araç Kültürünü Tanımadan Karar Vermek Hata

Bir diğer büyük yanılgı:
Aracı eleştirmek ama kültürünü tanımamak.

Birçok araç, yanlış kullanıldığı için kötü ün yapıyor.

• Kafka “karmaşık” deniyor ama aslında yanlış yerde kullanılmış
• Kubernetes “overkill” deniyor ama ekip hazır değil
• Bazı framework’ler “yavaş” deniyor ama problem yanlış modelleme

Burada önemli olan şu:

Araç tek başına iyi ya da kötü değildir.
Onu kullanan ekibin alışkanlıkları belirleyicidir.

Bu yüzden bir aracı seçerken sadece teknik dokümana değil,
ekibin gerçek yetkinliğine bakmak gerekiyor.

Maksimum Fayda = Mevcut Yapıyla Barışmak

Bir sistemi geliştirirken her şeyi baştan yıkıp yeniden yapmak cazip gelebilir.
Ama çoğu zaman bu gerçekçi değildir.

Benim öğrendiğim en değerli derslerden biri şuydu:

Elindeki yapı neyse, onunla maksimum faydayı üretmeye çalış.

Bu şu anlama geliyor:

• Kullanılan dili küçümseme
• Mevcut tool’ları karalama
• “Biz olsak baştan böyle yapmazdık” demek yerine
• “Bu yapıdan nasıl daha iyi sonuç çıkarırım?” diye düşün

Bu yaklaşım hem sistemi hem ekibi büyütüyor.

Sonuç: Mühendislik Ego Değil, Seçim İşidir

Bugün geriye dönüp baktığımda şunu net görüyorum:

• Her şeyi kendin yazmak sürdürülebilir değil
• Doğru araçlar seni yavaşlatmaz, hızlandırır
• Yanlış araç değil, yanlış yerde kullanılan araç vardır
• Ekip gerçeğini yok sayan mimari kağıt üzerinde kalır

Ve belki de en önemlisi:

İyi mimari, her şeyi kontrol etmek değil;
doğru yerlerde kontrolü paylaşabilmektir.

Bu denge kurulduğunda, sistem sadece çalışmaz;
yaşar, büyür ve devredilebilir hâle gelir.