Aracılığıyla paylaş

Kolaylaştırılmış uygulama geliştirme ve altyapı yönetimi için uygulama platformunuzu geliştirme

  • Makale

Kuruluşunuzun platform mühendisliği uygulamalarını geliştirmenin büyük bir parçası, uygulama platformunuzu değerlendirmektir. Uygulama platformu, kuruluşunuzda geliştirme, dağıtım ve uygulama yönetimini desteklemek için kullanılan tüm araçları ve hizmetleri içerir.

Basitleştirme ve standartlaştırma

Altyapı ve uygulama dağıtımlarını standart hale getirmek için kod olarak altyapı (IaC) ve otomasyon araçları şablonlarla birleştirilebilir. Platforma özgü özelliklerin son kullanıcı üzerindeki yükünü azaltmak için, seçenekleri yeniden adlandırılabilir adlandırma kurallarına bölerek platform ayrıntılarını soyutlama, örneğin:

  • Kaynak türü kategorileri (yüksek işlem, yüksek bellek)
  • Kaynak boyutu kategorileri (tişört boyutlandırma, küçük orta ve büyük)

Şablonlar, önceden ayarlanmış yapılandırmalarla test edilmiş olan genel gereksinimleri temsil etmelidir, böylece geliştirme ekipleri hemen minimum parametre sağlamayı ve seçenekleri gözden geçirmeye gerek kalmadan kullanmaya başlayabilir. Ancak, ekiplerin yayımlanan şablonlarda kullanılabilir veya istenenden daha fazla seçeneği değiştirmesi gereken durumlar olacaktır. Örneğin, onaylı bir tasarımın desteklenen şablon varsayılanlarının dışında belirli bir yapılandırmaya ihtiyacı olabilir. Bu örnekte operasyonlar veya platform mühendisliği ekipleri tek seferlik bir yapılandırma oluşturabilir ve şablonun bu değişiklikleri varsayılan olarak eklemesi gerekip gerekmediğine karar verebilir.

Kaymayı otomatik olarak düzeltebilen kayma algılama özelliklerine (GitOps) sahip IaC araçlarını kullanarak değişiklikleri izleyebilirsiniz. Bu araçlara örnek olarak Terraform ve bulutta yerel IaC araçları (örnekler, Küme API'si, Çapraz Düzlem, Azure Hizmet Operatörü v2) verilebilir. IaC aracı kayması dışında Azure Kaynak Grafı gibi kaynak yapılandırmalarını sorgulayan bulut yapılandırma araçları olduğunu algılar. Bunlar iki avantaj olarak kullanılabilir; altyapı kodunun dışındaki değişiklikleri izler ve önceden ayarlanmış yapılandırmaları gözden geçirirsiniz. Çok katı olmayı önlemek için, önceden tanımlanmış sınırlarla dağıtımlarda da toleranslar uygulayabilirsiniz. Örneğin, bir dağıtımın sahip olabileceği Kubernetes düğümlerinin sayısını sınırlamak için Azure İlkesi kullanabilirsiniz.

Kendi kendine mi yoksa yönetilen mi?

Genel bulutlarda SaaS, PaaS veya IaaS kullanma seçeneğiniz vardır. SaaS, PaaS ve IaaS hakkında daha fazla bilgi edinmek için Bulut kavramlarını açıklama eğitim modülüne bakın. PaaS hizmetleri kolaylaştırılmış geliştirme deneyimleri sunar ancak uygulama modellerinde daha açıklayıcıdır. Sonuç olarak, kullanım kolaylığı ve kontrol arasında değerlendirmeniz gereken bir denge vardır.

Platform tasarımı sırasında kuruluşunuzun hizmet gereksinimlerini değerlendirin ve önceliklerini belirleyin. Örneğin, uygulamaları doğrudan Azure Kubernetes Service'te (AKS) veya Azure Container Apps (ACA) aracılığıyla derlemeniz, hizmet gereksinimlerinize ve şirket içi kapasitenize ve beceri kümenize bağlıdır. Aynı durum, Azure İşlevleri veya Azure Uygulaması Hizmeti gibi işlev stili hizmetler için de geçerlidir. ACA, Azure İşlevleri ve App Service karmaşıklığı azaltırken AKS daha fazla esneklik ve denetim sağlar. OSS Radius kuluçka projesi gibi daha deneysel uygulama modelleri ikisi arasında denge sağlamaya çalışır, ancak genellikle tam destek ve yerleşik IaC biçimlerinde bulunan bulut hizmetlerine göre olgunluğun daha önceki aşamalarındadır.

Planlarken tanımladığınız sorunlar, bu ölçeğin hangi ucunun size uygun olduğunu değerlendirmenize yardımcı olmalıdır. Bir karara vardığınızda kendi mevcut beceri kümenizi sınadığınızdan emin olun.

Paylaşılan ve ayrılmış kaynaklar karşılaştırması

Kuruluşunuzda, kullanımı ve maliyet verimliliğini artırmak için birden çok uygulama tarafından paylaşılabilen kaynaklar vardır. Her paylaşılan kaynak kendi dikkate alınacak noktalara sahiptir. Örneğin, K8s kümelerini paylaşma konusunda dikkat edilmesi gerekenler bunlardır, ancak bazıları diğer kaynak türleri için geçerli olacaktır:

  • Kuruluş: Kurumsal sınırlar yerine kümeler gibi kaynakların kuruluş sınırları içinde paylaşılması, bunların kuruluş yönü, gereksinimleri ve önceliğiyle uyum sağlama şeklini geliştirebilir.
  • Uygulama kiracısı: Uygulamalar farklı kiracı yalıtımı gereksinimlerine sahip olabilir; diğer uygulamalarla birlikte kullanılabilirse bireysel uygulama güvenliği ve mevzuat uyumluluğunu gözden geçirmeniz gerekir. Örneğin, Kubernetes'te uygulamalar ad alanı yalıtımı kullanabilir. Ancak farklı ortam türleri için uygulama kiracılığını da göz önünde bulundurmanız gerekir. Örneğin, yanlış yapılandırmalar veya güvenlik sorunları nedeniyle beklenmeyen etkilerden kaçınmak için test uygulamalarının aynı kümelerdeki üretim uygulamalarıyla karıştırılmasını önlemek genellikle en iyisidir. Bunun yerine, paylaşılan bir kümede dağıtımdan önce bu sorunları izlemek için önce ayrılmış Kubernetes kümelerini test edip ayarlamayı tercih edebilirsiniz. Ne olursa olsun, karışıklığı ve hataları önlemenin anahtarı yaklaşımınızdaki tutarlılıktır.
  • Kaynak tüketimi: Her uygulama kaynağı kullanımını, yedek kapasiteyi anlayın ve paylaşımın uygun olup olmadığını tahmin etmek için bir projeksiyon yapın. Ayrıca, tüketilen kaynakların sınırlarını da (veri merkezi kapasitesi veya abonelik sınırları) bilmeniz gerekir. Amaç, paylaşılan bir ortamdaki kaynak kısıtlamaları nedeniyle uygulamanızı ve bağımlılıklarınızı taşımaktan kaçınmak veya kapasite bittiğinde canlı site olayları yaşamaktır. Kaynak tüketimini belirlemek ve çok fazla kaynak kullanan uygulamalara karşı koruma sağlamak için kaynak sınırlarını, temsili testleri, izleme uyarılarını ve raporlamayı kullanın.
  • Paylaşılan yapılandırmaları iyileştirme: Paylaşılan kümeler gibi paylaşılan kaynaklar için ek dikkate alınması ve yapılandırılması gerekir. Bunlar arasında çapraz ücretlendirme, kaynak ayırma, izin yönetimi, iş yükü sahipliği, veri paylaşımı, yükseltme koordinasyonu, iş yükü yerleştirme, temel yapılandırma oluşturma, yönetme ve yineleme, kapasite yönetimi ve iş yükü yerleştirme sayılabilir. Paylaşılan kaynakların avantajları vardır, ancak standart yapılandırmalar çok kısıtlayıcıysa ve gelişmezse eskir.

İdare stratejilerini uygulama

İdare, korumalar ile self servis özelliğini etkinleştirmenin önemli bir parçasıdır, ancak uyumluluk kurallarını uygulamalar için iş değerini etkilemeyen bir şekilde uygulamak yaygın bir zorluktır. İdarenin iki bölümü vardır:

  • İlk dağıtım uyumluluğu (hemen başlayın): Bu, yalnızca izin verilen kaynakların ve yapılandırmaların dağıtılabilmesini sağlamak için izin yönetimi ve ilkelerle kataloglar aracılığıyla sağlanan standartlaştırılmış IaC şablonlarıyla elde edilebilir.
  • Uyumluluğu koruma (doğru kalın): İlke tabanlı araçlar kaynak değişiklikleri olduğunda sizi engelleyebilir veya uyarabilir. Temel altyapınızın ötesinde, araçların kapsayıcılarınızda veya VM'lerinizde kullanılan işletim sistemilerle birlikte K8'ler gibi kaynakların içinde uyumluluğu da desteklediğini göz önünde bulundurun. Örneğin, kilitli bir işletim sistemi yapılandırmasını zorunlu kılmak veya Windows Grup İlkesi, SELinux, AppArmor, Azure İlkesi veya Kyverno gibi güvenlik yazılımı araçlarını yüklemek isteyebilirsiniz. Geliştiricilerin yalnızca IaC depolarına erişimi varsa, önerilen değişiklikleri gözden geçirmek ve kaynak denetim düzlemlerine (örneğin Azure) doğrudan erişimi önlemek için onay iş akışları ekleyebilirsiniz.

Uyumluluğu korumak için sorunlara erişmek, sorunları bildirmek ve üzerinde işlem yapmak için araçlar gerekir. Örneğin, Azure İlkesi denetim, raporlama ve düzeltme için birçok Azure hizmetiyle kullanılabilir. Ayrıca gereksinimlerinize bağlı olarak Audit, Deny ve DeployIfNotExists gibi farklı modlara sahiptir.

İlkeler uyumluluğu zorunlu kılabilir ancak uygulamaları da beklenmedik bir şekilde bozabilir. Bu nedenle, büyük ölçekte çalışırken kod olarak ilke (PaC) uygulamasına geçiş yapmayı göz önünde bulundurun. PaC, başlangıç sağınızın ve doğru yaklaşımınızın önemli bir parçası olarak şunları sağlar:

  • Merkezi olarak yönetilen standartlar
  • İlkeleriniz için sürüm denetimi
  • Otomatik test ve doğrulama
  • Dağıtım için daha az süre
  • Sürekli dağıtım

PaC, aşağıdaki gibi özelliklerle kötü olabilecek bir ilkenin patlama yarıçapını en aza indirmeye yardımcı olabilir:

  • Gözden geçirilip onaylanan bir depoda kod olarak depolanan ilke tanımları.
  • Test ve doğrulama sağlamak için otomasyon.
  • İlkelerin halka tabanlı aşamalı dağıtımı ve mevcut kaynaklarda düzeltme, kötü olabilecek bir ilkenin patlama yarıçapını en aza indirmeye yardımcı olur.
  • Düzeltme görevinin yerleşik güvenliği vardır ve dağıtımların yüzde 90'ından fazlası başarısız olursa düzeltme görevini durdurma gibi denetimler vardır.

Role özgü gözlemlenebilirlik ve günlüğe kaydetme uygulama

Uygulamalarınızı ve altyapınızı desteklemek için yığınınızın tamamında gözlemlenebilirlik ve günlüğe kaydetmeniz gerekir.

Gözlemlenebilirliği ve günlüğe kaydetmeyi gösteren Grafana panosunun çizimi.

Gereksinimler rol başına farklılık gösterir. Örneğin, platform mühendisliği ve operasyon ekibi, uygun uyarılarla altyapının sistem durumunu ve kapasitesini gözden geçirmek için panolar gerektirir. Geliştiriciler, uygulama ve altyapı durumunu gösteren sorun giderme ve özelleştirilmiş panolar için uygulama ölçümlerine, günlüklere ve izlemelere ihtiyaç duyar. Bu rollerden birinin karşılaştığı sorunlardan biri, çok fazla bilgiden bilişsel aşırı yükleme veya yararlı bilgi eksikliği nedeniyle bilgi boşluklarından kaynaklanıyor olabilir.

Bu zorlukları çözmek için aşağıdakileri göz önünde bulundurun:

  • Standartlar: Standart panoları oluşturmayı ve yeniden kullanmanızı kolaylaştırmak ve OpenTelemetry gözlemlenebilirlik çerçevesi gibi bir işlemle alımı basitleştirmek için günlük standartları uygulayın.
  • İzinler: Grafana gibi bir öğe kullanarak ekip veya uygulama düzeyinde panolar seçerek ilgili herkese toplanan verileri ve gerektiğinde uygulama ekiplerinin güvenilir üyelerinin günlüklere güvenli bir şekilde erişmesini sağlayan bir tesis sağlayın.
  • Bekletme: Günlükleri ve ölçümleri tutmak pahalı olabilir ve istenmeyen riskler veya uyumluluk ihlalleri oluşturabilir. Bekletme varsayılanlarını oluşturun ve bunları başlangıç doğru kılavuzunuzun bir parçası olarak yayımlayın.
  • Kaynak sınırlarını izleme: operasyon ekipleri belirli bir kaynak türü için sınırlamaları belirleyebilmeli ve izleyebilmelidir. Bu sınırlamalar, Azure İlkesi gibi araçlar kullanılarak IaC şablonlarına veya ilkelerine eklenmelidir. İşlemler daha sonra Grafana gibi bir yerde panoları kullanarak proaktif olarak izlemeli ve otomatik ölçeklendirmenin mümkün olmadığı veya etkinleştirilmediği paylaşılan kaynakları genişletmelidir. Örneğin, uygulamalar zaman içinde eklendikçe ve değiştirildiğinden kapasite için K8s küme düğümlerinin sayısını izleyin. Uyarı gereklidir ve kaynaklara program aracılığıyla eklenebilmeleri için bu tanımların kod olarak depolanması gerekir.
  • Önemli kapasiteyi ve sistem durumu ölçümlerini tanımlama: Prometheus veya Azure Container Insights gibi bir öğe kullanarak ölçüm koleksiyonunda yetersizlik için işletim sistemi ve paylaşılan kaynakları (örnekler: CPU, bellek, depolama) izleyin ve uyarın. Kullanımdaki yuvaları/bağlantı noktalarını, sohbetli uygulamaların ağ bant genişliği tüketimini ve kümede barındırılan durum bilgisi olan uygulamaların sayısını izleyebilirsiniz.

En düşük ayrıcalık, birleşik güvenlik yönetimi ve tehdit algılama ilkesiyle güvenlik oluşturma

Kod, kapsayıcı, küme ve bulut/altyapı gibi her katmanda güvenlik gereklidir. Önerilen en düşük güvenlik adımları şunlardır:

  • En az ayrıcalık ilkesini izleyin.
  • DevOps güvenlik yönetiminizi birden çok işlem hattında birleştirin.
  • En kritik riskinizi tanımlamak ve düzeltmek için bağlamsal içgörülerin görünür olduğundan emin olun.
  • Çalışma zamanında bulut iş yükleriniz genelindeki modern tehditleri algılamayı ve yanıtlamayı etkinleştirin.

Bu alandaki sorunları çözmeye yardımcı olmak için, bulutlar ve hibrit (örneğin, Bulut için Microsoft Defender) genelinde mühendislik ve uygulama sistemleriniz, kaynaklarınız ve hizmetlerinizde çalışan araçları değerlendirmek için araçlara ihtiyacınız vardır. Uygulama güvenliğinin ötesinde şunları değerlendirin:

İzin gereksinimleri ortama göre farklılık gösterebilir. Örneğin, bazı kuruluşlarda tek tek ekiplerin üretim kaynaklarına erişmesine izin verilmez ve incelemeler tamamlanana kadar yeni uygulamalar otomatik olarak dağıtılamaz. Ancak geliştirme ve test ortamlarında otomatik kaynak ve uygulama dağıtımına ve sorun giderme için kümelere erişime izin verilmesi gerekebilir.

Hizmetlere, uygulamalara ve altyapıya uygun ölçekte kimlik erişimini yönetmek zor olabilir. Kimlik bilgilerini oluşturmak, korumak ve yönetmek için kimlik sağlayıcıları. Planınız, uygulamalar ve hizmetler için kimlik doğrulama hizmetlerini içermelidir ve büyük ölçekte rol tabanlı erişim denetimi yetkilendirmeleri (RBAC) sistemleriyle tümleşebilir. Örneğin, her kümede doğrudan izinler ayarlamanıza gerek kalmadan Azure Kubernetes Service gibi Azure hizmetleri için uygun ölçekte kimlik doğrulaması ve yetkilendirme sağlamak için Microsoft Entra Id kullanabilirsiniz.

Uygulamaların depolama gibi bulut kaynaklarına erişmek için bir kimliğe erişmesi gerekebilir. Gereksinimleri gözden geçirmeniz ve kimlik sağlayıcınızın bunu mümkün olan en güvenli şekilde nasıl destekleyebileceğinizi değerlendirmeniz gerekir. Örneğin AKS'de buluta özel uygulamalar, kapsayıcılı iş yüklerinin kimlik doğrulamasına izin vermek için Microsoft Entra Id ile birleştirilen bir iş yükü kimliği kullanabilir. Bu yaklaşım, uygulamaların uygulama kodu içinde gizli dizi değişimi olmadan bulut kaynaklarına erişmesini sağlar.

İş yükü sahiplerini belirleyerek ve kaynakları izleyerek maliyetleri azaltın

Maliyeti yönetmek, platform mühendisliğinin bir diğer parçasıdır. Uygulama platformunuzu düzgün bir şekilde yönetmek için iş yükü sahiplerini tanımlamak için bir yönteme ihtiyacınız vardır. Belirli bir meta veri kümesi için sahiplere eşlenen kaynakların envanterini almak için bir yol istiyorsunuz. Örneğin Azure'da AKS Etiketlerini, Azure Resource Manager etiketlerini ve Azure Dağıtım Ortamları'ndaki projeler gibi kavramları kullanarak kaynaklarınızı farklı düzeylerde gruplandırabilirsiniz. Bunun çalışması için, seçilen meta verilerin iş yüklerini ve kaynakları dağıtırken zorunlu özellikleri (Azure İlkesi gibi bir şey kullanarak) içermesi gerekir. Bu, maliyet ayırma, çözüm kaynak eşlemesi ve sahiplere yardımcı olur. Yalnız bırakılmış kaynakları izlemek için düzenli raporlama çalıştırmayı göz önünde bulundurun.

İzlemenin ötesinde, Microsoft Maliyet Yönetimi gibi maliyet yönetimi sistemlerinde aynı meta verileri kullanarak kaynak kullanımları için tek tek uygulama ekiplerine maliyet atamanız gerekebilir. Bu yöntem uygulama ekipleri tarafından sağlanan kaynakları izler ancak kimlik sağlayıcınız, günlüğe kaydetme ve ölçüm depolama alanı ve ağ bant genişliği tüketimi gibi paylaşılan kaynakların maliyetini kapsamaz. Paylaşılan kaynaklar için işletim maliyetlerini tek tek ekiplere eşit olarak bölebilir veya tek tek tüketimin olmadığı ayrılmış sistemler (örneğin günlük depolama) sağlayabilirsiniz. Bazı paylaşılan kaynak türleri kaynak tüketimiyle ilgili içgörüler sağlayabilir, örneğin Kubernetes'te OpenCost veya Kubecost gibi araçlar vardır ve yardımcı olabilir.

Ayrıca, geçerli harcamaları gözden geçirebileceğiniz maliyet analizi araçlarını da aramalısınız. Örneğin Azure portalında, bir gruptaki kaynakların tüketimini izleyebilen ve önceden belirlenmiş eşiklere bastığınızda bildirim gönderebilen maliyet uyarıları ve bütçe uyarıları vardır.

Ne zaman ve nereye yatırım yapılacağına karar verme

Birden fazla uygulama platformlarınız varsa, yüksek maliyetler veya kötü gözlemlenebilirlik gibi sorunları çözen iyileştirmelere ne zaman ve nereye yatırım yapılacağına karar vermek zor olabilir. Yeni bir başlangıç yapmaya başladıysanız Azure Mimari Merkezi'nin değerlendirmeniz için çeşitli olası desenleri vardır. Ancak bunun ötesinde, yapmak istediklerinizi planlamaya başlarken göz önünde bulundurmanız gereken birkaç soru vardır:

Soru İpuçları
Mevcut uygulama platformunuzu uyarlamak, yeni bir başlangıç yapmak veya bu yaklaşımların bir bileşimini kullanmak mı istiyorsunuz? Sahip olduklarınızla mutlu olsanız veya yeni bir başlangıç yapmış olsanız bile, zaman içinde değişime nasıl uyum sağlayacağınızı düşünmek istiyorsunuz. Anında değişiklikler nadiren çalışır. Uygulama platformlarınız hareketli bir hedef. zaman geçtikçe ideal sisteminiz değişir. Bu düşünceyi ve ilgili geçiş planlarını ileriye dönük tasarımınızda hesaba katmak istiyorsunuz.
Bugün yaptıklarınızı değiştirmek istiyorsanız, hangi ürünlerden, hizmetlerden veya yatırımlardan memnunsunuz? "Bozuk değilse, tamir etme" deyişinde olduğu gibi. Bunu yapmak için bir sebep olmadan bir şeyleri değiştirmeyin. Ancak, evde yetiştirilen çözümleriniz varsa, uzun süreli bakımdan tasarruf etmek için mevcut bir ürüne geçmenin zamanı olup olmadığını göz önünde bulundurun. Örneğin, kendi izleme çözümünüzü kullanıyorsanız bu yükü operasyon ekibinizden kaldırıp yeni bir yönetilen ürüne geçirmek istiyor musunuz?
Zaman içinde gerçekleşen en fazla değişikliği nerede görüyorsunuz? Kuruluşunuzun uygulama türlerinin tümü (veya çoğu) için ortak olan alanlarda bunlardan herhangi biri var mı? Sizin veya şirket içi müşterilerinizin memnun olmadığınız ve sık sık değişmeyeceği alanlar başlamak için harika yerlerdir. Bunlar uzun vadede en büyük yatırım getirisine sahiptir. Bu, yeni bir çözüme geçişi kolaylaştırmaya nasıl yardımcı olabileceğinizi de ortaya çıkarmanıza yardımcı olabilir. Örneğin, uygulama modelleri akıcı olma eğilimindedir, ancak günlük analizi araçlarının raf ömrü daha uzun olur. Yön değişikliğinin istenen getirilere sahip olduğunu onaylarken başlamak için yeni projelere /uygulamalara da odaklanabilirsiniz.
En yüksek değer katan alanlarda özel çözümlere mi yatırım yapıyorsunuz? Benzersiz bir uygulama altyapısı platformu özelliğinin rekabet avantajınızın bir parçası olduğunu düşünüyor musunuz? Boşluklar belirlediyseniz, özel bir şey yapmadan önce satıcıların yatırım yapma olasılığının en yüksek olduğu alanları göz önünde bulundurun ve özel düşüncelerinizi başka bir yere odaklayın. Kendinizi özel bir uygulama altyapısı veya uygulama modeli sağlayıcısı yerine tümleştirici olarak düşünerek başlayın. Oluşturduğunuz her şeyin, uzun vadede ön maliyetleri en üst düzeye çıkarabilecek şekilde korunması gerekir. Satıcılar tarafından uzun vadeli, güneş batma veya uzun vadeli destek için plan yapacağından şüphelendiğiniz bir alanda özel bir çözüm oluşturma gereksinimini acilen hissediyorsanız. İç müşterileriniz genellikle kullanıma açık bir ürünle özel bir ürün kadar mutlu olur (daha fazla değilse).

Mevcut uygulama platformu yatırımlarınızı uyarlamak, çalışmaya başlamak için iyi bir yol olabilir. Güncelleştirmeler yaparken, herhangi bir dağıtımdan önce pilot fikirleri basitleştirmek için yeni uygulamalarla başlamayı göz önünde bulundurun. IaC ve uygulama şablon oluşturma yoluyla bu değişikliğin faktörünü dikkate alın. Yüksek etki, yüksek değerli alanlarda benzersiz ihtiyaçlarınız için özel çözümlere yatırım yapın. Aksi takdirde, kullanıma hazır bir çözüm kullanmayı deneyin. Mühendislik sistemlerinde olduğu gibi, zaman içinde değişikliği yönetmenize yardımcı olacak tek bir katı yol varsaymak yerine sağlama, izleme ve dağıtımı otomatikleştirmeye odaklanın.

İlgili içerik

Geliştirici self servis temeli tasarlama