Pull to refresh

Comments 6

Мдя. Я надеялся на что-то, связанное с software engineering, а вместо этого очередная вода для менеджмента. Каждый раз, когда в software engineering появляется "заказчик", всё, можно прекращать читать статью, она для гуманитариев.

Ну если отбросить тот момент, что чувак рекламирует свой продукт (как и большинство выступающих на конференциях владельцев бизнесов), то можно найти в статье и довольно интересные мысли. В принципе, Kubernetes тоже начинался с таких вот философских статей с налетом маркетинга.

Нет, k8s начинался… Ок, я не знаю с чего он начинался, я знаю, с чего его рассказывают, с идеи о том, что деплой и fail recovery для stateless-приложений это одно и то же, и что оба они — обычная кибернетическая система, стремящаяся восстанавливать состояние; отсутствие приложения — частный случай отклонения от от желаемого состояния.


Я статью как раз в поисках интересных философских идей и посмотрел — увы, нет. Часть утверждений же экстроординарные, то есть требующие экстроординарных доказательств (которых не привели).

Вся глобальная система управления безопасностью полетов, которая все же очень эффективна, держится на этих «мифах» (и не только на избыточности), кроме, пожалуй, шестого (простой ее не назовешь).
Держится. Но, тем не менее, катастрофы все же случаются, т.к. все предусмотреть крайне тяжело — с одной стороны. С другой, их было бы гораздо больше.
А с третьей стороны, самолёты стали настолько отказоустойчивы, что у нас в ряде катастроф выяснялось, что летающие по 10-15 лет пилоты банально не умеют летать без автопилота. То есть самолёты радикально надёжны в плане отказоустойчивости.

В дискуссии же напрямую отрицались очевидные и многократно проверенные факты. Например, что дублирование микросервисов/серверов увеличивает отказоустойчивость. Что добавление Kubernetes при правильной настройке и распределении сервисов по серверам и датацентрам увеличивает отказоустойчивость. Что грамотные архитектурные решения увеличивают отказоустойчивость. Это отрицается, хотя это факты из практики. И так как докладчик весьма компетентен, а многие его высказывания по теме реальной отказоустойчивости очень глубоки, то встают вопросы к его ангажированности или ловле хайпа.

В целом, из-за особенностей выступающего, материал получился однобоким. Хуже того, он предоставляет оружие в руки бизнеса, который не любит тратить ресурсы на автотесты, на рефакторинг, на упрощение продукта, на разработку максимально простой архитектуры, на разработку отказоустойчивых конструкций и на вложения в грамотную настройку продуктового окружения — на всё то, что реально увеличивает как устойчивость, так и отказоустойчивость сложной системы.
Sign up to leave a comment.