Я согласен, что нужен баланс гибкость vs сложность.
В то же время хочу обратить внимание, что это pet-проект. А для меня pet-проект - это не "запустить как можно быстрее и дешевле", а скорее "запустить что-то прикольное, при этом чему-то научится и/или попробовать и потыкать новый инструмент". В моем случае новый инструмент - Amvera, который закрывает часть с CI/CD пайплайном.
Если исходить из того, что запускаем проект на Amvera, вопрос Docker или не Docker не стоит - все будет запускаться именно в контейнерах, ибо под капотом Kubernetes.
А сам CI/CD для меня актуален: реализуя даже небольшие pet-проекты, я таки пришел к необходимости использования Docker (несколько причин, но наверно основная для меня: удобство при миграции между разными VPS, тем более если они на разных ОС), а потом и к тому, чтобы сборка была автоматизированной (связки github, github actions и dockerhub).
Неужели всюду так необходимо тащить с собой docker и героически решать проблемы, которые в нормальном мире просто не должно возникать.
ИМХО, мы уже в стадии, в которой нормальный мир - это когда любая разработка на выходе имеет Docker-образ.
Не скажу, что сильно долго думал на эту тему, но сходу вижу следующие причины:
SQLite поднимается локально внутри того же инстанса, в рамках которого будет работать Python. Таким образом, при рестарте мы будем терять состояния
Чтобы не терять состояния можно пробовать настроить сохранение в файлы - и даже положить их в persistenceMount в Amvera, но в контексте pet-проекта не хотелось дополнительно с этим заморачиваться
Лично для меня PostgreSQL куда более знакомый и понятный инструмент
Отмечу, что выводы и практические рекомендации по применению GreenPlum - хоть и сделаны на основе опыта конкретного проекта - но в целом универсальны для любых систем класса Campaign Management: с точки зрения СУБД нагрузка при построении сегментов и проведении batch-кампаний схожая, из какой бы системы это не запускалось.
В случае с Amvera вопрос Docker или не Docker не стоит, так как все запускается в контейнерах anyway.
Я согласен, что нужен баланс гибкость vs сложность.
В то же время хочу обратить внимание, что это pet-проект. А для меня pet-проект - это не "запустить как можно быстрее и дешевле", а скорее "запустить что-то прикольное, при этом чему-то научится и/или попробовать и потыкать новый инструмент". В моем случае новый инструмент - Amvera, который закрывает часть с CI/CD пайплайном.
Если исходить из того, что запускаем проект на Amvera, вопрос Docker или не Docker не стоит - все будет запускаться именно в контейнерах, ибо под капотом Kubernetes.
А сам CI/CD для меня актуален: реализуя даже небольшие pet-проекты, я таки пришел к необходимости использования Docker (несколько причин, но наверно основная для меня: удобство при миграции между разными VPS, тем более если они на разных ОС), а потом и к тому, чтобы сборка была автоматизированной (связки github, github actions и dockerhub).
ИМХО, мы уже в стадии, в которой нормальный мир - это когда любая разработка на выходе имеет Docker-образ.
Отличный вопрос!
Не скажу, что сильно долго думал на эту тему, но сходу вижу следующие причины:
SQLite поднимается локально внутри того же инстанса, в рамках которого будет работать Python. Таким образом, при рестарте мы будем терять состояния
Чтобы не терять состояния можно пробовать настроить сохранение в файлы - и даже положить их в persistenceMount в Amvera, но в контексте pet-проекта не хотелось дополнительно с этим заморачиваться
Лично для меня PostgreSQL куда более знакомый и понятный инструмент
Да, SAS на территории РФ больше не работает.
Отмечу, что выводы и практические рекомендации по применению GreenPlum - хоть и сделаны на основе опыта конкретного проекта - но в целом универсальны для любых систем класса Campaign Management: с точки зрения СУБД нагрузка при построении сегментов и проведении batch-кампаний схожая, из какой бы системы это не запускалось.