habr.com взгляд на микросервисы с марксистской точки зрения. Вся статья очень большая, с огромным вступлением, поэтому в коммент скопирую только фрагмент "по делу". Полная статья по ссылке.
Естественно, сами по себе ни разу не бэд.
> Красиво — небольшое.
Главное не размер !!!
Главное - соразмерность и согласованность.
> Пусть каждая программа делает что-то одно, но хорошо.
Предпочитая масштабируемость эффективности - это смотря с какой т.з. будет хорошо.
С т.з. эффективности - вопрос, хорошо ли это.
> Предпочитайте переносимость эффективности.
См. Выше. И важен баланс все же.
Иначе недолго утонуть в фреймворках, решая простые задачи.
> Храните данные в простых текстовых файлах.
То-то я вижу известные СУБД так и делают, ага)
Всякой задаче свой формат полезен. И текстовый в т.ч.
> Извлекайте пользу из уже существующих программных решений.
Так и рождаются нагромождения макросов на экселе вместо разработки БД )
Зачем, ведь существует эксель!!!
Всему своя мера же.
> Используйте скриптовые языки для уменьшения трудозатрат и улучшения переносимости.
Это слой сценариев по сути.
Когда программа "сама своему сценарию рантайм компилятор".
До определенного предела да - неплохо.
> Избегайте пользовательских интерфейсов, ограничивающих возможности пользователя по взаимодействию с системой.
Скорее избегайте организации интерфейсов, ограничивающих разработчика для дальнейшего расширения.
Это да.
Но.
Избегание тоже должно быть в меру.
Зависит от задачи.
> Делайте каждую программу «фильтром».
Ну такое себе.
***
В целом абсолютизация этих принципов так же спорна, как и их игнорирование, ибо принципы неплохи.
Такая же история.
> Автор производит впечатление малолетнего долбоёба не понимающего ни в разработке ПО, ни в жизни.
Есть такое впечатление слегка.
Воткнуть в сложную систему новый компонент, который будет опрашивать все события вне основной архитектурной парадигмы - да, риск.
Однако речь не просто об этом.
А также и о том, как мотивировал руководитель.
Плюс обрати внимание, чтобы реализовать функционал сбора статистики ему потребовалось 4 года, если автор нам не врет нагло.
Так что дело, возможно, не только в детектируемом долбоебизме автора.
>Плюс обрати внимание, чтобы реализовать функционал сбора статистики ему потребовалось 4 года, если автор нам не врет нагло.
Судя по описанию автор хотел прикрутить костылик к каждому сервису, и иметь отдельную бд под это. Вот у меня 50 микросервисов, и мне предлагают писать в бд во время их выполнения. Мой ответ будет грубым. Случись что с бд или процессом записи, и как я буду сервис поднимать и откатывать событие? Гражданин джуновским умом решает архитектурную задачу. Про отсутствие мониторинга смешно, я хз за яндекс, но даже в компаниях на порядок меньше логируется каждый чих, но не через постгрес а через более специализированные вещи. Судя по тому что упоминался биллинг, думается что речь идет о сохранении данных в какое-то подобие редиса, и это уже сильно прикольнее и правильнее. Вывод: молодой жалуется на то чего не понимает
> Боритесь! Отказывайтесь от вакансий, где вам предлагают работать над микросервисами. Встречно предлагайте монолитные приложения!
А методы борьбы в стиле луддитов - это точно марксизм?
Ну и в целом он описывает скорее процесс превращения индивидуального труда в общественный и возмущается примерно тем же, чем возмущались ремесленники, производившие все операции изготовления изделия, с появлением фабричного способа производства и разделением труда.
Складывается статья была написана ради наброса на вентилятор.
Не знаю насколько там близки к правде политические тезисы/призывы, но что касается профессиональных то это полный абсурд.
Естественно, сами по себе ни разу не бэд.
> Красиво — небольшое.
Главное не размер !!!
Главное - соразмерность и согласованность.
> Пусть каждая программа делает что-то одно, но хорошо.
Предпочитая масштабируемость эффективности - это смотря с какой т.з. будет хорошо.
С т.з. эффективности - вопрос, хорошо ли это.
> Предпочитайте переносимость эффективности.
См. Выше. И важен баланс все же.
Иначе недолго утонуть в фреймворках, решая простые задачи.
> Храните данные в простых текстовых файлах.
То-то я вижу известные СУБД так и делают, ага)
Всякой задаче свой формат полезен. И текстовый в т.ч.
> Извлекайте пользу из уже существующих программных решений.
Так и рождаются нагромождения макросов на экселе вместо разработки БД )
Зачем, ведь существует эксель!!!
Всему своя мера же.
> Используйте скриптовые языки для уменьшения трудозатрат и улучшения переносимости.
Это слой сценариев по сути.
Когда программа "сама своему сценарию рантайм компилятор".
До определенного предела да - неплохо.
> Избегайте пользовательских интерфейсов, ограничивающих возможности пользователя по взаимодействию с системой.
Скорее избегайте организации интерфейсов, ограничивающих разработчика для дальнейшего расширения.
Это да.
Но.
Избегание тоже должно быть в меру.
Зависит от задачи.
> Делайте каждую программу «фильтром».
Ну такое себе.
***
В целом абсолютизация этих принципов так же спорна, как и их игнорирование, ибо принципы неплохи.