Cloud Fundamentals

#IaaS و PaaS و SaaS و FaaS: مين مسؤول عن إيه؟IaaS, PaaS, SaaS and FaaS: who owns what?

الـ cloud مش مجرد server بعيد؛ هو اختيار قد إيه من التشغيل هتديره بنفسك. كل ما الخدمة تدير أكتر، مسؤولية infrastructure بتقل، لكن مسؤوليتك عن الداتا والصلاحيات والكود والتكلفة لسه موجودة.

FaaS نوع من التشغيل managed و event-driven، مش ضمان إن كل request رخيصة. اختار أقل عبء تشغيل يحقق احتياجاتك؛ VM مفيدة لو محتاج OS control، لكنها بتضيف شغل مستمر.

#Regions و Availability zones و RecoveryRegions, availability zones and recovery

نسختين على نفس الجهاز مش حماية من عطل مركز بيانات. region منطقة جغرافية للخدمات، و availability zones مواقع معزولة للأعطال جوه region، ببنية طاقة وتبريد وشبكة مستقلة حسب تصميم المزود. توافر zones والدعم في كل service و SKU محتاج مراجعة.

1. حدد SLO و RTO، الوقت المقبول لاسترجاع الخدمة، و RPO، مقدار الداتا المقبول فقدها زمنياً.
2. وزع compute و data على zones لما الخدمة تدعم ده؛ مجرد اختيار region مش بيضمن zone redundancy.
3. لو مطلوب تحمل عطل region كاملة، خطط routing و replication و failover عبر regions.
4. جرّب الاسترجاع، بما فيه DNS والأسرار والصلاحيات والـ backups، مش compute بس.

multi-region بيزود latency وتكلفة وتعقيد consistency. مش كل تطبيق محتاج active-active؛ backup قابل للاسترجاع أو warm standby ممكن يحقق الهدف بتعقيد أقل. replication مش backup: حذف غلط ممكن يتنسخ.

#خريطة Azure و AWS: تشابه وظيفة مش تطابقAzure and AWS mapping: similar roles, different contracts

الخريطة تساعدك تنقل الفكرة، مش الكود والإعدادات زي ما هي. راجع limits و pricing و delivery guarantees و identity model قبل الاختيار.

RDS عيلة engines مش clone لـ Azure SQL؛ Cosmos DB و DynamoDB ليهم models و consistency مختلفة. Entra ID identity provider للمستخدمين والـ workloads؛ IAM مركزه التحكم في AWS resources، و IAM Identity Center للفيدرشن ودخول workforce. Application Insights جزء من Azure Monitor، و CloudWatch أوسع من APM وحده، وممكن tracing يحتاج خدمات أو تكاملات إضافية. دليل المقارنة الرسمي.

#Managed identity بدل نسخ المفاتيحManaged identity instead of copied keys

connection key في config محتاج تخزين وتدوير، وتسريبه بيفتح resource لحد ما تلغيه. Azure managed identity بتدي التطبيق هوية يصدر بيها tokens قصيرة العمر لخدمات بتدعم Entra authentication؛ وفي AWS استخدم IAM roles و temporary credentials للـ workload. المثال محتاج Azure.Identity و Azure.Storage.Blobs، و blob موجود، وهوية التطبيق ليها Storage Blob Data Reader على scope مناسب.

using Azure.Identity;
using Azure.Storage.Blobs;

var account = Environment.GetEnvironmentVariable("STORAGE_ACCOUNT")
    ?? throw new InvalidOperationException("STORAGE_ACCOUNT is required");
var credential = new DefaultAzureCredential(); // (1)
var service = new BlobServiceClient(
    new Uri($"https://{account}.blob.core.windows.net"), credential); // (2)
var blob = service.GetBlobContainerClient("invoices").GetBlobClient("invoice.txt");
await blob.DownloadToAsync("invoice.txt"); // (3)

الهوية مش بتدي permissions تلقائياً، ومش بتفتح firewall. افصل identities حسب workload وطبق least privilege. لو خدمة ماتدعمش الهوية، خزّن مفتاحها في Key Vault أو Secrets Manager ودوّره. managed identity في Container Apps.

#Serverless: scale-to-zero مش من غير serversServerless: scale-to-zero still uses servers

serverless بينقل إدارة servers للمنصة. Functions مناسبة لأحداث زي invoice upload أو queue message. cold start هو وقت تجهيز instance جديدة، بما فيه runtime و dependencies وتهيئة التطبيق؛ مش كل invocation بيبقى cold، ومدة البدء بتعتمد على plan و runtime والتطبيق.

اعمل handlers idempotent لأن triggers كتير ممكن تعيد التسليم. قلل initialization وخلي connections reusable، لكن ماتخزنش حالة business المهمة في memory. لو latency صارمة، قيّم minimum instances أو provisioned capacity حسب الخدمة؛ ده يقلل فوايد scale-to-zero. شغل طويل أو CPU مستمر ممكن يناسب container job أو service أحسن.

#Scaling: زوّد السعة من غير ما تكسر اللي وراكScaling without overwhelming downstream systems

vertical scaling بيكبر instance، و horizontal scaling بيزود عددها. الأول محدود بحجم machine وممكن يحتاج restart؛ التاني محتاج app تقبل توزيع الطلبات. session و uploaded files و job state في memory بتمنع scale-out موثوق.

1. حدد bottleneck: CPU ولا database waits ولا queue backlog؟
2. اختار metric مناسب: CPU للحمل الحسابي، أو queue age و backlog للشغل الخلفي، مع latency كمؤشر نتيجة.
3. حدد minimum و maximum و cooldown أو stabilization علشان تمنع oscillation.
4. راجع مجموع connection pools والتزامن؛ 20 replicas ممكن تغرق database واحدة.
5. عند scale-in، امنع استقبال شغل جديد واعمل drain وحافظ على إمكانية retry.

autoscale رد فعل مش سحر؛ boot time وقياس metrics بياخدوا وقت. sudden bursts محتاجة headroom أو queue و backpressure. sticky sessions ممكن تساعد مؤقتاً، لكنها مش بديل لتصميم session shared.

#Storage tiers و Lifecycle و BackupStorage tiers, lifecycle and backup

صور المنتجات والـ PDFs مش لازم يتحطوا في relational rows. object storage بيحفظ blobs بمفاتيح و metadata؛ block storage مناسب لأقراص VMs، و file storage بيقدم shared filesystem. اختار حسب access pattern مش الحجم بس.

Azure و AWS عندهم tiers وأسماء وشروط مختلفة؛ مش كل archival tier offline بنفس الشكل. عرّف lifecycle policy بناء على آخر وصول أوعمر الداتا المدعوم، وراجع قانون الاحتفاظ و object versioning و soft delete. replication تحمي من عطل infrastructure، لكن versioned backup و restore مجرب مهمين لحذف أوتلف منطقي.

#VNet و VPC و Private endpointsVNets, VPCs and private endpoints

وجود الخدمة في cloud مش معناه إنها private. VNet في Azure و VPC في AWS بيوفروا مساحة شبكة منطقية، و subnets بتقسمها. routes بتحدد الطريق، و security groups أو NSGs بتحدد السماح، و DNS بيحدد العنوان؛ كل واحدة ممكن تكون سبب timeout.

1. حط التطبيق والداتا في topology واضحة، بمدخل public مقصود بس.
2. استخدم private endpoint أوآلية private access المناسبة للخدمة علشان data path يبقى خاص.
3. اضبط private DNS علشان hostname المعتاد يرجع العنوان الداخلي من شبكة التطبيق.
4. اقفل public access لما يبقى مناسب، واحتفظ بطريقة إدارة ودعم معروفة.
5. اختبر الهوية والصلاحيات منفصلين عن الشبكة.

private endpoint مش encryption ولا authorization؛ TLS و identity لسه مطلوبين. NAT للخروج مش public inbound route للتطبيق. خليك واعي بتكلفة NAT و data transfer وبـ overlapping address ranges عند ربط الشبكات. افحص resolution و route و port قبل افتراض إن المشكلة credentials.

#التكلفة و Infrastructure as CodeCost awareness and Infrastructure as Code

تكلفة cloud مش compute بس: database و storage operations و egress و NAT و logs و backups و idle resources ممكن يفرقوا. حط tags للـ owner والـ environment، و budgets وتنبيهات؛ budget alert مش spending cap مضمون. قارن تكلفة request أو order ناجح، مش فاتورة server واحدة.

IaC بيخلي infrastructure قابلة للمراجعة والتكرار. Bicep لـ Azure، و Terraform declarative بمزودين كتير و state، و Pulumi بيعبر بلغات عامة مع state برضه. المثال Bicep ملف كامل لـ storage account داخل resource group موجودة، محتاج Azure CLI و login وصلاحية deploy. اسم storage مشتق علشان يبقى lowercase وبطول مناسب.

param location string = resourceGroup().location

resource invoices 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'st${uniqueString(resourceGroup().id)}' // (1)
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false // (2)
    allowSharedKeyAccess: false
  }
}
output storageName string = invoices.name

قبل apply اعمل plan أو what-if، واحمي state لأنه ممكن يحتوي أسرار، وراجع drift والتغييرات المدمرة. ماتستخدمش cloud console كمسار دائم لتعديل production من غير تسجيله في IaC. مرجع storage resource.

#12-factor app و نشر ASP.NET CoreThe 12-factor app and ASP.NET Core deployment

التطبيق القابل للنقل محتاج أكتر من container. الـ 12 factors: codebase واحدة بتتبّعها Git؛ dependencies صريحة؛ config خارج الكود؛ backing services كresources؛ فصل build و release و run؛ processes من غير state دائمة؛ port binding؛ concurrency بالـ processes؛ disposability ببدء وإيقاف منظم؛ تقارب dev و production؛ logs كevent streams؛ و admin tasks كعمليات مستقلة. دي إرشادات؛ config حساسة محتاجة secret store مش commit.

لكل مسار: شغّل migrations كخطوة منفصلة، وراقب startup و requests، وجرب smoke test و rollback. لو platform runtime مش مناسب لـ .NET 10، container مناسبة أو self-contained publish قد يكونوا اختيارات حسب المنصة؛ راجع الدعم الحالي. ماتعتمدش على local filesystem للـ uploads أو sessions. نشر .NET على Elastic Beanstalk.