Comments 6
Мдя. Я надеялся на что-то, связанное с software engineering, а вместо этого очередная вода для менеджмента. Каждый раз, когда в software engineering появляется "заказчик", всё, можно прекращать читать статью, она для гуманитариев.
Нет, k8s начинался… Ок, я не знаю с чего он начинался, я знаю, с чего его рассказывают, с идеи о том, что деплой и fail recovery для stateless-приложений это одно и то же, и что оба они — обычная кибернетическая система, стремящаяся восстанавливать состояние; отсутствие приложения — частный случай отклонения от от желаемого состояния.
Я статью как раз в поисках интересных философских идей и посмотрел — увы, нет. Часть утверждений же экстроординарные, то есть требующие экстроординарных доказательств (которых не привели).
В дискуссии же напрямую отрицались очевидные и многократно проверенные факты. Например, что дублирование микросервисов/серверов увеличивает отказоустойчивость. Что добавление Kubernetes при правильной настройке и распределении сервисов по серверам и датацентрам увеличивает отказоустойчивость. Что грамотные архитектурные решения увеличивают отказоустойчивость. Это отрицается, хотя это факты из практики. И так как докладчик весьма компетентен, а многие его высказывания по теме реальной отказоустойчивости очень глубоки, то встают вопросы к его ангажированности или ловле хайпа.
В целом, из-за особенностей выступающего, материал получился однобоким. Хуже того, он предоставляет оружие в руки бизнеса, который не любит тратить ресурсы на автотесты, на рефакторинг, на упрощение продукта, на разработку максимально простой архитектуры, на разработку отказоустойчивых конструкций и на вложения в грамотную настройку продуктового окружения — на всё то, что реально увеличивает как устойчивость, так и отказоустойчивость сложной системы.
Хаос-инжиниринг и непрерывная проверка прода