Делаем минимум жизнеспособным

Продолжаем цикл материалов о том, с чего начинается сервис. Мы уже знаем, как нащупать перспективную идею. Одна проблема: инструкция к нашим задумкам не прилагается. Поэтому все познаем на практике. Сегодня Оксана Новицкая, директор по развитию Облакотеки, расскажет о своем опыте построения объектного хранилища.

Нам казалось, что идея сделать своё объектное хранилище — очевидная.
Вроде бы у всех конкурентов оно уже есть. Но на деле было столько нюансов, задач и решений, что можно снимать сериал. Вот как это выглядело:

Формулируем идею по-человечески

Да, идею надо изложить так, чтобы она была понятной. Не «хранилище данных по S3-протоколу», а «клиент может хранить любые данные в облаке, работать с ними через S3-совместимый API, подключать к своим приложениям или бэкапам, и при этом всё — в РФ, стабильно, прозрачно, с поддержкой».

Проблема, которую решаем: бизнесу нужно надежное облачное хранилище с понятным биллингом и без плясок с бубном. В приоритете: все должно быть просто, понятно и чтобы можно было разобраться за 5 минут.

Собираем команду

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

Тимлид/Product Owner — это дирижер, который лучше всех видит итоговую картину. В нашем случае это я. Моя обязанность — поставить задачу и сформулировать, как сервис должен работать для клиента.

Архитектор, чтобы выбирать движок (MinIO, Ceph и проч.). Здесь важно сразу «заложиться» на будущее и решить, как масштабироваться и обеспечивать отказоустойчивость.

Инженер-DevOps, который будет все разворачивать, деплоить, настраивать, делать мониторинг и так далее.

Бэкенд-разработчик — пишет API-обертки, авторизацию, прикручивает биллинг.

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

Определяем MVP

Главный вопрос: что нужно пользователю, чтобы реально начать использовать хранилище? Ответ: создать бакет, получить ключи доступа, загружать объекты, выгружать объекты, посмотреть, сколько данных хранится и сколько стоит. Никаких жизненных циклов объектов, репликации по регионам. Только базовый сценарий — залить и достать, посмотреть стоимость.

Смотрим, на что точно нужно обратить внимание

Составляем список, без которого нельзя запускаться, даже в минимально жизнеспособном виде. В этом перечне:

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

Счётчики и биллинг. Нам важно понимать, сколько данных у клиента, чтобы честно брать оплату.

Надежность. Данные не должны теряться. Даже если умирает нода.

Мониторинг. Если что-то пошло не так — мы узнаем первыми.

Документация. Клиент должен за 5 минут разобраться, как залить файл.

Решаем, кто будет первым тестировать

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

С ними мы проверяли удобство и понятность интерфейса, совместимость с их инструментами (backup-софтом, медиасерверами). Кроме того, тестили скорость и устойчивость к обрывам.

Когда смотришь на готовый сервис, кажется: «ну, просто хранилище».
А за ним — десятки решений, выборов, компромиссов, тестов и чёткое понимание: что нужно пользователю прямо сейчас.

И только когда все эти вопросы проработаны, и решения приняты, можно признать MVP «живым». С ним, кстати, тоже отдельная песня, расскажем в следующий раз .

#Оксана_объясни

Облакотека / Оставить «бусты»