Я полностью согласен что этот проект – в первую очередь инструмент разработчиков и администраторов, направленный на повышение удобства создания и управления, снижения стоимости и сроков создания других проектов на своей базе.
И с этой стороны это все находится в компетенции ДИТО и ЛУКОЙЛ-Технологии.
Но, с другой стороны, отсутствие собственных компетенций у обоих структур в области разработки приводит к парадоксальным решениям – мы пытаемся создать платформу-инструмент для
«сферического разработчика в вакууме». Это то же самое если бы мы покупали строительные инструменты впрок для некоего подрядчика, не понимая ни специфики работы, ни конкретной работы которой предстоит заниматься.
Основной целью внедрения платформы должны стать снижение стоимости создания приложений и увеличение скорости внедрения и изменений.
На текущий момент любой подрядчик которого приглашают реализовать проект сначала разбирается в текущей инфраструктуре, потом пишет собственную архитектуру с учетом приложения и наконец согласовывает решение со всеми службами эксплуатации включая безопасность. Я надеюсь, что платформа должна позволить исполнителям получить исчерпывающую информацию по архитектуре решения, в рамках которой они реализуют свое и оно будет развернуто в кратчайшие сроки.
В решении соответственно должны присутствовать несколько слоев:
- инфраструктурный слой, позволяющий работать с микросервисами, создавать и удалять инфраструктуру для тестирования и исследований, динамически масштабировать сервисы в зависимости от нагрузки и гибко ими управлять. Стандарт де-факто в отрасли – виртуализация на базе Docker, с оркестрацией на разных сервисах (например Kubernetes) и обеспечением как взаимодействия между сервисами, так и изоляцией их друг от друга (например, через технологии
SDN)
- слой данных, позволяющий управлять различными типами данных, такими как табличные (MS
SQL, Oracle, Postgres SQL, MariaDB, SAP HANA, Oracle и т.д.), объектные (MongoDB), key-value хранилища, очереди, MQTT брокеры и т.д. В общем выбор технологии не имеет значения, она будет зависеть от решаемой задачи и объемов хранимых данных. Главное, что нужно понимать – развертывание нового хранилища при правильно выстроенном инфраструктурном слое – дело нескольких минут. Готовых контейнеров для Docker на данный момент более 170 000. И каждый из них – это какое-либо приложение.
- слой приложений и обработки данных – это просто различные приложения, выполняющиеся в виртуальной среде. И тут как со слоем данных – в первую очередь важна инфраструктурная составляющая. Я могу за пару часов написать простенький скрипт на питоне, который будет обрабатывать данные по загазованности среды и формировать результат. Еще пару часов займет создание контейнера для тестирования, в котором он исполнится. И важно чтобы была инфраструктура способная его выполнить и обеспечить всем необходимым взаимодействием.
Кроме самой архитектуры вызывают сомнения следующие моменты:
- после создания платформы, кто ее будет поддерживать (а это достаточно большой объем работ)
- кто будет управлять архитектурой платформы и приложений на ее базе
Мне кажется, что именно эти люди (в современной терминологии DevOp специалисты) должны решать что в платформе важно а что нет. В крайнем случае это должны быть разработчики.
Вообще архитектура решений достаточно разнообразна и зависит от задач. Конкретным примером может служить тот факт, что Майкрософт под каждую задачу предлагает различную архитектуру решения на базе своей платформы ( https://docs.microsoft.com/ruru/azure/architecture/reference-architectures/ ). Такое разнообразие требует эффективных инструментов планирования и контроля.

Еще один фактор – каждый разработчик обычно создает инфраструктуру тестирования приложения. И чем она ближе к основной – тем быстрее вносятся изменения. В идеале все должно происходить автоматически. Применительно к платформе – у него или должна быть копия, или мы предоставляем ему площадку для тестирования.
Также немаловажным является то, сколько разработчиков на данный момент могут уже работать с платформой.
Большинство участников рынка (разработчики) реализуют такие решения самостоятельно.
Команда создает, поддерживает и обновляет платформу в зависимости от задач и потребностей используя открытые и проприетарные компоненты. Это позволяет с высокой степенью соответствовать текущим требованиям. Но старт требует больших усилий и временных затрат
(особенно с учетом особенностей нашей корпоративной ИТ инфраструктуры).
Покупка платформы в этом случае – возможность быстро начать, но это получение технического долга, который со временем придется отдать. Или вендор платформы станет аутстаффинговым подразделением компании по платформе…
Конкретно по вендорам:
Microsoft: отличная платформа в облаке, множество возможностей, все функции управления инфраструктурой и даже больше. Поддержка всех открытых технологий и стандартов. Множество готовых инструментов для данных, машинного обучения, IIoT и т.д. Огромный опыт применения для создания различных приложений. Из вопросов – насколько это переносимо в частное облако, цена, какие функции будут потеряны при переходе в частное облако. Минусы – они предлагают платформу без бизнес-приложений (может и не надо).
GE: в основе – все тоже решение от Microsoft с его + и -. Но дополнено уже некоторыми готовыми приложениями и интересными инструментами. Вопрос – насколько эти инструменты применимы и нужны.
Siemens MindSphere – отличное решение для IoT, но по моему мнению – это 10 часть от всей платформы.
IBM: наверно лучшее решение в области машинного обучения и анализа данных. Но остальные сервисы – по остаточному признаку. Инфраструктурная часть не развита – использует openstack.
Возможно сможет работать на базе Microsoft
Цифра: предлагают разработать платформу на основе открытых технологий. Интересно, но мы и сами так можем. Не видно преимуществ…
С3: интересное решение в области машинного обучения. Создание моделей без программирования (или с минимумом). Возможно ускорит работу аналитиков данных. Работает все на том же Microsoft стеке.
SAP: все решения свои. Платформа в базе на основе открытых технологий, но модифицированная компанией. Опыта именно провайдера PaaS не много. Слой данных достаточно интересный, но реализован на собственной СУБД. Малое количество разработчиков под платформу (хотя они стараются добавить больше обычных языков программирования типа C# и Python). Цена.