Latency budget, exercises and summaryميزانية زمن الاستجابة والتمارين والخلاصة

Picture a video call. When you speak, your voice should reach the other person quickly enough that the two of you do not talk over each other. The ITU-T telephony standard G.114 puts a number on “quickly enough”: if one-way delay stays below 150 ms, most applications experience essentially transparent interactivity, and 400 ms should not be exceeded for general network planning. So for one direction of that call, you have about 150 ms to spend, and every hop, queue and processing step you place in the path takes some of it.

تخيّل مكالمة فيديو. عندما تتكلم، يجب أن يصل صوتك إلى الطرف الآخر بسرعة كافية كي لا يقاطع أحدكما الآخر. يضع معيار الاتصالات الهاتفية ITU-T G.114 رقمًا لعبارة “بسرعة كافية”: إذا بقي التأخير في اتجاه واحد أقل من 150 ms فإن معظم التطبيقات تحظى بتفاعل شفاف عمليًا، ولا ينبغي تجاوز 400 ms في التخطيط العام للشبكات. إذن في اتجاه واحد من تلك المكالمة لديك نحو 150 ms لتنفقها، وكل قفزة (hop) وكل طابور انتظار وكل خطوة معالجة تضعها في المسار تأخذ جزءًا منها.

That allowance is the Latency budget. Its upper limit is written τ (tau): the maximum acceptable end-to-end Response time (RT) of a service. The budget is the interval $[0, \tau]$, and a design is inside it when $RT \le \tau$. Notice who sets τ. It is not the network, and it is not the hardware you happen to own. It comes from the user and the application: human perception for a chat or a game, physics for a headset that must keep up with your head. The network and the servers only decide how much of the budget you spend.

هذا المقدار المسموح به هو latency budget (ميزانية التأخير). ويُكتب حدّه الأعلى τ (تاو): أقصى response time (زمن استجابة) مقبول للخدمة من الطرف إلى الطرف. الميزانية هي الفترة $[0, \tau]$، ويكون التصميم داخلها عندما $RT \le \tau$. لاحظ من يحدد τ. ليست الشبكة، وليست الأجهزة التي تصادف أنك تملكها. إنها تأتي من المستخدم والتطبيق: الإدراك البشري في حالة المحادثة أو اللعبة، والفيزياء في حالة نظارة رأس يجب أن تواكب حركة رأسك. أما الشبكة والخوادم فتحدد فقط مقدار ما تنفقه من الميزانية.

What counts against the budgetما الذي يُخصم من الميزانية

It is tempting to compare τ with the Latency to a layer: the client reaches the edge with small latency, the fog with medium latency and the cloud with large latency. But latency is only part of the bill. Recall from part 9 that response time is the trip out, plus the Processing time (PT) at the server, plus the trip back:

من المغري مقارنة τ بـlatency (التأخير) إلى طبقة ما: يصل العميل إلى الحافة بتأخير صغير، وإلى الضباب بتأخير متوسط، وإلى السحابة بتأخير كبير. لكن التأخير ليس إلا جزءًا من الفاتورة. تذكّر من الجزء 9 أن زمن الاستجابة هو رحلة الذهاب، زائد processing time (وقت المعالجة) على الخادم، زائد رحلة العودة:

A per-layer latency figure is one-way, so never compare a single arrow directly with τ. When a pipeline splits its tasks across several layers, every hop between them joins the sum as well, together with every task’s processing time. The gauge below makes the consequence visible: the same request, three placements, one deadline.

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

The last step of that example hides the real tension of this whole part. Moving closer shrinks the latency terms, but closer sites are smaller, so the processing term can grow. Neither “always edge” nor “always cloud” is a rule; the inequality decides. The simulator lets you feel that tension. Its three tasks are an image resize, object detection and drawing boxes, and the presets map them to different layers. Set τ to 100 ms and find the one preset that stays in budget.

الخطوة الأخيرة في ذلك المثال تخفي التوتر الحقيقي في هذا الجزء كله. الاقتراب يقلّص حدود التأخير، لكن المواقع الأقرب أصغر، لذلك قد يكبر حد المعالجة. لا “الحافة دائمًا” ولا “السحابة دائمًا” قاعدة؛ المتباينة هي التي تحسم. يتيح لك المحاكي أن تشعر بهذا التوتر. مهامه الثلاث هي تغيير حجم صورة، واكتشاف الكائنات (object detection)، ورسم المربعات، والإعدادات المسبقة (presets) توزّعها على طبقات مختلفة. اضبط τ على 100 ms وابحث عن الإعداد المسبق الوحيد الذي يبقى داخل الميزانية.

Where real values of τ come fromمن أين تأتي القيم الحقيقية لـ τ

Because τ belongs to the user, you should never invent it. Studies of human perception and device physics give defensible numbers, and they span four orders of magnitude: a headset that must track your head has a couple of tens of milliseconds, a conversation has about a hundred and fifty, a recognition assistant has most of a second, and a user waiting for a report keeps attention for about ten seconds. The table collects the values this course relies on, roughly from the strictest to the most relaxed. You will use every row in the design exercises that follow.

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

One more rule turns these numbers into a real test. A budget is a promise about the experience of users, and users remember the slow requests, not the average one. So published budgets are stated at a percentile.

قاعدة أخرى تحوّل هذه الأرقام إلى اختبار حقيقي. الميزانية وعد بشأن تجربة المستخدمين، والمستخدمون يتذكرون الطلبات البطيئة لا الطلب المتوسط. لذلك تُذكر الميزانيات المنشورة عند مئين (percentile).

Knowing the inequality is not the same as designing a system. Real services are not one request and one server; they are pipelines of tasks with different needs. Design questions of this kind have no single right answer, but they do have a right method, and it is the same four steps every time: list the tasks, set τ per task, place each task on a layer, then check Response time (RT) and the trade-offs.

معرفة المتباينة ليست مثل تصميم نظام. الخدمات الحقيقية ليست طلبًا واحدًا وخادمًا واحدًا؛ إنها خطوط معالجة من مهام ذات احتياجات مختلفة. أسئلة التصميم من هذا النوع ليس لها إجابة صحيحة واحدة، لكن لها طريقة صحيحة، وهي الخطوات الأربع نفسها في كل مرة: اسرد المهام، وحدّد τ لكل مهمة، وضع كل مهمة على طبقة، ثم تحقّق من response time ومن المفاضلات.

Smart glasses are a good first case because every constraint pulls hard. The device is small, runs on a tiny battery and sits on your face, so it cannot get hot. Yet the job, recognizing the faces and objects in front of you, is heavy vision computing. Before reading on, take a minute and list the tasks a face-recognition assistant on glasses would need. That effort is what makes the model answer stick.

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

Step 4 is worth a second look, because it shows the method working honestly. The cloudlet design does not magically hit every bound: it meets the loose face-recognition deadline and misses the tight one. That is a real, measured result at the tail, and it is exactly the kind of statement a good design report makes. The cloud alternative misses by more, so the edge is the better placement, not a perfect one.

الخطوة 4 تستحق نظرة ثانية، لأنها تُظهر الطريقة وهي تعمل بأمانة. تصميم الـ cloudlet لا يحقق كل حد بطريقة سحرية: إنه يحقق المهلة المتساهلة للتعرف على الوجوه ويخفق في الصارمة. هذه نتيجة حقيقية مقاسة عند الذيل (tail)، وهي بالضبط نوع العبارة التي يكتبها تقرير التصميم الجيد. بديل السحابة يخفق بفارق أكبر، لذلك فالحافة هي التوزيع الأفضل، لا التوزيع المثالي.

The trade-offs behind the placementالمفاضلات وراء هذا التوزيع

Latency is not the only reason for this split. Shi et al., summarizing Ha et al.’s cloudlet study for wearable cognitive assistance, report that offloading can cut energy use by 30 to 40%, which matters on a device with a battery the size of a stick of gum. They also argue that processing at the edge protects privacy better than uploading raw data to the cloud, and faces are among the most sensitive data there is.

التأخير ليس السبب الوحيد لهذا التقسيم. فـ Shi et al.، في تلخيصهم لدراسة Ha et al. عن الـ cloudlet للمساعدة المعرفية القابلة للارتداء، يذكرون أن نقل المعالجة قد يخفض استهلاك الطاقة بنسبة 30 إلى 40%، وهذا مهم في جهاز ببطارية بحجم قطعة علكة. ويرون أيضًا أن المعالجة على الحافة تحمي الخصوصية أفضل من رفع البيانات الخام إلى السحابة، والوجوه من أكثر البيانات حساسية على الإطلاق.

The price is dependence. The glasses now need a working wireless link and an edge site near wherever the wearer walks. Edge sites are few and expensive, so scalability and reach are limited. The cloud has global reach and elastic capacity, but it misses the tight end of the budget. That is exactly why the design keeps both, and why every placement you propose should name what it gains and what it gives up.

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

Picture a warehouse worker holding a tablet. Overlays mark the next shelves to pick from, a ring counts progress, and a green arrow on the floor says the target is 12 m ahead. It looks like one app. For design purposes it is at least six tasks with deadlines that range from milliseconds to hours. That is the central idea of this concept: τ belongs to a task, not to an app, and a single app routinely needs every layer of the continuum at once.

تخيّل عاملًا في مستودع يحمل جهازًا لوحيًا. طبقات مضافة تحدد الرفوف التالية التي يلتقط منها، وحلقة تعدّ التقدم، وسهم أخضر على الأرض يقول إن الهدف على بعد 12 m أمامه. يبدو تطبيقًا واحدًا. لكنه لأغراض التصميم ست مهام على الأقل، بمهل تتراوح من الملّي ثانية إلى الساعات. هذه هي الفكرة المركزية في هذا المفهوم: τ تخص المهمة لا التطبيق، وكثيرًا ما يحتاج تطبيق واحد إلى كل طبقات المتصل في الوقت نفسه.

Motion-to-photon: the tightest budget in the courseMotion-to-photon: أضيق ميزانية في المقرر

Both augmented and virtual reality are governed by one deadline, so it pays to understand it before designing either. When you move your head, or the tablet, the image must move with you. The time from the movement to the matching light leaving the display is motion-to-photon (MTP) latency. If it is too long, your eyes and your inner ear disagree. Elbamby et al. explain that high MTP sends conflicting signals to the vestibulo-ocular reflex, which can cause motion sickness. In AR the failure is also visible: a virtual label that lags behind a real shelf is noticed at once, because the real world is the reference.

الواقع المعزز والواقع الافتراضي كلاهما محكوم بمهلة واحدة، لذلك يفيدك أن تفهمها قبل تصميم أي منهما. عندما تحرك رأسك، أو الجهاز اللوحي، يجب أن تتحرك الصورة معك. الزمن من الحركة إلى خروج الضوء المطابق من الشاشة هو تأخير motion-to-photon (MTP). إذا طال، تختلف عيناك مع أذنك الداخلية. يشرح Elbamby et al. أن ارتفاع MTP يرسل إشارات متعارضة إلى المنعكس الدهليزي العيني (vestibulo-ocular reflex)، وهذا قد يسبب دوار الحركة. وفي AR يكون الفشل مرئيًا أيضًا: التسمية الافتراضية التي تتأخر عن رف حقيقي تُلاحظ فورًا، لأن العالم الحقيقي هو المرجع.

The research community broadly agrees on the ceiling. Elbamby et al. report a broad consensus that MTP must stay below 15 to 20 ms. RFC 9699 uses 20 ms at most for XR as a whole, and shows how little of it is left for computing once the display has taken its share:

يتفق المجتمع البحثي إلى حد كبير على السقف. يذكر Elbamby et al. وجود إجماع واسع على أن MTP يجب أن يبقى أقل من 15 إلى 20 ms. ويستخدم RFC 9699 حدًا أقصاه 20 ms لـ XR ككل، ويبيّن كم يتبقى منه للحوسبة بعد أن تأخذ الشاشة نصيبها:

Estimates of the split vary. Elbamby et al. put display delay at about 10 to 15 ms, expected to fall to 5 ms, which leaves 14 ms for computing and communication. Either way, only a few milliseconds remain for any network trip, and a trip to a distant cloud does not fit even once.

تتفاوت تقديرات هذا التقسيم. يضع Elbamby et al. تأخير الشاشة عند نحو 10 إلى 15 ms، مع توقع انخفاضه إلى 5 ms، وهذا يترك 14 ms للحوسبة والاتصال. وفي الحالتين لا يتبقى إلا بضع ملّي ثوانٍ لأي رحلة عبر الشبكة، ورحلة إلى سحابة بعيدة لا تتسع حتى مرة واحدة.

The standard escape is reprojection, also called time warp: the device takes the last rendered frame and shifts it to match the newest head pose just before display. Reprojection is cheap, so it can run locally inside the MTP budget, and it means a heavy frame rendered elsewhere can arrive a little late without the image lagging behind your head. This one technique is what lets the heavy work leave the device at all.

المخرج المعتاد هو إعادة الإسقاط (reprojection)، وتسمى أيضًا time warp: يأخذ الجهاز آخر إطار مرسوم ويزيحه ليطابق أحدث وضعية للرأس قبيل العرض مباشرة. إعادة الإسقاط رخيصة، لذلك يمكن أن تعمل محليًا داخل ميزانية MTP، وهي تعني أن إطارًا ثقيلًا رُسم في مكان آخر يمكن أن يصل متأخرًا قليلًا من دون أن تتأخر الصورة عن رأسك. هذه التقنية الواحدة هي ما يسمح للعمل الثقيل بمغادرة الجهاز أصلًا.

Warehouse AR: six tasks, four layersالواقع المعزز في المستودع: ست مهام، أربع طبقات

Notice the new role of the fog layer. Nothing in the smart-glasses design was shared between users, but a warehouse is a team. The pick list and the route optimizer serve every picker in the building, their deadline is around a second rather than a frame, and keeping them on site avoids sending every lookup to the cloud. Shared site state is the natural job of fog.

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

Interactive VR: every pixel under the deadlineالواقع الافتراضي التفاعلي: كل بكسل تحت المهلة

Virtual reality shares the same budget, but raises the stakes: in AR only the overlay depends on MTP, while in VR every pixel you see does. The same four steps apply, and the same pattern appears, with a GPU-hungry rendering task pulled between a light headset and a distant data center.

يتشارك الواقع الافتراضي الميزانية نفسها، لكنه يرفع الرهان: في AR تعتمد الطبقة المضافة وحدها على MTP، أما في VR فكل بكسل تراه يعتمد عليه. تنطبق الخطوات الأربع نفسها، ويظهر النمط نفسه، مع مهمة رسم شرهة لـ GPU تتجاذبها نظارة رأس خفيفة ومركز بيانات بعيد.

The trade-offs are sharp. An edge GPU per site is expensive, so each site serves a limited number of users. The alternative, a headset tethered by cable to a local PC, meets the budget but gives up mobility. In Latency budget terms, every design is judged the same way: does the per-frame Response time (RT) fit inside MTP, measured at the tail rather than the average?

المفاضلات حادة. وجود GPU طرفي في كل موقع مكلف، لذلك يخدم كل موقع عددًا محدودًا من المستخدمين. والبديل، نظارة رأس موصولة بكابل إلى حاسوب محلي، يحقق الميزانية لكنه يتنازل عن حرية التنقل. وبلغة latency budget، يُحكم على كل تصميم بالطريقة نفسها: هل يتسع response time لكل إطار داخل MTP، مقاسًا عند الذيل لا المتوسط؟

Put the three designs side by side and one pattern falls out. The lecturer’s reference answers below are a compact version of the tables you built above. If you placed recognition, sensor interaction and rendering at the edge and storage and analytics in the cloud, you have the same architecture.

ضع التصاميم الثلاثة جنبًا إلى جنب وسيظهر نمط واحد. الإجابات المرجعية للمحاضر أدناه نسخة مختصرة من الجداول التي بنيتها أعلاه. إذا وضعت التعرف والتفاعل مع المستشعرات والرسم على الحافة، والتخزين والتحليلات في السحابة، فلديك المعمارية نفسها.

Every app keeps the Cloud, and every app adds the Edge. What decides the Mapping of a task is a single comparison: is its deadline shorter than the cloud round trip plus the processing it needs? Recognizing a face, reacting to a sensor and drawing the next frame all have deadlines the cloud cannot meet. Storing photos, crunching datasets and training models have none, and they want exactly what the cloud is good at: scale, durability and reach.

كل تطبيق يحتفظ بـ cloud، وكل تطبيق يضيف edge. ما يحدد mapping (توزيع) المهمة هو مقارنة واحدة: هل مهلتها أقصر من رحلة الذهاب والعودة إلى السحابة زائد المعالجة التي تحتاجها؟ التعرف على وجه، والاستجابة لمستشعر، ورسم الإطار التالي، كلها لها مهل لا تستطيع السحابة الوفاء بها. أما تخزين الصور ومعالجة مجموعات البيانات وتدريب النماذج فليس لها مهل، وهي تريد بالضبط ما تجيده السحابة: الحجم والمتانة والانتشار.

Latency is the strongest force in that split, but not the only one. Satyanarayanan’s SEC 2017 keynote gives three reasons to use the edge, and all three appeared in the exercises. Latency, in both mean and tail, drives rendering and recognition. Bandwidth, both peak and average, explains why glasses and AR tablets should not stream raw video to a distant data center. Privacy, which he calls an exposure firewall for the IoT, explains keeping faces on a nearby server.

التأخير أقوى قوة في هذا التقسيم، لكنه ليس الوحيد. تعطي كلمة Satyanarayanan الرئيسية في SEC 2017 ثلاثة أسباب لاستخدام الحافة، وقد ظهرت الثلاثة كلها في التمارين. التأخير، بمتوسطه وذيله، يحرّك قرار الرسم والتعرف. وعرض النطاق (bandwidth)، في ذروته ومتوسطه، يفسّر لماذا لا ينبغي للنظارات وأجهزة AR اللوحية أن تبث فيديو خامًا إلى مركز بيانات بعيد. والخصوصية، التي يسميها جدار حماية من الانكشاف (exposure firewall) لإنترنت الأشياء، تفسّر إبقاء الوجوه على خادم قريب.

The whole lecture in one pictureالمحاضرة كلها في صورة واحدة

That pattern is the lecture’s conclusion in miniature. Before, you architected an application on a single Server layer: pick a machine, deploy the backend, done. Now, because data, IoT devices and machine learning produce and consume so much close to the user, the server is spread across the Edge-to-cloud (E2C) continuum.

هذا النمط هو خلاصة المحاضرة في صورة مصغّرة. في السابق كنت تصمم معمارية التطبيق على server layer (طبقة خادم) واحدة: اختر جهازًا، وانشر الخلفية، وانتهى الأمر. أما الآن، فلأن البيانات وأجهزة إنترنت الأشياء وتعلم الآلة تنتج وتستهلك الكثير قرب المستخدم، صار الخادم موزعًا على E2C continuum.

That changes the unit of design. You no longer place a server; you place each task of each service Service pipeline. And a placement needs a criterion. The lecture chooses response time, written as a function of Latency and Processing time (PT). Its concrete form generalizes the budget condition from the start of this part to a pipeline that crosses several layers:

هذا يغيّر وحدة التصميم. لم تعد تضع خادمًا؛ بل تضع كل مهمة من كل pipeline (خط معالجة) لخدمة. والتوزيع يحتاج إلى معيار. تختار المحاضرة زمن الاستجابة، مكتوبًا كدالة في latency وprocessing time. وصيغته الملموسة تعمّم شرط الميزانية من بداية هذا الجزء على خط معالجة يعبر عدة طبقات:

Response time is the right criterion because it is what users actually experience, and because it keeps both levers in view. A faster server only shrinks the processing terms; placement is what shrinks the latency terms. Every argument in this part, from the fog example that missed by 10 ms to the headset that cannot afford one 4G round trip, was an argument about which lever was available.

زمن الاستجابة هو المعيار الصحيح لأنه ما يعيشه المستخدمون فعلًا، ولأنه يبقي الرافعتين كلتيهما في الصورة. الخادم الأسرع يقلّص حدود المعالجة فقط؛ والتوزيع هو ما يقلّص حدود التأخير. كل حجة في هذا الجزء، من مثال الضباب الذي أخفق بفارق 10 ms إلى نظارة الرأس التي لا تحتمل رحلة ذهاب وعودة واحدة عبر 4G، كانت حجة حول أي رافعة كانت متاحة.

The design loopحلقة التصميم

1. Break the service into a pipeline of tasks.قسّم الخدمة إلى خط معالجة من المهام.
2. Set τ for each task from a published source.حدّد τ لكل مهمة من مصدر منشور.
3. Choose a Mapping of tasks to Device, Edge, Fog and Cloud.اختر mapping (توزيعًا) للمهام على device وedge وfog وcloud.
4. Compute RT from latency and processing time, at a percentile.احسب RT من التأخير ووقت المعالجة، عند مئين (percentile).
5. Check RT ≤ τ and weigh battery, privacy, cost and reach. If it fails, remap and repeat.تحقّق من RT ≤ τ ووازن البطارية والخصوصية والتكلفة والانتشار. إذا فشل، أعد التوزيع وكرّر.

Where the course goes nextإلى أين يتجه المقرر بعد ذلك

Placing a task on a layer is still abstract. In practice it means running that task inside a virtual machine or a container on that layer. Satyanarayanan’s keynote notes that cloudlets can run lighter-weight containers such as Docker inside VMs, which is exactly what the virtualization and container lectures build.

وضع مهمة على طبقة لا يزال أمرًا مجردًا. عمليًا يعني تشغيل تلك المهمة داخل آلة افتراضية (VM) أو حاوية (container) على تلك الطبقة. تشير كلمة Satyanarayanan الرئيسية إلى أن الـ cloudlet يمكنها تشغيل حاويات أخف وزنًا مثل Docker داخل الآلات الافتراضية، وهذا بالضبط ما تبنيه محاضرات المحاكاة الافتراضية والحاويات.

Renting those layers means choosing a cloud model. NIST SP 800-145 defines the service models (SaaS, PaaS, IaaS) and the deployment models (private, community, public, hybrid). Those definitions are the subject of the cloud models lecture, and they decide who operates each layer in your mapping.

استئجار تلك الطبقات يعني اختيار نموذج سحابي. تعرّف وثيقة NIST SP 800-145 نماذج الخدمة (SaaS وPaaS وIaaS) ونماذج النشر (خاصة، ومجتمعية، وعامة، وهجينة). هذه التعريفات موضوع محاضرة النماذج السحابية، وهي التي تحدد من يشغّل كل طبقة في توزيعك.