Комментарии 15
Размер контейнеровоза впечатляет, но "размер" ≠ "сложность". Полагаю, что в обязанности команды входит только управление, а не обслуживание агрегатов. Этим занимаются специально обученные люди у берега. Разумеется, такая ответственная система спроектирована с дублированием всего, что только можно, и проработаны инструкции по действию команды при всяческих отказах. Более того, плавания могут занимать несколько дней, а людям свойственно спать. Скорее всего, из этих тринадцати человек, 1 - капитан, и 3 смены по четыре человека, т.е. одновременно работают всего 5 человек.
А теперь, представьте круизный лайнер того же масштаба на N-тыс. человек на борту. Сразу становится понятно, что 13 человек там не справятся. Вывод (неправильный): лайнер - сложная система, значит строим контейнеровозы. Но если присмотреться к лайнеру, то огромная команда занимается обслуживанием потребностей ̶г̶р̶у̶з̶а̶ людей. Именно управлением занимаются всё те же 13 человек.
Это же применимо к программным системам. Разумееется, если можно сделать что-то просто или сложно, то лучше просто
Обслуживанием груза клиентов занимается саппорт. Аналогия с кораблём отличная.
Мне видится посыл статьи в том, что если вы стартап, то делайте все как можно проще, иначе маленькой командой не вытяните своё творение. И это верно.
Но сравнение спорное. Если контейнеровоз является аналогией программной системы, то аналогией команды должны быть менеджеры, руководители и др. её пользователи, но никак не программисты. Служба порта, осуществляющая регулярное плановое обслуживание - это админы. А программисты сидят на судостроительной верфи, и их там много больше тринадцати.
Другое дело, что в стартапах один человек может быть и программист, и админ, и саппорт в одном лице.
Полагаю, что в обязанности команды входит только управление, а не обслуживание агрегатов.
Входит-входит. Иногда даже весьма трудозатратные операции, вроде замены поршня, тоже выполняются силами команды (не во время перехода, разумеется, а на стоянке).
У кораблестроение большая история. Большинство кораблей имеет типовую архитектуру. В училищах учат типовых специалистов.... Стартап это что-то новое. Вам вначале надо этот корабль создать, наладить, запустить.
А еще при построении кораблей нет продукт манагеров которые вдруг решают что теперь для бизнеса им нужны летающие контейнеровозы, а для очень важных клиентов чтобы еще и в космос мог залетать на пол шишечки =))
Корабль «Васа» должен был стать главным боевым кораблем шведского флота...
habr.com/ru/company/itsumma/blog/336398
Да, так и есть. Поэтому при первом запуске стартапа для операционной деятельности лучше использовать типовые модули типовых проверенных архитектур и только после успешной проверки бизнес-гипотез уже можно строить свою операционную систему, адаптированную под специфику (если нужно).
В чем практический смысл этой статьи применительно к реальным стартапам? Какое отношение корабли, тысячный раз делающие один и тот же маршрут преимущетвенно на автопилоте имеют к венчурному инвестированию? Если хотите аналогий с кораблями, сравните с тем же Куком, Колумбом, Магеланом. Для начала Вы не сможете механику гарантировать что машинное масло будет доступно через тысячу миль, а коку - что будет пресная вода. И что Ваши контейнеры кому то вообще окажутся нужны на том берегу. Согласитесь ситуация заиграла новыми оттенками и возникли вопросы поважнее чем оптимизация сложных процессов.
Сложные идеи ведут к сложным реализациям
Это еще ладно, иногда даже простые идеи реализуют сложно )
Меня по этой причине весьма напрягает хайп по Kubernetes.
Если что-то идет не так, там очень сложно понять, что происходит.
Если систему легко понять и ей легко управлять, то будет легко и чинить
"Это не есть факт, месье Дюк".
За интерфейсом (пользователя или программным - раз уж мы тут многие программисты) может скрываться очень сложная система, возможно недоступная даже для понимания пользователем этого интерфейса, не говоря уже о ремонте.
Мне одному такая «Экспертиза» кажется как минимум сомнительной? ;)
Было 629 процессов стало 20. Очевидно что 20 проще поддерживать, но куда делись функции 601 процесса? Они же выполняли какие-то бизнес-задачи.
Мне кажется архитектура кораблей имеет очень отдаленное отношение к архитектуре ПО.
ПО может и должно подвергаться рефакторингу, всевозможной в рамках бюждета и по мере необходимости оптимизации для увеличения контроля .
Но и новыми фичами ПО может и обязательно будет обрастать, потому что ПО не вещь в себе, а всегда выполняет задачи бизнеса (маркетинговые системы, а не абстрактные алгоритмы)
В простых системах меньше даунтайм