1.
buradan
yıllarca aws'in o "uçak kokpiti kılıklı" dashboard'larında, "ben sadece bir tane script çalıştıracaktım neden 15 sayfa döküman okuyorum?" diye ağlayan developer'ların gözyaşlarını silen, bulut bilişimin son dönemdeki en delikanlı platformu.
olayı şöyle özetleyeyim; aws veya azure kullanmak, sanayide şanzıman indirmeye benzer. her yer yağ pas içindedir, elinde ingiliz anahtarıyla "iam role" sıkıştırır, "vpc peering" diye conta yakarsın. heroku ise o mahallenin zengin ama biraz yaşlanmış, hantallaşmış ve her şeye fahiş fiyat çeken esnafıdır. railway ise bu mahalleye yeni açılan, her şeyi otomatiğe bağlamış, "abi sen kodu getir gerisini dert etme" diyen o cin gibi çocuktur.
mesela elinde gıcır gıcır bir .net 9.0 api, yanına can yoldaşı bir redis ve arka planda amele gibi veri tokatlayan bir worker üçlüsü var diyelim. normalde bunları ayağa kaldırmak için dockerfile içinde "aspnet:9.0" mıydı, "sdk:9.0" mıydı diye debelenir, portları birbirine bağlayacağım diye akraba olursun. railway'de ise olay tam olarak şu kadar zahmetsiz:
nixpacks denilen büyü: railway reposuna bakıyor, "haaa sen .net 9.0 yazmışsın, yanına da biraz redis atmışsın, dur ben sana mis gibi paket yapayım" diyor. .csproj dosyasını koklayıp anlıyor resmen, sana "dockerfile yaz" diye eziyet etmiyor.
mikroservis meselesi: gittin 'new service' dedin, redis'i tek tıkla fırlattın içeri. sana anında bir 'internal url' veriyor. .net api'ni ve worker'ını da bağladığın an, bunlar sanki aynı odadaki kankalarmış gibi haberleşmeye başlıyor.
private networking: api'den gelen ağır işi redis'e fırlatıyorsun, worker oradan kapıp işliyor. sen bu sırada "acaba redis'e dışarıdan sızarlar mı?" diye uykundan olmuyorsun; çünkü mutfakta (worker ve redis) ne döndüğünü kimse görmüyor, sadece api'nin kapısı dış dünyaya açık.
sağlık kontrolü (health check): .net 9.0 uygulaman ayağa kalkarken railway ensesinde bekliyor. "bu çocuk düzgünce nefes alıyor mu?" diye bakıyor. eğer uygulama ayağa kalkamazsa veya bir noktada şişip kalırsa (crash), railway durumu çakıp trafiği kesiyor veya servisi yeniden başlatıyor. "müşteriye 500 hatası yedirmeyelim" diye canla başla çalışıyor.
deployment plan (kesintisiz geçiş): yeni bir kod mu attın? railway eski sürümü hemen "şak" diye kapatmıyor. önce yeni .net 9.0 sürümünü yan tarafta usulca ayağa kaldırıyor, health check'ten "ok" alınca trafiği sessizce yeniye kaydırıyor. yani kullanıcı ruhu bile duymadan sen sürüm atlamış oluyorsun.
ephemeral environments: yani "geçici ortamlar". bir pull request mi açtın? çat diye o pr'a özel geçici bir link fırlatıyor sana. "bak bakalım kodun canlıda nasıl duruyor" diyor. merge edince de o ortamı imha edip "israfa gerek yok" diyor. tam bir çevreci, tam bir tasarrufçu.
kullandığın kadar öde: "instance açık kaldı, gece ben uyurken paramı yedi" derdi yok. işlemci ve ram ne kadar terlediyse o kadar fatura kesiyorlar.
özetle; mikroservis mimarisi kuracağım diye devops ameleliğine soyunmak istemeyen, "monorepo desteği olsun, tüm servislerim tek bir projede çiçek gibi dursun, ben sadece koduma odaklanayım" diyen her yazılımcının uğraması gereken durak. heroku'nun cenaze namazını kıldıran, devops dünyasının en yakışıklı çözümüdür.
fiyatlandırma sayfasındaki o barın hareket edişi, insanda "acaba daha ne kadar servis eklesem de sistem patlamasa" hissi uyandırır. bağımlılık yapar, dikkatli kullanın.
yıllarca aws'in o "uçak kokpiti kılıklı" dashboard'larında, "ben sadece bir tane script çalıştıracaktım neden 15 sayfa döküman okuyorum?" diye ağlayan developer'ların gözyaşlarını silen, bulut bilişimin son dönemdeki en delikanlı platformu.
olayı şöyle özetleyeyim; aws veya azure kullanmak, sanayide şanzıman indirmeye benzer. her yer yağ pas içindedir, elinde ingiliz anahtarıyla "iam role" sıkıştırır, "vpc peering" diye conta yakarsın. heroku ise o mahallenin zengin ama biraz yaşlanmış, hantallaşmış ve her şeye fahiş fiyat çeken esnafıdır. railway ise bu mahalleye yeni açılan, her şeyi otomatiğe bağlamış, "abi sen kodu getir gerisini dert etme" diyen o cin gibi çocuktur.
mesela elinde gıcır gıcır bir .net 9.0 api, yanına can yoldaşı bir redis ve arka planda amele gibi veri tokatlayan bir worker üçlüsü var diyelim. normalde bunları ayağa kaldırmak için dockerfile içinde "aspnet:9.0" mıydı, "sdk:9.0" mıydı diye debelenir, portları birbirine bağlayacağım diye akraba olursun. railway'de ise olay tam olarak şu kadar zahmetsiz:
nixpacks denilen büyü: railway reposuna bakıyor, "haaa sen .net 9.0 yazmışsın, yanına da biraz redis atmışsın, dur ben sana mis gibi paket yapayım" diyor. .csproj dosyasını koklayıp anlıyor resmen, sana "dockerfile yaz" diye eziyet etmiyor.
mikroservis meselesi: gittin 'new service' dedin, redis'i tek tıkla fırlattın içeri. sana anında bir 'internal url' veriyor. .net api'ni ve worker'ını da bağladığın an, bunlar sanki aynı odadaki kankalarmış gibi haberleşmeye başlıyor.
private networking: api'den gelen ağır işi redis'e fırlatıyorsun, worker oradan kapıp işliyor. sen bu sırada "acaba redis'e dışarıdan sızarlar mı?" diye uykundan olmuyorsun; çünkü mutfakta (worker ve redis) ne döndüğünü kimse görmüyor, sadece api'nin kapısı dış dünyaya açık.
sağlık kontrolü (health check): .net 9.0 uygulaman ayağa kalkarken railway ensesinde bekliyor. "bu çocuk düzgünce nefes alıyor mu?" diye bakıyor. eğer uygulama ayağa kalkamazsa veya bir noktada şişip kalırsa (crash), railway durumu çakıp trafiği kesiyor veya servisi yeniden başlatıyor. "müşteriye 500 hatası yedirmeyelim" diye canla başla çalışıyor.
deployment plan (kesintisiz geçiş): yeni bir kod mu attın? railway eski sürümü hemen "şak" diye kapatmıyor. önce yeni .net 9.0 sürümünü yan tarafta usulca ayağa kaldırıyor, health check'ten "ok" alınca trafiği sessizce yeniye kaydırıyor. yani kullanıcı ruhu bile duymadan sen sürüm atlamış oluyorsun.
ephemeral environments: yani "geçici ortamlar". bir pull request mi açtın? çat diye o pr'a özel geçici bir link fırlatıyor sana. "bak bakalım kodun canlıda nasıl duruyor" diyor. merge edince de o ortamı imha edip "israfa gerek yok" diyor. tam bir çevreci, tam bir tasarrufçu.
kullandığın kadar öde: "instance açık kaldı, gece ben uyurken paramı yedi" derdi yok. işlemci ve ram ne kadar terlediyse o kadar fatura kesiyorlar.
özetle; mikroservis mimarisi kuracağım diye devops ameleliğine soyunmak istemeyen, "monorepo desteği olsun, tüm servislerim tek bir projede çiçek gibi dursun, ben sadece koduma odaklanayım" diyen her yazılımcının uğraması gereken durak. heroku'nun cenaze namazını kıldıran, devops dünyasının en yakışıklı çözümüdür.
fiyatlandırma sayfasındaki o barın hareket edişi, insanda "acaba daha ne kadar servis eklesem de sistem patlamasa" hissi uyandırır. bağımlılık yapar, dikkatli kullanın.
devamını gör...
2.
millet ne saçma başlıklar açıyor başlığı.
devamını gör...