Едет себе водила-дальнобойщик. В кузове фуры...

Едет себе водила-дальнобойщик. В кузове фуры груз черных шаров для боулинга. Думает водила, в лом мне самому будет эту фуру разгружать, заеду-ка я в негритянский квартал, найму себе пару оболтусов за 5 баксов, они мне всё и разгрузят. Сказано-сделано, заехал в Гарлем, захватил пару 8-летних негритят, те свои велосипеды в кузов покидали и сами туда залезли. Едут, все довольны. Тут останавливает водилу полиция. Один коп грузовик осматривает, а другой в кузов полез. 1-ый коп (выписывая штраф):
- Мистер Джонс, вы нарушили правила дорожного движения, у вас не горят фары, просрочены номера и куча других мелких нарушений.
2-ой коп спрыгивает на землю, подбегает к водиле и кричит:
- Немедленно по газам и не останавливаться, пока не выедешь за пределы штата.
1-ый коп:
- Сейчас ему штраф выпишу и он поедет, куда торопиться?
2-ой коп:
- Слушай что я сказал, у него в кузове яйца негров, два вылупились, и они уже успели спиздить велосипед.

shabunov_oleg_lab_8/README.md

@@ -0,0 +1,21 @@
+# Лабораторная работа №8 - Устройство распределенных систем
+
+**Цель**: написать небольшое эссе своими словами, затрагивая следующие вопросы:
+
+1. Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
+2. Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
+3. Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
+4. Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
+5. Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
+
+## Эссе
+
+Современные сложные сервисы, такие как социальная сеть ВКонтакте, строятся в "распределённом" стиле потому, что одному монолитному приложению становится слишком тяжело справляться с огромным количеством функций и пользователей. Когда система разбита на множество маленьких сервисов, каждый из которых отвечает только за свою часть логики, её проще масштабировать, обновлять и поддерживать. Если какой-то сервис выходит из строя, вся система при этом не «падает», а продолжает работать, что делает архитектуру более устойчивой и гибкой.
+
+Со временем количество таких сервисов растёт, ими нужно управлять, размещать их на серверах, перезапускать при сбоях и следить за их состоянием. Чтобы не делать это вручную, были придуманы системы оркестрации, такие как Kubernetes. Они автоматически распределяют контейнеры по ресурсам, помогают масштабировать нужные компоненты и контролируют их работу. С одной стороны, это упрощает жизнь разработчикам: не нужно вручную поднимать десятки серверов. С другой стороны, сама система оркестрации довольно сложная, и её нужно уметь правильно настраивать, поэтому порог входа становится выше.
+
+В распределённых системах часто используются очереди сообщений. Они нужны для того, чтобы сервисы могли общаться друг с другом не напрямую, а через надёжного посредника. Сообщением может быть что угодно: запрос на обработку изображения, уведомление о новом заказе или данные, которые одному сервису нужно передать другому. Очереди позволяют сглаживать нагрузку — если сообщений много, они просто накапливаются, а сервис-потребитель обрабатывает их постепенно, со своей скоростью.
+
+Распределённые приложения дают множество преимуществ: они масштабируются, более устойчивы к сбоям, их можно развивать по частям, не трогая всю систему целиком. Но есть и минусы — сложность инфраструктуры растёт, нужно отслеживать взаимодействие сервисов, учитывать сетевые задержки и продумывать логику обмена данными.
+
+Использование параллельных вычислений в распределённых системах оправдано далеко не всегда. Оно нужно там, где задачи действительно независимы друг от друга и могут выполняться одновременно: обработка больших объёмов данных, работа рекомендательных систем, рендеринг, расчеты в научных моделях. Но бывают ситуации, когда параллельные вычисления только усложнят систему и ничего не дадут. Например, если алгоритм сильно зависит от результатов предыдущего шага, и каждый следующий этап можно выполнить только после завершения предыдущего, то распараллеливание становится бессмысленным. Так происходит, например, в транзакциях баз данных, где нужно строгое соблюдение последовательности действий либо согласованность данных. То же касается бизнес-логики, где важен жёсткий порядок операций: оформление заказа, проведение платежа, списание товара — все эти этапы должны идти строго друг за другом. Не стоит внедрять параллельные вычисления и в случаях, когда накладные расходы на их организацию превышают пользу. Например, если задача очень маленькая или выполняется доли секунды, то запуск параллельных процессов только добавит задержки. Также параллелизм бывает излишним в системах, где узким местом является не процессор, а, например, сеть или медленный внешний API: параллельная обработка запросов всё равно будет ждать ответа от внешнего сервиса и не ускорит работу.