Описать переход на SaaS модель [закрыто]

Closed. Этот вопрос должен быть более целенаправленным. В настоящее время ответы не принимаются.

Хотите улучшить этот вопрос?Обновите вопрос, чтобы он был сосредоточен только на одной проблеме, отредактировав этот пост.

Закрыт 5 лет назад.

Каков процесс органичного роста от отдельного решения до программного обеспечения как услуги? Очевидно

Масштабируемость — это не «функция», добавляемая в конце разработки. ^

поэтому меня интересует высокоуровневый код и необходимые изменения архитектуры.

Можно ли выбрать существующую платформу и сверхнормализовать ее?
Можно ли начать заново с базовой облачной архитектуры, а затем перенести устаревшие функции?
Вписываются ли в этот процесс агрессивные технологические обновления (например, веб-формы > MVC)?

Обновление:

Меня попросили дать пояснения по текущей архитектуре проекта. Не вдаваясь в подробности, подумайте о приложении веб-форм .NET, которое подключается к уровню бизнес-логики и интегрируется с несколькими сторонними поставщиками. Всякий раз, когда требуются новые экземпляры платформы (здесь мне не хватает терминологии, я имею в виду, когда новому клиенту требуются корректировки бизнес-логики, интеграция с различными сторонними поставщиками, новый брендинг и т. д.)существующий код разветвляется и создается новая среда. Любые изменения фактически очень низкоуровневы, независимо от того, происходят ли они непосредственно в файлах aspx, коде компонента или конфигурации базы данных.

Этот сценарий кажется вполне подходящим для реализации «надлежащей» модели SaaS, но мне трудно внести конструктивный вклад в процесс миграции. Перефразируя первоначальные вопросы, которые были бы эффективной стратегией для подражания:

Сверхнормализация существующей платформы и создание всего настраиваемого, эффективно приостанавливая эту смоделированную масштабируемостьи не привлекая новых клиентов, пока архитектура не будет реорганизована. . Недостатком этого имхо является то, что по-прежнему полагаются на код и структуру, не предназначенные для масштабируемости (подробности ниже).
Начните с нуля с того, что считается (субъективно) лучшейархитектурой для будущего решения, а затем по мере необходимости переносите устаревшие функции. Это позволяет осуществить практически любую желаемую технологическую модернизацию, но до завершения ее не видно, и, поскольку это агрессивное изменение, руководство будет рассматривать его как неотъемлемо высокий риск.

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

Если приведенный выше контекст позволяет дать совет по конкретному сценарию, я приму его. Однако я по-прежнему открыт для более общих советов, которые можно и нельзя делать, и указателей, подходящих для более широкой аудитории.

задан o.v. 1 July 2012 в 23:48

0 ответов

Другие вопросы по тегам:

.net architecture cloud saas

Описать переход на SaaS модель [закрыто]

0 ответов

Похожие вопросы: