Uygulama kodu gibi sürümlenen, test edilen ve dağıtılan altyapı — çünkü platformunuz, temelindeki kadar güvenilirdir.

Altyapınız bulut konsollarına tıklanarak yönetiliyor. Staging ve production arasındaki ortam farkları, altyapı düzeyinde "benim makinemde çalışıyor" sorunlarına neden oluyor. Ölçeklendirme manuel müdahale gerektiriyor, dağıtımlar sunuculara SSH bağlantısı kurmayı içeriyor ve olağanüstü durum kurtarma, kimsenin test etmediği bir Google Doc'tan ibaret. Tekrarlanabilir, sürüm kontrollü, kendi kendini onaran ve gözlemlenebilir bir altyapıya ihtiyacınız var — bir ekibin "kahraman bilgisi" olmadan işletebileceği bir altyapı.
Explore more design patterns and system architectures
Mimarlarımız, bu deseni kullanarak belirli gereksinimleriniz için sistemler tasarlamanıza ve oluşturmanıza yardımcı olabilir.
İletişime GeçinBuluta özel altyapı, altyapıyı kod olarak (IaC) ele alır, iş yüklerini Kubernetes (veya yönetilen eşdeğerleri) tarafından orkestrasyonu yapılan kapsayıcılarda çalıştırır, GitOps işlem hatları aracılığıyla dağıtım yapar ve operasyonel değiş tokuşun uygun olduğu yerlerde yönetilen hizmetleri kullanır. Bu desen, yüksek erişilebilirlik için çok bölgeli dağıtımı, esneklik için yatay pod otomatik ölçeklendirmeyi, hizmetler arası iletişim için service mesh'i ve kapsamlı observability'yi kapsar. Amaç "bulutta çalışmak" değil — varsayılan olarak otomatik, tekrarlanabilir ve dayanıklı bir altyapı inşa etmektir.
Mimari üç düzlemden oluşur. Control plane, Terraform/Pulumi aracılığıyla altyapı sağlama işlemlerini yönetir, GitOps denetleyicilerini (ArgoCD/Flux) çalıştırır ve secrets management'ı (Vault/AWS Secrets Manager) ele alır. Workload plane, uygulama kapsayıcılarını Kubernetes kümelerinde (EKS, GKE veya AKS) pod autoscaling, service mesh (Istio/Linkerd) ve ingress yönetimi ile çalıştırır. Observability plane, metrikleri (Prometheus), logları (Loki/CloudWatch), izleri (Jaeger/Datadog) ve uyarıları (PagerDuty/OpsGenie) toplar.
git revert'tir| Katman | Teknolojiler |
|---|---|
| İşlem | Kubernetes (EKS, GKE, AKS), ECS Fargate, Cloud Run |
| IaC | Terraform, Pulumi, AWS CDK |
| GitOps | ArgoCD, Flux, GitHub Actions |
| Ağ | Istio, Linkerd, AWS App Mesh, Nginx Ingress, Cert-Manager |
| Gözlemlenebilirlik | Prometheus, Grafana, Datadog, Loki, Jaeger, PagerDuty |
| Ne Zaman Kullanılmalı | Ne Zaman Kaçınılmalı |
|---|---|
| Bağımsız ölçeklendirme ve dağıtım gerektiren 5'ten fazla hizmet çalıştırıyorsanız | Tek bir PaaS (Vercel, Railway, Render) üzerinde çalışabilen tek bir uygulamanız varsa |
| Birden çok ekip paylaşılan altyapıya katkıda bulunuyorsa | Ekibiniz 3 mühendisten az ise — Kubernetes'in operasyonel yükü baskın olacaktır |
| Erişilebilirlik veya uyumluluk için çok bölgeli dağıtıma ihtiyacınız varsa | Proje, HA veya karmaşık orkestrasyon gerektirmeyen bir MVP ise |
| Uyumluluk tekrarlanabilir, denetlenebilir bir altyapı gerektiriyorsa | Maliyet optimizasyonu kritikse ve iş yükü serverless ekonomisine uyuyorsa |
MW, altyapıyı tek seferlik bir kurulum olarak değil, bir ürün olarak sunar. Uygulama kodunuz için geliştiricilerinizin kullandığı aynı iş akışını kullanarak — pull request'ler aracılığıyla altyapı değişikliklerini planlayan, inceleyen ve uygulayan CI/CD işlem hatlarına sahip Terraform modülleri sağlıyoruz. Kubernetes dağıtımlarımız üretim sınıfı varsayılanları içerir: pod disruption budgets, kaynak limitleri, ağ politikaları ve otomatik sertifika rotasyonu. Ekibinizin altyapıyı bağımsız olarak işletebilmesi için operasyonel runbook'lar, Grafana panoları ve on-call yükseltme politikaları ile teslim ediyoruz.
Kullandığınız kadar ödeyin, kullanmadığınızda sıfıra ölçeklendirin ve sunucuları tamamen yönetmeyi bırakın — ancak ekonominin ne zaman işlemeyi durduracağını bilin.
Cloud-native, uygulamaları özellikle elastic scaling, managed services ve distributed architecture gibi cloud yeteneklerinden faydalanacak şekilde tasarlamak demektir; sadece on-premises uygulamaları cloud'daki virtual machines'e taşımak yerine. MicrocosmWorks, altyapıyı değerli ve uzun ömürlü değil, geçici ve değiştirilebilir olarak ele alan containerization, declarative infrastructure-as-code, service meshes ve CI/CD automation kullanarak cloud-native sistemler kurar. Pratikteki fark şudur: cloud-native bir uygulama 10'dan 10.000 kullanıcıya otomatik olarak scale edebilir, insan müdahalesi olmadan altyapı arızalarından kurtulabilir ve günde onlarca kez güncelleme dağıtabilir.
MicrocosmWorks, auto-scaling, rolling deployments, service discovery ve multi-environment consistency gibi gelişmiş orkestrasyon özelliklerine ihtiyaç duyan 10'dan fazla mikro hizmet çalıştıran kuruluşlar için Kubernetes'i önermektedir; AWS ECS, Google Cloud Run veya Azure Container Apps gibi daha basit platformlar ise daha az hizmete sahip veya Kubernetes uzmanlığı sınırlı ekipler için daha uygundur. Birçok ekibin Kubernetes'i erkenden benimsediğini ve özellik geliştirmekten çok kümeyi yönetmek için zaman harcadığını gördüğümüzden, orkestrasyon katmanını önermeden önce gerçek iş yükü karmaşıklığınızı ve ekip olgunluğunuzu değerlendiriyoruz. Değerlendirmemiz, sizin özel ölçeğiniz için yönetilen Kubernetes, serverless containers ve platform-as-a-service seçeneklerini karşılaştıran bir TCO analizi içermektedir.
MicrocosmWorks, multi-cloud infrastructure provisioning için Terraform'u ve HCL yerine TypeScript veya Python gibi programlama dillerini kullanmayı tercih eden ekipler için Pulumi'yi standart olarak kullanır; tüm altyapı tanımları Git'te saklanır ve uygulama koduyla aynı CI/CD pipeline'ı üzerinden dağıtılır. IaC depolarını; networking, compute, databases ve observability için yeniden kullanılabilir modüllere ayırarak, bu modüllerin ortama özel konfigürasyonlar oluşturmak üzere birleştirilebilmesini sağlıyoruz; böylece development, staging ve production ortamları arasında tutarlılık temin ediliyor. Her altyapı değişikliği, herhangi bir değişiklik uygulanmadan önce hangi kaynakların oluşturulacağını, değiştirileceğini veya yok edileceğini tam olarak gösteren otomatik plan önizlemeleriyle birlikte pull request incelemesinden geçer.
MicrocosmWorks, buluta özgü bağımlılıkları iyi tanımlanmış arayüzlerin arkasında izole eden bir soyutlama katmanı ile bulut-yerel mimariler tasarlar ve bu sayede tüm uygulamayı yeniden yazmaya gerek kalmadan bireysel hizmetler için sağlayıcıları değiştirmeyi mümkün kılar. Mümkün olan her yerde Kubernetes, PostgreSQL, Redis ve OpenTelemetry gibi taşınabilir teknolojiler kullanırız ve DynamoDB veya Cloud Spanner gibi buluta özgü hizmetleri, alternatif sağlayıcılar için yeniden uygulanabilecek adaptör katmanlarına sarmalarız. Bu yaklaşım, ilk geliştirme sırasında minimum ek yük ekler ancak iş yüklerini daha sonra farklı bir sağlayıcıya taşımanız veya uyumluluk veya esneklik nedenleriyle multi-cloud bir strateji benimsemeniz gerekirse aylar süren geçiş çabasından tasarruf sağlar.
Tipik bir cloud-native altyapı projesi, MicrocosmWorks'ün mevcut architecture'ınızı, workloads'larınızı ve ekibinizin yeteneklerini değerlendirdiği 2 haftalık bir assessment ile başlar. Ardından, container orchestration, CI/CD pipelines, observability ve security controls dahil olmak üzere foundational infrastructure'ı sağlayan 4-8 haftalık bir platform build süreci gelir. Daha sonra, engineering team'inizin uygulamalı knowledge transfer için bizim ekibimizle birlikte çalıştığı bir ortamda, ilk 2-3 services'ınızı containerize edip yeni platforma deploy ettiğimiz 4-6 haftalık bir application migration phase yürütürüz. Cloud-native consulting rates'imiz saat başına 10 ila 40 ABD doları arasında değişmekte olup, assessment'tan production readiness'e kadar olan tüm engagement tipik olarak 10-16 hafta sürer.