LINUX.ORG.RU

Вопрос хипстерам в программировании

 


0

2

Последнее время заметил тенденцию, что типовые вещи стали выносить в отдельные сервисы, использовать новомодные микросервисные архитектуры и т.д.

Так вот захотел я сделать парочку пет-проектов для себя ну и потыкать все это дело, один из них школа английского.

Раньше бы я сделал фронт (или попросил бы сделать front-end программера), написал бы POST\GET\WebSocket методов и обменивался бы информацией с бекендом + хранил бы данные в PostgreSQL. Соответственно, аутентификация была бы закостылина в код.

А сейчас я так понимаю, что модно взять и поставить k8s, внутри развернуть поды с сервисом, который отвечает за функционал, отдельный сервис за аутентификацию, отдельный сервис за хранение данных, все связать очередью типа RabbitMQ, поставить сервис API Gateway и все это скрыть за NGINX?

★★★★

Ответ на: комментарий от alpha

Ты используешь фразу «нулевая нагрузка» как заклинание. От того что она «нулевая», 404 в 200 не превращаются магически

Не, кастую я другое заклинание: простая система = надежная система. Если нечему ломаться, то нечего мониторить.

не окажется вообще никого со сколько нибудь реальным понимаем что это за сервис, откуда он начинается, кто за него отвечает и кто будет его чинить
Учет тебя владельцем этой странички

То есть, под на кубернете поднять ты можешь, а учесть меня владельцем странички — нет; только с подом?

Теперь у нас ещё «передний» сервак появился. Он тоже должен сам собой завестись в чистом поле?

А есть разные варианты. Это может быть тот же сервак, который будет хостить мой файлик. Может быть и некий кэш/балансер/дописать свое.

То есть теперь ты каждому человеку для хостинга статичного HTML предлагаешь развернуть платформу для виртуального хостинга?

Платформа (она же контрольная панель) нужна в том случае, если услуга по хостингу предоставляется бабе зине за отдельную плату, и баба зина будет сама настраивать свой хостинг под свои нужды. Если же хостинг внутренний, то никакой контрольной панели не нужно, разраб сам докладывает дамину требования по хостингу и получает от админа реквизиты по деплою.

Всё-таки разработчики жутко наивные ребята когда дело до инфраструктуры доходит

Сочинение на тему «почему моя должность работника инфраструктуры кому-то нужна».

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Сочинение на тему «почему моя должность работника инфраструктуры кому-то нужна».

Это элементарное разделение ответственности. Когда разработчик исчезает, исчезает и его обязанности - разработка. Но работающая инфраструктура, если разработчик все-таки чего-то достиг, должна оставаться. Если исчезает админ - исчезает работающая инфраструктура. И так далее.

Да, у всего есть инерция. Вот у меня есть пример того, как уволившийся разработчик без пропуска, около забора сидел с ноутом, что бы вайфай подцеплять и доделывать там что-то по разным причинам ему понадобившееся. У админов инерция чуть больше, до первого пропадания света, например :)

zendrz ★★
()
Ответ на: комментарий от byko3y

Не, кастую я другое заклинание: простая система = надежная система. Если нечему ломаться, то нечего мониторить.

А ещё единороги и радуги.

То есть, под на кубернете поднять ты можешь, а учесть меня владельцем странички — нет; только с подом?

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

Ты продолжаешь изобретать какие-то другие варианты решения задачи и «что можно было бы сделать» при том что не можешь объяснить почему уже имеющееся решение тебя не удовлетворяет.

А есть разные варианты. Это может быть тот же сервак, который будет хостить мой файлик. Может быть и некий кэш/балансер/дописать свое.

И тут в тред врывается та самая балансировка. Всё веселее и веселее.

Если же хостинг внутренний, то никакой контрольной панели не нужно

При чём тут контрольная панель-то. Ты понимаешь что виртуальный хостинг он где-то хостится? Его кто-то админит? Поддерживает? Настраивает? Что это всё кто-то тоже должен сделать?

разраб сам докладывает дамину требования по хостингу и получает от админа реквизиты по деплою.

Ты их и получил. Иди пользуйся.

alpha ★★★★★
()
Ответ на: комментарий от byko3y

Платформа (она же контрольная панель)

Благодаря таким разработчикам работа у Infrastructure Engineer никогда не перевёдется.

alpha ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Как ты из этого

If a node A connects to node B, and node B has a connection to node C, then node A also tries to connect to node C

вывел это

эрланг может пробрасывать сообщения и через ноду тоже

?

theNamelessOne ★★★★★
()
Ответ на: комментарий от theNamelessOne

Connections are by default transitive

так. возможно я неправильно выразился.

ну или у меня в голове уже с давних пор когда эрланг курил всё перепуталось. если в курсе - поправь.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Если A коннектится к B, а у B есть коннект к C, тогда A создаст коннект ещё и к C, в этом тут заключается транзитивность. A не будет гонять сообщения к C через B.

theNamelessOne ★★★★★
()

У проблемы есть ещё и социальное измерение. Админам интересно поиграться с k8s и другими модными крутыми игрушками. Менеджерам интересно набрать нетупых админов. А привлечь на вакансию «нужен мотальщик изоленты для поддержки легаси-велосипеда» можно либо спецконтингент, либо за большие деньги. А денег нет.

Поэтому система сама собой и к всеобщей пользе и удовольствию мигрирует в сторону усложнения.

ugoday ★★★★★
()
Последнее исправление: ugoday (всего исправлений: 1)
Ответ на: комментарий от Dark_SavanT

И эти люди говорят мне «иди книжку почитай», а другие тут придумали целое явление «лизка», специально с маленькой буквы, чтобы больше унизить.

anonymous
()
Ответ на: комментарий от anonymous

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

Dark_SavanT ★★★★★
()
Ответ на: комментарий от ugoday

Мама посмотри какой я кластер кубернетиса на амазоне собрал! Мама, почему ты плачешь?

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Лучше расскажи про свой опыт работы на эрланге, если такой есть, а книжку я конечно почитаю.

anonymous
()

ОП, да все очень просто - люди не любит рефакторить код. И программеры (в «легаси» копаться), и менеджеры (рефакторинг - трата ресурсов). По этому решили «а давай в следующий раз сразу большую распределенную систему писать, ну прямо как в Google, вдруг полегче ее менять будет, чем раньше?» И да, с первого взгляда кажется, что легче - задача по прежнему одна, а коротких тем много, кажется, все кипит и булькает. На том и остановились. А так - пишешь хорошую уютную маленькую систему, потом наращиваешь по надобности, были бы ресурсы на это. Кстати, микросервисы - зло, а распределенный монолит - рулит.

anonymous
()
Ответ на: комментарий от Dark_SavanT

Если я правильно поняла, ноды в эрланге соединяются через одно единственное tcp соединение. А это значит, что он нихрена не маштабируется на больших объемах

Лиза, иди книжки читай для начала, прежде чем $@#!% в интернетах пороть

Что основного посыла не меняет - если не учитывать локальность данных и гонять их постоянно с ноды на ноду - будут проблемы.

Ты так в явном виде и не описал лизкину ошибку: Erlang VM обычно крутится всеми процессами в одном узле, где никакой проблемы масштабирования нет. Между узлами соединение происходит при помощи TCP, что есть неоптимально, но как-то и пофик вообще, на самом деле.

Намного более серьезной проблемой является отсутствие достаточно эффективного компилятора, не важно JIT или AOT:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/hipe-node...

Ну и да, лизкин препод — мудак, но это как бы самоочевидно, иначе он бы не был преподом.

byko3y ★★★★
()
Ответ на: комментарий от EXL

Так а что девопс должен был тебе предложить? Расположить страничку на «переднем» серваке?

Да. Статика и кэш на nginx, который и есть передний сервак. Вся более сложная обработка отправляется вглубь системы, тем же самым nginx-ом.

byko3y ★★★★
()
Ответ на: комментарий от zendrz

Когда разработчик исчезает, исчезает и его обязанности - разработка. Но работающая инфраструктура, если разработчик все-таки чего-то достиг, должна оставаться. Если исчезает админ - исчезает работающая инфраструктура

Потому работа документируется, чтобы при исчезновении любого сотрудника работа не вставала колом. И поды сами по себе никак не документируют систему.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Может быть он не хотел тебе давать туда доступ? Не хотел проблем в дальнейшем, чтобы ты его тыркал по каждом чиху «ой, мне вот там подправить страничку снова надо». Или вдруг бы тебе внезапно потребовалось к этой статичной страничке что-то не статичное добавить?

А с контейнером у тебя из коробки уже есть свой собственный загончик и ручка управления.

EXL ★★★★★
()
Ответ на: комментарий от byko3y

Erlang VM обычно крутится всеми процессами в одном узле

Обычно на кластере из нод. Есть примеры кластера с 10 тыс. нод.

anonymous
()
Ответ на: комментарий от alpha

Не, кастую я другое заклинание: простая система = надежная система. Если нечему ломаться, то нечего мониторить.

А ещё единороги и радуги

Ну давай, расскажи мне, как ты собралась ломать статичную страничку?

Я могу поднять сто тысяч пятьсот разных вариантов систем для решения разных задач

Поднять-то поднимаешь — что потом с этим делать-то? Из них хотя бы половина вообще как-то заработает?

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

Аргумент такой: девопс — ватокат, вместо того, чтобы раз настроить систему и уйти на пенсию — сидит и занимает место.

Ты понимаешь что виртуальный хостинг он где-то хостится? Его кто-то админит? Поддерживает? Настраивает? Что это всё кто-то тоже должен сделать?

Понимаю, я сам настраивал онный. При наличии опыта делается за несколько минут, раз и навсегда.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Аргумент такой: девопс — ватокат, вместо того, чтобы раз настроить систему и уйти на пенсию — сидит и занимает место.

Технические аргументы во весь рост.

При том что именно это - один раз настроить и передать управление пользователю - он и сделал.

Понимаю, я сам настраивал онный. При наличии опыта делается за несколько минут, раз и навсегда.

Ладно, пора заканчивать. Это какой-то совсем тёмный лес.

alpha ★★★★★
()
Ответ на: комментарий от ugoday

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

Твоя теория не объясняет, например, прошлой тенденции к Java. Люди тянутся не к «пользове и удовольствию», а в основном к возможности получить легкие деньги. В итоге в нулевых получали неподдерживаемый ад на SOA, а теперь всё то же самое повторяется уже на контейнерах. Зато работы у жава-кодеров выше крыши и они счастливы безмерно, потому что сделали успешную инвестицию. Примерно так же работы по поддержке микросервисных систем в ближайшие лет 20 будет много. В отличие от монолитов, которые и так работают.

byko3y ★★★★
()
Ответ на: комментарий от EXL

Может быть он не хотел тебе давать туда доступ? Не хотел проблем в дальнейшем, чтобы ты его тыркал по каждом чиху «ой, мне вот там подправить страничку снова надо». Или вдруг бы тебе внезапно потребовалось к этой статичной страничке что-то не статичное добавить?
А с контейнером у тебя из коробки уже есть свой собственный загончик и ручка управления

Из ручек только «залить новую версию».

byko3y ★★★★
()

У меня это не модно, у тебя модно, у Сержи модно, но не это. О чем вообще пост? Ты пытаешься понять усредненный подход к организации непонятно чего?

anonymous
()
Ответ на: комментарий от anonymous

Обычно на кластере из нод. Есть примеры кластера с 10 тыс. нод

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

byko3y ★★★★
()
Ответ на: комментарий от alpha

При том что именно это - один раз настроить и передать управление пользователю - он и сделал

Нет, если мне понадобится сделать еще одну страничку на еще одном роуте — я должен буду снова бежать к нему на поклон. Посмотри на упомянутый рядом WhatsApp — там 10 кодеров бэка одновременно являются операторами и поддерживают несколько сотен серваков. Без кубернета, без контейнеров — как так, это же ведь должно нарушать какие-то законы физики? Ан нет, работает.

Понимаю, я сам настраивал онный. При наличии опыта делается за несколько минут, раз и навсегда.

Ладно, пора заканчивать. Это какой-то совсем тёмный лес

Что такое, разговор пошел по конкретике, а потому пора его заканчивать? Да, я поднимал nginx с апачкой, по канону, в апачке приложения, в nginx статика. Тут же я прихожу — а мне подами в рыло тычат, мол, нельзя хостить, надо контейнер. С какого перепугу — спрашиваю я? А вот стабильность-надежность-масштабируемость-поддерживаемость-стильность-модность-молодежность — отвечают мне. Я просто не буду называть конкретных признаков, по которым я 100% понял, что это лопух, который сам не понимает, что несет — я и так много рассказал вам. Тут многие так ссутся под NDA даже минимальные подробности раскрывать, что я вам просто щедрый подарок от всего сердца сделал.

byko3y ★★★★
()
Ответ на: комментарий от AntonyRF

я тут на работе три дня рассказывал почему нам не нужен k8s для лендинга

Во-во, а как же настройка прав, мониторинг — вдруг твой лендинг отвалится? Как ты разворачивать лендинг будешь? Как же можно прожить без отдельного сервера в контейнере под отдельную страничку?

byko3y ★★★★
()

новомодные микросервисные архитектуры

сервисной архитектуре миллиард лет алё. Что у вас еще новомодного? Использовать СУБД вместо текстовых файлов?

Dred ★★★★★
()
Ответ на: комментарий от anonymous

Его цель, собрать ЛИДОВ

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

Shadow ★★★★★
()
Ответ на: комментарий от byko3y

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

Ок, но ТВОЙ сервак же останется тем же, просто nginx пнёт.

Shadow ★★★★★
()
Ответ на: комментарий от anonymous

ОП, да все очень просто - люди не любит рефакторить код. И программеры (в «легаси» копаться), и менеджеры (рефакторинг - трата ресурсов). По этому решили «а давай в следующий раз сразу большую распределенную систему писать, ну прямо как в Google, вдруг полегче ее менять будет, чем раньше?»

Это что ж получается, я... люблю рефакторить код? Но почему-то в моем рабстве я, наверное, единственный человек, который на регулярных совещаниях не докадывает «я тут кароч рефакторингом всё время занимался, потому новых фич нету».

byko3y ★★★★
()
Ответ на: комментарий от Shadow

Никогда не понимал, зачем такой трэш, если «лендинг» может продавать, а вместо сбора лидов нужно просто сделать регистрацию из одноклассников/вконтакте

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

на кой черт вообще нужны лендинги.

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

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от Shadow

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

Ок, но ТВОЙ сервак же останется тем же, просто nginx пнёт

Какой еще «мой сервак»? Добавить под под новую страничку — это настроить новый nginx-контейнер с минимальными изменениями, и конфигурнуть роутер на nginx. В итоге роутер конфигурять придется хоть так, хоть эдак, но с контейнерами и кубернетом та же задача по конфигурации и поддержки стала значительно сложнее, выросла из абсолютно плёвой до значительной.

byko3y ★★★★
()
Ответ на: комментарий от Shadow

Но «сферический лендинг в вакууме» без интернет-магазина или сбора аккаунтов в соцсетях - это хтоническая хрень

Да. Я только не совсем понял — в чем ценность сбора аккаунтов в соцсетях? Они же не являются интернет-магазинами. Или являются?

byko3y ★★★★
()
Ответ на: комментарий от anonymous

какая-то маркетоидная чушь

Добро пожаловать в чуть более чем все информационные средства в 2021 году.

byko3y ★★★★
()
Ответ на: комментарий от Stack77

Я бы подискутировал с тобой, но мои комменты, даже сугубо технические, удаляет какой-то модератор. Не пойму, по какой причине …

Владимир

anonymous
()
Ответ на: комментарий от byko3y

Типа вместо вызова функции, исходный код которой я могу прочитать

Что тебе мешает прочитать код микросервиса, с которым ты хочешь взаимодействовать?

я должен вызвать HTTP API по написанным с бодуна докам, и надеяться, что я получу тот ответ, который жду, и этот ответ не поменяется со временем.

Почти так, только не вызвать HTTP API, а подписаться на событие в message bus/event bus, если тебе вдруг что-то понадобилось от другого микросервиса

У меня есть смутное подозрение, что «упрощают» микросервисы разработку только тем, кто чужой код все равно не умеет читать, и кому проще половину рабочего времени сидеть и болтать про архитектуру API вместо того, чтобы наконец написать сотню строк и всунуть их в нужное место.

Упрощает слабой связностью между кодом команд, их процессами и инструментами разработки и деплоя.

Представь, что, в некоторм приближении, shell и множество консольных утилит, а также X11 и множество графических приложений — это микросервисная архитектура, а монолит — один большой бинарь, содержащий это всё.

Там аноним написал:

микросервис выполняет только одну достаточно элементарную функцию, изучать там особенно нечего.

это, конечно же, не так. Микросервисная архитектура про связные контексты (bounded context), и отдельный микросервис в системе может решать несколько задач, если они тесно связаны друг с другом, и быть больше, чем иной монолит, так что ты, как разработчик этого микросервиса, можешь даже и не иметь необходимость «вызвать HTTP API по написанным с бодуна докам», а писать код только сугубо в рамках своего сервиса и спокойно вызывать «функции, исходный код которых ты можешь прочитать».

К сожалению, многие слишком дословно воспринимают слово «микросервис», не поинтересовавшись, в чём там суть и строят системы/распиливают свои монолиты на огромное количество очень мелких сервисов, не задумываясь о силе связей между отдельными функциями, и тем самым попросту перенося свои проблемы в межсервисную инфраструктуру, не решая их, а фактически усугубляя.

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

Что тебе мешает прочитать код микросервиса, с которым ты хочешь взаимодействовать?

Хорошо, тогда зачем вообще нужен микросервис? Ты приколачиваешь один сервис гвоздями к конкретной реализации второго сервиса — после этого релизить и править их можно будет только вместе.

Почти так, только не вызвать HTTP API, а подписаться на событие в message bus/event bus, если тебе вдруг что-то понадобилось от другого микросервиса

Сорта говна.

Упрощает слабой связностью между кодом команд, их процессами и инструментами разработки и деплоя

И усложняет как раз слабой связанностью. Потому что абсолютно бесплатных абстракций не существует, за всё нужно платить.

Представь, что, в некоторм приближении, shell и множество консольных утилит, а также X11 и множество графических приложений — это микросервисная архитектура, а монолит — один большой бинарь, содержащий это всё

А я уже привел пример ядра линя, которое не вписывается ни в одну из твоих крайностей. Почему-то у адептов микросервисов никакой середины существовать не может, а монилит — это обязательно единый бинарный блоб, из которого даже картинки выковырять нельзя, хотя картинки — это такие же «модули», которые можно подменять.

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

Тогда это не микросервис, а просто сервис.

К сожалению, многие слишком дословно воспринимают слово «микросервис», не поинтересовавшись, в чём там суть и строят системы/распиливают свои монолиты на огромное количество очень мелких сервисов

«Постойте ж, я сыскал секрет», кричит Осел: «мы, верно, уж поладим, коль рядом сядем». Послушались Осла: уселись чинно в ряд; а всё-таки квартет нейдет на лад. Вот, пуще прежнего, пошли у них разборы и споры, кому и как сидеть. Случилось Соловью на шум их прилететь. Тут с просьбой все к нему, чтоб их решить сомненье: «Пожалуй,- говорят,- возьми на час терпенье, чтобы квартет в порядок наш привесть: и ноты есть у нас, и инструменты есть, скажи лишь, как нам сесть!»

byko3y ★★★★
()
Ответ на: комментарий от theNamelessOne

В новый OTP, кстати, завезли JIT-компиляцию

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Чот слабовато, если честно

Ну это первая итерация, как я понимаю. Дальше будут улучшать.

theNamelessOne ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.