Кастомная разработка — хороший способ выпустить продукт, который сделает клиента счастливым. Но практика показала, что стремление удовлетворить желания отдельных клиентов может привести к нежелательным последствиям на уровне платформы. 

Меня зовут Виктор Коноплёв, я руководитель продукта Private Cloud в VK Cloud. Расскажу, куда нас привела любовь к клиентам и кастомная разработка, как мы в итоге меняли архитектуру и перешли на создание автоматизированных решений.

С чего начиналось Private Cloud

Одной из ключевых особенностей развития VK Cloud является то, что мы сразу же ориентировались на построение облака на основе Open-Source-решений. Такой подход выбран ради создания Enterprise-Ready-решения, которое позволяет быть независимым от вендора. При этом мы не просто берём лучшее из OpenStack, в процессе адаптации к облачным реалиям многие из компонентов мы существенно модернизируем и оптимизируем для увеличения безопасности их использования и устойчивости к нагрузкам.


Пример Open-Source-компонентов.

Путь нашей платформы VK Cloud начался с публичного облака. Оно состояло из базовых продуктов: виртуальных серверов, дисковых хранилищ, инструментов аварийного восстановления, собственного S3. Со временем дополнительно запустили платформенные сервисы: управляемые базы данных и Kubernetes. 


Компоненты первой версии цифровой платформы VK Cloud до появления Private Cloud.

Однако было очевидно, что публичное облако подходит не всем клиентам: есть ряд компаний, которым по требованиям информационной безопасности (ИБ) запрещён сквозной выход в интернет, и они не могут размещать данные в публичных облаках. Например, из-за необходимости прямого доступа к внутренним системам, наличия сложных внутрикорпоративных интеграций или других факторов. Они вынуждены строить собственную ИТ-инфраструктуру или использовать готовые решения в виде частных облаков. 

Понимая это, мы инвестировали в создание нового предложения — частного облака Private Cloud, которое можно развернуть на мощностях заказчика в его дата-центре. В Private Cloud были добавлены все функции и сервисы, доступные на тот момент в публичном облаке. Вместе с тем специально для Private Cloud был написан новый инсталлятор (инструмент для запуска ПО) для развёртывания нужных компонентов инфраструктуры — тот, который был в публичном облаке, не подходит для частного. 

Первые клиенты и первые трудности

Для частного облака Private Cloud была создана отдельная независимая команда. Такое разделение было осознанным и позволяло нам больше ориентироваться на конкретных клиентов, особенности их инфраструктуры. Кроме того, наличие отдельной команды помогало нам реализовывать все пожелания клиентов и по запросу добавлять новые фичи в их инсталляции.

Одновременно с этим публичное облако продолжало развиваться независимо и делало это достаточно активно: его команда была в разы больше команды Private Cloud. Довольно быстро в публичном облаке появились новые сервисы и решения:

• магазин приложений,
  
• инструменты для Big Data и машинного обучения,
  
• инструменты для построения CI/CD,
  
• тарификатор,
  
• система биллинга,
  
• система мониторинга и алертинга,
  
• сервис для балансировки нагрузки между разными гипервизорами.
  

Обновлённый набор компонентов цифровой платформы VK Cloud.

Но изменения, которые мы вносили в публичное облако, не касались Private Cloud — сервисами занимались разные команды, которые вели параллельную разработку в разных направлениях и использовали разные инструменты деплоя. Со временем это привело к некоторым сложностям:

• Клиенты Private Cloud часто не имели доступа к функциям и сервисам, уже реализованным в публичном облаке: между компонентами публичного облака много сложных зависимостей, поэтому не все новые функции можно было реализовать в Private Cloud.
  
• Поддерживать десятки различных инсталляций под каждого клиента было сложно.
  
• Доставлять обновления компонентов в каждой отдельной инсталляции было дорого и долго, из-за этого между приватным и публичным облаком стал нарастать дисбаланс в функциональности.
  

Такое положение дел не устраивало ни нас, ни клиентов частного облака: они справедливо хотели пользоваться всем набором фич, которые уже были в публичном облаке. Мы решили устранить это несоответствие.

Анализ проблемы и поиск решения

Первоначальная структура публичного облака была довольно простой и очевидной: было несколько продуктов, которые на разных платформах мы доделывали под себя и разворачивали в публичном облаке.


Первая архитектура VK Cloud.

После запуска Private Cloud архитектура была расширена.


Архитектура VK Cloud с Private Cloud.

Впоследствии в набор реализуемых архитектур VK Cloud был добавлен ещё один вариант развёртывания частного облака с сертифицированными компонентами, разработанный для клиентов, которым нужно аттестовать своё облако по ФСТЭК. 


Архитектура VK Cloud.

С такой архитектурой и организацией работы поддерживать Private Cloud было затруднительно: сервис не был связан с публичным облаком, имел отдельный инсталлятор. Кроме того, общая схема работы двух сервисов была слишком сложной.

Итак, мы пришли к ситуации, при которой у нас было несколько независимо работающих команд, несколько вариантов развёртывания Private Cloud, много уже сделанных и работающих по разным схемам деплойментов. Поддерживать разные инсталляции было дорого, разрабатывать документацию под них — долго и сложно, а добавлять новые фичи сразу во все инсталляции часто вообще невозможно.  

Мы поставили себе задачу получать все новинки публичного облака в частном как можно быстрее. Это был двойной вызов: во-первых, на тот момент архитектура не была готова к таким изменениям, во-вторых, нужно было уйти от концепции двух независимых команд разработки. Решать эти задачи стали в комплексном подходе со всех сторон:

1. Объединить команды. Уход от концепции двух независимых команд помог нам увеличить количество специалистов и получить дополнительную экспертизу. Это помогло ускорить разработку и повысить её качество.
   
2. Собрать единое ядро компонентов. Мы подготовили общий стек сервисов, которые будут как в публичном облаке, так и в Private Cloud. В него вошли сервисы управления ресурсами облака, инструменты контроля доступа, система мониторинга и другие. При выборе сервисов мы отталкивались от необходимой функциональности и запросов клиентов: нам было важно, чтобы сервисы, которыми уже пользуются клиенты Private Cloud и публичного облака, остались доступными, и изменения на нашей стороне не отразились на непрерывности бизнес-процессов пользователей.
   
3. Протестировать все компоненты. Мы проверили сервисы ядра на стабильность работы в разных условиях и с разными инструментами.
   
4. Сделать общий инсталлятор и реализовать возможность его разного конфигурирования. Благодаря этому инсталлятор может по-разному настраивать компоненты для публичного облака и Private Cloud. Например, Identity and Access Management (IAM), который отвечает за идентификацию и контроль доступа, в публичном облаке может работать внутренним сервисом, а в Private Cloud — интегрироваться с инструментом для управления доступом.
   

Архитектура VK Cloud Solutions и Private Cloud.

Подобная глубокая переработка структуры позволила сделать Private Cloud точной копией публичного облака со всеми его функциями и возможностями, а также синхронизировать выпуск обновлений. Помимо этого, с такой архитектурой мы автоматизировали развёртывание и ушли от ручной настройки. 

Как результат, изменение подхода к архитектуре публичного облака и Private Cloud помогло ускорить их развитие. Например, если раньше Private Cloud работало только по одному сценарию (IaaS), то сейчас таких сценариев три:

• ИТ-инфраструктура как сервис. Объединение вычислительных мощностей компании во внутреннее облако с финансовым контролем по каждому проекту, автоматизированным предоставлением ресурсов по модели Pay-as-you-go (плата только за использованные ресурсы) и объектным S3-хранилищем. 
  
• Платформа для разработки. Ускорение и стандартизация написания приложений для микросервисной архитектуры с автоматизацией процесса разработки (создание кода, тестирование, интеграция тестовых и продуктовых сред) и инструментами для безопасности DevSecOps.
  
• Платформа данных. Объединение данных компании для анализа и монетизации. Private Cloud может выступать в качестве основы для единых хранилищ, озёр и витрин данных. 
  

При этом работа над сервисом и различными экосистемными подходами к оптимизации процессов разработки, развёртывания и поддержки продолжается. Так, в ближайшее время мы планируем добавить в Private Cloud VDI, Big Data и IoT. 

Какие выводы мы сделали

Создание коробочных версий продукта — нетривиальная задача, при выполнении которой возникает много соблазнов. Чтобы обойти трудности, с которыми мы столкнулись, рекомендуем следующие правила:

1. При разработке сложного продукта определить неизменяемое ядро и соблюдать правила:

• одно место реализации одной функции — не стоит делать много реализаций и кастомизаций в разных местах и командах;
  
• клиентам нужен API для управления инфраструктурой — он упрощает интеграцию с ландшафтом клиентов;
  
• любые доработки под клиента лучше реализовывать рядом, поверх стабильных API, или добавлять в ядро продукта после анализа и обобщения.
  

2. Нужно унифицировать технологии и процессы DevSecOps, включая:

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

3. Разделение команд — хорошее решение, но только если оно временное. По ходу развития продукта важно вовремя изменить организационную структуру и архитектуру сервиса: это поможет исключить несогласованность и получить дополнительные компетенции внутри команды. 

Private Cloud  от VK Cloud доступно для наших клиентов. Узнать о нём подробнее можно, если оставить заявку на официальном сайте.