у нас на проекте все по контейнерам и даже ci (докер) контейнерный

Какая инфраструктура для тестов?

Тонкая грань)

Да не, ее вполне легко провести же. Если тест не работает без окружения (база, другие сервисы и т.д.), то это интеграционный

тесты все свое носят с собой

+

Какая инфраструктура для тестов?

локально у разработчиков vagrant в котором просто докер, на прле в CI стоит drone с кучкой серверов и опять просто докер

локально у разработчиков vagrant в котором просто докер, на прле в CI стоит drone с кучкой серверов и опять просто докер

Вагрант зачем?

локально у разработчиков vagrant в котором просто докер, на прле в CI стоит drone с кучкой серверов и опять просто докер

Инфраструктура может быть такой, что на одной тачке все может не поместиться

Вагрант зачем?

не все на линуксе сидят

Вагрант зачем?

видимо винда у них

Ага

Инфраструктура может быть такой, что на одной тачке все может не поместиться

вперед запускать на CI

Инфраструктура может быть такой, что на одной тачке все может не поместиться

ну это уже отдельный кейс

видимо винда у них

Виртуализация виртуализации виртуализацией погоняет

у нас щас elastic + postgrs+redis + два аппа + тесты через compose стартуют

для influx мы делали просто, если фикстура видит ENV=devel, то не запускает контейнер а коннектится к удаленному серверу

норм на тачке влезает

Ну и вообще развертывание с нуля инфраструктуры может быть нетривиальной задачей

Ну и вообще развертывание с нуля инфраструктуры может быть нетривиальной задачей

вот значит никто не пилил продукт

Ну и вообще развертывание с нуля инфраструктуры может быть нетривиальной задачей

Нетривиальной и дорогой

Нетривиальной и дорогой

+

вот значит никто не пилил продукт

в смысле коробочный?

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

в смысле коробочный?

да

так что в тестах оно делалось постоянно

ну это разные области, да

не вижу причин не делать так же везде

разве что вопрос в данных

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

Приветы. Питон выходит, что strong typed?

и куча всяких баз/очередей и т.п.

С другой стороны можно хорошо автоматизировать. Тот же ансибл поможет

Приветы. Питон выходит, что strong typed?

да

Приветы. Питон выходит, что strong typed?

Да

ну каждая переменная в каждый момент имеет строго определенный тип, да

Типа типизация динамическая, но при этом strong

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

ну да, было 5 приложений

и перевод из одного типа в другой делается вполне себе явно и по правилам

ну каждая переменная в каждый момент имеет строго определенный тип, да

Строгая это про другое. Если в каждый момент разная - это значит, что динамическая

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

Сотни микросервисов.. Ад девопса?

и перевод из одного типа в другой делается вполне себе явно и по правилам

Ага.это значит Стронг.

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

не скажи, у нас коробочный и у нас на вооружении mysql, memcached, influx, rabbitmq + наш продукт разбит на сервисы, которые надо параллелить и разбивать на разные инстансы

ну с микросеврисами я щас только учусь нормально жить

пока не нравится процесс

хотя до сотен тоже не дотягивает

Сотни микросервисов.. Ад девопса?

Ну они могут быть довольно унифицированно обслуживаться, деплоиться. Но тем не менее сетап самой инфраструктуры может быть сложным

/me сваял свое поделие для запуска отдельных скриптов

нынешнее поколение школоты

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

или я там не знаю

захар здесь?

dockerus composicium

или я там не знаю

А бери любой базворд

dockerus composicium

кекус лоликус

не скажи, у нас коробочный и у нас на вооружении mysql, memcached, influx, rabbitmq + наш продукт разбит на сервисы, которые надо параллелить и разбивать на разные инстансы

mysql, memcached, influx, rabbitmq, ну это в общем довольно маленький стэк. В больших проектах, особенно где много легаси этот стек может быть во много раз больше

ну с микросеврисами я щас только учусь нормально жить

Тут как с фломастерами - ра вкус и цвет. Обязательно будут миссионеры микросервисов. У них свет на них сошелся. И будут противники)

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

А выбор архитектуры все таки от задачи следует делать, а не моды

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

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

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

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

Тут как с фломастерами - ра вкус и цвет. Обязательно будут миссионеры микросервисов. У них свет на них сошелся. И будут противники)

Это не совсем вкусовщина. С большим монолитом в какой-то момент времени становится слишком сложно жить. И переход на микросервисы, это скорее вынужденная мера

Это не совсем вкусовщина. С большим монолитом в какой-то момент времени становится слишком сложно жить. И переход на микросервисы, это скорее вынужденная мера

Я о том, что надо разбивать не сильно мелко. Иначе тараканов не наловишься.

Я о том, что надо разбивать не сильно мелко. Иначе тараканов не наловишься.

А, ну это само собой. Черезмерное дробление тоже не айс

Ядро линукса по факту монолит. Крупный и сложный проект. При хорошей организации живет и развивается. Поэтому процессы важны не меньше.

Это не совсем вкусовщина. С большим монолитом в какой-то момент времени становится слишком сложно жить. И переход на микросервисы, это скорее вынужденная мера

Да, только “большой монолит” это тысяч сто строк кода+ (а есть случаи, когда и миллион держат и ничего). А куча ньюфагов в индустрии пилят на микросервисы все, что плохо лежит. Все лучше с микросервисами. Мы слышали ты любишь микросервисы? Мы добавили микросервисы в твои микросервисы, чтобы ты мог проксировать пока ходишь в сервис меш ?

у вас что работы нет

целый день треп

переходите на Go, тут есть работка

ERROR: S client not available

“Инкапсуляция по сети” можно сказать. Ну захватывающая концепция конечно, но ведь не все в них уперлось. Это оркестрация, сервис меш, логгирование, трейсинг, мониторинг, дашборды для логов, всякие амбассадоры для апи гейтвеев

Да, только “большой монолит” это тысяч сто строк кода+ (а есть случаи, когда и миллион держат и ничего). А куча ньюфагов в индустрии пилят на микросервисы все, что плохо лежит. Все лучше с микросервисами. Мы слышали ты любишь микросервисы? Мы добавили микросервисы в твои микросервисы, чтобы ты мог проксировать пока ходишь в сервис меш ?

ну 100k строк не очень много, как по мне. Но если ты говоришь о проблеме что на волне хайпа все стали делать микросервисы там где надо и где не надо. То тут я с тобой солидарен

ну 100k строк не очень много, как по мне. Но если ты говоришь о проблеме что на волне хайпа все стали делать микросервисы там где надо и где не надо. То тут я с тобой солидарен

Дааа, ++

Это боль в смысле что я видел когда и тысячи строк кода (ну там 10к - 20к кодовая база) начинают раздирать на десятки микросервисов

Поддержка становится такой болью

почему?

ведь каждый сервис независим от остального, имеет фиксированную версию и апи

и правки в одном сервисе не должны ломать работу остальных при сохранении апи

Вот Фаулер дает пояснение https://martinfowler.com/bliki/MonolithFirst.html

ведь каждый сервис независим от остального, имеет фиксированную версию и апи

Накладные расходы на содержание этой вакханалии велики

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

Без трейсинга ты не знаешь где упало. Без оркестрации ты не можешь управлять этим

самое хреновое, когда эти микросервисы начинают писать на джанге с drf и потом офигенные профессионалы в этих технологиях им нужны в команду чтобы банальный круд на 4 таблицы писать

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

Проблема большого монолита в том, что его становится сложно релизить и больше вероятность регресса

Сетевые задержки жрут производительность

оркестрацию сделал

сетевые?

зачем там сетевые?

у меня все локальненько на юникс сокетах и пайпах

А как твои микросервисы будут общаться? Через юникс сокеты? ?

ну они пока не микросервисы, а отдельные приложения. Да, сокеты и пайпы

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

кидают себе жсончиками друг в другна

Когда это реально физически в разных узлах

ну если нужно разносить физически, то наверно просто потому что на одном они уже не помещаются

Сетевые задержки жрут производительность

Внутри одного дц это не выглядит проблемой, особенно если keep alive есть

Так именно. Чаще всего этот вариант и предполагается

Как сделать таую аналогию на пайтон? http://jsbin.com/xopaziy/1/edit?js,console

Транзакции тоже идут лесом, но это не такая уж беда, если все разделено

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

Транзакции тоже идут лесом, но это не такая уж беда, если все разделено

И вообще не беда, если у тебя и до разделения не было транзакций ))