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

Предпосылки для движения вперед

• Вы прочитали 1 часть серии
• Вы знакомы с фреймворками/методологиями, которые мы изучаем ниже, по крайней мере, просмотрев ссылки на видео, опубликованные в части 1 .
• Вы прочитали вторую часть серии

Не написав ни единой строки кода и не потратив денег , наши упражнения с «живыми документами», созданные в части 2 , выявили системные требования, которые определяют наши будущие потребности в инфраструктуре хостинга:

Нам не нужно немедленно удовлетворять все «сверх» потребности, но знание их при разработке и создании нашего MVP может помочь свести к минимуму переделки. Давайте узнаем, как!

Первоначальный объем MVP на основе карты историй и OGSM

eTumble готовится стать новым прорывом в онлайн-знакомствах. Наша команда мудро потратила время на проведение SWOT-анализа, задокументировала наш стратегический план на 3–5 лет с использованием OGSM Framework, визуализировала и расставила приоритеты для нашего MVP с помощью Story Mapping, а также разработала и задокументировала нашу архитектуру с использованием частей методологии модели C4.

Наш план OGSM определил первоначальную цель в 25 000 пользователей в год 1 и тактики для достижения нашей цели, такие как реферальная программа и демонстрации в кампусе колледжа. После нескольких итераций картирования историй мы остановились на нашей области MVP — и записали ее .

Если бы мы пропустили стратегическое планирование, чтобы определить важность рекламных акций, возможно, мы недостаточно повторили карту истории, чтобы остановиться на MVP, что помогает расставить приоритеты в том, что мы создадим в первую очередь. Еще страшнее то, что мы, возможно, назвали его «Mike's Match Maker» (выше) вместо нашего более крутого названия eTumble. ;-)

Быстрое попадание нашего MVP в руки предполагаемых пользователей даст нам лучшее понимание проблемной области и, следовательно, повлияет на решения на стратегическом уровне и уровне идей. Вот почему наши планы называются «живыми документами» и должны повторяться с течением времени по мере обучения.

Выбор нашей платформы облачного хостинга

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

В предыдущих частях этой серии я умолчал о том, что мы будем использовать Google Cloud Platform (GCP), поэтому я кратко объясню свой типичный подход.

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

В этой статье более подробно рассматривается сравнение двух популярных мобильных фреймворков, GCP Firebase и AWS Amplify , но они находятся за платным доступом Medium. По общему мнению, Firebase была более всеобъемлющей, простой в использовании и, возможно, более рентабельной.

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

Автоматизация развертывания нашего исходного кода

Помимо людей, ядром каждого запуска программного обеспечения является их исходный код — структурированный текст, который преобразуется в инструкции, которые компьютер может понять и обработать. Чтобы наши программы достигли целевой аудитории (при условии отсутствия «дымовой завесы MVP» на данном этапе), их необходимо развернуть в выбранной нами среде (средах) хостинга.

Одна из наших стратегий для eTumble — внедрять инновации быстрее других. Хотя это может описать многие аспекты запуска программного обеспечения, мы сосредоточимся на скорости разработки и скорости, с которой новые функции (пользовательские истории) могут быть реализованы конечными пользователями. Были проведены исследования, доказывающие, что это является конкурентным преимуществом, однако в этой статье мы не будем вдаваться во все подробности конвейеров DevOps и DevSecOps, а также CI/CD.

Как это происходит, зависит от личных предпочтений команды разработчиков. Многие поставщики хостинга исходного кода (например, Github.com, Gitlab.com или Bitbucket.com) теперь имеют собственные инструменты. Многие также предлагают веб-перехватчики, когда происходят события, запускающие сторонние решения. У каждого поставщика облачного хостинга также есть свои собственные службы, такие как Azure Dev Ops от Microsoft или Cloud Build и Cloud Deploy от GCP.

Обычно я рекомендую большинству организаций рассмотреть решение облачного провайдера, по крайней мере, на этапе «развертывания» ваших конвейеров сборки, потому что это устраняет необходимость делиться долгоживущими ключами служебной учетной записи (которые могут быть скомпрометированы) со сторонней организацией. система. GCP предлагает Workload Identity Federation , которая позволяет назначать роли IAM стороннему решению без совместного использования ключей, что также является опцией.

Рекомендации по масштабированию в облаке

Монолит или нет

Посмотрим правде в глаза, большинство успешных в мире программных стартапов сегодня начинались как трехуровневое монолитное приложение. Нет ничего плохого в монолитах на ранней стадии. Связывание сводит к минимуму многие технические сложности, и, как подразумевает «командная топология», эти решения часто связаны с когнитивной нагрузкой на вашу команду . С целью набрать 25 000 пользователей в первый год и сфокусироваться на кампусе колледжа, это вполне приемлемый дизайн для того, что предусмотрено нашим MVP.

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

На диаграммах архитектуры модели C4 мы определили «контроллеры» в представлении компонентов для приложения «Backend API». Например, строки, указывающие на публикацию сообщений в Pub/Sub, изначально могут включать логику микросервиса в приложении API на уровне «Модель» архитектуры Модель-Представление-Контроллер (MVC). Маршруты API остаются прежними.

При учете микросервисов мы можем перенести функциональность «Модель» из приложения API в отдельные сервисы и обмениваться данными через HTTP/RPC или асинхронный обмен сообщениями. Если вы планируете заранее, вы можете разработать слой-оболочку для вызовов функций или методов, которые первоначально взаимодействуют с уровнем данных, и перейти к удаленным вызовам в будущем с минимальными изменениями кода.

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

Переход на «бессерверные» технологии или использование контейнеров

В начале этой серии из трех частей я заявил, что современные стартапы программного обеспечения имеют преимущество перед стартапами даже пять-десять лет назад, отчасти благодаря гипермасштабируемым облачным провайдерам. Отличным примером являются бессерверные продукты, такие как AWS Lambda, Google Cloud Functions или даже Azure Functions. Разработчики могут помещать свой код в эти «среды выполнения» и получать выгоду от отсутствия обслуживания инфраструктуры и автоматического масштабирования.

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

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

Для создания API, который будет направлять запросы к различным внутренним частям, контейнеризованное приложение может быть более разумным выбором. Поскольку все зависимости упакованы в образ, контейнеры упрощают локальную разработку и тестирование. Большинство провайдеров облачного хостинга предлагают «бессерверные» контейнерные решения, такие как ECS на AWS и Cloud Run или App Engine Flexible на GCP.

Я предпочитаю переносимость контейнеров для более сложных приложений, и если вы следуете принципам 12-факторной методологии приложений , они также снижают риск смещения конфигурации в разные среды в конвейере CI/CD.

Приянка Вергадия из Google предоставляет коллекцию «набросков», и это ниже иллюстрирует « Где я должен размещать свои вещи » — это полезное руководство.

Использование групп электронной почты для масштабирования от одной до многих команд

Предположим, мы начали с нескольких человек, но наш план в конечном итоге требует поддержки десятков миллионов пользователей во многих странах. Мы, несомненно, расширим нашу организацию, включив в нее множество команд и специалистов (оси Y и Z масштабного куба AKF применимы и к нашей организации).

При настройке управления идентификацией и доступом (IAM) с облачными платформами рекомендуется назначать роли группам, а не отдельным пользователям. В статье, которую я написал пару лет назад о структурировании предприятий в облаке , я объясняю рекомендуемые начальные группы и многое другое.

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

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

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

Проектирование иерархии облачных ресурсов для мультитенантности

Этот контрольный список Secure GCP Reference , который я написал пару лет назад, включает наглядный пример рекомендуемого передового опыта. Поскольку мы разрабатываем нашу облачную архитектуру для нашего MVP, на ранней стадии может быть некоторая «выброшенная» работа, но я все же рекомендую аналогичную структуру при настройке любой иерархии облачных ресурсов.

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

на ранней стадии может быть некоторая работа «на выброс»

У GCP есть отличный справочник, в котором более подробно описывается, как установить корпоративную мультитенантность . Ниже приведена иллюстрация того, как облачная инфраструктура eTumble может выглядеть в будущем, когда мы достигнем целей Y2 и Y3 (без учета просмотра ресурсов для краткости статьи).

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

Внешние системы (аутентификация, платежи, электронная почта и т. д.)

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

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

Поздравляем! Эта серия из трех частей проведет вас по пути от полезных методологий и фреймворков к разработке запуска программного обеспечения с нуля и, наконец, к использованию «живых документов» для планирования облачной инфраструктуры как на раннем, так и на более позднем этапе.

• Часть 1: предыстория и введение в методологию
• Часть 2: внедрение методологий с фиктивным стартапом
• Часть 3: проектирование и масштабирование облачной инфраструктуры

Я с нетерпением жду, когда вы возьмете эти принципы и закончите там, где мы остановились, чтобы помочь решить проблему одиночества в планетарном масштабе . ;-)

Если вы считаете, что эта серия будет полезна другим, пожалуйста, не держите это в секрете. Дайте каждой части немного «любви» и хлопков и поделитесь с другими. Спасибо за чтение!