01Sorun ve çözüm
Platform engineering hizmetimizde geliştiricilerin bu işleri kendi başlarına ve standartlara uygun biçimde yapabildiği bir iç geliştirici platformu kuruyoruz. Servis şablonları, hazır dağıtım hatları, self servis kaynak talebi ve servis kataloğu tek bir yerde toplanır. Platformu bir iç ürün gibi ele alır, kullanıcısı olan geliştiricilerden düzenli geri bildirim alırız.
Devamını okuDaha az göster
Amaç yeni bir araç yığını eklemek değil, mevcut CI/CD, Kubernetes ve bulut kaynaklarınızın üzerine ince ve anlaşılır bir katman koymaktır. Takımların izlediği “altın yol” zorunlu olduğu için değil, işi kolaylaştırdığı için tercih edilir.
02Kimler için
Platform engineering kimler için anlamlı
Platform yatırımı, belirli bir takım ve servis sayısından sonra karşılığını vermeye başlar.
- Birden fazla geliştirme takımı olan ve her takımın altyapıyı farklı yönettiği yazılım şirketleri
- DevOps ekibi, gelen ortam ve yetki talepleri yüzünden kendi iyileştirme işlerine vakit bulamayan kurumlar
- Mikroservis sayısı arttıkça hangi servisin kime ait olduğunu ve hangi sürümde çalıştığını takip edemeyen ekipler
- Yeni katılan geliştiricinin ilk canlı dağıtımına kadar geçen süreyi kısaltmak isteyen teknoloji ekipleri
- Güvenlik ve uyum kurallarını her takıma tek tek anlatmak yerine platformun içine yerleştirmek isteyen şirketler
03İhtiyaçlar
Platform ekibi olmadan biriken sorunlar
Bu sorunlar tek tek küçük görünür; toplamda geliştirme hızını ve güvenliği belirgin biçimde aşağı çeker.
- 01
Bilet tabanlı altyapı
Her veritabanı, kuyruk ya da yeni ortam bir bilet ve bekleme anlamına geldiğinde geliştiriciler ya bekler ya da kendi kısayollarını yaratır. Kısayollar da zamanla kimsenin sahiplenmediği kaynaklara dönüşür.
- 02
Kopyalanarak çoğalan hatlar
Bir CI dosyası depodan depoya kopyalandıkça her biri farklı biçimde evrilir. Tek bir güvenlik taramasını eklemek onlarca depoda ayrı değişiklik gerektirir.
- 03
Belirsiz sahiplik
Bir servis alarm verdiğinde kimin sorumlu olduğu, belgelerinin nerede durduğu ve hangi servislere bağlı olduğu bilinmezse müdahale gecikir.
- 04
Bilişsel yük
Uygulama geliştiricisinden Kubernetes, Terraform, ağ ve gözlemlenebilirlik araçlarının hepsini ayrıntısıyla bilmesi beklendiğinde ürün işine ayrılan zaman azalır.
- 05
Tutarsız güvenlik
Kimi serviste imaj taraması, gizli anahtar yönetimi ve kaynak limitleri varken kimisinde yoktur. Bir denetimde hangi servisin hangi kurala uyduğu kanıtlanamaz.
04Özellikler
Platform engineering hizmetinin kapsamı
Platformu tek seferde değil, en çok zaman kaybettiren akıştan başlayarak adım adım kurarız.
- 01
Geliştirici yolculuğu analizi
Geliştiricilerle görüşerek yeni servis açma, ortam isteme, dağıtım ve hata ayıklama adımlarında nerede beklendiğini çıkarırız. Platformun ilk sürümü bu bulgulara göre önceliklendirilir.
- 02
Servis şablonları
Dil ve çatıya göre hazırlanan proje şablonları; CI hattı, konteyner tanımı, sağlık kontrolleri, log ve metrik ayarları ile güvenlik taramalarını hazır olarak getirir.
- 03
Self servis altyapı
Veritabanı, önbellek, kuyruk ya da geçici test ortamı gibi kaynaklar onaylı modüller üzerinden bir form veya bir dosyayla istenir; arka planda Terraform ya da Crossplane gibi araçlar çalışır.
- 04
Servis kataloğu ve geliştirici portalı
Backstage gibi bir portalla servislerin sahibi, belgeleri, bağımlılıkları, dağıtım durumu ve panoları tek yerden görülür.
- 05
Kod olarak politika
Kaynak limitleri, izin verilen imaj kaynakları, etiketleme ve ağ kuralları Open Policy Agent ya da Kyverno gibi araçlarla tanımlanır; kurala uymayan değişiklik dağıtımdan önce yakalanır.
05Entegrasyonlar
Platform engineering için bir araya getirilen araçlar
Platform, ekibinizin halihazırda kullandığı araçların üzerine kurulur.
- 01
Kaynak kod ve CI
GitHub, GitLab ya da Bitbucket depoları; GitHub Actions, GitLab CI veya Jenkins hatları ortak ve sürümlenen şablonlara bağlanır.
- 02
GitOps ve dağıtım
Argo CD ya da Flux ile ortamların istenen durumu depoda tutulur; kümeye yapılan her değişiklik geriye dönük izlenebilir.
- 03
Kubernetes ve bulut hesapları
EKS, AKS, GKE ya da kendi kümeleriniz ile bulut hesap ve ağ yapısı platformun alt katmanını oluşturur.
- 04
Gizli anahtar yönetimi
HashiCorp Vault, AWS Secrets Manager ya da Azure Key Vault'taki değerler, External Secrets gibi araçlarla uygulamalara güvenli biçimde aktarılır.
- 05
Gözlemlenebilirlik ve olay yönetimi
Her şablon varsayılan panolar ve alarmlarla gelir; servis kataloğu nöbet ve olay yönetim araçlarına bağlanır.
06Süreç
Platform engineering hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Platformu sürdürülebilir kılan ilkeler
Platform bir projeyle bitmez; kullanıcıları olan bir iç üründür. Yol haritası geliştirici geri bildirimleriyle ve dağıtım sıklığı, değişikliklerin ne sıklıkla geri alındığı, sorunların ne kadar sürede giderildiği gibi teslimat göstergeleriyle yönetilir. Kullanılmayan bir özellik ne kadar özenle tasarlanmış olursa olsun yeniden değerlendirilir.
Devamını okuDaha az göster
Self servis, kontrolsüzlük anlamına gelmez. Geliştiricinin talep ettiği her kaynak önceden onaylanmış bir modülden üretilir; şifreleme, yedekleme, etiketleme ve erişim kuralları modülün içinde gelir. Böylece güvenlik ve maliyet takibi her takımın ayrı ayrı hatırlamasına bağlı kalmaz.
Takımları platforma zorla taşımak yerine yeni servislerden başlamayı, mevcut servisleri kademeli ve gönüllü olarak almayı öneririz. Kurulumdan sonra platformun bakımını üstlenebilir ya da kendi platform ekibinizi kurarken danışman olarak yanınızda olabiliriz.
08Çalışma modelleri
Bu hizmette çalışma modelleri
- 01
Proje bazlı
Sabit kapsam, sabit fiyat ve belirli teslim tarihi
Kapsamı belli, teslim tarihi olan işler için.
- Yazılı kapsam ve kabul ölçütleri
- Sabit fiyat ve belirli teslim tarihi
- Teslim ve kabul adımları sözleşmede
- 02
Bakım ve destek
Aylık sözleşmeli, SLA'lı bakım, destek ve geliştirme saati
Yayındaki bir sistemin sürekliliği için.
- Aylık sözleşme ve SLA
- İzleme, güncelleme ve hata düzeltme
- Aylık geliştirme saati
- 03
Danışmanlık
Saatlik veya günlük teknik danışmanlık
Karar, denetim veya yön belirleme gereken durumlar için.
- Saatlik veya günlük çalışma
- Yazılı rapor ve öneriler
- Ekibinizle birlikte çalışma
09Sık sorulan sorular
Platform engineering hakkında sık sorulan sorular
Platform engineering fiyatları neye göre belirlenir?
Takım ve servis sayısı, mevcut CI/CD ve Kubernetes olgunluğu, kurulacak bileşenler ve kurulum sonrası işletme desteği belirleyicidir. İlk aşama genellikle analiz ve tek bir altın yolun kurulmasıyla sınırlı tutulur, sonraki adımlar bu deneyime göre planlanır.
Platform engineering ile DevOps arasındaki fark nedir?
DevOps, geliştirme ve operasyonun birlikte çalışmasını öngören bir kültür ve uygulama bütünüdür. Platform engineering ise bu kültürü ölçeklemek için altyapı yeteneklerini self servis bir ürün olarak sunan ekip ve araç yaklaşımıdır.
Backstage kurmak zorunda mıyız?
Hayır. Backstage yaygın bir seçenektir ama kendisi de bakım ister. Küçük ekiplerde iyi belgelenmiş şablonlar ve güncel bir servis listesi yeterli olabilir; portal ihtiyacı servis ve takım sayısına göre değerlendirilir.
Kaç geliştiriciden sonra bir platform ekibine ihtiyaç duyulur?
Kesin bir sayı yoktur. Altyapı taleplerinin bir iki kişide toplandığı, takımların aynı sorunları tekrar tekrar çözdüğü ve yeni geliştiricilerin uyum sürecinin uzadığı noktada platform yatırımı anlam kazanır.
Platform engineering firması olarak mevcut araçlarımızı değiştirecek misiniz?
Gerekmedikçe hayır. Çalışan CI sistemi, bulut hesabı ve izleme araçları korunur; platform bunların üzerinde ortak bir arayüz ve standart oluşturur. Araç değişikliği yalnızca güvenlik açığı ya da sürdürülemez bakım yükü gibi somut bir neden olduğunda gündeme gelir.
Takımlar platformu kullanmak istemezse ne olur?
Platform zorunlu kılındığında değil, işi kolaylaştırdığında benimsenir. Bu yüzden ilk sürümü en çok şikâyet edilen akış üzerine kurar, erken kullanıcı takımlarla birlikte geliştirir ve geri bildirimle iyileştiririz.
10İlgili hizmetler