Share via

Uygulama platformunuzu geliştirme

  • Makale

Platform mühendisliği yolculuğunuzda ilk olarak ele almak istediğiniz sorunları anladıktan sonra, uygulama platformunuzla ilgili bazı zorlukları gidermeniz gerektiğini fark edebilirsiniz. Bu makalede, tam olarak bunu nasıl yapabileceğinize ilişkin bazı ipuçları sağlanır. İyi tasarlanmış bir uygulama platformu oluşturmanın sık kaçırılan veya unutulan yönleri hakkında daha fazla bilgi edineceksiniz. Özellikle altyapı yönetimi, güvenlik, maliyet yönetimi, idare ve gözlemlenebilirlik.

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

Bugün bir veya daha fazla uygulama platformlarınız varsa, tanımladığınız 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 Ipuç -ları
Mevcut uygulama platformunuzu uyarlamak, yeni bir başlangıç yapmak veya bu yaklaşımların bir bileşimini kullanmak istiyor musunuz? Şu anda 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 istersiniz. Flaş kesme nadiren işe yarar. Mühendislik sistemlerine çok benzer şekilde uygulama platformlarınız da hareketli bir hedeftir. Bugün varacakların zaman geçtikçe değişecek. Bu düşünceyi ve ilgili geçiş planlarını ileriye dönük tasarımınıza hesaba katmak isteyeceksiniz. Kod olarak altyapı (IaC) ve şablon oluşturma yaklaşımları hakkında daha fazla bilgi için bkz. Yeni uygulamalarda bu varyasyonun bazılarını yönetmenize yardımcı olmak için yazılım mühendisliği sistemleri uygulama .
Bugün yaptıklarınızı değiştirmek istiyorsanız, hangi ürünlerden, hizmetlerden veya yatırımlardan memnunsunuz? Deyiş şöyle diyor: "Eğer kırık değilse, onu düzeltme." Bunu yapmak için bir neden 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ı düşünün. Örneğin, kendi izleme çözümünüzü kullanıyorsanız bu yükü operasyon ekibinizden kaldırmak ve 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? Bunlardan herhangi biri kuruluşunuzun uygulama türlerinin tümü (veya çoğu) için ortak olan alanlarda var mı? Sizin veya dahili müşterilerinizin memnun olmadığınız ve sık sık değişmeyeceğiniz 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 nasıl kolaylaştırabileceğ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 yatırım yapıyor musunuz? Benzersiz bir uygulama altyapısı platformu özelliğinin rekabet avantajınızın bir parçası olduğunu düşünüyor musunuz? Özel bir şey yapmadan önce boşluklar belirlediyseniz 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üşüncenize başka bir yere odaklanın. Kendinizi özel bir uygulama altyapısı veya uygulama modeli sağlayıcısı yerine bir tümleştirici olarak düşünerek başlayın. Oluşturduğunuz her şey, uzun vadede ön maliyetleri en üst düzeye taşıyan bakımın yapılması gerekecektir. Satıcıların uzun vadeli, güneş batma planı veya uzun vadeli destek planı kapsamında olduğundan şüphelendiğiniz bir alanda özel bir çözüm oluşturmak için acil ihtiyaç duyuyorsanı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şlamanın iyi bir yolu 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 etkili ve 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 katı bir yol varsaymak yerine sağlama, izleme ve dağıtımı otomatikleştirmeye odaklanın.

Tasarım ve mimari ile ilgili dikkat edilmesi gerekenler

Kullanabileceğiniz çeşitli olası uygulama platformu desenleri olsa da, aşağıda kritik öneme sahip olan ancak genellikle tasarım sırasında gözden kaçırılan bazı ortak alanlar bulunmaktadır.

Altyapı yönetimi

Yazılım mühendisliği sistemlerini uygulama bölümünde belirtildiği gibi, altyapı ve uygulama dağıtımlarını standartlaştırmak için 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 ayırarak platform ayrıntılarını soyutlamanız gerekir, ö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.)

Hedef, önceden ayarlanmış yapılandırmalarla test edilmiş genel gereksinimleri temsil eden şablonlara sahip olmak olmalıdır, 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, onaylanan 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 görev yapabilir; altyapı kodu 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, değerlendirmeniz gereken kullanım kolaylığı ve denetim arasında bir denge vardır.

Platform tasarımı sırasında, sunmak veya taşımak istediğiniz hizmetleri değerlendirin ve önceliklerini belirleyin. Örneğin, uygulamaları doğrudan Azure Kubernetes Service (AKS) veya Azure Container Apps (ACA) aracılığıyla derlemek, 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. ACA, Azure İşlevleri ve App Service karmaşıklığı azaltırken AKS daha fazla esneklik ve denetim sağlar. OSS Radius inkübasyon projesi gibi daha deneysel uygulama modelleri, ikisi arasında bir denge sağlamaya çalışır, ancak genellikle tam destek ve yerleşik IaC biçimlerinde varlığı olan bulut hizmetlerine göre olgunluğun ö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 mevcut iç beceri kümelerinizi factore edindiğinizden emin olun.

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

Varlığınızın içinde, kullanımı ve maliyet verimliliğini artırmak için birden çok uygulama tarafından paylaşılabilen birçok kaynak vardır. Paylaşılabilen kaynakların her birinin kendi dikkate alınacak noktaları vardır. Örneğin, K8s 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ı arasında değil, içinde paylaşılması, bunların kuruluş yönü, gereksinimler, öncelik vb. ile uyum sağlama şeklini geliştirebilir.
  • Uygulama kiracısı: Uygulamalar farklı kiracı yalıtımı gereksinimlerine sahip olabilir; diğer uygulamalarla birlikte kullanılabilirse tek tek 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ısını da dikkate almanı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ızda tutarlılıktır.
  • Kaynak tüketimi: Her uygulama kaynak 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 tükenmesi nedeniyle canlı site olayları yaşamaktır. Kaynak sınırlarının, temsili testlerin, izleme uyarılarının ve raporlamanın kullanılması, kaynak tüketimini belirlemeye ve diğer uygulamaları etkileyebilecek çok fazla kaynak tüketen uygulamalara karşı korumaya yardımcı olabilir.
  • 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ırmayı 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.

Bu sorunlardan bazıları PaaS çözümleri tarafından basitleştirilir, ancak bu noktaların çoğu veritabanını paylaşma gibi bir şey için bile geçerlidir. Paylaşımda hem yukarı hem de aşağı taraf vardır ve bu nedenle dengeleri dikkatli bir şekilde düşünmelisiniz.

Bu makalenin Kubernetes kümesi yönü hakkında daha fazla bilgi için Azure Kubernetes Service (AKS) çok kiracılı belgelerine bakın.

Yönetim

İdare, korumalarla self servis etkinleştirmenin önemli bir parçasıdır, ancak uyumluluk kurallarını uygulamalar için iş değerine olan zamanı etkilemeyen bir şekilde uygulamak yaygın bir zorluktır. İdare geniş bir konu başlığıdır, ancak bu karşılaştığınız bir sorunsa, bu alanın her iki yönünü de aklınızda bulundurun:

  • İ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 sunulan standartlaştırılmış IaC şablonlarıyla gerçekleştirilebilir.
  • Uyumluluğu koruma (doğru şekilde devam edin): İ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 sistemleriyle birlikte K8s gibi kaynaklar içinde uyumluluğu da desteklediğini düşünün. Örneğin, kilitli bir işletim sistemi yapılandırmasını zorunlu kılmak veya Windows grup ilkesi, 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 engellemek için onay iş akışları ekleyebilirsiniz.

Uyumluluğu korumak için sorunlara erişmek, raporlamak 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ı 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 & doğrulama
  • Dağıtım için daha az süre
  • Sürekli dağıtım

PaC, aşağıdaki ö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.
  • Mevcut kaynaklarda düzeltme & ilkelerin kademe tabanlı aşamalı dağıtımı, 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.

Gözlemlenebilirlik

Uygulamalarınızı ve altyapınızı desteklemek için platform mühendisliğinizin, operasyonlarınızın ve geliştirici ekiplerinizin neler olduğunu görmek için kullanabileceği tüm yığını gözlemleyebilir ve günlüğe kaydetmeniz gerekir.

Grafana panosunun çizimi.

Ancak 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 işlemleri 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 kaynaklanan bilişsel aşırı yükleme veya yararlı bilgi eksikliği nedeniyle bilgi boşluklarından kaynaklanmasıdır.

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

  • Standart: Standartlaştırılmış panoların oluşturulmasını ve yeniden kullanılmasını kolaylaştırmak ve OpenTelemetry gözlemlenebilirlik çerçevesi gibi bir şey aracılığıyla alım işlemeyi basitleştirmek için günlük standartları uygulayın.
  • Izin:Grafana gibi bir şey kullanarak ekip veya uygulama düzeyinde panolar sağlamayı göz önünde bulundurun ve gerektiğinde uygulama ekiplerinin güvenilir üyelerinin günlüklere güvenli bir şekilde erişmesini sağlayan bir tesis ile ilgilenen herkese toplu veriler sağlayın.
  • Saklama: Günlükleri ve ölçümleri tutmak pahalı olabilir ve istenmeyen riskler veya uyumluluk ihlalleri oluşturabilir. Bekletme varsayılanları 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. Mümkün olduğunda, 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ğinde kapasite için K8s küme düğümlerinin sayısını izleyin. Uyarı gereklidir ve bu tanımların kaynaklara program aracılığıyla eklenebilmesi için kod olarak depolanması gerekir.
  • Önemli kapasiteyi ve sistem durumu ölçümlerini belirleme:Prometheus veya Azure Container Insights gibi bir şey kullanarak ölçüm toplama ile işletim sistemini ve paylaşılan kaynakları (örnekler: CPU, bellek, depolama) yetersizlik için izleyin ve uyarın. Kullanımdaki yuvaları/bağlantı noktalarını, gevelene 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.

Güvenlik

Kod, kapsayıcı, küme ve bulut/altyapıdan her katmanda güvenlik gereklidir. Her kuruluşun kendi güvenlik gereksinimleri vardır, ancak yüksek düzeyde, platformunuz için dikkate almanız gereken bazı şeyler ş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 hizmetleriniz genelinde çalışan araçları değerlendirmek için araçlara ihtiyacınız vardır. Uygulama güvenliğinin ötesinde şunları değerlendirmek istersiniz:

İ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 verilebilir.

Hizmetlere, uygulamalara ve altyapıya uygun ölçekte kimlik erişimini yönetmek zor olabilir. Uygulamalara ve hizmetlere kimlik doğrulama hizmetleri sağlarken kimlik bilgilerini oluşturmak, korumak ve yönetmek için sağlayıcıların kimlik doğrulaması ve yetkilendirme yönetimi (RBAC) için rol tabanlı erişim denetimi yetkilendirme sistemleriyle tümleştirilmesini istersiniz. Örneğin, doğrudan her kümede izinler ayarlamanıza gerek kalmadan Azure Kubernetes Service gibi Azure hizmetleri için uygun ölçekte kimlik doğrulaması ve yetkilendirme sağlamak üzere Azure RBAC ve 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 içinde buluta özel uygulamalar, kapsayıcılı iş yüklerinin kimlik doğrulamasına izin vermek için Microsoft Entra ID ile birleştirilen bir İş 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.

Meta veri & maliyet yönetimi

Maliyet, platform mühendisliği çalışmalarınız için en üst sırada yer alan bir diğer sorundur. 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 istersiniz. Ö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 işe yaraması 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 ödemesi, çözüm kaynağı eşlemesi, sahipler vb. konusunda 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 sistemleriyle 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, & ölçüm depolamasını günlüğe kaydetme ve ağ bant genişliği tüketimi gibi paylaşılan kaynakların maliyetini kapsamaz. Paylaşılan kaynaklar için, operasyonel maliyetleri tek tek ekiplere eşit olarak bölebilir veya tekdüzen olmayan tüketimin olduğu ayrılmış sistemler (örneğin günlük depolaması) 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 bir gruptaki kaynakların tüketimini izleyebilen ve önceden belirlenmiş eşiklere girdiğinizde bildirim gönderebilen maliyet uyarıları ve bütçe uyarıları vardır.

Geliştirici self servis temeli tasarlama