Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Хотите легко прототипировать - начните с нижних уровней. "Три мушкетёра" отлично подходят для локального запуска и легко масштабираются при необходимости и на standalone-виртуалку с контейнерами, и на деплой в Kubernetes с помощью шаблонизатора.
Но, конечно, всё это должны были предлагать и внедрять девопс-инженеры, а не разработчики - у них профдеформация неподходящая. И, бога ради, не пускайте сеньоров в CI/CD.
начните с нижних уровней. "Три мушкетёра"
Там уже лишние навороты - Docker, composer. О чем и говорилось в этой статье. Не надо умножать сущности там, где они не нужны. Принцип YAGNI.
Там уже лишние навороты - Docker, composer.
git, в общем-то, тоже лишний наворот, только вот готовы ли Вы от него отказаться?
Ну как же они не нужны? Повторяемое окружение нужно? Нужно. Возможность запускать несколько экземпляров на одной машине нужно? Нужно.
Вот, вы уже не представляете, как жить без лишних сущностей )
Не знаю, зачем там повторяемое окружение. Если запуск нескольких экземпляров есть на практике, то нужно, если нет - то нет.
Я отлично знаю, как в максимально посконно-сермяжном режиме развернуть сервис за 20 минут - с копированием файлов через scp, ручным созданием пользователей/групп, навешиванием прав, правкой конфигов, запихиванием в crontab. И знаю, насколько быстро поддерживать такую штуку становится больно. И как тяжело уже через месяц вспомнить, как повторить те же телодвижения.
Оверхед добавления перечисленных выше штук, по моему опыту, невелик - а польза существенна.
И как тяжело уже через месяц вспомнить, как повторить те же телодвижения.
Вообще докер для этого не обязателен. deb/rpm/msi способны решить все или почти все перечисленные задачи. Которые не могут, можно решить отдельным собственным deb/rpm/mst-пакетом или скриптом, если уж совсем по-простому.
Ну, разверните deb-пакетом парочку экземпляров "Постгрес + приложение + nginx" рядом :) Посмотрим, сколько ручных подтыкиваний придётся сделать, чтобы оно друг с другом не сражалось. А потом то же самое на макбуке разработчика с ARM-процессором.
В целом наверное можно, но придётся городить забор из костылей практически с нуля.
В целом наверное можно, но придётся городить забор из костылей практически с нуля.
https://iredmail.org/
Как раз разворачивает Postgres, nginx и пару приложений :))
Это и есть забор из костылей. Кто-то тестит и чинит руками отваливающиеся зависимости каждый раз, когда выходит обновление одного из десятка компонентов, и всё это - только чтобы не ставить докер.
Кто-то тестит и чинит руками отваливающиеся зависимости каждый раз, когда выходит обновление одного из десятка компонентов, и всё это - только чтобы не ставить докер
https://github.com/mailcow/mailcow-dockerized 7450 коммитов
https://github.com/iredmail/iRedMail 2762 коммита
Оно, конечно, нельзя сказать, что это совсем уж корректный способ, но в целом, в случае докера "кто-то тестит и чинит руками" примерно в три раза чаще, чем без него :)
Правильный посыл.
Есть неполнота и неточности. Вы не упомянули заказчика и его ТЗ (даже если это "фаундер"). Не надо писать там всякую ересь. И с каких это пор разраб сам выдумывает архитектуру и технологии?.. Может, это вам "сложность продать легко", я не знаю. Но нормальный разумный человек помнит, что "все гениальное просто". И ищет оптимум, а не приключений на свою пятую точку.
Главное. Эта тенденция все усложнять стала просто эпидемией среди большого слоя более молодых людей. Нужно поставить бризер вместо того, чтобы тупо открыть окно. Да, при этом еще нужен измеритель концентрации углекислого газа с обязательным программированием микроконтроллера. Нужно включать с мобильника термопот вместо того, чтобы дойти до кухни и включить чайник. Нужно бесконечно трындеть про дофамин, ГАМК, нейромедиаторы, прокрастинацию и выгорание. Главное, убежать от реальности в надуманные проблемы. Да, еще must have умный пылесос и прочий "умный дом" как точка доступа злоумышленников...
Нужно поставить бризер вместо того, чтобы тупо открыть окно. Да, при этом еще нужен измеритель концентрации углекислого газа с обязательным программированием микроконтроллера.
Открыл окно в -15, через минуту отвлекся на рабочий чат, ... к вечеру в спальне почти минус. Жизнь слишком сложна и быстра стала, чтобы помнить все мелочи. Популярность измерения СО2 - отголосок микроквартир без вентиляции, на этих жалких 20 метрах с низкими потолками кислород выгорает моментально, буквально час-полтора без проветривания и духота. Плюс, в крупных городах открыл окно на улицу - к вечеру черная покрышечная пыль везде, а в бризере фильтр стоит. Не от хорошей жизни это дерьмо появилось...
Нужно включать с мобильника термопот вместо того, чтобы дойти до кухни и включить чайник.
Та же история. Включил, пока ждал - внимание переключилось, забыл. Вспомнил - он уже остыл, грей заново. И так несколько раз. Потом подгорает задница, и появляется термопот, который всегда горячий - подошел и налил. Увы, но сейчас у большинства населения "кошкино внимание" и проблемы с памятью, за исключением бездельников, конечно - они идеально помнят, сколько у них спичек в каком коробке у плиты.
Открыл окно в -15, через минуту отвлекся на рабочий чат, ... к вечеру в спальне почти минус. Жизнь слишком сложна и быстра стала, чтобы помнить все мелочи. Популярность измерения СО2 - отголосок микроквартир без вентиляции, на этих жалких 20 метрах с низкими потолками кислород выгорает моментально, буквально час-полтора без проветривания и духота. Плюс, в крупных городах открыл окно на улицу - к вечеру черная покрышечная пыль везде, а в бризере фильтр стоит. Не от хорошей жизни это дерьмо появилось...
Если нет изначально принудительной вентиляции и фильтрации воздуха в помещении - проблема. Климат-контроль эту проблему решает, в меру своих сил конечно.
который всегда горячий - подошел и налил.
Благодарю, что напомнили! Термос с кнопкой-наливайкой держит кипяток 6 часов, всё никак не приму за правило заполнять его утром.
Увы, но сейчас у большинства населения "кошкино внимание"
Вот это в точку. Но подозреваю, что наши попытки это исправить за счёт автоматизации напоминает заметание проблем под коврик, и скорее всего это лишь усугубляет проблему в итоге и становимся зависимы от гаджетов.
Всё имхо.
Увы, но сейчас у большинства населения "кошкино внимание"
Вот это в точку. Но подозреваю, что наши попытки это исправить за счёт автоматизации напоминает заметание проблем под коврик, и скорее всего это лишь усугубляет проблему в итоге и становимся зависимы от гаджетов.
Здесь полностью соглашусь, что правильнее было бы находить "серебряную пулю" против "плохого" внимания, СДВГ, около-ковидных последствий и деформаций и т.п.
Популярность измерения СО2 - отголосок микроквартир без вентиляции, на этих жалких 20 метрах с низкими потолками кислород выгорает моментально, буквально час-полтора без проветривания и духота
Это скорее следствие популярности герметичных окон, из-за чего некорректно работает вытяжка многоэтажки - для неё нет притока. У родителей до сих пор деревянные рамы со щелями, вытяжка отклоняет пламя зажигалки, в квартире свежий воздух.
Открыл окно в -15, через минуту отвлекся на рабочий чат, ... к вечеру в спальне почти минус.
Вот бы люди придумали делать маленькое окошко вверху оконной рамы, открывающееся в вертикальной плоскости. Тогда его можно было бы приоткрыть на 1 см и так оставить на весь день, не боясь выморозить комнату и стоящие на подоконнике цветы...
Нужно поставить бризер вместо того, чтобы тупо открыть окно.
Бризер ставят те, кто не может "тупо открыть окно".
Да, при этом еще нужен измеритель концентрации углекислого газа с обязательным программированием микроконтроллера.
Какой-то каменно-угольный период описываете. Насколько я знаю, уже достаточно давно датчик СО2 - простое устройство Plug-and-Play по ZigBee. Из коробки подключается к "умной" колонке и всё, никакие микроконтроллеры программировать не нужно.
Из коробки подключается к "умной" колонке и всё
... теперь вы каждые полчаса будете бегать окном размахивать по указанию колонки. Тогда уж ставьте проточку и пусть датчик ей сразу рулит.
Можно подумать, что без умной колонки и датчика мне своего встроенного не хватает чтобы так бегать ))
... теперь вы каждые полчаса будете бегать окном размахивать по указанию колонки
Может в этом и был изначальный план? Вынужденная физическая активность, чтобы уж совсем в кресло не врастать.
Но вообще уже давно придуманы и микропроветривание, и КПВ-125, и другие устройства. А датчик будет указывать не на размахивание окном, а то, что приточное отверстие нужно отрегулировать в сторону увеличения.
Сложность продать легко. Простоту создать трудно.
Отличный ответ HRу когда нет нужного им опыта :'-D
По идее, большинство "масштабирований" отпадает тогда, когда затраты идут за счет того, кто проектирует систему. Если это стартап на три человека и они принимают участие как в разработке, так и финансировании, то таких проблем возникнуть не должно.
Хорошая новость заключается в том, что на сегодняшний день реляционные базы стали достаточно масштабируемыми для того, чтобы держать весь world-wide трафик.
Вон, небольшой американский стартап OpenAI недавно рассказывал как у них внутри PG внутри трудится.
Деньги инвесторов (или личные сбережения фаундера) сгорают на оплату кластеров в облаке. Два сеньора, которых наняли за большие деньги, целыми днями настраивают CI/CD пайплайны и спорят о правильной гранулярности сервисов.
Расскажите мне, какой Ашот - владелец этих районных парикмахерских, оторвет от своего ашотского пуза бабло на оплату кластеров и на зарплату двух сеньоров, которые в месяц стоят по 3 тыщи баксов каждый? У Ашота в месяц на всю зарплату всем его работницам парикмахерских уходит только одна тыща, а тут надо шесть выложить каким-то двум поглощателям смузи? В общем, спасибо, примером насмешили.
Я работая в компании - мировом гиганте. И у нас используется несколько глобальных сервисов. Но, основная работа лежит на множестве локальных сервисов, собранных крайне просто и примитивно, которые выполняют основные задачи.
Всё потому, что срок жизни продукта в современном мире это 5 - 6 лет. Новый продукт - по любому нужно вносить глобальные изменения. И гораздо проще написать заново набор сервисов под конкретный продукт, чем тянуть за собой огромного гиганта из микросервисов, который требует поддержки и обслуживания.
Начинай делать то, что можешь доделать в срок «в одного».
Реальному бизнесу нужно решение тех вопросов, которые перед ним стоят прямо сейчас.
Если вам нужно поставить «унитаз» в вашей квартире вы готовы ходить в ведро месяцами чтобы дождаться когда сантехник освоит новый «фреймворк» или «архитектуру» или вам нужен работающий унитаз здесь и сейчас?
Айти на другой планете живет, родной.
Может, дело в рынке труда?
1) Если нет опыта в высоконагруженных системах и т.п., то работу найти сложнее. Следовательно, надо текущий проект превратить в высоконагруженный.
2) Работодателям нужны прям элитные разработчики, а не крудовщики. Они стараются нанять лучших. А у тех профдеформация: они работали в условном Яндексе и видели только что-то сложное и высоконагруженное, а проектов на коленке не видели. Вот у них последующие проекты начинают походить на творения Яндекса.
Изложение однобокое. Конечно, не стоит представлять себя гуголом, но я много раз оказывался в ситуации, когда малодушно выбранное более быстрое, но заведомо более плохое решение аукалось проблемами и расходами.
Сложность системы растет не линейно, а экспоненциально с каждым новым компонентом.
Скорее квадратично, пропорционально возможному количеству связей между компонентами.
Разработчик хочет играть с новыми игрушками. Ему скучно писать CRUD‑ы. Ему хочется челленджа. И если бизнес не дает сложных задач, разработчик придумывает сложность в архитектуре.
В итоге проект становится полигоном для обучения. За счет работодателя.
Бизнесу (особенно на старте) плевать на красоту вашего графа зависимостей. Бизнесу нужно проверить гипотезу. Быстро. Дешево.
Классический конфликт интересов. Наемного работника проблемы бизнеса напрямую не беспокоят, бизнес не беспокоят проблемы наемного работника. И та и другая сторона пытается решить свои проблемы за счет другой стороны. Если обе стороны адекватны и понимают суть конфликта, пытаются придти к компромиссу, то все складывается хорошо. Бизнес получает свою "проверку гипотезы", наемные работники получают свои деньги за труд.
Кстати, я думаю тут еще и сам бизнес виноват, часто нанимают на разработку какого-то примитива, сверхквалифицированных людей, по принципу чем круче спец, тем лучше в итоге проект получится, хотя там бы спокойно справился какой-либо крепкий мидл, без особых претензий. Вот и получается, что пара суперсеньоров начинают воспроизводить инфраструктуру гугла для решения задач уровня районной парикмахерской. Они просто по другому не особо то умеют и любят работать, им скучно, и вообще не для того они столько времени и сил потратили на получение текущего грейда ,что-бы копаться в скучном монолитике с крудами и всем этим вот.
Странный тезис. Senior как раз отличается тем, что умеет не переусложнять MVP. Это чаще ошибка middle-уровня - когда хочется “сделать красиво и навсегда” вместо того, чтобы решить задачу бизнеса здесь и сейчас. Опытный разработчик понимает и требования бизнеса, и стадию продукта, и цену лишней сложности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему мы строим звездолеты для перевозки картошки