Антон, доброго времени суток!
Спасибо за комментарий, это однозначно "+", так как чтобы найти эту двусмысленность надо внимательно прочесть статью. Однако, противоречия в моих мыслях нет.
Тем более, что эта часть статьи просто, ну очень краткий, экскурс в историю.
Основная мысль все же — хотите внедрять микросервисы, разберитесь с теорией распределенных вычислений.
Дело в том, что различают вычисления:
параллельные — вычисления в рамках одного компьютера, но с несколькими ядрами (aka суперкомпьютер, если ядер максимально возможное количество)
распределенные — вычисления с использованием нескольких компьютеров объединенных по сети.
я описываю некую последовательность в историческом контексте, чтобы подвести к появлению задачи распределенных вычислений. Логика простая.
Однопроцессорный компьютер -> Многоядерный -> Суперкомпьютер -> Распределенные вычисления. Поэтому, закон Амдала упоминаю в контексте суперкомпьютера.
… фундаментальный предел эффективности решения вычислительной задачи на суперкомпьютерах.
Но Вы правы, закон Амдала описывает предел алгоритмических задач вне зависимости на одном многоядерном компьютере мы считаем или на нескольких компьютерах, объединенных по сети.
В качестве причин появления распределенныхы вычислений можно было бы указать еще возрастающие нагрузки и описывающую эти процессы "Теорию массового обслуживания", но это отдельная большая тема.
Во-первых, надо сказать что за consistency надо следить всегда, даже при использовании реляционных СУБД. И если неправильно работать с транзакциями, то "ручну починку" можно получить и в реляционной базе.
Вторе, если просто попытаться заменить базу данных (с реляции на NOSQL) без внесения изменений в архитектуру, например, оставить stateless сервисы, которые раньше работали с реляционной базой, то результат будет печальный.
По-сути я и говорю о том, что нельзя просто взять и запилить микросервисы, нужно понимать что меняются подходы к проектированию системы — это распределенные вычисления. Нужно использовать кластера, распределенные журналы событий (Apache Kafka), event sourcing и тд.
Только в этом случае выгоды будут очевидными.
P.S. Ручная починка состояния — это вообще не вариант. Мы голосуем за Self-Healing Services.
Антон, доброго времени суток!
Спасибо за комментарий, это однозначно "+", так как чтобы найти эту двусмысленность надо внимательно прочесть статью. Однако, противоречия в моих мыслях нет.
Тем более, что эта часть статьи просто, ну очень краткий, экскурс в историю.
Основная мысль все же — хотите внедрять микросервисы, разберитесь с теорией распределенных вычислений.
Дело в том, что различают вычисления:
я описываю некую последовательность в историческом контексте, чтобы подвести к появлению задачи распределенных вычислений. Логика простая.
Однопроцессорный компьютер -> Многоядерный -> Суперкомпьютер -> Распределенные вычисления. Поэтому, закон Амдала упоминаю в контексте суперкомпьютера.
Но Вы правы, закон Амдала описывает предел алгоритмических задач вне зависимости на одном многоядерном компьютере мы считаем или на нескольких компьютерах, объединенных по сети.
В качестве причин появления распределенныхы вычислений можно было бы указать еще возрастающие нагрузки и описывающую эти процессы "Теорию массового обслуживания", но это отдельная большая тема.
Спасибо, за комментарий.
Во-первых, надо сказать что за consistency надо следить всегда, даже при использовании реляционных СУБД. И если неправильно работать с транзакциями, то "ручну починку" можно получить и в реляционной базе.
Вторе, если просто попытаться заменить базу данных (с реляции на NOSQL) без внесения изменений в архитектуру, например, оставить stateless сервисы, которые раньше работали с реляционной базой, то результат будет печальный.
По-сути я и говорю о том, что нельзя просто взять и запилить микросервисы, нужно понимать что меняются подходы к проектированию системы — это распределенные вычисления. Нужно использовать кластера, распределенные журналы событий (Apache Kafka), event sourcing и тд.
Только в этом случае выгоды будут очевидными.
P.S. Ручная починка состояния — это вообще не вариант. Мы голосуем за Self-Healing Services.