Каждому клиенту потребуется отдельный экземпляр приложения с собственным сервером.
[Метапункт для справки в будущем - его полезность, вероятно, низкая, поскольку вы уже внедрили свое приложение.]
Исходя из опыта поддержки систем, спроектированных таким образом, модель разработки, которая создает требование, чтобы каждый арендатор имел независимую инфраструктуру, будет дорогостоящей в обслуживании по мере масштабирования.
Более того, вне конкретных проблемных областей 1 это редко необходимо.Такие подходы обычно облегчают процесс разработки (избегая проблем, связанных с разделением модели данных для каждого клиента) с более дорогими и сложными операционными накладными расходами при развертывании и обслуживании службы в производстве.В частности, вы страдаете от следующих взаимосвязанных проблем:
Неэффективность затрат : каждому экземпляру вашего приложения требуются ресурсы для предоставления услуг.Дублирование этих ресурсов для каждого арендатора повлечет за собой значительные накладные расходы, связанные с прямыми расходами на оплату ресурсов и косвенными затратами на эксплуатационные накладные расходы, связанные с кодом доставки и обслуживанием вашего автопарка.
Несколько общих машин проще рассуждатьо и управлять чем машина для каждого арендатора, особенно если вы новичок в размещении производственного сервиса.Более того, если вы хотите воспользоваться SLA от Google, вы должны развернуть каждый экземпляр клиента в соответствии с его надежными принципами проектирования - что означает добавление избыточности за счет многозонных развертываний (больше затрат на инфраструктуру) для развертывания каждого арендатора.
Меньше пула ресурсов и эластичности : общедоступные облака работают очень хорошо , когда вы можете объединять ресурсы (особенно ЦП, память) и эффективно управлять своим приложениемпринятие решений о масштабировании в соответствии с вашими глобальными реальными потребностями, которыми пользуются все арендаторы.Модель развертывания для каждого клиента все еще может получить эти преимущества, но вы разбиваете свой масштабируемый домен на работу для каждого клиента.Если ваши арендаторы не являются крупными и имеют значительную инфраструктуру, это почти наверняка будет стоить вам дороже.Экземпляр каждого арендатора должен масштабироваться индивидуально, и вы, вероятно, заплатите за значительное количество незанятых экземпляров, которые будут работать, когда арендаторы не используют вашу систему.(Отказ от ответственности: я не знаю, что делает ваша система, поэтому я просто иду в отраслевые тенденции.)
1 К таким проблемным областям относятсяотрасли с высокой степенью регулирования, которым требуются жесткие границы для обеспечения строгой изоляции данных между пользователями системы;ничего такого характера, безопасности или проданы безопасности сознательных лиц (дискуссионные);случаи, когда унаследованные (локальные) приложения перемещаются из локального развертывания на одно арендатора в облачные развертывания без значительного рефакторинга данных или модели развертывания.
Это будетбудет легко с 2-3 случаями, но что, если есть 10-20 или 100-200?Как бы вы организовали экземпляры таким образом, чтобы вносить изменения во все из них, не тратя полдня на то, чтобы сделать это вручную?
Вам нужно будет сделать вашу модель воспроизводимой и гарантировать, что ваши процессы будутавтоматизирован.Все, что меньше, станет неуправляемым и неизбежно приведет к смещению между развертываниями, что сделает их особыми «снежинками», и со временем их будет сложнее рассуждать.
Существуют различные инструменты и подходы, которые помогают здесь:
Управление конфигурацией : инструменты типа Ansible или Соль .Желаемая конфигурация каждого экземпляра указывается декларативным способом в исходном коде.Вместо того, чтобы выполнять команды вручную (например, через SSH для каждой машины), вы делегируете конкретному инструменту интерпретацию желаемой конфигурации и изменяете конфигурацию удаленных экземпляров, чтобы заставить их сходиться к выраженному состоянию.Если машина умирает, вы можете легко заменить ее, повторно запустив плейбуки развертывания на чистом экземпляре.
Литейные образы : общедоступные облака делают дешевыми раскручиваниедо новых экземпляров.В отличие от физических машин, вы можете уничтожать экземпляры и воссоздавать их при каждом развертывании.Это продвигает шаги выше в вашей цепочке сборки, возможно, до того, как машины будут нуждаться в настройке для каждого арендатора (избегая дублирования усилий), а замена машин на хорошо зарекомендовавшие себя версии, построенные из чистого образа, помогает устранить дрейф.Такие инструменты, как Packer в сочетании со средством управления конфигурацией, помогают создавать общие образы, которые можно развернуть с помощью групп управляемых экземпляров .
Инфраструктура как код : такие инструменты, как Terraform выполняют работу, аналогичную инструментам управления конфигурацией, для декларативного определения вашей инфраструктуры - указание групп экземпляров и их конфигурации в коде, а неуказание и нажатие в консоли управления облаком.
Вывод ключа: эти инструменты помогают определить процесс, но сами по себе они не являются решениями.Вам нужно решить, какие шаги требуются в конвейере доставки, чтобы получить код от коммита до производства и реализовать , что .Эти инструменты помогут, но не являются панацеей.
Контейнеры
Если вам требуются индивидуальные развертывания, и уже слишком поздно менять архитектуру вашего приложения, вы можете рассмотреть возможность создания контейнераваше приложение и использует управляемую контейнерную платформу, такую как Google Kubernetes Engine , чтобы развернуть его.GKE позволит вам запускать общую инфраструктуру («кластер» Kubernetes) для каждого арендатора, таким образом получая выгоду от экономии масштаба в инфраструктуре, одновременно размещая независимый набор контейнеров для каждого арендатора в системе.
В этой модели ваш конвейер развертывания будет включать этапы создания образов контейнера из кода (с использованием вашей любимой системы CI или управляемой службы, такой как Google Cloud Builder ) и реализации процесса отправки этих изображений в производство.