Merge pull request '[Л/Р 8] Миронов Евгений' (#85) from MironovEvgeniy/distributed-computing:mironov-eo-lab-8 into main

Reviewed-on: http://student.git.athene.tech/v.moiseev/distributed-computing/pulls/85

tasks/mironov-eo/lab_8/README.md

@@ -0,0 +1,27 @@
+	# Отчет по лабораторной работе №8
+
+Выполнил студент гр. ИСЭбд-41 Миронов Е.О.
+
+## Задачи
+
+Написать небольшое эссе (буквально несколько абзацев) своими словами. А помогут Вам в этом вопросы из списка: 
+1. Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
+2. Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
+3. Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
+4. Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
+5. Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
+
+## Эссе
+
+Сложные системы пишутся в микросервисной архитектуре для большей отказоустойчивости. Также это позволяет не повторять существующий код а решить проблему всего 1 раз и вынести в отдельный сервис, что соответствует принципу DRY и еще куче архитектурных паттернов. Микросервисная архитектура - это решение в котором есть свои плюсы и минусы, и далеко не каждому приложению подойдет такая архитектура. Я пока что считаю, что проще развернуть несколько экземлпяров монолита (возможно с несколькими обособленными сервисами), чем уходить в микросервисы, но это скорее всего потому что я еще не сталкивался с проектом которому действительно нужна микросервисная архитектура. 
+
+Системы оркестрации приложений позволяет гибко управлять набором существующих контейнеров. Они позволяют вынести настройки группы контейнеров в отдельный конфигурационный файл. Системы оркестрации приложений помогают более быстро минимизировать количество однотипной работы при разворачивании контейнеров(имею ввиду создание образа, запуск и т. д.)
+
+Очереди обработки сообщений нужны для создания асинхронного API и ослабления связи между экземплярами сервисов. Мы посылаем сообщение брокеру и не заботимся о его доставке получателям, мы в принципе не знаем кто наши получатели. И наоборот получателей не волнует кто отправил сообщение, они знают только очередь из которой они его получили. 
+
+Плюсы микросервисов - высокая отказоустойчивость, быстрое развертывание (хотя конечно зависит от реализации).
+Минусы - задержки при передаче по сети, также любая передача по сети - лишняя угроза безопасности, сложность проектирования и разработки, сложность мониторинга системы.
+
+Распределенная система и параллельные вычисления - несвязанные понятия. Нам по большинству без разницы куда внедрять параллельность, в микросервисы или в монолит. Могу только представить ситуацию, когда два каких-то микросервиса физически размещены на одной машине, и при одновременных параллельных вычислениях будут мешать друг другу в борьбе за ресурсы процессора. 
+Если рассматривать многопоточность отдельно, то она тоже не всегда применима. Если рассматривать ситуацию, когда процессор постоянно активен на большой процент своей мощности, то при параллельной обработке одних данных, у нас будут медленее обрабатываться другие данные. Это применимо когда нам нужно как можно быстрее обработать что-то, к примеру когда на запрос клиента выполняются долгие вычисления и мы стараемся быстрее дать ответ (вешать тяжелые вычисления на клиентский запрос без всяких ограничений очень плохо), а ресурсами на выполнение какого-то фонового job можно и немного пожертвовать, из-за чего он выполнится позже (хотя на практике все с точностью наоборот). 
+При написании параллельных алгоритмов высок риск отхватить очень трудно находимую ошибку, поэтому лучше использовать параллельность там, где это действительно необходимо