# Platform Engineering & Internal Developer Platform (IDP) Hizmetleri

**URL:** https://securesys.com.tr/tr/hizmetler/platform-engineering-internal-developer-platform-idp

Modern yazılım geliştirme ekipleri yalnızca kod geliştirme süreçleriyle değil; altyapı oluşturma, CI/CD pipeline yönetimi, Kubernetes, cloud servisleri, güvenlik kontrolleri, monitoring, secret management ve deployment süreçleriyle de ilgilenmek zorunda kalmaktadır.

Uygulama ve altyapı mimarilerinin büyümesiyle birlikte geliştiricilerin kullandığı teknoloji sayısı artmakta; bu durum operasyonel karmaşıklık, farklı deployment standartları, güvenlik problemleri ve uzun teslimat süreleri oluşturabilmektedir.

**Platform Engineering**, geliştiricilerin ihtiyaç duyduğu altyapı, deployment, CI/CD, security ve operasyon servislerini standartlaştırılmış ve self-service bir platform üzerinden sunmayı amaçlayan modern yazılım mühendisliği yaklaşımıdır.

Bu yaklaşımın merkezinde çoğunlukla **Internal Developer Platform – IDP** bulunur.

SecureSys **Platform Engineering ve Internal Developer Platform (IDP) Hizmetleri** ile kurumların yazılım ekipleri için merkezi, güvenli, otomatik ve ölçeklenebilir geliştirme platformları oluşturmasına destek sağlar.

Platform Engineering yaklaşımımız;

**Developer Experience + Self-Service + Automation + CI/CD + GitOps + Kubernetes + Infrastructure as Code + [DevSecOps](/tr/hizmetler/devops-devsecops-hizmetleri) \+ Observability + Governance**

bileşenlerinin birlikte ele alınmasına dayanır.

Amaç geliştiricinin altyapının karmaşık detaylarıyla uğraşmak yerine yazılım geliştirmeye odaklanmasını sağlamaktır.

### Platform Engineering Nedir?

Platform Engineering, yazılım geliştirme ekiplerinin uygulama geliştirme ve deployment süreçlerini kolaylaştırmak amacıyla reusable servisler, araçlar ve otomasyon katmanları oluşturulmasını sağlayan mühendislik yaklaşımıdır.

Geleneksel yapılarda geliştiricinin yeni bir uygulamayı production ortamına taşıması için;

- sunucu talep etmesi,
- network açtırması,
- database oluşturması,
- CI/CD pipeline hazırlaması,
- container registry ayarlaması,
- Kubernetes deployment oluşturması,
- monitoring sistemi eklemesi,
- güvenlik kontrollerini yapılandırması

gerekebilir.

Bu işlemlerin farklı ekipler tarafından manuel olarak yapılması deployment sürelerini uzatabilir.

Platform Engineering yaklaşımında bu süreçlerin önemli bölümü standart servisler haline getirilir.

Geliştirici ihtiyacı olan servisi platform üzerinden talep eder ve arka plandaki otomasyon gerekli kaynakları oluşturur.

### Internal Developer Platform – IDP Nedir?

Internal Developer Platform, kurum içerisinde geliştiricilerin uygulama geliştirmek, test etmek, deploy etmek ve yönetmek için kullandığı merkezi platformdur.

IDP üzerinden geliştirici;

- yeni proje oluşturabilir,
- repository açabilir,
- CI/CD pipeline oluşturabilir,
- Kubernetes namespace talep edebilir,
- database oluşturabilir,
- secret tanımlayabilir,
- uygulama deploy edebilir,
- log görüntüleyebilir,
- monitoring bilgilerine ulaşabilir.

Bu işlemler organizasyonun güvenlik ve governance politikaları içerisinde gerçekleştirilir.

### Platform Engineering Neden Önemlidir?

Modern yazılım geliştirme altyapıları geçmişe göre çok daha karmaşıktır.

Bir geliştiricinin yalnızca uygulama dilini bilmesi artık yeterli olmayabilir.

Geliştiricinin aynı zamanda;

- Git,
- Docker,
- Kubernetes,
- Helm,
- CI/CD,
- cloud,
- Terraform,
- monitoring,
- security

teknolojileriyle çalışması gerekebilir.

Bu durum geliştiricilerin bilişsel yükünü artırabilir.

Platform Engineering bu karmaşıklığı platform katmanının arkasında yönetmeyi amaçlar.

### Developer Experience – DevEx

Platform Engineering'in önemli hedeflerinden biri **Developer Experience – DevEx** seviyesini artırmaktır.

Developer Experience, geliştiricinin günlük geliştirme süreçlerinde yaşadığı deneyimi ifade eder.

İyi tasarlanmış bir platform;

- hızlı onboarding,
- kolay deployment,
- standart development environment,
- otomatik pipeline,
- self-service infrastructure,
- merkezi documentation

sağlayabilir.

Bu sayede developer ekiplerinin operasyonel işlemlere ayırdığı zaman azaltılabilir.

### Developer Self-Service

Self-Service, Platform Engineering'in temel prensiplerinden biridir.

Geliştirici basit altyapı ihtiyaçları için her seferinde operasyon ekibine ticket açmak zorunda kalmamalıdır.

Örneğin geliştirici portal üzerinden:

#### Yeni PostgreSQL Database

seçeneğini seçebilir.

Platform arka planda;

- database oluşturur,
- network tanımlar,
- kullanıcı oluşturur,
- secret kaydeder,
- monitoring ekler.

Bu işlemler tamamen otomatik hale getirilebilir.

### Self-Service Infrastructure

Internal Developer Platform üzerinden;

- virtual machine,
- container,
- Kubernetes namespace,
- database,
- object storage,
- message queue,
- cache

gibi servisler self-service olarak sunulabilir.

Ancak self-service sınırsız yetki anlamına gelmez.

Kaynaklar belirlenen kurumsal politika ve quota'lar içerisinde oluşturulur.

### Golden Paths

Platform Engineering yaklaşımında **Golden Path**, geliştiricinin belirli bir uygulama türünü oluşturmak için kullanabileceği önerilen ve standartlaştırılmış yolu ifade eder.

Örneğin kurum içerisinde yeni bir API geliştirilecekse Golden Path:

**Repository → Code Template → CI/CD → [SAST](/tr/hizmetler/kaynak-kod-analizi-sast-hizmeti) → Container Build → Kubernetes → Monitoring**

şeklinde olabilir.

Geliştirici her projede aynı altyapıyı sıfırdan oluşturmak zorunda kalmaz.

### Golden Template

Standart uygulama template'leri oluşturulabilir.

Örneğin:

#### Java Microservice Template

- Spring Boot
- Dockerfile
- CI/CD
- SAST
- Kubernetes Manifest
- Monitoring

hazır olarak sunulabilir.

Benzer şekilde;

#### .NET API Template

veya

#### Node.js Microservice Template

oluşturulabilir.

### Platform as a Product

Modern Platform Engineering yaklaşımında internal platform yalnızca teknik bir altyapı projesi olarak görülmez.

Platform bir **ürün** gibi yönetilir.

Bu nedenle;

- kullanıcıları,
- roadmap'i,
- SLA'ları,
- feedback süreçleri,
- versiyonları,
- servis kataloğu

bulunabilir.

Platform ekibinin müşterisi kurum içerisindeki developer ekipleridir.

### Platform Team

Platform Engineering yaklaşımında özel bir Platform Team oluşturulabilir.

Platform ekibi;

- infrastructure,
- Kubernetes,
- CI/CD,
- automation,
- security,
- observability

bileşenlerini merkezi olarak yönetir.

Developer ekipleri bu servisleri platform üzerinden tüketir.

### Internal Developer Portal

Internal Developer Portal, platform servislerinin developer ekiplerine sunulduğu merkezi arayüzdür.

Portal üzerinden;

- uygulamalar,
- servisler,
- deployment'lar,
- documentation,
- ownership,
- monitoring,
- infrastructure

görüntülenebilir.

### Developer Portal ve IDP Arasındaki Fark

Developer Portal genellikle kullanıcı arayüzünü ifade eder.

Internal Developer Platform ise portalın arkasındaki;

- automation,
- infrastructure,
- CI/CD,
- Kubernetes,
- cloud,
- security

servislerinin tamamını kapsar.

Bu nedenle portal IDP'nin görünen yüzü olarak düşünülebilir.

### Service Catalog

Platform içerisinde kurumun sunduğu servislerin merkezi kataloğu oluşturulabilir.

Örneğin:

- PostgreSQL Database
- Kubernetes Namespace
- Redis Cache
- Object Storage
- API Gateway
- Message Queue
- CI/CD Pipeline

servisleri katalog üzerinden sunulabilir.

### Software Catalog

Kurum içerisindeki tüm uygulama ve microservice'lerin merkezi envanteri tutulabilir.

Software Catalog içerisinde;

- application name,
- owner,
- repository,
- environment,
- API,
- dependency,
- documentation

bilgileri bulunabilir.

### Application Ownership

Büyük kurumlarda bir uygulamanın hangi ekip tarafından yönetildiğinin belirlenmesi zorlaşabilir.

Internal Developer Platform içerisinde her servis için ownership bilgisi tutulabilir.

Bu sayede incident veya security vulnerability durumunda ilgili ekip hızlı şekilde belirlenebilir.

### Platform Engineering ve DevOps

Platform Engineering, DevOps'un alternatifi değildir.

DevOps kültürünün daha ölçeklenebilir hale getirilmesini sağlayan bir yaklaşım olarak değerlendirilebilir.

DevOps ekipler arasında collaboration ve automation oluştururken Platform Engineering ortak servisleri merkezi platform haline getirir.

### Platform Engineering ve DevSecOps

Platform Engineering güvenlik kontrollerinin standart hale getirilmesi için önemli fırsat sunar.

Örneğin kurumun Golden Path yapısında;

- SAST,
- SCA,
- Secret Scanning,
- Container Scanning,
- IaC Security,
- DAST

varsayılan olarak aktif olabilir.

Bu durumda yeni uygulama oluşturulduğunda güvenlik kontrolleri otomatik olarak devreye girer.

### Secure by Default Platform

SecureSys platform tasarımında **Secure by Default** yaklaşımını kullanabilir.

Bu modelde geliştiricinin güvenliği ayrıca yapılandırması yerine güvenlik kontrolleri varsayılan olarak platforma entegre edilir.

Örneğin;

- encryption aktif,
- MFA zorunlu,
- SAST aktif,
- secret scanning aktif,
- private network kullanımı,
- logging aktif

şeklinde standartlar uygulanabilir.

### CI/CD Platformu

Internal Developer Platform merkezi CI/CD servisleri sunabilir.

Geliştiriciler her proje için sıfırdan pipeline oluşturmak yerine standart pipeline template'lerini kullanabilir.

### Pipeline Templates

Örneğin standart pipeline:

#### Code

↓

#### Build

↓

#### Unit Test

↓

#### SAST

↓

#### SCA

↓

#### Container Build

↓

#### Image Scan

↓

#### Deployment

şeklinde oluşturulabilir.

### GitLab Platform Engineering

GitLab kullanan kurumlarda;

- repository,
- CI/CD,
- security,
- container registry,
- deployment

süreçleri Platform Engineering yaklaşımıyla standartlaştırılabilir.

### GitHub Platform Engineering

GitHub tabanlı yapılarda;

- GitHub Actions,
- repository templates,
- branch protection,
- secrets,
- automation

kullanılarak developer platform oluşturulabilir.

### Azure DevOps Platform Engineering

Microsoft ekosisteminde Azure DevOps;

- Boards,
- Repos,
- Pipelines,
- Artifacts

servisleriyle platform mimarisine dahil edilebilir.

### Jenkins Platform Engineering

Mevcut Jenkins altyapıları merkezi pipeline template'leri ve shared library yapılarıyla standartlaştırılabilir.

### Infrastructure as Code

Platform Engineering altyapısının önemli bölümü Infrastructure as Code yaklaşımıyla oluşturulabilir.

Sunucu veya cloud kaynakları manuel olarak oluşturulmak yerine kod üzerinden tanımlanabilir.

### Terraform

Terraform;

- compute,
- network,
- storage,
- Kubernetes,
- database,
- cloud services

kaynaklarının otomatik oluşturulmasında kullanılabilir.

Platform arka planda Terraform modüllerini çalıştırabilir.

### Reusable Terraform Modules

Platform ekibi standart Terraform modülleri oluşturabilir.

Örneğin:

#### Secure VM Module

otomatik olarak;

- private network,
- disk encryption,
- monitoring,
- backup,
- security policy

ile birlikte VM oluşturabilir.

### Infrastructure Standardization

IaC kullanımı kurum içerisinde standart altyapı oluşturulmasını sağlar.

Her ekip farklı firewall veya network ayarı kullanmak yerine onaylı template'leri kullanabilir.

### GitOps

GitOps, platform ve application konfigürasyonlarının Git repository üzerinden yönetilmesini sağlar.

Infrastructure veya Kubernetes değişiklikleri Git üzerinde version controlled şekilde tutulabilir.

### GitOps Deployment

Örnek akış:

**Developer → Git → Pull Request → Approval → GitOps Controller → Kubernetes**

şeklinde oluşturulabilir.

### Kubernetes Platform Engineering

Kubernetes modern Platform Engineering mimarilerinin önemli altyapılarından biridir.

SecureSys Kubernetes tabanlı Internal Developer Platform tasarlayabilir.

Platform içerisinde;

- namespace,
- resource quota,
- ingress,
- network policy,
- secrets,
- monitoring

standartlaştırılabilir.

### Kubernetes Namespace as a Service

Developer ekipleri portal üzerinden yeni namespace talep edebilir.

Platform otomatik olarak;

- namespace,
- RBAC,
- resource quota,
- network policy,
- logging,
- monitoring

oluşturabilir.

### Container as a Service Entegrasyonu

SecureSys [CaaS](/tr/hizmetler/container-as-a-service-caas-kubernetes-hizmeti) altyapısı Internal Developer Platform'un compute katmanı olarak kullanılabilir.

Örneğin:

**Developer Portal → IDP → CaaS → Kubernetes**

mimarisi oluşturulabilir.

### Database as a Service Entegrasyonu

Developer ekiplerinin sık ihtiyaç duyduğu servislerden biri database'dir.

IDP üzerinden;

- PostgreSQL,
- MSSQL,
- MySQL

database servisleri oluşturulabilir.

Örnek:

**Developer Portal → Service Catalog → PostgreSQL → [DBaaS](/tr/hizmetler/database-as-a-service-dbaas)**

### Object Storage as a Service

Uygulamaların object storage ihtiyacı platform üzerinden self-service olarak sunulabilir.

Geliştirici;

- bucket,
- quota,
- retention,
- access policy

parametrelerini belirleyebilir.

### API Gateway as a Service

Microservice uygulamalarının API yayınlama süreçleri merkezi hale getirilebilir.

Platform;

- API registration,
- authentication,
- rate limiting,
- routing

servislerini otomatik sağlayabilir.

### Secrets as a Service

Developer ekipleri credential bilgilerini source code içerisinde saklamamalıdır.

Internal Developer Platform merkezi secret management servisi sunabilir.

Uygulamalar secret değerlerini runtime sırasında güvenli sistemlerden alabilir.

### Certificate as a Service

TLS sertifika oluşturma ve yenileme süreçleri otomatik hale getirilebilir.

Bu sayede sertifika expiration kaynaklı servis kesintileri azaltılabilir.

### Platform Security

Internal Developer Platform kritik altyapı servislerine eriştiği için güçlü şekilde korunmalıdır.

SecureSys Platform Security kapsamında;

- authentication,
- MFA,
- RBAC,
- PAM,
- network segmentation,
- secrets,
- logging

kontrollerini değerlendirebilir.

### Platform RBAC

Her geliştirici tüm production sistemlerine erişmemelidir.

Role-Based Access Control ile;

- Developer,
- DevOps,
- Platform Engineer,
- Security Engineer,
- Administrator

rolleri oluşturulabilir.

### Least Privilege

Platform içerisindeki kullanıcı ve service account'lara yalnızca ihtiyaç duydukları yetkiler verilmelidir.

Bu yaklaşım saldırı yüzeyini azaltır.

### Workload Identity

Uygulamaların uzun süreli username/password kullanması yerine workload identity yaklaşımı uygulanabilir.

Bu model özellikle cloud-native platformlarda güvenliği artırabilir.

### Platform PAM Entegrasyonu

Platform administrator hesapları yüksek yetkilere sahiptir.

SecureSys PAM entegrasyonuyla;

- privileged access,
- credential vault,
- session recording,
- approval,
- password rotation

süreçlerini merkezi hale getirebilir.

### Platform Network Security

Platform bileşenleri ayrı network zonlarında konumlandırılabilir.

Örneğin:

#### Developer Network

↓

#### Platform Services

↓

#### Application Network

↓

#### Database Network

Bu yapı network segmentation ile desteklenebilir.

### Kırmızı Ağ ve Platform Engineering

Yüksek güvenlik gerektiren ortamlarda Internal Developer Platform tamamen izole network içerisinde kurulabilir.

Örneğin:

**Kırmızı Ağ → Private Git → Private Registry → Private Kubernetes → Private DBaaS**

mimarisi oluşturulabilir.

Bu model internet erişimi olmayan kritik yazılım geliştirme ortamları için kullanılabilir.

### Air-Gapped Developer Platform

Savunma, kritik altyapı ve yüksek güvenlik gerektiren ortamlarda tamamen Air-Gapped Developer Platform oluşturulabilir.

Bu yapıda;

- Git,
- CI/CD,
- artifact repository,
- container registry,
- Kubernetes,
- security scanners

internet bağlantısı olmadan çalışabilir.

### Private Container Registry

Air-Gapped veya private platformlarda container image'lar kurum içindeki private registry üzerinde saklanabilir.

Bu yaklaşım supply chain risklerini azaltabilir.

### Private Package Repository

Developer ekiplerinin doğrudan internet üzerindeki package repository'lere erişmesi sınırlandırılabilir.

Merkezi;

- Maven,
- npm,
- NuGet,
- PyPI

proxy/repository sistemleri oluşturulabilir.

### Software Supply Chain Security

Platform Engineering yazılım tedarik zinciri güvenliğinin merkezi uygulanmasını kolaylaştırır.

Platform seviyesinde;

- SCA,
- SBOM,
- dependency scanning,
- artifact signing,
- secret scanning,
- container scanning

kontrolleri zorunlu hale getirilebilir.

### SBOM Otomasyonu

Her build sonrasında otomatik Software Bill of Materials oluşturulabilir.

SBOM uygulamanın kullandığı dependency ve component'lerin görünür hale gelmesini sağlar.

### Artifact Management

Build sonucunda oluşan artifact'lar merkezi repository içerisinde saklanabilir.

Örneğin;

- binary,
- package,
- container image,
- library

versiyonlanabilir.

### Artifact Signing

Release artifact'larının bütünlüğünü doğrulamak amacıyla dijital signing mekanizmaları kullanılabilir.

Bu yaklaşım [software supply chain](/tr/hizmetler/software-supply-chain-security-sbom) güvenliğini güçlendirir.

### Policy as Code

Platform politikaları kod olarak tanımlanabilir.

Örneğin:

#### Public Database Yasak

#### Privileged Container Yasak

#### Encryption Zorunlu

#### Production Deployment Approval Zorunlu

gibi kurallar otomatik uygulanabilir.

### Compliance as Code

Kurumsal güvenlik ve compliance gereksinimleri otomatik kontrollere dönüştürülebilir.

Bu yaklaşım manuel compliance kontrollerinin bir bölümünü otomatik hale getirebilir.

### Platform Observability

Internal Developer Platform'un sağlıklı çalışması için merkezi observability altyapısı gerekir.

Observability;

**Metrics + Logs + Traces**

bileşenlerinden oluşur.

### Centralized Logging

Application ve platform logları merkezi log yönetim sistemine aktarılabilir.

Geliştiriciler yalnızca yetkili oldukları uygulamaların loglarına erişebilir.

### Metrics Monitoring

Platform üzerinde;

- CPU,
- memory,
- latency,
- error rate,
- request count,
- pod health

gibi metrikler izlenebilir.

### Distributed Tracing

Microservices mimarisinde bir request birden fazla servis üzerinden geçebilir.

Distributed tracing ile request'in servisler arasındaki yolculuğu analiz edilebilir.

### Application Performance Monitoring

APM sistemleri application performance problemlerinin analiz edilmesini sağlar.

Platform Engineering ile APM entegrasyonu varsayılan servis olarak sunulabilir.

### Platform ve SOC Entegrasyonu

Platform güvenlik olayları SecureSys [SOC 7x24](/tr/hizmetler/soc-7x24-izleme-managed-soc-hizmeti) altyapısına aktarılabilir.

Örneğin;

- repository değişiklikleri,
- privileged login,
- Kubernetes audit,
- deployment,
- security gate bypass

olayları [SIEM](/tr/hizmetler/siem-soar-guvenlik-hizmeti) üzerinden analiz edilebilir.

### Platform SIEM Entegrasyonu

Git, Kubernetes, cloud ve CI/CD sistemlerinden gelen loglar SIEM'e aktarılabilir.

Bu sayede development ve production ortamları tek güvenlik görünürlüğü altında değerlendirilebilir.

### Platform Vulnerability Management

Platform içerisinde tespit edilen;

- SAST vulnerability,
- vulnerable dependency,
- container vulnerability,
- infrastructure vulnerability

bulguları merkezi vulnerability management sürecine dahil edilebilir.

### Developer Security Dashboard

Developer ekiplerine uygulamalarının güvenlik durumunu gösteren dashboard sunulabilir.

Dashboard içerisinde;

- SAST,
- SCA,
- SBOM,
- container vulnerability,
- security gate

sonuçları gösterilebilir.

### Platform Engineering ve FinOps

Self-service altyapının kontrolsüz kullanılması cloud maliyetlerini artırabilir.

Bu nedenle Platform Engineering ve FinOps birlikte değerlendirilmelidir.

### Resource Quota

Her ekip veya proje için;

- CPU,
- RAM,
- storage,
- database,
- cloud resource

limitleri belirlenebilir.

### Showback

Takımların kullandığı altyapı kaynaklarının maliyeti raporlanabilir.

Bu modele Showback adı verilir.

### Chargeback

Daha gelişmiş yapılarda kullanılan kaynak maliyetleri ilgili departmana veya projeye yansıtılabilir.

### Platform Cost Optimization

SecureSys;

- unused resources,
- oversized workloads,
- idle environments,
- storage consumption

analizleriyle platform maliyetlerinin optimize edilmesine destek sağlayabilir.

### Ephemeral Environment

Developer veya test ekipleri için geçici environment'lar otomatik oluşturulabilir.

Örneğin Pull Request açıldığında geçici test ortamı oluşturulur.

PR kapatıldığında environment otomatik silinir.

Bu yaklaşım development hızını artırırken kaynak tüketimini kontrol altında tutabilir.

### Development Environment as a Service

Developer ekiplerine standart development ortamları servis olarak sunulabilir.

Bu sayede "benim bilgisayarımda çalışıyordu" problemi azaltılabilir.

### Platform Engineering ve Microservices

Microservices mimarilerinde servis sayısı hızla artabilir.

Platform Engineering;

- service template,
- API gateway,
- logging,
- monitoring,
- deployment,
- security

süreçlerini standartlaştırarak microservices yönetimini kolaylaştırabilir.

### Platform Engineering ve API Yönetimi

Platform içerisinde API servislerinin;

- registration,
- documentation,
- authentication,
- authorization,
- versioning

süreçleri merkezi hale getirilebilir.

### Platform Engineering ve AI Uygulamaları

[Generative AI](/tr/hizmetler/llm-generative-ai-cozumleri) ve AI Agent uygulamalarının yaygınlaşması developer platformlarının kapsamını genişletmektedir.

AI geliştirme ekipleri;

- model endpoint,
- vector database,
- GPU,
- object storage,
- secret management,
- monitoring

gibi özel altyapı servislerine ihtiyaç duyabilir.

Internal Developer Platform bu servisleri self-service olarak sunabilir.

### AI Platform Engineering

AI uygulamaları için özel Golden Path oluşturulabilir.

Örneğin:

**AI Application Template → Git → CI/CD → Security → Model API → Vector DB → Kubernetes → Monitoring**

Bu yapı AI geliştirme süreçlerini standartlaştırabilir.

### LLM Platform Servisleri

Platform içerisinde;

- LLM endpoint,
- prompt management,
- vector database,
- RAG service,
- evaluation,
- monitoring

servisleri developer ekiplerine sunulabilir.

### AI Agent Platformu

[AI Agent](/tr/hizmetler/ai-agent-agentic-ai-cozumleri) geliştiren ekipler için;

- model access,
- tool integration,
- API management,
- identity,
- secrets,
- logging

servisleri merkezi platform üzerinden sağlanabilir.

### AI Governance ve Platform Engineering

AI uygulamalarının hızla çoğalması governance ihtiyacını artırır.

Platform Engineering;

- hangi model kullanılıyor,
- hangi uygulama modele erişiyor,
- hangi data source kullanılıyor,
- hangi ekip uygulamanın sahibi

gibi bilgilerin merkezi yönetilmesini sağlayabilir.

### ISO/IEC 42001 ve AI Platformları

AI uygulamalarının geliştirilmesi ve işletilmesinde kullanılan platformların governance, logging, access control ve lifecycle süreçleri AI yönetim sistemi yaklaşımını teknik olarak destekleyebilir.

Platform üzerinde;

- model envanteri,
- application ownership,
- access control,
- logging,
- change management

mekanizmaları oluşturulabilir.

### Platform Engineering ve ISO/IEC 27001

Internal Developer Platform üzerinde erişim kontrolü, logging, secure development, change management ve vulnerability management süreçlerinin merkezi uygulanması ISO/IEC 27001 bilgi güvenliği süreçlerini destekleyebilir.

### Platform Engineering KPI'ları

Platform başarısı yalnızca teknik uptime ile ölçülmemelidir.

Örnek KPI'lar;

- deployment frequency,
- lead time,
- developer onboarding time,
- failed deployment rate,
- platform adoption,
- self-service usage,
- provisioning time

olarak belirlenebilir.

### DORA Metrikleri

DevOps performansının ölçülmesinde;

- Deployment Frequency,
- Lead Time for Changes,
- Change Failure Rate,
- Mean Time to Restore

gibi metrikler kullanılabilir.

Platform Engineering bu metriklerin iyileştirilmesine katkı sağlayabilir.

### Developer Onboarding Süresi

Yeni bir developer'ın development ortamını hazırlaması günler sürebilir.

Platform Engineering ile gerekli;

- repository,
- development environment,
- access,
- documentation,
- tooling

standartlaştırılarak onboarding süresi azaltılabilir.

### Platform Documentation

Platform servislerinin doğru kullanılabilmesi için merkezi documentation oluşturulmalıdır.

Dokümantasyonda;

- servis kataloğu,
- Golden Paths,
- API'ler,
- deployment,
- troubleshooting

bilgileri bulunabilir.

### TechDocs ve Documentation as Code

Teknik dokümantasyon Git repository içerisinde kod gibi yönetilebilir.

Bu yaklaşım dokümantasyonun uygulamayla birlikte güncel tutulmasına yardımcı olur.

### Platform Engineering Maturity Assessment

SecureSys kurumun mevcut Platform Engineering olgunluğunu değerlendirebilir.

Analizde;

- developer experience,
- CI/CD,
- Kubernetes,
- IaC,
- self-service,
- security,
- observability,
- governance

alanları incelenebilir.

### Platform Engineering Yol Haritası

Platform Engineering tek seferde kurulması gereken büyük bir proje olmak zorunda değildir.

Aşamalı geçiş yapılabilir.

#### Aşama 1 – Standardization

CI/CD, repository ve deployment standartları oluşturulur.

#### Aşama 2 – Automation

Infrastructure as Code ve otomasyon süreçleri uygulanır.

#### Aşama 3 – Self-Service

Developer Portal ve Service Catalog oluşturulur.

#### Aşama 4 – Security

DevSecOps, Policy as Code ve security gate entegrasyonları yapılır.

#### Aşama 5 – Observability

Monitoring, logging ve tracing merkezi hale getirilir.

#### Aşama 6 – Platform as a Product

Platform kullanım metrikleri ve developer feedback süreçleri oluşturulur.

### Platform Migration

Mevcut development ve DevOps altyapıları Internal Developer Platform modeline taşınabilir.

Geçiş sırasında;

- mevcut repository,
- pipeline,
- Kubernetes,
- cloud,
- security,
- monitoring

sistemleri analiz edilir.

Mevcut yatırımların mümkün olduğunca korunması hedeflenebilir.

### Multi-Cloud Developer Platform

Internal Developer Platform farklı cloud sağlayıcıları üzerinde kaynak oluşturabilir.

Developer hangi cloud üzerinde çalıştığını bilmek zorunda kalmadan standart servis kataloglarını kullanabilir.

### Hybrid Cloud Platform Engineering

Kurumun bazı uygulamaları on-premise, bazı uygulamaları cloud ortamında çalışabilir.

IDP bu altyapıları tek servis modeli altında birleştirebilir.

Örneğin:

#### Developer Portal

↓

#### Private Cloud / Public Cloud / Kubernetes / DBaaS

### Private Platform Engineering

Veri egemenliği veya güvenlik gereksinimleri nedeniyle tamamen kurum veri merkezinde çalışan private developer platform oluşturulabilir.

Bu yapı özellikle kamu, finans, savunma ve kritik altyapı ortamlarında değerlendirilebilir.

### Platform High Availability

Internal Developer Platform kritik development altyapısı haline geldiğinde platformun kendisinin de yüksek erişilebilir olması gerekir.

SecureSys;

- Git,
- CI/CD,
- registry,
- Kubernetes,
- database,
- monitoring

bileşenlerini HA mimarisinde tasarlayabilir.

### Platform Backup

Git repository, configuration, artifact ve platform database'leri düzenli olarak yedeklenmelidir.

Backup altyapısı Immutable Backup ve [Cold Backup](/tr/hizmetler/cold-backup-yedekleme-immutable-backup-hizmeti) sistemleriyle entegre edilebilir.

### Platform Disaster Recovery

Kritik developer platformları için Disaster Recovery mimarisi oluşturulabilir.

Örneğin:

**Primary IDP → Replication / Backup → DR Platform**

Bu sayede ana platform kullanılamaz olduğunda development operasyonlarının alternatif ortamda devam etmesi hedeflenebilir.

### Platform Engineering as a Service

Platform Engineering kabiliyetini kendi içerisinde oluşturmak istemeyen kurumlar için yönetilen hizmet modeli uygulanabilir.

SecureSys **Platform Engineering as a Service** kapsamında;

- platform kurulumu,
- Kubernetes,
- CI/CD,
- IaC,
- developer portal,
- security,
- monitoring,
- operasyon

süreçlerini yönetebilir.

### Managed Internal Developer Platform

IDP kurulumunun ardından platformun günlük operasyonları SecureSys tarafından yönetilebilir.

Hizmet kapsamında;

- platform monitoring,
- upgrades,
- Kubernetes operations,
- CI/CD management,
- security updates,
- capacity management,
- incident management

süreçleri yürütülebilir.

### Platform Health Check

Mevcut Internal Developer Platform veya DevOps altyapısının sağlık kontrolü gerçekleştirilebilir.

SecureSys Platform Health Check kapsamında;

- architecture,
- security,
- performance,
- availability,
- automation,
- developer experience

alanlarını değerlendirebilir.

### SecureSys Platform Engineering Hizmet Süreci

#### \1. Mevcut Ortam Analizi

Development, DevOps, infrastructure ve cloud ortamları analiz edilir.

#### \2. Developer Journey Analizi

Bir geliştiricinin koddan production'a kadar geçtiği süreçler çıkarılır.

#### \3. Platform Gereksinimlerinin Belirlenmesi

Developer ekiplerinin ihtiyaç duyduğu ortak servisler belirlenir.

#### \4. Hedef Platform Mimarisi

IDP, Kubernetes, CI/CD, IaC ve security mimarisi oluşturulur.

#### \5. Service Catalog

Self-service sunulacak servisler belirlenir.

#### \6. Golden Paths

Standart application ve deployment yolları oluşturulur.

#### \7. Automation

IaC ve GitOps entegrasyonları gerçekleştirilir.

#### \8. DevSecOps

SAST, SCA, SBOM, secret scanning ve container security kontrolleri eklenir.

#### \9. Observability

Logging, monitoring ve tracing altyapısı oluşturulur.

#### \10. Security

RBAC, PAM, secrets ve network segmentation uygulanır.

#### \11. Developer Portal

Platform servisleri merkezi portal üzerinden sunulur.

#### \12. Operasyon ve Sürekli İyileştirme

Platform kullanım verileri ve developer feedback'leri doğrultusunda sürekli geliştirilir.

### Neden SecureSys Platform Engineering?

Platform Engineering yalnızca Kubernetes cluster kurmak veya developer portal oluşturmak değildir.

Başarılı bir Internal Developer Platform;

**Developer Experience + Infrastructure + Kubernetes + CI/CD + Automation + Security + Observability + Governance**

bileşenlerinin birlikte çalışmasını gerektirir.

SecureSys Platform Engineering yaklaşımı, altyapı ve yazılım geliştirme süreçlerini siber güvenlik kabiliyetleriyle birlikte ele alır.

Bu nedenle platform yalnızca developer ekiplerini hızlandırmayı değil; aynı zamanda kurumun güvenlik ve operasyon standartlarının yazılım geliştirme süreçlerine otomatik olarak uygulanmasını hedefler.

Yaklaşımımız:

**Build Once → Standardize → Automate → Secure → Self-Service → Measure → Improve**

modeline dayanır.

### Sık Sorulan Sorular

#### Platform Engineering nedir?

Platform Engineering, developer ekiplerine ortak altyapı, CI/CD, Kubernetes, security ve operasyon servislerinin standart platform üzerinden sunulmasını sağlayan mühendislik yaklaşımıdır.

#### Internal Developer Platform nedir?

IDP, geliştiricilerin uygulama oluşturma, deploy etme ve yönetme süreçlerinde ihtiyaç duyduğu servisleri self-service olarak kullanmasını sağlayan kurum içi platformdur.

#### Developer Portal ile IDP aynı şey midir?

Hayır. Developer Portal genellikle kullanıcı arayüzüdür. IDP ise portalın arkasındaki otomasyon, infrastructure, CI/CD ve platform servislerinin tamamını kapsar.

#### Golden Path nedir?

Golden Path, kurumun belirli bir uygulama türü için önerdiği standart development ve deployment yoludur.

#### Platform Engineering DevOps'un yerine mi geçer?

Hayır. Platform Engineering, DevOps prensiplerinin büyük developer organizasyonlarında daha standart ve ölçeklenebilir uygulanmasını sağlar.

#### Platform Engineering DevSecOps ile birlikte kullanılabilir mi?

Evet. SAST, SCA, SBOM, secret scanning, container scanning ve security gate kontrolleri platforma varsayılan olarak entegre edilebilir.

#### Kubernetes Platform Engineering için zorunlu mudur?

Hayır. Ancak Kubernetes modern Internal Developer Platform mimarilerinde yaygın kullanılan altyapılardan biridir.

#### IDP on-premise kurulabilir mi?

Evet. Internal Developer Platform tamamen kurumun kendi veri merkezinde veya private cloud ortamında kurulabilir.

#### Air-Gapped Developer Platform kurulabilir mi?

Evet. İnternet erişimi olmayan izole ortamlarda private Git, registry, CI/CD ve Kubernetes kullanılarak Air-Gapped Developer Platform oluşturulabilir.

#### Platform Engineering as a Service alınabilir mi?

Evet. Platformun kurulumu, güvenliği, monitoring'i ve operasyonu yönetilen hizmet olarak sunulabilir.

### Yazılım Ekiplerinizi SecureSys Internal Developer Platform ile Hızlandırın

Her developer ekibinin ayrı CI/CD pipeline, Kubernetes konfigürasyonu, monitoring sistemi, security araçları ve infrastructure süreçleri oluşturması zaman içerisinde ciddi teknik borç ve operasyonel karmaşıklık meydana getirebilir.

SecureSys Platform Engineering hizmetleriyle;

**Developer Portal → Service Catalog → Golden Paths → CI/CD → DevSecOps → Kubernetes → DBaaS → Observability**

süreçlerini ortak bir Internal Developer Platform altında birleştirebilirsiniz.

Developer ekiplerinin altyapı ticket'ları ve tekrarlayan operasyonlarla zaman kaybetmesi yerine, onaylanmış ve güvenli servisleri self-service olarak kullanmasını sağlayabilirsiniz.

**Platform Engineering olgunluk seviyenizi analiz ettirin, Internal Developer Platform mimarinizi oluşturun ve yazılım geliştirme altyapınızı güvenli bir self-service platforma dönüştürün.**