Многие уроки, которые вы усвоите в крупных компаниях, часто невозможно напрямую применить к первому стеку стартапа. На этапе начального изучения необходимо оптимизировать развертывание с учетом скорости, стоимости и альтернативности. Альтернативность указывает, насколько быстро вы можете изменить направление в пределах определенной архитектуры.
Бизнес на этапах развертывания или извлечения в процессе разработки продукта может использовать архитектуру, ориентированную на службы или микрослужбы. Такой тип архитектуры развертывания редко подходит для стартапа, который еще не нашел подходящий продукт или рынок или не закрепился в коммерческой среде.
Для основного стека стартапа лучше использовать простую монолитную конструкцию. Такая структура ограничивает время, затрачиваемое на управление инфраструктурой, обеспечивая достаточную возможность масштабирования при росте числа клиентов.
Потенциальные варианты использования
В этой статье представлен пример простого базового стека стартапа и его компоненты.
Архитектура
Стартап Contoso создал прототип приложения с серверной частью в Ruby on Rails и интерфейсной частью в React, написанной на TypeScript. Команда Contoso выполняла демонстрации на своих ноутбуках. Теперь они хотят развернуть свое приложение для первых встреч с клиентами.
Хотя приложение очень функциональное, оно пока не требует сложной архитектуры на основе микрослужб. Компания Contoso выбрала простую монолитную архитектуру, включающую компоненты, рекомендуемые для стека стартапа.
Скачайте файл Visio для этой архитектуры.
Поток данных
Компоненты базовой архитектуры стека для стартапов:
- Служба приложений Azure предоставляет простой сервер приложений для развертывания масштабируемых приложений без настройки серверов, подсистем балансировки нагрузки или другой инфраструктуры.
- База данных Azure для PostgreSQL — это служба базы данных Azure для ведущей системы управления реляционными базами данных с открытым кодом. Вы можете сосредоточиться на разработке приложения, а не на управлении серверами баз данных.
- Виртуальная сеть Azure разделяет сетевой трафик и обеспечивает защиту внутренних служб от угроз из Интернета. Серверы приложений используют интеграцию виртуальной сети для взаимодействия с базой данных в обход Интернета.
- GitHub Actions встраивает непрерывную интеграцию и развертывание (CI/CD) в систему управления исходным кодом. GitHub Actions поддерживает большое число языков и тесно интегрируется со службами Azure.
- Хранилище BLOB-объектов Azure содержит статические ресурсы и снимает нагрузку с серверов приложений.
- Azure CDN (сеть доставки содержимого) ускоряет доставку содержимого пользователям через глобальную сеть.
- Azure Monitor отслеживает и анализирует происходящее в инфраструктуре приложения.
Базовые компоненты стека стартапа
Сложный стек может приводить к ошибкам, требующим постоянного внимания. Сложная архитектура может отвлекать ресурсы от создания продукта. Ошибки не возникают из-за самой сложности, но в сложном стеке больше рисков, что они появятся. Не все сложные архитектуры являются пустой тратой энергии, но они требуют много ресурсов, если вы пока не нашли подходящий продукт или рынок. Первый стек стартапа должен быть простым, чтобы вы могли сосредоточиться на разработке продукта.
На следующей простой диаграмме показан рекомендуемый базовый стек для стартапа. Этих компонентов достаточно для того, чтобы вывести продукт на рынок. Для 80 % стартапов этот стек содержит все необходимое для тестирования базовых гипотез по продукту. Для стартапов, работающих с машинным обучением и Интернетом вещей или в строго регулируемой среде, может потребоваться больше компонентов.
Сеть доставки содержимого
Если сначала у вас будет всего несколько клиентов, CDN пока не требуется. Однако добавление CDN к продукту, уже находящемуся в рабочей среде, может привести к непредвиденным побочным эффектам. Лучше реализовать CDN заранее. CDN кэширует статическое содержимое ближе к клиентам, а также предоставляет фасад, за которым можно выполнять итерацию для API и архитектуры.
Сервер приложений
Код должен где-то выполняться. В идеале эта платформа должна упростить развертывания, при этом требуя минимум входных данных. Сервер приложений должен масштабироваться по горизонтали, но некоторые действия по масштабированию можно выполнять вручную, пока вы все еще находитесь на этапе изучения.
Как и большая часть компонентов этого стека, сервер приложений должен выполнять себя сам. Раньше сервер приложений был виртуальной машиной или экземпляром веб-сервера, запущенным на сервере без операционной системы. Теперь можно использовать модель "платформа как услуга" (PaaS) и контейнеры, чтобы сократить операционные издержки.
Статическое содержимое
Обслуживание статического содержимого на сервере приложений приводит к потере ресурсов. После настройки конвейера CI/CD работа по созданию и развертыванию статических ресурсов в каждом выпуске требует минимум усилий. Большинство производственных веб-платформ развертывают статические ресурсы с помощью CI/CD, поэтому стоит начать с этой рекомендации.
База данных
После запуска приложения необходимо сохранить данные в базе данных. В большинстве случаев оптимальным решением является реляционная база данных. Реляционная база данных предоставляет несколько методов доступа и обеспечивает высокую скорость, проверенную временем. Реляционные базы данных включают Базу данных SQL Azure, Базу данных Azure для PostgreSQLи Базу данных Azure для MariaDB. Для некоторых вариантов использования требуется база данных документов или база данных NoSQL, например MongoDB или Azure Cosmos DB.
Объединение журналов
Если в приложении возникла проблема, провести диагностику следует в кратчайшие сроки. Объединение журналов и использование трассировки приложений с самого начала помогают команде сосредоточиться на самих проблемах. Вам не придется обращаться к файлу на сервере приложений и просматривать журналы для получения данных мониторинга.
CI/CD
Отсутствие повторяемых и быстрых развертываний существенно замедляет итерацию по продукту. Хорошо настроенный конвейер CI/CD упрощает процесс развертывания кода на сервере приложений. Быстрые и простые развертывания означают, что вы почти сразу сможете наблюдать результаты вашего труда. Частая интеграция позволяет избежать отклонений в базах кода, которые приводят к конфликтам слияния.
Развертывание этого сценария
Основные понятия и методики одинаковы для большинства проектов, создаваемых с помощью Dockerfile.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Автор субъекта:
- Эндрю Харви | CTO и адвокат по запуску