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