Saif Ali AlghamdiTransformation & Growth Advisor
تواصل
LibraryمكتبتيDigital & Technologyرقمي وتقنية
INFORMATION TECHNOLOGY · OPERATIONAL FRAMEWORKتقنية المعلومات · إطار تشغيلي

Cloud-Native Platforms & Kubernetesالمنصّات السحابية الأصيلة وKubernetes

SectionالقسمDigital & Technologyرقمي وتقنية
Reading timeزمن القراءة9 min٩ دقيقة
ByإعدادSaif Alghamdiسيف الغامدي
One

Overview

Field: Cloud-native platforms & operations
Scope: Running containerized applications reliably and securely at scale
Owner role: Platform engineering lead, with service owners
Review cadence: Continuous operation, platform review each quarter
By: Saif Alghamdi

Cloud-native is a way of building and running software that treats the underlying infrastructure as a fluid, automated resource rather than fixed machines. Applications are packaged into containers, run across a cluster of computers, and managed by a system that keeps them healthy automatically, so the platform absorbs failure and scale rather than a person handling each incident by hand.

The shift matters because it changes what operations means. In the old model, a service ran on a specific server that a person set up, patched, and rescued when it failed, so scale and reliability were manual and slow. In the cloud-native model, a service is described declaratively, the platform runs as many copies as needed across whatever machines are available, and it restarts, reschedules, and heals them without intervention. Operations moves from tending individual servers to governing an automated system.

This framework describes the operational essentials of a cloud-native platform, centered on Kubernetes as the de facto orchestration standard, and it borrows the least-privilege and monitoring discipline of the security frameworks. It aligns to the guidance of the cloud-native community without reproducing any source text, and is written to be reusable across environments.

Note: Cloud-native trades the simplicity of a single server for the resilience and scale of an automated platform. That trade is worth it at scale, but the automation is only as safe as the way it is configured and governed.
الأول

نظرة عامة

المجال: المنصّات السحابية الأصيلة وتشغيلها
النطاق: تشغيل التطبيقات الحاوية بموثوقيةٍ وأمانٍ على نطاق
دور المالك: قائد هندسة المنصّة، مع ملّاك الخدمات
دورية المراجعة: تشغيلٌ مستمر، ومراجعة منصّةٍ كل ربع
إعداد: سيف الغامدي

السحابي الأصيل طريقةٌ لبناء البرمجيات وتشغيلها تعامل البنية التحتية كموردٍ سائلٍ مُؤتمَت لا كآلاتٍ ثابتة. فتُحزَم التطبيقات في حاويات، وتعمل عبر عنقودٍ من الحواسيب، ويديرها نظامٌ يُبقيها سليمةً تلقائيًا، فتمتصّ المنصّةُ الفشلَ والنطاق بدل أن يعالج شخصٌ كل حادثةٍ يدويًا.

التحوّل يهمّ لأنه يغيّر معنى التشغيل. ففي النموذج القديم، تعمل خدمةٌ على خادمٍ بعينه يُعِدّه شخصٌ ويُرقّعه ويُنقذه حين يفشل، فكان النطاق والموثوقية يدويين بطيئين. وفي النموذج السحابي الأصيل، تُوصَف الخدمة تعريفيًا، وتُشغّل المنصّة ما يلزم من نُسخٍ عبر أي آلاتٍ متاحة، وتُعيد تشغيلها وجدولتها وشفاءها دون تدخّل. فينتقل التشغيل من رعاية خوادم مفردة إلى حوكمة نظامٍ مُؤتمَت.

يصف هذا الإطار أساسيات تشغيل منصّةٍ سحابية أصيلة، مُتمركزًا حول Kubernetes كمعيار التنسيق الفعلي، ويستعير انضباط أقلّ الصلاحية والمراقبة من أطر الأمن. ويتوافق مع إرشاد مجتمع السحابي الأصيل دون نسخ أي نصّ مصدري، ومكتوب ليكون قابلًا لإعادة الاستخدام عبر البيئات.

ملاحظة: السحابي الأصيل يقايض بساطة الخادم الواحد بمرونة ونطاق منصّةٍ مُؤتمَتة. تلك المقايضة تستحق على نطاق، لكن الأتمتة آمنةٌ بقدر كيفية إعدادها وحوكمتها فقط.
Two

Containers

The building block of cloud-native is the container: a package that bundles an application with everything it needs to run, so it behaves the same way wherever it is placed. Containers are the unit the whole platform schedules, scales, and heals.

A container solves an old, painful problem: software that works on one machine and breaks on another because the environments differ. By packaging the application together with its dependencies, a container carries its own environment with it, so it runs identically on a developer's laptop, in a test system, and in production. That consistency is what makes automated deployment across a fleet of machines reliable rather than a gamble.

Immutability

Containers are treated as immutable and disposable, which is a deliberate discipline, not a limitation. Rather than logging into a running container to fix or update it, you build a new version and replace the old one entirely. This sounds wasteful but is the source of much of the platform's reliability: every running copy is identical and known, there is no drift from manual tweaks, and rolling back is simply redeploying the previous version. A server you never modify by hand is a server that cannot accumulate the untracked changes that cause mysterious failures.

The contrast with a traditional virtual machine is instructive. A virtual machine emulates a whole computer including its own operating system, which is heavy and slow to start, while a container shares the host's operating system and packages only the application, which is light and starts in seconds. That lightness is what lets a platform run many containers per machine and start new ones instantly in response to load or failure.

Note: Treat containers as cattle, not pets. You do not name, nurse, and repair each one, you replace it, and designing your operations around disposability is what unlocks automated healing and scaling.
الثاني

الحاويات

لبنة السحابي الأصيل هي الحاوية: حزمةٌ تجمع تطبيقًا مع كل ما يحتاجه للعمل، فيتصرّف بالطريقة نفسها أينما وُضِع. والحاويات هي الوحدة التي تجدولها المنصّة كلها وتوسّعها وتشفيها.

الحاوية تحلّ مشكلةً قديمة مؤلمة: برمجيةٌ تعمل على آلةٍ وتنكسر على أخرى لاختلاف البيئات. فبحزم التطبيق مع اعتماداته، تحمل الحاوية بيئتها معها، فتعمل بتطابقٍ على حاسب مطوّرٍ وفي نظام اختبارٍ وفي الإنتاج. وذلك الاتساق ما يجعل النشر المُؤتمَت عبر أسطولٍ من الآلات موثوقًا لا مقامرة.

عدم القابلية للتغيير

تُعامَل الحاويات كغير قابلةٍ للتغيير وقابلةٍ للاستبدال، وهو انضباطٌ متعمَّد لا قيد. فبدل الدخول لحاويةٍ عاملة لإصلاحها أو تحديثها، تبني نسخةً جديدة وتستبدل القديمة كليًا. يبدو هذا هدرًا لكنه مصدر كثيرٍ من موثوقية المنصّة: فكل نسخةٍ عاملة متطابقة ومعلومة، ولا انزياح من تعديلاتٍ يدوية، والتراجع مجرد إعادة نشر النسخة السابقة. وخادمٌ لا تعدّله يدويًا أبدًا خادمٌ لا يستطيع تراكم التغييرات غير المُتتبَّعة التي تُسبّب الأعطال الغامضة.

والمقارنة بآلةٍ افتراضية تقليدية مُفيدة. فالآلة الافتراضية تُحاكي حاسبًا كاملًا بنظام تشغيله، وهو ثقيلٌ بطيء البدء، بينما الحاوية تشارك نظام تشغيل المضيف وتحزم التطبيق فقط، وهو خفيفٌ يبدأ في ثوانٍ. وتلك الخفّة ما يتيح للمنصّة تشغيل حاوياتٍ كثيرة لكل آلةٍ وبدء جديدةٍ فورًا استجابةً للحمل أو الفشل.

ملاحظة: عامِل الحاويات كقطيعٍ لا كحيواناتٍ أليفة. لا تُسمّي كلًّا وترعاه وتُصلِحه، بل تستبدله، وتصميم تشغيلك حول قابلية الاستبدال هو ما يُطلِق الشفاء والتوسّع المُؤتمَتين.
Three

Orchestration with Kubernetes

Running one container is easy, running hundreds across many machines reliably is not, and that coordination problem is what an orchestrator solves. Kubernetes is the platform that decides where containers run, keeps the right number alive, and repairs the system when something breaks.

The core idea of Kubernetes is declarative desired state. Instead of issuing step-by-step commands, you describe the state you want, such as run five copies of this service, and the platform continuously works to make reality match that description. If a machine dies and takes two copies with it, Kubernetes notices the gap between desired and actual and starts two replacements elsewhere, without anyone being paged. This closed loop of compare-and-correct is the source of the platform's self-healing behavior.

  • Desired state: you declare what should be true, and the platform reconciles reality to it continuously.
  • Scheduling: the platform decides which machine each container runs on, packing work efficiently across the cluster.
  • Self-healing: failed containers are restarted and lost ones rescheduled automatically, without manual intervention.
  • Scaling: the number of copies can grow and shrink with demand, automatically or on command.

The declarative model also transforms how change is made. Because the entire desired state is described in configuration, that configuration can be version-controlled, reviewed, and applied like code, so a change to production is a reviewed edit to a file rather than a risky manual action on a live server. This is the foundation of modern, auditable operations, where what is running is always exactly what the reviewed configuration says.

Note: Manage the platform through its declared configuration, never by manual changes to the live cluster. A manual fix that is not in the configuration will be quietly undone the next time the platform reconciles, or worse, it will persist as untracked drift.
الثالث

التنسيق بـ Kubernetes

تشغيل حاويةٍ واحدة سهل، وتشغيل مئاتٍ عبر آلاتٍ كثيرة بموثوقيةٍ ليس كذلك، وتلك مشكلة التنسيق التي يحلّها المنسِّق. وKubernetes هو المنصّة التي تقرّر أين تعمل الحاويات، وتُبقي العدد الصحيح حيًّا، وتُصلِح النظام حين ينكسر شيء.

الفكرة الجوهرية لـ Kubernetes هي الحالة المرغوبة التعريفية. فبدل إصدار أوامر خطوةً خطوة، تصف الحالة التي تريدها، كأن «شغّل خمس نُسخٍ من هذه الخدمة»، وتعمل المنصّة باستمرار لتطابق الواقعَ ذلك الوصف. فإن ماتت آلةٌ وأخذت معها نسختين، يلاحظ Kubernetes الفجوة بين المرغوب والفعلي ويبدأ بديلين في مكانٍ آخر، دون استدعاء أحد. وحلقة المقارنة والتصحيح المغلقة هذه مصدر سلوك الشفاء الذاتي للمنصّة.

  • الحالة المرغوبة: تُعلِن ما ينبغي أن يكون صحيحًا، وتُطابِق المنصّة الواقعَ به باستمرار.
  • الجدولة: تقرّر المنصّة على أي آلةٍ تعمل كل حاوية، مُحزِّمةً العمل بكفاءةٍ عبر العنقود.
  • الشفاء الذاتي: الحاويات الفاشلة تُعاد تشغيلها والمفقودة تُعاد جدولتها تلقائيًا، دون تدخّل يدوي.
  • التوسّع: عدد النُسخ يكبر ويصغر مع الطلب، تلقائيًا أو بأمر.

والنموذج التعريفي يحوّل كذلك كيف يُجرى التغيير. فلأن الحالة المرغوبة كلها موصوفةٌ في إعدادٍ، يمكن التحكّم بإصدار ذلك الإعداد ومراجعته وتطبيقه كالشيفرة، فيصير تغييرُ الإنتاج تعديلًا مُراجَعًا لملفٍّ لا فعلًا يدويًا محفوفًا على خادمٍ حيّ. وهذا أساس التشغيل الحديث القابل للتدقيق، حيث ما يعمل دائمًا هو بالضبط ما يقوله الإعداد المُراجَع.

ملاحظة: أدِر المنصّة عبر إعدادها المُعلَن، لا بتغييراتٍ يدوية على العنقود الحيّ. فإصلاحٌ يدوي ليس في الإعداد سيُلغى بهدوءٍ عند مطابقة المنصّة التالية، أو أسوأ، يبقى انزياحًا غير مُتتبَّع.
Four

Cluster Networking

In a cluster, containers are constantly created, destroyed, and moved between machines, so the network that connects them cannot rely on fixed addresses. Cluster networking is the layer that lets services find and reach each other reliably despite that constant change.

The problem is that a container's address is temporary, it changes every time the container is replaced, so hard-coding one is hopeless. The platform solves this with a stable abstraction, a service, which provides a single, unchanging name and address for a set of interchangeable container copies. Other parts of the system talk to the service by name, and the platform routes each request to a healthy copy behind it, so callers never need to know or care where the copies actually are or how many exist.

  • Service: a stable name and address in front of a changing set of container copies, with requests balanced across the healthy ones.
  • Ingress: the controlled entry point that lets outside traffic reach services inside the cluster, on defined routes.
  • Service discovery: the automatic mechanism by which services find each other by name rather than address.
  • Network policy: rules that control which services may talk to which, the network equivalent of least privilege.

Segmentation as a control

By default, everything in a cluster can often talk to everything else, which is convenient and dangerous. Network policy applies least privilege to traffic: each service is allowed to communicate only with the specific services it genuinely needs, so a compromise of one service cannot freely reach the rest. This internal segmentation is one of the most valuable and most neglected security controls in a cluster, because it turns a flat network where one breach spreads everywhere into a set of compartments that contain it.

Note: Design network policy as deny by default, allow by exception, exactly as you would access control. A cluster where every service can reach every other is one compromised container away from a cluster-wide incident.
الرابع

شبكة العنقود

في العنقود، تُنشَأ الحاويات وتُدمَّر وتُنقَل بين الآلات باستمرار، فلا تستطيع الشبكة التي تصلها الاعتماد على عناوين ثابتة. وشبكة العنقود هي الطبقة التي تتيح للخدمات إيجاد بعضها والوصول إليها بموثوقيةٍ رغم ذلك التغيّر الدائم.

المشكلة أن عنوان الحاوية مؤقّت، يتغيّر كل مرةٍ تُستبدَل، فتثبيته عبثٌ. وتحلّ المنصّة هذا بتجريدٍ ثابت، «خدمة»، تقدّم اسمًا وعنوانًا واحدًا لا يتغيّر لمجموعةٍ من نُسخ الحاويات المتبادَلة. فتحادث بقية أجزاء النظام الخدمةَ بالاسم، وتوجّه المنصّة كل طلبٍ لنسخةٍ سليمة خلفها، فلا يحتاج المتّصلون أبدًا لمعرفة أو الاهتمام بأين النُسخ فعلًا أو كم عددها.

  • الخدمة: اسمٌ وعنوانٌ ثابت أمام مجموعةٍ متغيّرة من نُسخ الحاويات، بموازنة الطلبات عبر السليمة.
  • المدخل (Ingress): نقطة الدخول المضبوطة التي تتيح لحركة الخارج بلوغ الخدمات داخل العنقود، على مساراتٍ محدَّدة.
  • اكتشاف الخدمات: الآلية التلقائية التي تجد بها الخدمات بعضها بالاسم لا بالعنوان.
  • سياسة الشبكة: قواعد تتحكّم بأي الخدمات يجوز أن تحادث أيًّا، وهي مكافئ أقلّ الصلاحية للشبكة.

التجزئة كضابط

افتراضيًا، كثيرًا ما يستطيع كل شيءٍ في العنقود محادثة كل شيءٍ آخر، وهو مريحٌ وخطر. وسياسة الشبكة تطبّق أقلّ الصلاحية على الحركة: يُسمَح لكل خدمةٍ بالتواصل فقط مع الخدمات المحدَّدة التي تحتاجها فعلًا، فلا يستطيع اختراق خدمةٍ بلوغ البقية بحرّية. وهذه التجزئة الداخلية من أثمن الضوابط الأمنية وأكثرها إهمالًا في العنقود، لأنها تحوّل شبكةً مسطّحة ينتشر فيها اختراقٌ واحد لكل مكان إلى مقصوراتٍ تحتويه.

ملاحظة: صمّم سياسة الشبكة كمنعٍ افتراضي وسماحٍ بالاستثناء، تمامًا كالتحكّم بالوصول. فعنقودٌ تصل فيه كل خدمةٍ لكل أخرى على بُعد حاويةٍ مخترَقة واحدة من حادثةٍ تعمّ العنقود.
Five

Reliability & Scaling

The promise of a cloud-native platform is that it keeps services running through failure and adjusts to load without a person in the loop. That promise is delivered by a few mechanisms working together, and it is only as good as how they are configured.

Self-healing depends on the platform knowing whether a container is actually working, not just running. Health checks are the small probes the application exposes so the platform can ask, are you alive, and are you ready to serve. A container that fails its check is restarted or taken out of rotation automatically, so a hung process is replaced rather than left to silently drop requests. Without accurate health checks, self-healing is blind, and the platform will happily send traffic to a broken copy.

  • Health checks: probes that tell the platform whether a copy is alive and ready, so broken ones are replaced automatically.
  • Replication: running multiple copies so the loss of one does not interrupt the service.
  • Autoscaling: adding copies when load rises and removing them when it falls, matching capacity to demand.
  • Rolling updates: replacing copies gradually so a new version is deployed with no downtime and can be rolled back if it misbehaves.

Rolling updates deserve emphasis because they change the economics of releasing software. Instead of a risky, all-at-once cutover during a maintenance window, a new version replaces the old copies a few at a time while the service keeps serving, and if the new version fails its health checks, the rollout stops and reverses automatically. This makes deployment routine and low-risk, which in turn lets an organization release small changes often rather than large changes rarely, the pattern that correlates with both speed and stability.

Note: The platform's automation is only as smart as its health checks. Invest in accurate liveness and readiness probes, because they are what turn running into working in the platform's eyes.
الخامس

الموثوقية والتوسّع

وعد المنصّة السحابية الأصيلة أنها تُبقي الخدمات عاملةً خلال الفشل وتتكيّف مع الحمل دون شخصٍ في الحلقة. ويُسلَّم ذلك الوعد بآلياتٍ قليلة تعمل معًا، وهو جيّدٌ بقدر كيفية إعدادها فقط.

الشفاء الذاتي يعتمد على معرفة المنصّة هل الحاوية تعمل فعلًا، لا مجرد أنها مُشغَّلة. وفحوص الصحّة هي المجسّات الصغيرة التي يكشفها التطبيق لتسأل المنصّة: هل أنت حيّ، وهل أنت جاهز للخدمة. وحاويةٌ تفشل فحصها تُعاد تشغيلها أو تُخرَج من الدوران تلقائيًا، فتُستبدَل عمليةٌ معلَّقة بدل تركها تُسقِط الطلبات بصمت. وبلا فحوص صحّةٍ دقيقة، الشفاء الذاتي أعمى، وترسل المنصّة الحركة بسرورٍ لنسخةٍ معطوبة.

  • فحوص الصحّة: مجسّاتٌ تخبر المنصّة هل نسخةٌ حيّة وجاهزة، فتُستبدَل المعطوبة تلقائيًا.
  • التكرار: تشغيل نُسخٍ متعددة فلا يقطع فقدُ واحدةٍ الخدمة.
  • التوسّع التلقائي: إضافة نُسخٍ حين يرتفع الحمل وإزالتها حين يهبط، مطابقةً السعة للطلب.
  • التحديثات المتدحرجة: استبدال النُسخ تدريجيًا فتُنشَر نسخةٌ جديدة بلا انقطاعٍ ويمكن التراجع إن أساءت.

وتستحق التحديثات المتدحرجة تأكيدًا لأنها تغيّر اقتصاد إصدار البرمجيات. فبدل تحوّلٍ محفوف دفعةً واحدة في نافذة صيانة، تستبدل نسخةٌ جديدة القديمةَ قليلًا قليلًا بينما تبقى الخدمة تخدم، وإن فشلت الجديدة فحوصها، يتوقّف الطرح ويتراجع تلقائيًا. وهذا يجعل النشر روتينيًا منخفض الخطر، مما يتيح للمنشأة إصدار تغييراتٍ صغيرة كثيرًا بدل كبيرةٍ نادرًا، وهو النمط المرتبط بالسرعة والاستقرار معًا.

ملاحظة: أتمتة المنصّة ذكيّةٌ بقدر فحوص صحّتها. استثمر في مجسّات حياةٍ وجاهزيةٍ دقيقة، فهي ما يحوّل «مُشغَّل» إلى «عامل» في عين المنصّة.
Six

Platform Security & Observability

A powerful automated platform is a powerful target, so cloud-native security applies the same least-privilege and monitoring principles as the security frameworks, adapted to the platform's specifics. Two concerns dominate: limiting what each part can do, and being able to see what is happening.

Least privilege runs through the platform at every level. Each container should run with only the permissions it needs, not as an all-powerful process, so a compromised container is limited in what it can do. Access to the platform's control system should be scoped by role, so people and services can change only what they are meant to. Secrets, the passwords and keys applications need, should be managed by the platform and injected securely rather than baked into container images where they leak. And the container images themselves are a supply chain that must be vetted, because an image built from a compromised base carries that compromise into the cluster.

  • Least-privilege workloads: containers run with minimal permissions, never as unrestricted processes.
  • Scoped platform access: role-based control over who and what can change the cluster.
  • Managed secrets: credentials handled by the platform and injected securely, never embedded in images.
  • Image supply chain: container images vetted and scanned, because a trusted image is a trusted foundation.

Observability

An automated platform that you cannot see into is impossible to operate or trust. Observability is the ability to understand what the system is doing from the outside, through three kinds of signal: metrics that measure how it is performing, logs that record what happened, and traces that follow a single request across the many services it touches. Together they turn an opaque, distributed system into one you can diagnose, so that when something goes wrong you can find where and why rather than guessing.

Bottom line: a cloud-native platform delivers resilience and scale through containers, declarative orchestration, and automated healing, and it stays safe and operable only when least privilege, network segmentation, and observability are built in from the start.
السادس

أمن المنصّة والرصد

منصّةٌ مُؤتمَتة قوية هدفٌ قوي، فأمن السحابي الأصيل يطبّق مبادئ أقلّ الصلاحية والمراقبة نفسها من أطر الأمن، مُكيَّفةً لخصائص المنصّة. وهاجسان يسودان: تقييد ما يستطيع كل جزءٍ فعله، والقدرة على رؤية ما يجري.

أقلّ الصلاحية يسري في المنصّة عند كل مستوى. فينبغي أن تعمل كل حاويةٍ بالصلاحيات التي تحتاجها فقط، لا كعمليةٍ كليّة القدرة، فتكون الحاوية المخترَقة محدودةً فيما تفعل. والوصول لنظام تحكّم المنصّة ينبغي تحديده بالدور، فيغيّر الناس والخدمات فقط ما يُقصَد لهم. والأسرار، أي كلمات المرور والمفاتيح التي تحتاجها التطبيقات، ينبغي أن تديرها المنصّة وتُحقَن بأمانٍ لا أن تُخبَز في صور الحاويات حيث تتسرّب. وصور الحاويات نفسها سلسلة إمدادٍ يجب فحصها، لأن صورةً بُنيت من أساسٍ مخترَق تحمل ذلك الاختراق إلى العنقود.

  • أحمالٌ بأقلّ صلاحية: الحاويات تعمل بصلاحياتٍ دنيا، لا كعملياتٍ غير مقيَّدة.
  • وصولٌ محدَّد للمنصّة: تحكّمٌ بالأدوار في من وما يستطيع تغيير العنقود.
  • أسرارٌ مُدارة: بيانات دخولٍ تديرها المنصّة وتُحقَن بأمان، لا تُضمَّن في الصور.
  • سلسلة إمداد الصور: صور الحاويات مفحوصة وممسوحة، لأن صورةً موثوقة أساسٌ موثوق.

الرصد

منصّةٌ مُؤتمَتة لا تستطيع الرؤية داخلها يستحيل تشغيلها أو الثقة بها. والرصد هو القدرة على فهم ما يفعله النظام من الخارج، عبر ثلاثة أنواع إشارة: مقاييس تقيس كيف يؤدّي، وسجلات تسجّل ما حدث، وتتبّعاتٌ تلاحق طلبًا واحدًا عبر الخدمات الكثيرة التي يمسّها. وهي معًا تحوّل نظامًا موزَّعًا غامضًا إلى قابلٍ للتشخيص، فحين يسوء شيء تجد أين ولماذا لا أن تخمّن.

الخلاصة: المنصّة السحابية الأصيلة تسلّم المرونة والنطاق عبر الحاويات والتنسيق التعريفي والشفاء المُؤتمَت، وتبقى آمنةً وقابلةً للتشغيل فقط حين تُبنى أقلّ الصلاحية وتجزئة الشبكة والرصد من البداية.
Seven

Key Takeaways & References

Cloud-native platforms deliver resilient, scalable operations by treating infrastructure as automated, declarative, and disposable, governed with the same security discipline as everything else.

  • Package applications as immutable containers so they run identically everywhere and heal by replacement.
  • Orchestrate with declarative desired state, and manage the platform through version-controlled configuration, not manual changes.
  • Give services stable names, and segment traffic with network policy as least privilege for the network.
  • Rely on health checks, replication, autoscaling, and rolling updates for reliability and low-risk releases.
  • Build in least privilege, managed secrets, a vetted image supply chain, and observability from the start.

References

السابع

الخلاصات والمراجع

المنصّات السحابية الأصيلة تسلّم تشغيلًا مرنًا قابلًا للتوسّع بمعاملة البنية التحتية كمُؤتمَتة وتعريفية وقابلة للاستبدال، محوكَمةً بانضباط الأمن نفسه كأي شيءٍ آخر.

  • احزم التطبيقات كحاوياتٍ غير قابلة للتغيير فتعمل بتطابقٍ في كل مكان وتشفى بالاستبدال.
  • نسّق بالحالة المرغوبة التعريفية، وأدِر المنصّة عبر إعدادٍ مُتحكَّم بإصداره لا بتغييراتٍ يدوية.
  • امنح الخدمات أسماءً ثابتة، وجزّئ الحركة بسياسة الشبكة كأقلّ صلاحيةٍ للشبكة.
  • اعتمد على فحوص الصحّة والتكرار والتوسّع التلقائي والتحديثات المتدحرجة للموثوقية والإصدار منخفض الخطر.
  • ابنِ أقلّ الصلاحية والأسرار المُدارة وسلسلة إمداد صورٍ مفحوصة والرصد من البداية.

المراجع