Как начать работу с Amazon Web Services 2: создание MVP

В прошлой статье мы рассмотрели, какие же программы AWS предлагает стартапам. Сегодня наш фокус сместится на то, как стартапу правильно построить MVP на AWS и те концептуальные вещи, которые являются основой основ (Core Foundation) AWS.

...

Что такое MVP?

MVP — это продукт, с которым вы можете выйти на рынок. Он состоит из трех простых понятий: Minimal-Viable-Product. 

Прежде всего, Minimal — это продукт, в котором находится минимальное количество необходимых фич, но при этом — не PoC (Proof-of-Concept, или доказательство осуществимости концепции — Startup Jedi) или набросок, а именно продукт, который может работать от начала до конца и привлечь пользователей. 

Viable — значит, что продукт может жить. Но также подразумевается, что это usable продукт, то есть его уже можно использовать, loveable — первые пользователи продукта его смогут полюбить, testable — его можно будет протестировать.

Настоящий Minimum Viable Product — это когда вы начали с построения скейта, потом доработали его до скутера, затем велосипед, мотоцикл, и в итоге вы построили машину. Именно таков естественный путь эволюции при построении продукта.  

Здесь уместно упомянуть Reid Hoffman,со-основателя LinkedIn, который говорил: «Если вам не стыдно за первую версию вашего продукта, с которым вы выходите на рынок, то это значит, что вы вышли на рынок слишком поздно». И это именно так, идеального продукта не бывает, над любым продуктом всегда нужно работать и постоянно его дорабатывать.

...

Процесс создания MVP

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

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

Итерации также должны быть непрерывными и короткими — не имеет смысла разрабатывать что-то 6 месяцев, не поняв, нужно ли это пользователям. 

Что важно помнить при планировании итераций?

Planning/Планирование 

Если рассматривать планирование как график, то в нем есть ось высокого и низкого влияния (вертикаль) — это тот результат, который получают ваши пользователи, и ось медленного или быстрого построения (горизонталь) — это время, потраченное на разработку. 

Эти оси образуют 4 квадрата:

Distraction. Если у вас есть то, что вы можете быстро построить, но это имеет маленькое влияние на ваших пользователей, то это просто очередной раздражитель, который отвлекает от построения вашего MVP.

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

Break Down. Если же у вас есть то, что хорошо повлияет на ваших пользователей, но вы не можете это быстро построить, то нужно разбить это на несколько частей и доставлять до пользователя частями. 

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

Minimize Task Size/ Уменьшение размера задач

Для уменьшения размера выполняемых задач их лучше разбивать на более мелкие, которые:

• Смогут выполнить 1-2 инженера, 

• Могут быть закрыты за 1 спринт,

• Добавляют инкрементальную стоимость вашему MVP,

• Легко приоритезировать, упростить и сделать более понятными. 

Например, уведомления для пользователей. Первая версия — простое e-mail сообщение без красивого форматирования, главное, чтобы оно было информационное. Следующая итерация — добавить разметку, детали, оценку по времени или какой-нибудь результат, а уже после этого можно добавить push нотификацию, смс — это и есть итерационный процесс для уменьшения размера задач, над которыми нужно работать одномоментно.

Standups

Очень важно, чтобы вся ваша команда — от разработчиков до топов — коммуницировала. В независимости от того, сколько вас в команде, 2 человека или 20, важно синхронизироваться и оставаться на связи каждый день. Сделайте общение простым и быстрым. Коммуникации добавят ясности всем, кто над чем работает и какие задачи стоят в приоритете, потому что стартапы двигаются очень быстро и приоритеты, которые были на прошлой неделе, на этой неделе могут перестать быть актуальными.

Continuous delivery 

Система  помогает постоянно обновлять продукт с новыми релизами и новыми фичами. Инструменты, которые использует AWS: CodeCommit, CodeBuild (continues integration система), CodeDeploy и все это преобразуется в CodePipeline. 

Это простые и легкие инструменты, которые менеджерятся за вас, у вас нет необходимости оформлять подписку на других ресурсах или следить за добавлением пользователей. Все находится в одном AWS аккаунте и здесь вы платите только за те ресурсы, которые используете. 

...

Что также важно учитывать — Core Foundations 

 «Стоит однажды проинвестировать в те вещи, которые в последующем будет очень сложно поменять».

Security

Одной из основных концептуальных вещей при создании продукта является информационная безопасность.

В Amazon есть понятия «one way door» и «two ways door». Первое — это, когда вы принимаете решения, которые в последующем будет сложно изменить, а второе — когда изменить принятое решение достаточно просто.

То есть, если вы недостаточно проинвестируете в защиту вашей системы, то в будущем вас могут взломать и вы потеряете доверие пользователей. Поэтому лучше настроить наиболее оптимальную безопасность с самого начала.

Безопасность — самый первый приоритет на Amazon. Мы оперируем такой моделью, которая называется «Разделенная модель для безопасности», когда мы со своей стороны берем на себя ответственность за безопасность data-центров, серверного оборудования, самого гипервизора или операционной системы, а вы — за приложения, которые строите и разворачиваете на нашей среде. У нас очень много инструментов, которыми вы можете воспользоваться для обеспечения информационной безопасности вашего приложения:  Amazon Cognito, Amazon CloudFront, AWS Secrets Manager, AWS Systems Manager, AWS CloudTrail и другие. 

Integration Point

У нас на платформе AWS реализованы возможности для ведения документации, есть расширенная документация: tutorials, видео, quick starts, которыми вы можете воспользоваться. 

Data Model and Store

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

Если вы выбрали реляционную базу данных, когда ваш бизнес и ваш продукт подразумевает связи между данными, если вам нужны транзакции, то у нас есть  Aurora и RDS. Если вы можете активизировать свои данные для того, чтобы хранить их в памяти, то это, как правило, супер «горячие» данные, сессионные данные или другие, предполагающие работу с очень быстрыми милисекундными данными, но с очень маленькими объемами — в этом случае можно использовать ElastiCache. Если вам нужен Key-Value в Storage или Document в Storage, то я советую посмотреть в сторону  DynamoDB или DocumentDB. Также у нас есть специальные базы данных: Graph, Time-series, Ledger, которые предназначены для совсем специфичных use case. 

В настоящее время на AWS больше десятка разных видов хранилищ данных, и если на самых ранних этапах создания продукта у вас возникли сложности с выбором, то лучше обратиться к нам, мы окажем помощь, чтобы в дальнейшем у вас не возникло проблем с ре-архитектурой.

Полное видео с презентацией Егора вы можете посмотреть тут:

В следующей заключительной статье мы будем разбираться в облачных решениях Amazon Web Services для построения архитектуры.