14 Kas 2025·8 dk
Craig McLuckie ve Cloud-Native: Platform Düşüncesi Kazanıyor
Craig McLuckie’nin cloud-native benimsenmesindeki rolüne ve platform düşüncesinin konteynerleri güvenilir üretim altyapısına nasıl dönüştürdüğüne dair pratik bir bakış.
Craig McLuckie’nin cloud-native benimsenmesindeki rolüne ve platform düşüncesinin konteynerleri güvenilir üretim altyapısına nasıl dönüştürdüğüne dair pratik bir bakış.
Ekipler konteyner başlatamadıkları için zorlanmıyor. Zorlanıyorlar çünkü yüzlerce konteyneri güvenli şekilde çalıştırmak, kesinti olmadan güncellemek, bir şeyler bozulduğunda kurtarmak ve yine de özellikleri zamanında teslim etmek zorundalar.
Craig McLuckie’nin “cloud-native” hikayesi önemli çünkü gösterişli demoların zafer turu değil. Bu, konteynerlerin gerçek ortamlarda işletilebilir hale nasıl geldiğinin kaydı—olayların yaşandığı, uyumluluğun var olduğu ve işin öngörülebilir teslimata ihtiyaç duyduğu yerler.
“Cloud-native”, “bulutta çalışmak” değil. Yazılımı sıkça dağıtılabilecek, talep değiştiğinde ölçeklenebilecek ve parçalar arızalandığında çabuk onarılabilecek şekilde inşa edip işletme yaklaşımıdır.
Pratikte bu genelde şunları ifade eder:
Erken konteyner benimsemeleri genellikle bir araç kutusu gibiydi: ekipler Docker alıyor, scriptleri birbirine bağlıyordu ve operasyonların yetişeceğini umuyordu. Platform düşüncesi bunu tersine çevirir. Her ekip kendi üretim yolunu icat etmek yerine, güvenli, uyumlu ve gözlemlenebilir yolu aynı zamanda kolay yol yapan paylaşılan “hazırlanmış yollar” yani bir platform inşa edersiniz.
Bu değişim, “konteyner çalıştırabiliyoruz”dan “işimizi onların üzerinde yürütebiliyoruz”ya geçişin köprüsüdür.
Bu yazı sonucun sorumluluğunu taşıyanlar için, sadece mimari diyagramlarla ilgilenenler için değil:
Hedefiniz ölçekli, güvenilir teslimatsa, bu tarihten pratik dersler çıkarabilirsiniz.
Craig McLuckie, erken cloud-native hareketiyle bağlantılı en tanınmış isimlerden biridir. Onu Kubernetes, Cloud Native Computing Foundation (CNCF) ve altyapının bir ürün gibi ele alınması gerektiği fikriyle ilgili konuşmalarda göreceksiniz—bilet yığını veya kabile bilgisinden ziyade ürün yaklaşımı gibi.
Kesin olmakta fayda var. McLuckie tek başına “cloud-native”ı icat etmedi ve Kubernetes tek kişilik bir proje olmadı. Kubernetes Google’daki bir ekip tarafından yaratıldı ve McLuckie o erken çabanın parçasıydı.
İnsanların ona sıkça atfettiği şey, mühendislik kavramını daha geniş endüstrinin gerçekten benimseyebileceği bir şeye dönüştürmeye yardımcı olmasıdır: daha güçlü topluluk inşası, net paketleme ve tekrarlanabilir operasyonel uygulamalara yönelik itki.
Kubernetes ve CNCF döneminde McLuckie’nin mesajı trend mimarilerden çok üretimin öngörülebilir hale getirilmesi üzerine oldu. Bu şu anlamlara geliyor:
“Paved roads”, “golden paths” veya “platform as a product” gibi ifadeleri duyduysanız, hepsi aynı fikrin etrafında dolaşıyor: doğru şeyi yapmayı kolaylaştırarak ekiplerin bilişsel yükünü azaltmak.
Bu gönderi biyografi değil. McLuckie, konteynerler, orkestrasyon ve ekosistem inşasının kesişiminde durduğu için kullanışlı bir referans noktası. Buradaki dersler kişilik hakkında değil—platform düşüncesinin neden gerçek üretimde konteynerleri çalıştırmanın kilidini açtığı hakkında.
Konteynerler “cloud-native” etiketi yaygınlaşmadan çok önce heyecan verici bir fikirdi. Günlük ifadeyle bir konteyner, uygulamayı gerekli dosya ve kütüphanelerle birlikte paketlemenin bir yolu; farklı makinelerde aynı şekilde çalıştırılmasını sağlar—ürünü içindeki tüm parçalarla mühürlenmiş bir kutuda göndermeye benzer.
Başlangıçta birçok ekip konteynerleri yan projeler, demolar ve geliştirici iş akışları için kullandı. Yeni servisleri hızlı denemek, test ortamları oluşturmak ve “bende çalışıyor” sürprizlerinden kaçınmak için iyiydiler.
Ama birkaç konteynerden 7/24 çalışan bir üretim sistemine geçmek bambaşka bir iştir. Araçlar gerçekti, ama operasyonel hikâye eksikti.
Yaygın sorunlar hızla ortaya çıktı:
Konteynerler yazılımı taşınabilir hale getirdi, ama taşınabilirlik tek başına güvenilirlik garanti etmedi. Ekiplerin tutarlı dağıtım uygulamalarına, net sahipliğe ve operasyonel korunaklara ihtiyacı vardı—böylece konteynerleştirilmiş uygulamalar bir kere çalışmak yerine her gün öngörülebilir şekilde çalışırdı.
Platform düşüncesi, bir şirketin altyapıyı tek seferlik bir proje olarak görmeyi bırakıp iç bir ürün olarak ele almaya başladığı andır. “Müşteriler” geliştiricileriniz, veri ekipleri ve yazılım gönderen herkes. Ürün hedefi daha fazla sunucu ya da daha fazla YAML değil—fikirden üretime daha pürüzsüz bir yoldur.
Gerçek bir platformun net bir vaadi vardır: “Bu yolları kullanarak inşa ve dağıtım yaparsan güvenilirlik, güvenlik ve öngörülebilir teslimat elde edersin.” Bu vaat ürün alışkanlıkları gerektirir—dokümantasyon, destek, versiyonlama ve geri bildirim döngüleri. Ayrıca makul varsayılanlar, hazırlanan yollar ve ekiplerin gerçekten ihtiyaç duyduğunda kaçabilecekleri bir çıkış da dahil olmak üzere kasıtlı bir kullanıcı deneyimi gerektirir.
Standardizasyon karar yorgunluğunu ortadan kaldırır ve kazara karmaşıklığı önler. Ekipler aynı dağıtım desenlerini, loglama ve erişim kontrollerini paylaştığında, problemler tekrarlanabilir olur—ve bu nedenle çözülebilir. On-call dönüşümleri iyileşir çünkü olaylar tanıdıktır. Güvenlik incelemeleri daha hızlı olur çünkü platform korunakları yerleşik hale getirir, her ekip bunları yeniden icat etmek zorunda kalmaz.
Bu herkesin aynı kutuya sokulması meselesi değil. İşin ayırt edici kısmı için ekiplerin enerjisini harcayabilmesi adına %80’inin sıkıcı olması konusunda anlaşmaktır.
Platform yaklaşımları ortaya çıkmadan önce altyapı genellikle özel bilgiye bağlıydı: birkaç kişi hangi sunucuların yamalandığını, hangi ayarların güvenli olduğunu ve hangi scriptlerin “iyi” olduğunu bilirdi. Platform düşüncesi bunu tekrarlanabilir desenlerle değiştirir: şablonlar, otomatik sağlama ve geliştiriciden üretime tutarlı ortamlar.
Doğru yapıldığında platformlar daha az evrakla daha iyi yönetişim sağlar. Politikalar otomatik kontroller haline gelir, onaylar denetlenebilir iş akışlarına dönüşür ve uyumluluk kanıtı ekipler dağıttıkça üretilir—böylece organizasyon kontrolü sağlar ama herkesi yavaşlatmaz.
Konteynerler uygulamayı paketlemeyi ve göndermeyi kolaylaştırdı. Zor olan, gönderdikten sonra ne olduğuydu: nerede çalışacağına karar vermek, sağlıklı tutmak ve trafik ya da altyapı değiştiğinde uyum sağlamak.
İşte Kubernetes’in doldurduğu boşluk budur. “Bir yığın konteyneri” her gün işletilebilen bir şeye dönüştürdü; sunucular çöktüğünde, sürümler geldiğinde ve talep arttığında bile.
Kubernetes genellikle “konteyner orkestrasyonu” olarak tanımlanır, ama pratik problemler daha spesiftir:
Bir orkestratör olmadan ekipler bu davranışları scriptlerle yapar ve istisnaları elle yönetir—ta ki scriptler gerçeğe uymayana kadar.
Kubernetes, ne istediğinizi ilan ettiğiniz bir yer olan paylaşılmış bir kontrol düzlemi fikrini popülerleştirdi (“bu servisten 3 adet çalıştır”). Platform, gerçek dünyayı o istenen duruma uyacak şekilde sürekli çalışır.
Bu sorumluluklarda büyük bir değişim demektir:
Kubernetes, konteynerler moda olduğu için ortaya çıkmadı. Büyük filoları işletme deneyimlerinden büyüdü: altyapıyı geri bildirim döngülerine sahip bir sistem olarak ele almak, tek seferlik sunucu görevleri olarak değil. Bu operasyonel zihniyet, konteynerleri “çalıştırabiliyoruz” dan “üretimde güvenle çalıştırabiliyoruz”a taşıyan köprü olmasını sağladı.
Cloud-native sadece yeni araçlar getirmedi—yazılım gönderme günlük ritmini değiştirdi. Ekipler “el yapımı sunucular ve manuel runbook”tan API’lerle, otomasyonla ve deklaratif yapılandırmayla yönetilen sistemlere geçti.
Cloud-native kurulum, altyapının programlanabilir olduğunu varsayar. Bir veritabanı, yük dengeleyici veya yeni bir ortam mı gerekiyor? Manuel kurulum beklemek yerine ekipler ne istediklerini tarif eder ve otomasyon onu oluşturur.
Ana değişim deklaratif konfigürasyondur: istenen durumu tanımlarsınız (“bu servisin 3 kopyasını çalıştır, bu portta aç, belleği X ile sınırla”) ve platform gerçek dünyayı o duruma uydurmaya çalışır. Bu değişiklikleri incelenebilir, tekrarlanabilir ve geri alınması daha kolay yapar.
Geleneksel teslimatta canlı sunucuların yamalanması yaygındı. Zamanla her makine biraz farklı hale gelir—konfigürasyon sürüklenmesi ve bu ancak bir olay sırasında ortaya çıkar.
Cloud-native teslimat ekipleri immutable dağıtımlara itti: bir artifakt bir kere oluşturulur (çoğunlukla bir container image), dağıtılır; bir değişiklik gerektiğinde yeni sürüm dağıtılır. Otomatik roll-out ve sağlık kontrolleriyle birleşince bu yaklaşım bir-off düzeltmelerden kaynaklanan “gizemli kesintileri” azaltır.
Konteynerler, birçok küçük servisi tutarlı şekilde paketlemeyi kolaylaştırdı; bu da mikroservis mimarilerini teşvik etti. Mikroservisler ise dağıtım, ölçekleme ve servis keşfi için tutarlı gereksinimleri artırdı—bunlar orkestrasyonun güçlü olduğu alanlar.
Ödün: daha fazla servis, daha fazla operasyonel yük getirir (gözlemleme, ağ, sürümleme, olay müdahalesi). Cloud-native bu karmaşıklığı yönetmeye yardım eder, ama yok etmez.
Taşınabilirlik, ekipler ortak dağıtım ilkelere ve API’lere standardize olduğunda gelişti. Yine de “her yerde çalıştır” genelde iş gerektirir—güvenlik, depolama, ağ ve yönetilen servisler arasındaki farklar önemlidir. Cloud-native, kilitlenmeyi ve sürtüşmeyi azaltmak olarak anlaşılmalıdır, yok etmek olarak değil.
Kubernetes sadece güçlü olduğu için yayılmadı. Nötr bir yuvaya, net yönetişime ve rakip şirketlerin kuralları tek bir satıcının sahiplenmeden işbirliği yapabileceği bir yere sahip olduğu için yayıldı.
Cloud Native Computing Foundation (CNCF), açık karar alma, öngörülebilir proje süreçleri ve halka açık yol haritaları ile paylaşılan yönetişim yarattı. Bu, çekirdek altyapıya bahis yapan ekipler için önemlidir. Kurallar şeffaf ve tek bir şirketin iş modeline bağlı olmadığında benimseme daha az riskli görünür—ve katkıda bulunmak daha cazip hale gelir.
Kubernetes ve ilgili projeleri barındırarak CNCF, “popüler bir açık kaynak aracı”nı tek bir satıcının üstünde uzun vadeli bir platforma dönüştürmeye yardımcı oldu. Sağladıkları şunları içerir:
Çok sayıda katkıcı (bulut sağlayıcıları, startup’lar, işletmeler ve bağımsız mühendisler) ile Kubernetes daha hızlı ve gerçek dünya yönlerinde evrildi: ağ, depolama, güvenlik ve ikinci-gün operasyonları. Açık API’ler ve standartlar araçların entegrasyonunu kolaylaştırdı, bu da kilitlenmeyi azalttı ve üretim kullanımına dair güveni artırdı.
CNCF aynı zamanda ekosistem patlamasını hızlandırdı: service mesh’ler, ingress denetleyiciler, CI/CD araçları, politika motorları, gözlemlenebilirlik yığınları ve daha fazlası. Bu bolluk bir güç ama aynı zamanda örtüşme yaratır.
Çoğu ekip için başarı, iyi desteklenen küçük bir bileşen seti seçmekten, birlikte çalışabilirliği tercih etmekten ve sahipliği netleştirmekten gelir. “Her şeyin en iyisi” yaklaşımı genellikle bakım yüküne yol açar, daha iyi teslimata değil.
Konteynerler ve Kubernetes, “yazılımı nasıl çalıştırırız?” sorusunun büyük bir kısmını çözdü. Otomatik olarak daha zor soruyu çözmediler: “gerçek kullanıcılar geldiğinde nasıl çalışır halde tutarız?” Eksik katman operasyonel güvenilirliktir—net beklentiler, paylaşılan uygulamalar ve doğru davranışları varsayılan yapan bir sistem.
Bir ekip hızlı gönderim yapıp yine de bir kötü dağıtımla kaosa yol açabilir eğer üretim tabanı tanımsızsa. Asgari olarak şunlara ihtiyacınız var:
Bunlar yoksa her servis kendi kurallarını icat eder ve güvenilirlik şansa kalır.
DevOps ve SRE önemli alışkanlıklar getirdi: sahiplik, otomasyon, ölçülmüş güvenilirlik ve olaylardan öğrenme. Ancak alışkanlıklar onlarca ekip ve yüzlerce servis üzerinde ölçeklenmez.
Platformlar bu uygulamaları tekrarlanabilir kılar. SRE hedefler belirler (örn. SLO’lar) ve geri bildirim döngüleri kurar; platform bu hedeflere ulaşmak için hazırlanan yollar sağlar.
Güvenilir teslimat genelde tutarlı bir yetenek seti gerektirir:
İyi bir platform bu varsayılanları şablonlara, pipeline’lara ve çalışma zamanı politikalara yerleştirir: standart paneller, ortak uyarı kuralları, dağıtım korunakları ve geri alma mekanizmaları. Böylece güvenilirlik isteğe bağlı olmayı bırakır ve yazılım göndermenin öngörülebilir bir sonucu haline gelir.
Cloud-native araçlar güçlü olabilir ve yine de çoğu ürün ekibi için “çok fazla” hissi verebilir. Platform mühendisliği bu boşluğu kapatır. Misyon basittir: uygulama ekiplerinin bilişsel yükünü azaltmak, böylece özellik göndermeye odaklanıp altyapı uzmanı gibi çalışmak zorunda kalmasınlar.
İyi bir platform ekibi iç altyapıyı bir ürün gibi ele alır. Net kullanıcılar (geliştiriciler), net çıktılar (güvenli, tekrar edilebilir teslimat) ve bir geri bildirim döngüsü vardır. Bir yığın Kubernetes ilkesini teslim etmek yerine, platform fikirli yollarla servisleri inşa etmek, dağıtmak ve işletmek için öneriler sunar.
Pratik bir mercek: “Bir geliştirici fikirden çalışan bir servise kaç bilet açmadan gelebiliyor?” sorusunu sormaktır. Bu iş akışını sıkıştıran araçlar—korunakları korurken—cloud-native platform hedefiyle uyumludur.
Çoğu platform, ekiplerin varsayılan olarak seçebileceği yeniden kullanılabilir “hazırlanmış yollar” setidir:
Amaç Kubernetes’i saklamak değil—onu kazara karmaşıklığı önleyecek makul varsayılanlara paketlemektir.
Bu ruhla, Koder.ai ekiplerin sohbet yoluyla dahili araçlar veya ürün özellikleri hızlıca kurmak istediklerinde bir “DX hızlandırıcısı” katmanı olarak kullanılabilir; sonra entegrasyon zamanı geldiğinde kaynak kodu dışa aktarabilirsiniz. Platform ekipleri için onun planning modeu ve yerleşik snapshots/rollback özellikleri, üretim iş akışlarında istediğiniz güvenilirlik-öncelikli duruşu da yansıtabilir.
Her hazırlanan yol bir ödündür: daha fazla tutarlılık ve daha güvenli operasyonlar, ama daha az tekil seçenek. Platform ekipleri en iyisini, şu sunumu yaparken başarır:
Platform başarısını ölçülebilir şekilde görebilirsiniz: yeni mühendislerin daha hızlı işe başlaması, daha az el yapımı dağıtım scripti, daha az “snowflake” cluster ve olaylarda daha net sahiplik. Ekipler “bu servisin sahibi kim ve nasıl gönderiyoruz?” sorusunu toplantı açmadan yanıtlayabiliyorsa, platform işini yapıyor demektir.
Cloud-native teslimatı hızlandırabilir ve operasyonları sakinleştirebilir—ama ekipler neyi geliştirmeye çalıştıklarında net olduklarında. Birçok yavaşlama, Kubernetes ve ekosisteminin amaç olarak değil araç olarak ele alınmasından kaynaklanır.
Yaygın bir hata, Kubernetes’i “modern ekiplerin yaptığı şey” diye benimsemektir; kısa vadeli hedefler (daha kısa lead time, daha az olay, daha tutarlı ortamlar) olmadan. Sonuç görünür kazanç olmadan çok göç çalışması olur.
Başarı kriterleri önceden tanımlanmazsa, hangi aracın seçileceği, ne kadar standardize edileceği ve platformun “bittiğinin” nasıl anlaşılacağı her karar subjektif olur.
Kubernetes bir temel, tam bir platform değil. Ekipler genellikle hemen eklenti ekler—service mesh, birden fazla ingress controller, custom operator’ler, politika motorları—ama net sınırlar ya da sahiplik olmadan.
Aşırı özelleştirme başka bir tuzaktır: el yapımı YAML desenleri, el yapımı şablonlar ve sadece orijinal yazarların anladığı tekil istisnalar. Karmaşıklık artar, işe alıştırma yavaşlar ve yükseltmeler riskli hale gelir.
Cloud-native, kaynak yaratmayı kolaylaştırır—ve unutmayı da. Cluster yayılması, kullanılmayan namespace’ler ve fazla sağlanan iş yükleri maliyetleri sessizce yükseltir.
Güvenlik tuzakları da yaygındır:
Değişime başlamadan önce bir veya iki iyi tanımlı servisle küçük başlamak faydalıdır. Standartları erken belirleyin (golden path’ler, onaylanan temel imajlar, yükseltme kuralları) ve platform yüzey alanını kasıtlı olarak sınırlı tutun.
Dağıtım sıklığı, kurtarma ortalama süresi ve geliştiricinin ilk deploy’a kadar geçen süresi gibi sonuçları ölçün—ve bu sayıları hareket ettirmeyen her şeyi opsiyonel kabul edin.
Cloud-native’ı tek seferde “benimsiyorsunuz” diye bir yol yok. Başarılı ekipler McLuckie dönemiyle ilişkilendirilen temel fikri takip eder: doğru yolu kolay yol yapan bir platform inşa edin.
Küçük başlayın, sonra işe yarayanı kodlayın.
Yeni iş akışlarını deniyorsanız, standartlaştırmadan önce uçtan uca “golden path” deneyimini prototiplemek faydalıdır. Örneğin, ekipler Koder.ai kullanarak sohbetle hızlıca çalışan bir web uygulaması (React), backend (Go) ve veritabanı (PostgreSQL) oluşturabilir; çıkan kod tabanını platform şablonları ve CI/CD gelenekleri için başlangıç noktası olarak kullanabilirsiniz.
Araç eklemeden önce sorun:
Araç kullanımını değil, sonuçları takip edin:
Eğer iyi bir “platform MVP” paketinin nasıl göründüğüne dair örnekler isterseniz, /blog metnine bakabilirsiniz. Bütçeleme ve dağıtım planlaması için /pricing başvurusu da yardımcı olabilir.
Son on yıldan çıkarılacak büyük ders basit: konteynerler zekice paketlendikleri için “kazandı” demek yanlış olur. Platform düşüncesi onları güvenilir kıldı—tekrarlanabilir dağıtımlar, güvenli roll-out’lar, tutarlı güvenlik kontrolleri ve öngörülebilir operasyonlar.
Gelecek bölüm tek bir çıkış aracı hakkında olmayacak. Cloud-native’ı en iyi yapan şey, sıkıcılaşmasıdır: daha az sürpriz, daha az tekil düzeltme ve koddan üretime daha pürüzsüz bir yol.
Policy-as-code varsayılan hale geliyor. Her dağıtımı manuel incelemek yerine, ekipler güvenlik, ağ ve uyumluluk kurallarını kodlaştıracak; böylece korunaklar otomatik ve denetlenebilir olacak.
Geliştirici deneyimi (DX) bir ürün gibi ele alınacak. Hazırlanmış yollar: şablonlar, self-service ortamlar ve ekiplerin bilişsel yükünü azaltan net golden path’ler daha fazla öncelik kazanacak.
Daha fazla pano değil, daha basit operasyon. En iyi platformlar karmaşıklığı gizleyecek: fikirli varsayılanlar, daha az hareketli parça ve yerleştirilmiş güvenilirlik desenleri.
Yeni araç bir süreci nasıl hızlandırıyor, olay oranını nasıl düşürüyor veya güvenlik duruşunu nasıl iyileştiriyor açıklayamıyorsanız, muhtemelen öncelikli değildir.
Mevcut teslimat acı noktalarını değerlendirin ve bunları platform ihtiyaçlarına eşleyin:
Cevapları platform backlog’unuz olarak ele alın—ve ekiplerin her hafta hissettiği çıktılarla başarınızı ölçün.
Cloud-native, yazılımı sıkça dağıtabilme, talep değiştiğinde ölçeklendirebilme ve arıza durumunda hızlıca toparlanabilme biçiminde inşa edip işletme yaklaşımıdır.
Pratikte genellikle konteynerler, otomasyon, daha küçük servisler ve çalışan sistemleri gözlemleme, güvence altına alma ve yönetme için standart yollar içerir.
Bir konteyner yazılımı tutarlı şekilde göndermeye yardımcı olur, ama kendi başına ölçekli üretim problemlerini çözmez—örneğin güvenli yükseltmeler, servis keşfi, güvenlik kontrolleri ve kalıcı gözlemlenebilirlik gibi konuların üstesinden gelmez.
Boşluk, bir avuç konteynerden yüzlerce konteynerin 7/24 çalıştığı ortama geçildiğinde ortaya çıkar.
“Platform düşüncesi”, iç altyapıyı geliştiriciler gibi belirli kullanıcıları olan bir iç ürün olarak ele almak demektir; net bir vaat (güvenli, tekrar edilebilir teslimat) vardır.
Her takımın kendi üretim yolunu kendisinin örmek yerine, kuruluş paylaşılan hazırlanmış yollar (golden paths) oluşturur; mantıklı varsayılanlar ve destek sağlar.
Kubernetes, “bir yığın konteyneri” günlük işletime uygun bir sisteme dönüştüren operasyonel katmanı sağlar:
Ayrıca, istenen durumun ilan edildiği ve sistemin gerçek dünyayı buna uydurmaya çalıştığı paylaşılan bir sağlar.
Deklaratif konfigürasyon, ne istediğinizi (istenen durum) tarif etmeniz anlamına gelir; adım adım prosedür yazmak yerine sonucu tanımlarsınız.
Pratik faydalar:
Immutable deployment, canlı sunucuları yerinde yama yapmak yerine bir artifaktı bir kere oluşturup o artifaktı dağıtmak demektir (genellikle bir container image).
Bir şeyi değiştirmek gerektiğinde, çalışan sistemi değiştirmek yerine yeni bir sürüm gönderirsiniz. Bu, konfigürasyon sürüklenmesini azaltır ve olayların yeniden üretilebilirliğini ve geri almayı kolaylaştırır.
CNCF, Kubernetes ve ilgili projelere tarafsız bir yönetim evi sağlayarak çekirdek altyapıya bahse girmenin riskini azalttı.
Sağladıkları şunlardır:
Bir üretim tabanı (production baseline), güvenilirliği öngörülebilir kılacak asgari yetenek ve uygulama setidir; örneğin:
Bunlar yoksa her servis kendi kurallarını icat eder ve güvenilirlik şansa kalır.
Platform mühendisliği, geliştiricilerin yarı zamanlı altyapı uzmanlarına dönüşmesini engellemek için cloud-native yapı taşlarını fikirli varsayılanlar haline getirir:
Amaç Kubernetes’i gizlemek değil; güvenli yolu en kolay yol haline getirmektir.
Sık görülen tuzaklar şunlardır:
Sürdürmeyi sağlayan tedbirler: