Преимущества реализации сред CI/CD на уровне проекта / приложения GAE по сравнению с уровнем обслуживания / модуля?

Question

В Naming Developer Environments Google предлагает 2 подхода для реализации различных сред CI/CD для приложений GAE

• основанные на разных сервисах (которые раньше назывались модулями) внутри одного проекта / приложения:

Если вы решите создать приложение для микросервисов, используя только несколько служб, вы можете создать один проект App Engine для каждой из ваших сред и присвоить им соответствующие имена, например: web-app-dev, web-app-qa, а также web-app-prod,

• на основе разных проектов / приложений:

В качестве альтернативы, если вы решите создать приложение для микросервисов с использованием нескольких проектов, вы сможете добиться одинакового разделения между средами, но вам нужно будет использовать больше проектов, таких как web-app-dev, web-app-prod, user-service-dev, а также user-service-prod, Вам нужно будет использовать шаблоны кода, чтобы обеспечить dev проекты называют только другими dev проекты и prod проекты называют только другими prod проекты.

Выражение в приведенных выше фрагментах документации, по-видимому, предполагает, что два подхода были бы приблизительно эквивалентны, но между этими двумя подходами есть по крайней мере одно существенное различие: подход, основанный на проекте / приложении, обеспечивает изоляцию данных, в то время как подход, основанный на услуге / модуле, этого не делает. - хранилище данных и memcache совместно используются всеми службами.

Более подробное сравнение между двумя подходами с точки зрения изоляции документировано в разделе Сравнение изоляции служб и изоляции проектов:

В следующей таблице приведено сравнение между использованием нескольких сервисов и нескольких проектов в архитектуре микросервисов:

У меня вопрос: кроме вышеупомянутых различий, есть ли другие преимущества использования подхода, основанного на проектах, по сравнению с подходом, основанным на услугах? Или что-нибудь, что можно считать недостатком?

Answer 1

Проектный подход также позволяет разделить проблемы с выставлением счетов и роли IAM.

Вы можете зайти так далеко, что вам будут начисляться разные кредитные карты, или просто установить лимиты биллинга независимо (кто хочет, чтобы prod снизился, потому что ошибка разработчика превысила ваш лимит биллинга?). Вы также получите отдельные отчеты о выставлении счетов, так что мы сможем легче определить, сколько будет стоить prod vs dev.

Сервисный подход потенциально минимизирует дополнительную административную работу. Например, если по какой-то причине вам нужно было настроить VPN или другие сетевые аспекты, один проект означает, что вам нужно настроить его только один раз, а не один раз для каждого проекта.