Дуже малоймовірно, що хтось має пет-проект на мікросервісах з міжсервісною комунікацією на брокері повідомлень. Шлях більшості систем починається з монолітна (а особливо якщо це пет-проект), бо так тупо швидше і простіше. Тому це і не гуглиться🤌
Тому порад кілька:
— шукати і дивитися всі можливі доповіді з конференцій по мікросервісним рішенням
— знайти проект/продукт з мікросервісним підходом (знаю, зараз це не так щоб дуже легко)
— знайти ментора (це скоріше за все буде за гроші), який без порушень NDA зможе розказати про архітектурні рішення і підходи.

Хоча знову ж таки, для c#, для чого в монорепозиторії мати nuget пакет? Якщо він публікується з окремими версіями і ним користується ще хтось, то йому явно місце в окремому репозиторії. Якщо ж він потрібен лише сервісам в монорепозиторії , то сенсу робити проект пакетом немає.

Згоден, погарячкував :)

Дякую :)
От якраз цікаво, що для typescript є інструменти для полегшення роботи з монорепозиторіями, а для c# немає. Але наразі нам нічого особливого і не знадобилося — все залежить від того як вибудувати плин роботи і від розміру репозиторію.

А я все чекаю коли ти її напишеш)))

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

Теж таке є, але то вже про метрики — системні і бізнесові, grafana наше все. Це трішки інша тема і теж варта не меншої статті :)

Так, про логи дуже часто згадують коли «от, а як би ж були логи».

Так маєте рацію, економія ресурсів незначна. Але враховуючи що k8s сам слідкує за цілісністю свого кластеру, то в нас не виникало ситуації, коли дві master-поди не бачать одна одну, зберігаючи зв’язок з іншою частиною кластеру. Можливо у вас був практичний досвід як це відбувається?

Чому ж ніхто :) ELK якраз дуже мейнстрімна штука, а в поєднанні з Kafka може пережувати взагалі все. Але graylog виявився трішки простішим у налаштуванні і інтеграції в продукт. Простий підхід — з двох інструментів, що задовольняють твоїм потребам, вибери найменший і найпростіший. Наступним кроком розвитку буде вже ELK, якщо graylog стане замалим :)

Скільки завгодно логів можна будь-куди записати — наскільки зручно потім ними оперувати, не лише розробнику, але й службі підтримки, як у нашому випадку? Та й кастити логи в json нам не доводиться, за нас це graylog робить. Плюс можливість сповіщень, що налаштовуються в кілька кліків, плюс аналітика в дашбордах. Можна що завгодно побудувати з нуля, але можливо готові рішення вже закривають наявні потреби.

Радий, що наша стаття дарує позитив :) перші тези про відсутність логів/логи в файлах — це все ж таки про початкові етапи проекту, це не аксіома, але таке трапляється і це потрібно виправляти, бажано на чужому досвіді.
LDAP — так ми вористовуємо лише авторизацію в ui.
Використання реляційних БД для зберігання логів — спірне питання, не їх задача працювати з великим текстом, все ж таки ElasticSearch створений саме для цього, головне правильне налаштування.
Про BufferingForwardingAppender — знову ж таки це був проміжний етап в нашому логуванні, він замінений на асинхронний amqp апендер. А з буфером проблем не було, знову ж таки головне налаштувати не лише розмір буферу, а й періодичність його скидання.

помолились и в продакшн

Так вот об этом я и говорю. Почему должно быть иначе, если компания оплачивает это время и выделяет свои ресурсы — комп, интернет, удобное кресло и чай/кофе/плюшки, в конце концов. It makes no sense.

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

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

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

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