Bir adayın CV’sinde üç farklı AWS sertifikası görüp, mülakatta kendisine verdiğimiz basit bir Nginx reverse proxy yapılandırmasında veya disk doluluğu sorununda tıkandığına şahit olduktan sonra kafamda şu soru netleşti: AWS Sertifikaları yerine Self-Hosting tecrübesi mi daha değerli? Sektörde uzun süredir devam eden bu tartışma, genellikle bulut sağlayıcılarının pazarlama bütçelerinin gölgesinde kalıyor. Oysa üretim ortamında (production) çalışan sistemlerin ayakta kalması, sertifika sınavlarındaki çoktan seçmeli soruları çözmekten çok daha farklı refleksler gerektiriyor.
Kendi altyapınızı yönetmek size işletim sisteminin, network katmanının ve veritabanı motorlarının gerçek sınırlarını öğretir. Bulut sağlayıcıları ise bu sınırları kalın bir soyutlama katmanıyla örterek sizi kendilerine bağımlı kılmak ister. Bu yazıda, kariyerinizde hangi yolun size daha fazla teknik derinlik ve uzun vadeli bağımsızlık kazandıracağını kendi saha tecrübelerim üzerinden analiz edeceğim.
AWS Sertifikaları yerine Self-Hosting: Hangisi Sizi Gerçek Bir Sistemci Yapar?
Altyapıyı bir başkasının API’leri üzerinden yönetmek ile doğrudan işletim sistemi seviyesinde kontrol etmek arasında çok ciddi bir zihniyet farkı vardır. AWS sertifikaları size Amazon’un kendi ekosistemindeki servisleri (RDS, ECS, ALB) nasıl birbirine bağlayacağınızı öğretirken, self-hosting doğrudan bu servislerin arkasında çalışan açık kaynaklı teknolojilerin kalbine inmenizi sağlar. Birinde bir butona basarak veritabanı ayağa kaldırırken, diğerinde PostgreSQL’in shared_buffers ayarını sunucunun RAM kapasitesine göre elinizle yapılandırmak zorunda kalırsınız.
Soyutlama katmanları mühendisleri tembelleştirir ve sistemlerin çalışma prensiplerinden uzaklaştırır. Kendi sunucunuzu barındırdığınızda (self-hosting), AWS’in sizden gizlediği disk I/O darboğazları, kernel seviyesindeki bellek limitleri (OOM killer) ve ağ paketlerinin kaybolması gibi gerçek dünya sorunlarıyla baş başa kalırsınız. Bu durum, hata anında “CloudWatch loglarında ne yazıyor?” diye bakmak yerine, doğrudan terminale bağlanıp journald veya dmesg çıktılarını okuma refleksi kazanmanızı sağlar.
graph TD; A["AWS Kullanıcısı"] --> B["Yönetilen AWS API"] B --> C["Soyutlanmış Altyapı"] D["Self-Hosting Uzmanı"] --> E["Linux İşletim Sistemi"] E --> F["Ağ ve Donanım Katmanı"]
Bulut Sertifikalarının Sınırları: Sınavı Geçmek ile Üretim Ortamını Yönetmek Arasındaki Fark Nedir?
Sertifika sınavları, gerçek hayattaki kriz anlarını ve belirsizlikleri simüle etmekte yetersiz kalır. AWS Solutions Architect sınavına hazırlanan biri, hangi depolama sınıfının daha ucuz olduğunu ezberleyebilir ancak disk doluluğu yüzünden kilitlenen bir PostgreSQL veritabanını kurtarmayı sınavda öğrenemez. Sınavlar doğrusal ve her zaman tek bir doğru cevabı olan senaryolar üzerine kuruludur; oysa üretim ortamı kaotiktir.
Geçmişte çalıştığım bir üretim ERP’si projesinde, bulut tabanlı bir veritabanı servisinin bağlantı limitlerine takıldığımızda yaşadığımız darboğazı hatırlıyorum. Sınav müfredatına göre çözüm hemen “Instance tipini büyütmek” veya “Read Replica eklemek” gibi maliyetli adımlardı. Ancak sorunun kök nedeni, yazılımdaki kontrolsüz bir ORM sorgusunun yarattığı N+1 problemiydi ve bunu çözmek bulut konsolundan değil, doğrudan kod seviyesinde connection pool ayarlarını (pg_isready ve pg_activity kullanarak) optimize etmekten geçiyordu.
Kendi Sunucunu Yönetmek (Self-Hosting) Hangi Pratik Becerileri Kazandırır?
Kendi sunucunuzu (bare-metal veya VPS) yönettiğinizde, modern yazılım dünyasının temelini oluşturan Linux işletim sistemiyle doğrudan temas kurarsınız. Bu temas, size servislerin arka planda nasıl çalıştığını gösteren systemd unit dosyalarını yazmayı, servis bağımlılıklarını yönetmeyi ve log rotasyonunu yapılandırmayı öğretir. Aşağıdaki gibi basit bir systemd servis dosyası yazmak ve bunu production ortamında canlı tutmak, AWS ECS üzerinde bir container çalıştırmaktan çok daha öğreticidir:
[Unit]
Description=Uretim ERP API Servisi
After=network.target postgresql.service
[Service]
Type=simple
User=deploy
WorkingDirectory=/var/www/erp
ExecStart=/var/www/erp/venv/bin/uvicorn main:app --host 127.0.0.1 --port 8000
Restart=always
RestartSec=5
StandardOutput=journal
StandardError=journal
LimitNOFILE=65535
[Install]
WantedBy=multi-user.targetBu servis dosyasını sunucuya yükleyip systemctl enable --now erp-api komutunu çalıştırdığınızda, işletim sisteminin bu süreci nasıl izlediğini, hata durumunda nasıl yeniden başlattığını ve journalctl -u erp-api -f ile logların nasıl anlık olarak takip edildiğini bizzat deneyimlersiniz. Ayrıca, ağ tarafında iptables kuralları yazarak güvenlik duvarı yapılandırmayı, Docker bridge network’lerinin nasıl çalıştığını anlamayı ve Nginx üzerinde SSL sertifikalarını elinizle yönetmeyi öğrenirsiniz.
Maliyet ve Kontrol Dengesi: Şirketler Neden Bare-Metal ve Hibrit Altyapılara Dönüyor?
Son yıllarda sektörde ciddi bir buluttan kaçış (cloud repatriation) dalgası yaşanıyor. Şirketler, bulut sağlayıcılarının başlangıçta ucuz görünen ancak ölçeklendikçe kontrol edilemeyen faturalara dönüşen maliyet modellerinden rahatsız olmaya başladı. Özellikle veri aktarım (egress) maliyetleri ve yüksek IOPS gerektiren disk yapılandırmaları, self-hosting veya bare-metal kiralama modellerine göre fahiş fiyatlanıyor.
Kendi donanımınızı veya kiralık sunucularınızı yönettiğinizde, her kuruşun karşılığında hangi fiziksel kaynağı aldığınızı net olarak bilirsiniz. Örneğin, yüksek trafikli bir web uygulamasında AWS Application Load Balancer (ALB) için ödediğiniz saatlik ücret ve veri işleme maliyeti yerine, aylık sabit ücretli bir sunucu üzerinde optimize edilmiş bir Nginx veya HAProxy çalıştırmak kabaca onda bir maliyetle çok daha yüksek throughput sağlayabilir. Bu maliyet bilinci, yazılım mimarisi tasarlarken kaynakları verimli kullanma disiplini kazanmanızı sağlar.
| Özellik | AWS / Yönetilen Bulut | Self-Hosting (Bare-Metal / VPS) |
|---|---|---|
| Başlangıç Hızı | Çok Hızlı (Dakikalar içinde) | Orta (Kurulum ve konfigürasyon gerekir) |
| Maliyet Yapısı | Kullandıkça Öde (Değişken ve riskli) | Sabit Aylık / Yıllık Ücret (Öngörülebilir) |
| Teknik Derinlik | Düşük (Sadece API ve konsol yönetimi) | Yüksek (İşletim sistemi, ağ ve donanım) |
| Bağımlılık (Lock-in) | Yüksek (AWS ekosistemine bağımlılık) | Yok (Taşınabilir açık kaynak standartları) |
| Hata Ayıklama | Sınırlı (Sağlayıcının sunduğu loglar) | Sınırsız (Tüm kernel ve sistem logları) |
Hangisini Seçmeli: Kariyerinizin Hangi Aşamasında Hangi Yolu Tercih Etmelisiniz?
Kariyerinizin başındaysanız, kendinizi bulutun hazır şablonlarına teslim etmek yerine self-hosting ile sistemlerin nasıl çalıştığını öğrenmeniz uzun vadeli gelişiminiz için çok daha sağlıklıdır. İlk 2-3 yılınızda kendi ev laboratuvarınızı (home lab) kurmak, ucuz VPS’ler üzerinde kendi web sitelerinizi, veritabanlarınızı ve mail sunucularınızı barındırmak size parayla satın alınamayacak bir tecrübe kazandırır. Bu aşamada alınan AWS sertifikaları, adayın altı boş bir teorik bilgiye sahip olduğu izlenimini yaratabilir.
Ancak kurumsal dünyada, özellikle büyük ölçekli ve regülasyona tabi şirketlerde çalışıyorsanız, AWS veya diğer büyük bulut sağlayıcılarının sertifikaları birer “kapı açıcı” rolü oynayabilir. Şirketler, iş ortaklığı seviyelerini (AWS Partner Network gibi) korumak için bünyelerinde sertifikalı personel bulundurmak zorundadır. Bu nedenle, teknik derinliğinizi self-hosting ile sabitledikten sonra, kurumsal pazarda elinizi güçlendirmek için bu sertifikaları birer araç olarak alabilirsiniz.
Kendi Altyapınızı Kurarken Hangi Temel Bileşenleri Öğrenmelisiniz?
Gerçek bir self-hosting deneyimi elde etmek istiyorsanız, işe her şeyi otomatik olarak kuran tek tıkla kurulum panellerinden (cPanel, Plesk gibi) uzak durarak başlamalısınız. Temiz bir Debian veya Ubuntu sunucu kiralayıp, tüm bileşenleri terminal üzerinden elinizle kurup yapılandırmak en öğretici yöntemdir. Bu süreçte odaklanmanız gereken öncelikli başlıklar şunlardır:
- İşletim Sistemi Güvenliği: SSH portunu değiştirmek, şifre ile girişi kapatıp sadece SSH Key kullanımını zorunlu kılmak ve
fail2bankurarak brute-force saldırılarını engellemek. - Web Sunucusu ve Ters Vekil (Reverse Proxy): Nginx veya Caddy kullanarak gelen istekleri karşılamak, SSL/TLS sertifikalarını Let’s Encrypt (
certbot) ile otomatik yenilenecek şekilde yapılandırmak. - Veritabanı Yönetimi: PostgreSQL veya MariaDB kurulumu yapmak, veritabanı erişim izinlerini (
pg_hba.conf) sadece lokal ağla sınırlandırmak ve düzenli yedekleme (cronvepg_dumpile) mekanizmaları kurmak. - Konteynerizasyon: Uygulamaları Docker ve
docker-composekullanarak izole etmek, container loglarının disk doluluğuna yol açmaması için log rotation limitleri koymak.
Aşağıdaki basit docker-compose.yml dosyası, production ortamında kaynak sınırlandırması (limits) yapılarak bir uygulamanın ve veritabanının nasıl güvenli bir şekilde ayağa kaldırılacağını gösteren iyi bir başlangıç örneğidir:
version: '3.8'
services:
db:
image: postgres:15-alpine
container_name: erp_postgres
environment:
POSTGRES_USER: erp_user
POSTGRES_PASSWORD: guvenli_parola_buraya
POSTGRES_DB: erp_prod
volumes:
- pgdata:/var/lib/postgresql/data
deploy:
resources:
limits:
cpus: '1.0'
memory: 1gb
restart: unless-stopped
web:
image: nginx:alpine
container_name: erp_nginx
ports:
- "80:80"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
depends_on:
- db
restart: unless-stopped
volumes:
pgdata:Son Söz
Kariyer tercihim ve işe alımlarda öncelik verdiğim kriter her zaman net: AWS sertifikası olan ama arka planda çalışan Linux’un ağ köprüsünden (bridge) bihaber olan bir aday yerine, evinde veya ucuz bir VPS üzerinde kendi servislerini ayağa kaldırıp bozmuş, hata loglarında sabahlamış bir adayı tercih ederim. Sertifikalar size kurumsal dünyanın kapılarını aralayabilir ancak sizi o kapının arkasında kalıcı kılacak olan şey, self-hosting sürecinde edindiğiniz ve bulut sağlayıcılarından bağımsız olan saf mühendislik refleksleridir. Kendinize yatırım yapın, sistemleri bozun, tekrar kurun ve bulutun size sunduğu hazır şablonların arkasındaki gerçek dünyayı keşfedin.