Библиотка VS Сервис VS Сайдкар.
Library vs Service vs Sidecar.
https://atul-agrawal.medium.com/library-vs-service-vs-sidecar-ff5a20b50cad
Подвернулась интересная статья со сравнением подходов к разработке переиспользуемой функциональности. Не со всем согласен, где-то в скобках прокомментировал, но аргументы хорошие.
Библиотека — переиспользуемый код распространяется как часть приложения. Код библиотеки работает в том же процессе и контейнере, что и код приложения.
Плюсы:
+ Сетевая задержка: код запускается в одном процессе с приложением, никаких расходов.
+ Доступность: общая доступность высока, т.к. нет сетевого взаимодействия (CAP-теорема)
+ Простота использования: библиотеку просто подключить (спорно: если у вас зоопарк языков, то чтобы подключить библиотеку, например, к C++, можно потратить много времени).
+ Тот же контекст окружения: память, процессор итд доступны для библиотеки как части того же контейнера (спорно: не очень ясно почему это преимущество, т.к. это ресурсы, за которые код библиотеки будет конкурировать с основным приложением)
Минусы:
- Ресурсы: за память, процессор итд библиотека будет конкурировать с приложением, что может вызывать разные проблемы.
- Технологии: может потребоваться несколько реализаций библиотеки (или для нее коннекторов), если у вас используются разные, например, языки программирования.
- Поддерживаемость: любые багфиксы в библиотеке требуют тестирования и перевыкатки всех использующих ее приложений.
Сервис — переиспользуемый код выносится в отдельный сервис/инстанс/контейнер, в который приложение ходит по сети, используя request/response механизм.
Плюсы:
+ Ресурсы: основное приложение и сервис задеплоены по-отдельности так, чтобы процессор, память итд не шарились между ними. Ресурсы могут оптимизироваться и управляться для обоих по-отдельности.
+ Поддерживаемость: сервис может выкатываться отдельно от основного приложения, так что релизы всех используемых приложения не требуются.
+ Технологии: сервис может быть написан с использованием любых необходимых технологий, главное, чтобы сетевой протокол с основным приложением был поддержан.
Минусы:
- Простота использования: сервисы менее просты по сравнению с библиотекой (спорно: для сервиса можно сделать удобный клиент, а библиотеку можно так обновить, что потребуется переписать половину приложения).
- Сетевая задержка: добавляются задержки при сетевых хождениях в сервис.
- Тот же контекст окружения: память, процессор итд основного приложения недоступны сервису, т.к. запущены чаще всего в разных инстансах. (спорно: не очень понятно, почему это минус).
- Доступность: общая доступность ниже по сравнению с библиотекой из-за хождений по сети.
Library vs Service vs Sidecar.
https://atul-agrawal.medium.com/library-vs-service-vs-sidecar-ff5a20b50cad
Подвернулась интересная статья со сравнением подходов к разработке переиспользуемой функциональности. Не со всем согласен, где-то в скобках прокомментировал, но аргументы хорошие.
Библиотека — переиспользуемый код распространяется как часть приложения. Код библиотеки работает в том же процессе и контейнере, что и код приложения.
Плюсы:
+ Сетевая задержка: код запускается в одном процессе с приложением, никаких расходов.
+ Доступность: общая доступность высока, т.к. нет сетевого взаимодействия (CAP-теорема)
+ Простота использования: библиотеку просто подключить (спорно: если у вас зоопарк языков, то чтобы подключить библиотеку, например, к C++, можно потратить много времени).
+ Тот же контекст окружения: память, процессор итд доступны для библиотеки как части того же контейнера (спорно: не очень ясно почему это преимущество, т.к. это ресурсы, за которые код библиотеки будет конкурировать с основным приложением)
Минусы:
- Ресурсы: за память, процессор итд библиотека будет конкурировать с приложением, что может вызывать разные проблемы.
- Технологии: может потребоваться несколько реализаций библиотеки (или для нее коннекторов), если у вас используются разные, например, языки программирования.
- Поддерживаемость: любые багфиксы в библиотеке требуют тестирования и перевыкатки всех использующих ее приложений.
Сервис — переиспользуемый код выносится в отдельный сервис/инстанс/контейнер, в который приложение ходит по сети, используя request/response механизм.
Плюсы:
+ Ресурсы: основное приложение и сервис задеплоены по-отдельности так, чтобы процессор, память итд не шарились между ними. Ресурсы могут оптимизироваться и управляться для обоих по-отдельности.
+ Поддерживаемость: сервис может выкатываться отдельно от основного приложения, так что релизы всех используемых приложения не требуются.
+ Технологии: сервис может быть написан с использованием любых необходимых технологий, главное, чтобы сетевой протокол с основным приложением был поддержан.
Минусы:
- Простота использования: сервисы менее просты по сравнению с библиотекой (спорно: для сервиса можно сделать удобный клиент, а библиотеку можно так обновить, что потребуется переписать половину приложения).
- Сетевая задержка: добавляются задержки при сетевых хождениях в сервис.
- Тот же контекст окружения: память, процессор итд основного приложения недоступны сервису, т.к. запущены чаще всего в разных инстансах. (спорно: не очень понятно, почему это минус).
- Доступность: общая доступность ниже по сравнению с библиотекой из-за хождений по сети.