С одной стороны термин CSP ввел гартнер, переименовав тот класс информационных систем, который ранее назывался ECM. С другой стороны это сделано, как ответ на изменения в требованиях пользователей к системам управления контентом, причем не столько даже функциональных требований, сколько технологических. И именно в этом и различие:
1. Микросервисная (не в маркетинговом смысле:) архитектура, поддержка деплоя в k8s
2. Бизнес-ориентированное API
3. Плагины/магазин приложений, богатая интеграция с популярными продуктами совместной работы (вообще CSP и CCP классы приложений постепенно объединяются)
4. Поддержка работы с несколькими разнородными репозиториями и т.д.
А Вы все верно пишете. В данном случае сложность приложения распределена между сервисами, а не сконцентрирована в одном месте. И если уйти от маркетинга к практике, то не всегда микросервисы это хорошо. На практике мы всегда комбинируем микросервисы там где это уместно и модульный подход с сохранением связанности кода на уровне компилятора, там где микросервисы создадут больше накладных расходов, чем пользы. Например, в интеграционном слое и при разработке обособленных бизнес-операций нагрузка на которые может существенно изменяться во времени удобно использовать микросервисы. В разработке прикладных приложений, например, личных кабинетов, на наш взгляд часто более уместен модульный подход.
Полная совместимость с PCI DSS не всегда востребована, но тут важно понимать, что соответствовать требованиям по безопасности должна не сама платформа, а конечное решение. Включая инфраструктуру на которой это решение развернуто.
Конечно же CSP платформы можно развернуть и на своем оборудовании и в России это основной сценарий развертывания. При этом чтобы получить максимальную отдачу от внедрения CSP требуется и определенная зрелость инфраструктуры и персонала заказчика. Например, крайне желательно наличие поддерживаемой заказчиком инфраструктуры kubernates. Но тут нужно оговориться, что CSP-платформа может быть развернута и как standalone решение, без использования kubernates. Это оправдано в небольших внедрениях.
Ответ на вопрос о предотвращении простоя сервисов, контроле критически важных компонент и т.д. опять же лежит в основе архитектуры CSP-платформ. В основе микросервисервисных решений практически всегда лежит kubernates. Решения изначально проектируются так, чтобы платформа следила за состоянием сервисов, падение микросервиса приводило к его перезапуску, а увеличение нагрузки на микросервис к запуску его новых экземпляров.
Если под «сменой вендора» имеется ввиду возможность развития внедренного решения не той командой, которая его создавала, то как как CSP-платформы в меньшей степени этому сопротивляются, нежели «закрытые» решения. У нас практически половина проектов по внедрению платформы сопровождается погружением команды разработки заказчика в устройство платформы и по результатам проекта мы передаем в т.ч. исходные коды платформы. В результате, поток запросов по развитию решения со стороны бизнеса в первую очередь отрабатывается внутренней командой. От этого выигрывает бизнес — скорость изменений, вносимых внутренней командой зачастую намного выше, т.к. отсутствуют бюрократические преграды.
1. Микросервисная (не в маркетинговом смысле:) архитектура, поддержка деплоя в k8s
2. Бизнес-ориентированное API
3. Плагины/магазин приложений, богатая интеграция с популярными продуктами совместной работы (вообще CSP и CCP классы приложений постепенно объединяются)
4. Поддержка работы с несколькими разнородными репозиториями и т.д.