Comments 11
Это же путь к монолиту, от которого и уходят в сервисной архитектуре
Даа… были не так давно микросервисы хайповой темой. Люди попробовали их, далеко не всем зашло связывать и огранизовывать этот балаган и хаос. Сервисы которые могут отваливаться по одному или которые надо запускать в определенном порядке. По итогу еще большой вопрос что хуже, монолит или головняк с пачкой сервисов.
Сервисы создаются для заработка. Зачем делать бесплатную библиотеку, когда можно создать
платный сервис и заработать на нем
Да, библиотека сильно проще устроена, чем сервис. Это касается кода, накладных расходов на использование (нет http-транспорта, например), тестирования системы в связке. Разумеется, монолит сделать проще и прагматичнее, особенно, на ранних этапах.
Тут можно поговорить преимущества отдельного сервиса перед встраиваемой библиотекой, например:
Разумеется, сервисная или (микросервисная) архитектура требует многих дополнительных компетенций и инструментов: kubernates, мониторинг, документирование, трассировка запросов и т. д.
Короче, согласен с автором. Но, кажется, уже все уже остыли к микросервисам и перестали иметь бредить, разве нет? Давно стал слышать про пресловутый «прагматичный подход»
Тут можно поговорить преимущества отдельного сервиса перед встраиваемой библиотекой, например:
- Масштабирование отдельно от основного приложения
- Возможность использования других технологий и языков
- Не нужно поддерживать dependecy hell
- Проще выкатка, в том плане, что нужно обновить один раз для всех.
- Легче иметь отдельную команду, кто это поддерживает
Разумеется, сервисная или (микросервисная) архитектура требует многих дополнительных компетенций и инструментов: kubernates, мониторинг, документирование, трассировка запросов и т. д.
Короче, согласен с автором. Но, кажется, уже все уже остыли к микросервисам и перестали иметь бредить, разве нет? Давно стал слышать про пресловутый «прагматичный подход»
«Крайние точки зрения всегда ошибочны! Рассматривайте проектирование как грязный, неряшливый эвристический процесс» — С. Макконнелл
«чем догматичнее вы будете в отношении методики проектирования, тем меньше реальных проблем решите» — Ф. Дж. Плоджер
Есть вещи, которые вы просто не сможете запихать в библиотеку — вроде тех же баз данных, очередей, диспетчеров событий, кэшей и т.п. Есть проекты, которые в виде монолита будут компилироваться очень долго и печально (особенно на С/С++, даже с namespaces). Есть системы, которые нельзя останавливать для апгрейда.
А по поводу микросервисов — так карго-культ еще никому не помог. Нужно думать как удовлетворить требования бизнеса подходящими в каждом случае средствами — а не как запилить самые «правильные» аджайл, UI-фреймворк и архитектуру бэкенда.
Еще, кстати, одна область где монолит плохо подходит — это event-driven системы. Где практически любые «хотелки» заказчика реализуются как внешние обработчики или инжекторы событий.
А по поводу микросервисов — так карго-культ еще никому не помог. Нужно думать как удовлетворить требования бизнеса подходящими в каждом случае средствами — а не как запилить самые «правильные» аджайл, UI-фреймворк и архитектуру бэкенда.
Еще, кстати, одна область где монолит плохо подходит — это event-driven системы. Где практически любые «хотелки» заказчика реализуются как внешние обработчики или инжекторы событий.
UFO just landed and posted this here
Event-driven — это одна из первых попыток избежать монолита и создать асинхронную, модульную и расширяемую архитектуру.
В монолите такие системы обычно чувствуют себя «не очень» — как минимум, из-за ограничений инфраструктуры. Например, конечного числа нитей в пуле, работающем на прием событий — для которого в монолите придется организовывать QoS для внешних по отношению к внутренним.
Ну и модель «разработка (ядро) + профессиональный сервис (кастомизация)» будет трудно реализовать без внешних по отношению к монолиту сервисов — а для них нужно будет городить отдельную архитектуру/платформу и т.п.
В монолите такие системы обычно чувствуют себя «не очень» — как минимум, из-за ограничений инфраструктуры. Например, конечного числа нитей в пуле, работающем на прием событий — для которого в монолите придется организовывать QoS для внешних по отношению к внутренним.
Ну и модель «разработка (ядро) + профессиональный сервис (кастомизация)» будет трудно реализовать без внешних по отношению к монолиту сервисов — а для них нужно будет городить отдельную архитектуру/платформу и т.п.
В случае с Java хотел бы ещё добавить, что иногда гибче и удобнее создавать стартеры.
У нас был проект, когда должен был выполняться поиск и фильтрация сущностей в обход базы данных, для максимального перформанса, in-memory. Обновления в эту систему загружались не сразу. Потом появилась необходимость фильтровать сущности без поиска, но всегда с актуальными данными из базы. Мы превратили модуль фильтрации в стартер, начали использовать стратер в старом проекте и на основе него бысро получилось создать новый сервис, который выполнял фильтрацию из базы. Всё без дублирования кода.
У нас был проект, когда должен был выполняться поиск и фильтрация сущностей в обход базы данных, для максимального перформанса, in-memory. Обновления в эту систему загружались не сразу. Потом появилась необходимость фильтровать сущности без поиска, но всегда с актуальными данными из базы. Мы превратили модуль фильтрации в стартер, начали использовать стратер в старом проекте и на основе него бысро получилось создать новый сервис, который выполнял фильтрацию из базы. Всё без дублирования кода.
Что-то как-то тема не раскрыта…
(Микро)сервис это когда, есть стейт, кода важен его собственный релиз цыкл и котроль над рабочей версией в один текучий момент и т.д. ещё более высокоурвоневые вещи. Библиотеками простите решают просто другой класс задач.
Sign up to leave a comment.
Пишите библиотеки вместо сервисов (если это возможно)