Aracılığıyla paylaş

Geliştirme ve altyapı yönetimini kolaylaştırmak için uygulama platformunuzu geliştirin

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. Son kullanıcı üzerindeki platforma özgü ayrıntıların yükünü azaltmak için, platform ayrıntılarını anlaşılır adlandırma kurallarına bölerek soyutlayabilirsiniz, örneğin:

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

Ş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 vardı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ı (örneğin, Küme API'si, Çapraz Düzlem, Azure Hizmet Operatörü v2) verilebilir. IaC aracı kayması algılamasının dışında , Azure Kaynak Grafı gibi kaynak yapılandırmalarını sorgulayan bulut yapılandırma araçları vardır. Bunlar iki avantaj olarak kullanılabilir; altyapı kodu dışındaki değişiklikleri izlemek ve değiştirilmiş önceden ayarlanmış yapılandırmaları gözden geçirmek için. Ç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'ni kullanabilirsiniz.

Kendi kendine mi yoksa yönetilen mi?

Genel bulutlarda hizmet olarak yazılım (Saas), hizmet olarak platform (PaaS) veya hizmet olarak altyapı (IaaS) kullanma seçeneğiniz vardır. SaaS, PaaS ve IaaS hakkında daha fazla bilgi edinmek için Bulut hizmeti türlerini 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 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 App Service gibi işlev stili hizmetler için de geçerlidir. Container Apps, Fonksiyonlar ve App Service karmaşıklığı azaltırken AKS daha fazla esneklik ve kontrol sağlar. Radius OSS 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.

Planlama sırasında tanımladığınız sorunlar, bu ölçeğin hangi sonunun sizin için doğru olduğunu değerlendirmenize yardımcı olmalıdır. Bir karar verirken kendi mevcut iç beceri kümenizi göz önünde bulundurduğunuzdan emin olun.

Paylaşılan ve ayrılmış kaynaklar

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 kaynağın kendi dikkate alınacak noktaları vardır. Örneğin, Kubernetes kümelerini paylaşma konusunda dikkat edilmesi gerekenler bunlardır, ancak bazıları diğer kaynak türleri için geçerlidir:

  • Organizasyon: Kümeler gibi kaynakların kuruluş sınırları dışında değil, içinde paylaşılması, bunların kuruluş yönü, gereksinimleri ve önceliğiyle uyum sağlama şeklini geliştirebilir.
  • Uygulama kiracılığı: Uygulamalar farklı kiracı yalıtım gereksinimlerine sahip olabilir; diğer uygulamalarla birlikte kullanılabilirse bireysel uygulama güvenliğini 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 uygulamanın kaynak kullanımını ve yedek kapasitesini 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

Yönetim, koruyucu önlemler ile self servis özelliğini etkinleştirmenin önemli bir parçasıdır, ancak uyumluluk kurallarını etkilemeden iş uygulamalarına değer katmak, yaygın bir zorluktur. İdarenin iki bölümü vardır:

  • İlk dağıtım uyumluluğu (sağdan başla): 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 gerçekleştirilebilir.
  • 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, kapsayıcılarınızda veya VM'lerinizde kullanılan işletim sistemiyle birlikte Kubernetes gibi kaynakların içinde uyumluluğu da destekleyen araçları 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 Azure gibi kaynak denetimi düzlemlerine 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, doğru başlayın ve doğru kalın 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

Rol bazlı gözlemlenebilirlik ve kayıt uygulama

Uygulamalarınızı ve altyapınızı desteklemek için yığınınızın tamamında gözlemlilik ve kayıt tutma gerekir.

Gözlemlenebilirlik ve loglama gösteren Grafana panosunun ekran görüntüsü.

Gereksinimler rol başına farklılık gösterir. Örneğin, platform mühendisliği ve operasyon ekipleri, altyapının sistem durumunu ve kapasitesini uygun uyarılarla 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şabileceği bir sorun, çok fazla bilgiden bilişsel aşırı yükleme veya yararlı bilgi eksikliği nedeniyle bilgi boşluklarından kaynaklanır.

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

  • Standartlar: Standartlaştırılmış panolar oluşturmayı ve yeniden kullanmayı kolaylaştırmak için günlük standartları uygulayın ve OpenTelemetry gözlemlenebilirlik çerçevesi gibi bir araçla veri alım sürecini basitleştirin.
  • İzinler:Grafana gibi bir öğe kullanarak ekip veya uygulama düzeyinde panolar sunun ve gerektiğinde günlüklere güvenli bir şekilde erişebilmeleri için uygulama ekiplerinin güvenilir üyelerine yönelik bir tesis ile ilgilenen herkese toplu veri sağlayın.
  • Alıkoyma: Günlükleri ve ölçümleri tutmak pahalı olabilir ve istenmeyen riskler veya uyumluluk ihlalleri oluşturabilir. Koruma varsayılanlarını oluşturun ve bunları doğru başlangıç rehberinizin 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 panolar kullanarak önceden sürekli izlemeli ve otomatik ölçeklendirmenin mümkün olmadığı veya etkinleştirilmediği durumlarda paylaşılan kaynakları genişletmelidir. Örneğin, uygulamalar zaman içinde eklendikçe ve değiştirildiğinde kapasite için Kubernetes 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 kapasite ve sağlık ölçümlerini belirleme: İşletim sistemi ve paylaşılan kaynakları (örneğin, CPU, bellek ve depolama) açlık durumu için izleme ve uyarı alma, Prometheus veya Azure Monitor'da Kubernetes izleme gibi bir araç kullanarak metrik toplama. 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 verilebileceğini düşünebilirsiniz.

Hizmetlere, uygulamalara ve altyapıya uygun ölçekte kimlik erişimini yönetmek zor olabilir. Kimlik sağlayıcıları kimlik bilgilerini oluşturur, korur ve yönetir. Planınız uygulamalar ve hizmetler için kimlik doğrulama hizmetlerini içermelidir ve bu hizmet büyük ölçekte rol tabanlı erişim denetimi (RBAC) yetkilendirme sistemleriyle tümleştirilmelidir. Ö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, Azure Kubernetes Service'te buluta özel uygulamalar, kapsayıcılı iş yüklerinin kimlik doğrulaması yapması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 sahiplerle ilişkilendirilen kaynakların envanterini edinmek 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 bireysel ekiplere eşit olarak bölebilir veya tüketimin dengesiz olduğu durumlarda 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'in 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 platformunuza sahipseniz, 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:

Question İ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 sürekli değişen 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şinin dediği gibi; sebepsiz yere 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 ve 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 korunması gerekir ve bu da uzun vadede ön maliyetleri alt üst eder. tr-TR: Uzun vadede satıcılar tarafından karşılanacağını düşündüğünüz bir alanda acilen özel bir çözüm oluşturma gereksinimi hissediyorsanız, çözümü sonlandırma veya uzun vadeli destek için plan yapmayı ihmal etmeyin. İç müşterileriniz genellikle hazır bir ürünle, özel bir ürün kadar mutlu olur, hatta belki daha fazla.

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

  • Last updated on