А вы тестировали под реальной нагрузкой? Что то вроде apache flink? С 100-500 mb/s read/write..
Повторю тоже что и в предыдущей подобной статье про минио - пару лет назад, разваливался кластер минио как шалтайбалтай, обратно не собрать, и не важно сколько реплик данных.
Речь о пайплайнах, а не том что выкатывается. Пайплайн должен абстрагироваться от деталей сервиса.
Коротко-живущие пайплайны отличаются от остальных енвов, как раз наличием доп. шагов по поднятию/тушению необходимой инфры и сервисов. Чего не должно быть для условного пре-прод.
Представленный пример с существенным отличием инфры дев/прод проблема не техническая, а финансовая. За что платят - то и получают. И еще не известно экономят ли..
С болью в отсутствии инструментария - согласен. Хоть и helm charts + argocd + crossplane очень помогают разгрузить пайплайн. Можно еще глянуть на стандарт Open Application Model. Но это все не про тесты пайплайна. Остаются ручные тесты на дев, или таки есть варианты получше?!
Вот про боль со вводом стейджинга - не понял. Если речь про пайплайны, то как и зачем им отличаться от прод окружений с технической точки зрения? С коротко-живущими еще понятно..
Видимо вас прекрасно поняли, и все так же не согласны..
Спасибо и за бесплатно такое не надо. Удалил вотсап и перешёл на альтернативы, давно. Это простой выбор каждого.
Само собой не просто так - блеф и манипуляции нацеленные на аудиторию, но без понимания разницы между ценностями в u.s. и Европе.
Вы мешаете все в кучу чтоб сложней разобраться? Вы в курсе что в u.s. данные пользователей не могут покидать штат? Что то не слышно возмущений. И все равно как мета будет исполнять требования в европе, это их забота. А если уйдут, значит не нужен тут такой сервис.
Коллеги пробовали минио около года назад, не знаю поменялось ли что то с тех пор, но под нагрузкой (io) минио гарантированно разваливался, при этом статус в самом минио показывал что все хорошо. Востановление данных не работало (при реплика данных х 3).
Тестируйте свои решения на базе минио очень тщательно или готовтесь потерять все данные.
Для некоторых решений остановились на Rook Ceph, работает стабильно, хорошая производительность, рабочее автовостановление.
Учитывайте что под NAS решение вам могут понадобиться выделеные люди, зависит от размера кластера и критичности данных. Ну и читайте пост мортем разных компаний использующие похожие решения, это вам даст пищу для размышлений.
Вам в недочеты указывают, при том бесплатно, а вы "фанбой-феномен" -ом оправдываете.
У мнения - к8с сложно/дорого, есть право на жизнь в ограниченом количестве случаев, но вы же позиционируете мнение как общее утверждение.. а это не так.
Компьютерная наука относиться к естественным наукам, тут для выводов нужны исходные данные и аргументация. А если вы пришли со своим мнением за лайками, возможно вы ошиблись разделом или ресурсом.
Бизнес требования часто важнее технических. А бизнес зависит от рынка. Все так.
Забавно что в моем городе, еще лет 8-10 назад ситуация была с точностью на оборот. Проекты на питоне закрывались изза отсутствия разрабов, а те что жили агресивно хантили с других яп.
Ни где и не утверждал что этого нет или это невозможно. Но и задачи усложнить себе жизнь не было. Зачем решать то что на других платформах нет как проблемы?
С доками у фласка все хорошо, если сравнивать в среднем по питону. Но нет смысла сравнивать с тем же симфони.
Все что вы описали работает для, условно одного разраба, а на 100+ с установкой придёт и поддержка и недовольные и т.д. Подозреваю что реального опыта реализации того что вы предлагаете на 100+, у вас не было?!
Неуверен что есть смысл сравнивать, там пропасть в зрелости экосистем. В symfony/spring думать особо не надо - все решено и описано в доках. И речь не только о web reqest/response. Я в целом, дб миграции, scaffolding, модульность и т.д.
Конкретно с вебом, нет дефакто стандарт фреймворка. Тоесть если идёт речь о разработке n продуктов в n командах, компании проще взять что то типа symfony или spring который покроет 95% требований. С тем же джанго, каждая команда будет собирать свой стек.
Я так понимаю посыл статьи: "девопс сложно, там ни кто ни чего не понимает — приходите к нам"?
Или все же про бизнес который требует от бекенд разрабов еще и деплоем заниматься, не позаботившись спросить об опыте и желании? Ну и за одно приглядеть за сервером, чтоб 2 раза не вставать… Если человек уволился, это явно не от радости.
Про сеть замачено правильно, предмет сложный и потому нередко их разделяют, например на продопс и нетопс, потому винить девопс за то что на них повесили все… притянуто за уши.
В сухом остатке статью можно изтолковать так: Приходите к нам, заплатите в "5 раз больше" и будете это делать постоянно, за то не надо будет разбираться как управлять ит.
И в этом нет ни чего плохого, с покупкой бу или нового авто ситуация аналогичная.
И "админ, переименованный по-модному" сможет создать csi к8с оператора?! Со всеми необходимыми процесамми для разработки и поддержки? Или это задача для девелоперов?
А вы тестировали под реальной нагрузкой? Что то вроде apache flink? С 100-500 mb/s read/write..
Повторю тоже что и в предыдущей подобной статье про минио - пару лет назад, разваливался кластер минио как шалтайбалтай, обратно не собрать, и не важно сколько реплик данных.
С чего бы для всех?
С go пропорции рутин и тредов вообще мало кого волнуют, а тех кого волнует не редко пишут на c++/rust.
Проблем с определением количества ресурсов нет, с cgroups тоже, пример: go, jvm, c# и куча прочих.
А если вы про сишную либу под капотом.. ну давайте поговрим о трединге/асинке в php? Там тоже ведь сишные либы подкапотом...
Если очень нужен питон и по другому ни как, то конечно можно.. но вообще дичь, просто неиспользуйте питон там где не надо.
А то как в известной мысли про молоток и гвозди.
Речь о пайплайнах, а не том что выкатывается. Пайплайн должен абстрагироваться от деталей сервиса.
Коротко-живущие пайплайны отличаются от остальных енвов, как раз наличием доп. шагов по поднятию/тушению необходимой инфры и сервисов. Чего не должно быть для условного пре-прод.
Представленный пример с существенным отличием инфры дев/прод проблема не техническая, а финансовая. За что платят - то и получают. И еще не известно экономят ли..
С болью в отсутствии инструментария - согласен. Хоть и helm charts + argocd + crossplane очень помогают разгрузить пайплайн. Можно еще глянуть на стандарт Open Application Model. Но это все не про тесты пайплайна. Остаются ручные тесты на дев, или таки есть варианты получше?!
Вот про боль со вводом стейджинга - не понял. Если речь про пайплайны, то как и зачем им отличаться от прод окружений с технической точки зрения? С коротко-живущими еще понятно..
п.с. к авторам ни какого отношения не имею.
Вряд-ли к вам это относиться.
DGE regulations.
Штаты: New Jersey, Pennsylvania, Michigan
Видимо вас прекрасно поняли, и все так же не согласны..
Спасибо и за бесплатно такое не надо. Удалил вотсап и перешёл на альтернативы, давно. Это простой выбор каждого.
Само собой не просто так - блеф и манипуляции нацеленные на аудиторию, но без понимания разницы между ценностями в u.s. и Европе.
Вы мешаете все в кучу чтоб сложней разобраться? Вы в курсе что в u.s. данные пользователей не могут покидать штат? Что то не слышно возмущений. И все равно как мета будет исполнять требования в европе, это их забота. А если уйдут, значит не нужен тут такой сервис.
Коллеги пробовали минио около года назад, не знаю поменялось ли что то с тех пор, но под нагрузкой (io) минио гарантированно разваливался, при этом статус в самом минио показывал что все хорошо. Востановление данных не работало (при реплика данных х 3).
Тестируйте свои решения на базе минио очень тщательно или готовтесь потерять все данные.
Для некоторых решений остановились на Rook Ceph, работает стабильно, хорошая производительность, рабочее автовостановление.
Учитывайте что под NAS решение вам могут понадобиться выделеные люди, зависит от размера кластера и критичности данных. Ну и читайте пост мортем разных компаний использующие похожие решения, это вам даст пищу для размышлений.
Вам в недочеты указывают, при том бесплатно, а вы "фанбой-феномен" -ом оправдываете.
У мнения - к8с сложно/дорого, есть право на жизнь в ограниченом количестве случаев, но вы же позиционируете мнение как общее утверждение.. а это не так.
Компьютерная наука относиться к естественным наукам, тут для выводов нужны исходные данные и аргументация. А если вы пришли со своим мнением за лайками, возможно вы ошиблись разделом или ресурсом.
Бизнес требования часто важнее технических. А бизнес зависит от рынка. Все так.
Забавно что в моем городе, еще лет 8-10 назад ситуация была с точностью на оборот. Проекты на питоне закрывались изза отсутствия разрабов, а те что жили агресивно хантили с других яп.
Ни где и не утверждал что этого нет или это невозможно. Но и задачи усложнить себе жизнь не было. Зачем решать то что на других платформах нет как проблемы?
С доками у фласка все хорошо, если сравнивать в среднем по питону. Но нет смысла сравнивать с тем же симфони.
Все что вы описали работает для, условно одного разраба, а на 100+ с установкой придёт и поддержка и недовольные и т.д. Подозреваю что реального опыта реализации того что вы предлагаете на 100+, у вас не было?!
Неуверен что есть смысл сравнивать, там пропасть в зрелости экосистем. В symfony/spring думать особо не надо - все решено и описано в доках. И речь не только о web reqest/response. Я в целом, дб миграции, scaffolding, модульность и т.д.
За то время на дальнейшую разработку и поддержку окупят сполна затраты на началный сетап.
Вы давно заглядывали в доки фласка? Вы серьезно предлагаете это для компаний с ~100 разрабами?
Как там CLI командами? Typehints, ORM, IoC...
Но мой взгляд с питоном слишком много что не так.
Конкретно с вебом, нет дефакто стандарт фреймворка. Тоесть если идёт речь о разработке n продуктов в n командах, компании проще взять что то типа symfony или spring который покроет 95% требований. С тем же джанго, каждая команда будет собирать свой стек.
Я так понимаю посыл статьи: "девопс сложно, там ни кто ни чего не понимает — приходите к нам"?
Или все же про бизнес который требует от бекенд разрабов еще и деплоем заниматься, не позаботившись спросить об опыте и желании? Ну и за одно приглядеть за сервером, чтоб 2 раза не вставать… Если человек уволился, это явно не от радости.
Про сеть замачено правильно, предмет сложный и потому нередко их разделяют, например на продопс и нетопс, потому винить девопс за то что на них повесили все… притянуто за уши.
В сухом остатке статью можно изтолковать так: Приходите к нам, заплатите в "5 раз больше" и будете это делать постоянно, за то не надо будет разбираться как управлять ит.
И в этом нет ни чего плохого, с покупкой бу или нового авто ситуация аналогичная.
И "админ, переименованный по-модному" сможет создать csi к8с оператора?! Со всеми необходимыми процесамми для разработки и поддержки? Или это задача для девелоперов?
А зачем? Тут же в концовке все поясняют…
"Лучше поищите стороннюю экспертизу для подстраховки."
Например k3s..
Их десятки и наверно ближе к сотни… перечислять не вижу смыла, выбирайте по своим требованиям.