Work.Дыбр - разгребая наследие ушедших

[dzz]

И никогда, вы слышите, никогда не доверяйте web-разработчикам проектирование архитектуры промышленных систем!

Задачка - относительно простая система управления видеоконтентом для андроидных экранчиков. Архитектура - 6 виртуальных серверов на реальных IP (2 базы, бэк, storage, фронт, nginx-маршрутизатор) + CI/CD с гитлабом для всего этого великолепия. Декомпозиция по учебнику :)

Товарищ уволился три месяца назад, проект передали в мой отдел.

Сейчас понадобилось собрать standalone-машинку для мелкого пилота. Два человека охреневают от мощи архитектурного решения уже третий день, постепенно впихивая весь этот сон разума в одну операционку :)

Мораль: не переусложняйте.

P.S. Автор хотел написать систему, масштабируемую на 100500 клиентов. Но само приложение разработано так, что каждому клиенту нужен свой экземпляр системы. Sic.

Comments

[parakhod.livejournal.com]

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

А вот такие захардкоженные конструкции — это уже лет 5-7 назад было совсем не комильфо. Самый треш что мне попадался — десяток дроплетов на DigitalOcean, на каждом вручную запущенный докер, в каждом по одному (!) контейнеру, и в каждом контейнере айпишники и секреты прописанные вручную, разумеется. Типа двойное резервирование всего (зачем-то), зеркалящаяся mongo, но даже докер сам при перезагрузке не запускался, не говоря уж о контейнерах. Не говоря уж о процессах в контейнерах — node там падал быстро и фатально.

[dzz.livejournal.com]

На самом деле, придумать архитектуру, которая нормально масштабируется вниз, не так просто. Я обычно два перетекающих друг в друга варианта прорабатываю — облачный "капучино" и автономный "эспрессо".

А в описанном случае контейнеризация тоже была бы избыточна, т.к. в приложении нет механизма балансировки нагрузки. Достаточно было раскидать сервисы по портам, а дальше хочешь — пакуй в докеры, хочешь — собирай всё на одной железке.

[parakhod.livejournal.com]

Ну так такие вещи грумятся большим количеством народа и не один день, и даже не один год бывает.

Ну и да, разумеется контейнеры и вообще микросервисная архитектура — вещь хитрая, и не всегда оптимальная. Подобные реализации — это обычно когда люди услышали про принцип где-то, но сути так и не поняли.

!

[de_nada]

Вы правы.
Я тут первым комментарием обрыдался с подобного подхода — "все (и всё) по контейнерам!".

Так ладно описываемые упыри суют туда Кафки с Зукиперами — но и в более простых вещах такое чудят, что на голову не натянешь!

Вчерась завёл у себя в периметре "локальный/онпремизный "тимвьювер"" на базе РустДеска, так слегонца ошалел от документации по развёртыванию.

Там же, сцуко, два — ДВА, Карл! — модуля (сервер и релей), запускаемые с минимальными пар-рами шелл-скриптом посредством rc.local (ладно, можно залудить самопальный "сервис" для systemd, если уж так хочется).
Ан нет: дока по развёртыванию упоминает альт-решение с запуском через pm2 (который сам требует последнего nodejs). Вот что в головах у людей, а?
Так ещё и есть у них вариант с докером — они эту пиписечную поделку по контейнерам распихивают, прикиньте!

К слову — сам по себе продукт бомба.
Сегодня удалённо причинял пользу и наносил добро нашему удалёнщику из Еревана, сидящему на тухлом вайфае.
Начал с AnyDesk, но он чёта еле булькал, пришлось переползти на эту, пилотную, инсталляцию РустДеска.
Млин, небо и земля — легко, быстро, гладко, удобно.

С учётом того, что подключение шифрованное и идёт через мой локальный сервак на крохотной центосёвой виртуалке в периметре, ни о каком MiTM`e, даже потенциальном, речи не идёт, не говоря уже об "уходах с нашего рынка" всех этих тимвьюверов-энидесков (или вспышках их жадности, как у последнего недавно — с прикручиванием халявного использования).

Так что коллегам рекомендую присмотреться к RD — чёткое поделие.

С уважением.

RE: !

[parakhod.livejournal.com]

Ну мы-то по другую сторону "железного занавеса" сидим, от нас ничего не уходит.
По счастью нам и самим уходить ниоткуда не приходится, потому что никуда и не приходили (у нас нет on-premises инсталляций нашей платформы восточнее Саксонии).

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

RE: !

[vitus_wagner]

Классы — не зло. Классы — отсутствие добра (как Дьявол — отсутствие Бога).

Классы и экземпляры это слишком общая абстракция.

Хорошая абстракция имеет ограниченную область применимости и за счет этих ограничений позволяет какие-то эффективные оптимизации.

Вот, например реляционная алгебра.

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

Функциональное программирование кажется привлекательным потому что до сих пор, пока оно не было мейнстримом, с ним справлялись в основном люди с математическим бэкграундом, которые умеют придумывать абстракции. Но вообще -то функциональная парадигма сама по себе — тоже штука слишком общаяя, и когда вместо людей туда набегут дево-псы, будет то же, что и с ООП.

Re: !

[dzz.livejournal.com]

Классы — это просто инструмент, достаточно удачный для широкого использования. Другое дело, что во всём следует соблюдать меру.

Re: !

[vitus_wagner]

На мой взгляд, классы крайне неудачный инструмент для ШИРОКОГО пользования. Он дает ощутимые преимущества только при правильном ОО-дизайне. Что, конечно, проще чем придумать целый новый раздел математики, но тем не менее.

RE: Re: !

[dzz.livejournal.com]

Строго говоря, ЛЮБАЯ технология даёт преимущества только при грамотном её использовании :)

Применительно к ООП, разработка системы классов — основа дизайна программы, поскольку неверно выбранное решение влияет на весь код. Понимание того, какие прикладные классы нужны и нужны ли вообще (и можно обойтись только библиотечными) — показатель квалификации программиста. Ибо единственный универсальный инструмент — это мозг :)))

В тех же контейнерах принципиально нет ничего плохого, для ряда задач они ой как полезны и удобны, но надо понимать, когда как их готовить.

[vitus_wagner]

Беда в том, что веб-разработчик не думает, а применяет готовые шаблоны. Его так учили — сначала странички рисовать с помощью какой-нибудь template engine, потом клиент-сайд из готовых фреймворков собирать, ну и так далее.