На заре существования Facebook (когда он еще назывался thefacebook.com) Марк Цукерберг разместил его на серверах Гарвардского университета. В те времена компании покупали или арендовали физические серверы для запуска своего программного обеспечения. Появление облака в середине 2000-х годов изменило игру. Эластичность, которую оно обеспечило, во многом способствовала быстрому прогрессу, которым мы все наслаждаемся с тех пор. Требования, которые мы предъявляем к программному обеспечению, значительно возросли, и, соответственно, его архитектура стала гораздо более сложной. Однако за гибкость пришлось заплатить определенную цену — сложность соединения кода с инфраструктурой. Сегодня эта цена еще выше.
Герой контейнеров
Компания Heroku вошла в историю облачных решений как первая невероятно успешная попытка справиться с этой сложностью. Они возглавили первый крестовый поход, чтобы избавить разработчиков программного обеспечения от дракона сложности инфраструктуры. Людям это нравилось. Heroku стала пионером дико популярного подхода к развертыванию на основе контейнеров, который абстрагировался от бремени управления виртуальными машинами. Благодаря тому, что компания Heroku придерживалась своего мнения относительно использования контейнеров, она смогла привлечь широкий круг клиентов, желающих быстро создавать приложения. Контейнеры представляют собой взаимно изолированные процессы, связанные между собой сторонними конфигурациями, которые не входят в кодовую базу приложения — такой выбор дизайна приводит к отсутствию эластичности и гранулированного контроля над системой. Это приводит к консервативному подходу к работе с инфраструктурой, постоянному избыточному резервированию и, следовательно, переплате за потенциальную будущую нагрузку.
Кроме того, инфраструктура по-прежнему рассматривается отдельно от кода — эти два мира живут отдельно и мало что знают друг о друге. Проводки нужно делать гораздо меньше, чем, например, в AWS, но то, что осталось сделать — а это очень много — вам все равно придется делать самостоятельно. Heroku обменивает эластичность AWS на готовые компоненты строительных блоков, которые статически соединяются вместе с помощью комбинации команд CLI и операций на приборной панели. Конечно, Heroku ограничен своим основополагающим принципом: статические контейнеры как строительные блоки приложений. С Heroku действительно не нужно думать об инфраструктуре — но только в начале. Как только ваше приложение масштабируется, ваши счета накапливаются, и у вас не остается выбора: вернуться к AWS.
Бессерверная головоломка
Нам нужно поговорить о бессерверных технологиях. Serverless (вспомните AWS Lambda) — это новая модель выполнения облачных вычислений, в которой распределение машин происходит по требованию, а пользователь в основном абстрагирован от базовых серверов. С ней пришло знакомое обещание — разработчикам вообще не нужно думать об инфраструктуре. Несмотря на свое несколько контринтуитивное название (потому что, конечно, где-то всегда есть работающие серверы), serverless звучит как отличный идеал, к которому нужно стремиться. Все просто: разработчики хотят тратить как можно больше времени на создание бизнес-ценностей путем написания кода, а компании — не тратить состояния на DevOps. Кажется, что это святой Грааль, но есть одна загвоздка. Вы можете спросить: «Если вы говорите, что serverless — это так здорово, то почему мы все еще не перешли на него»?
Ну, serverless заставляет вас писать бизнес-логику приложений в виде функций, а не в виде более традиционной идиомы процессов с состоянием. Чтобы воспользоваться преимуществами serverless, вы должны построить свое приложение в виде множества обработчиков запросов или событий без состояния, что часто требует перестройки системы снизу вверх. Для некоторых случаев использования парадигма serverless работает, но во многих случаях разбиение вещей на дискретные, разделенные функции может быть неоптимальным или даже нецелесообразным. Следующий вопрос — можем ли мы получить свой торт и съесть его тоже? Можем ли мы сохранить парадигму stateful процессов и абстрагироваться от базовой инфраструктуры и оркестровки?
Инфраструктура из кода
В shuttle мы хотим расширить возможности инженеров, создав наилучший возможный опыт для разработчиков.
Мы уже разработали систему, основанную на аннотациях, которая позволяет развертывать приложения Rust одним нажатием клавиши, а также обеспечивать такие зависимости, как базы данных, с помощью статического анализа в режиме реального времени.
#[shuttle_service::main]
async fn rocket(
#[shared::Postgres] pool: PgPool, // automatic db provisioning + hands you back an authenticated connection pool
) -> shuttle_service::ShuttleRocket {
// application code
}
Опираясь на феноменальные разработки, сделанные до нас, мы видим лучшее будущее. Будущее, в котором разработчикам не нужно будет делать никаких «проводов», когда речь идет о коде и инфраструктуре.
В этом будущем инфраструктура может быть определена непосредственно из кода. Но не в том смысле, что «инфраструктура как код», а в том, что код, который пишут разработчики, неявно определяет инфраструктуру. То, что вашему коду на самом деле нужно в плане инфраструктуры, будет определяться по мере создания приложения, вместо того, чтобы вам приходилось заранее думать о том, какой элемент инфраструктуры необходим и как его подключить.
Эта установка также должна разрушить границы, которые удерживают контейнеры изолированными друг от друга (и, следовательно, затрудняют их оркестровку), не обязательно избавляясь от парадигмы контейнеров. Это не должно принуждать вас к какому-то определенному способу написания приложений, а просто быть продолжением вашего рабочего процесса.
Получить свой торт и съесть его тоже
Оглядываясь на успех Heroku, становится очевидным, что фокусирование на одном языке, Ruby, который в то время становился довольно популярным, было замечательной стратегией. Это позволило их команде сосредоточиться и создать непревзойденный опыт для своих пользователей.
В shuttle мы убеждены, что Rust — лучший язык для начала этого пути. Уже много лет подряд он является самым любимым языком разработчиков (а также одним из самых быстрорастущих языков). Если вы хотите создать лучший опыт для разработчиков — имеет смысл начать с самого любимого языка. Действительно, Rust — первый язык, оснащенный таким мощным набором инструментов для статического анализа и генерации кода, которые необходимы для создания лучшего опыта разработчика, когда речь идет об Infrastructure как от кода.
Сняв бремя работы с DevOps с разработчиков, многие из которых считают ее пугающей и стрессовой, мы не только сделаем разработку более приятной и эффективной, но и дадим возможность гораздо большему числу людей писать и выпускать приложения.
С самого начала все мы разделяли любовь к программному обеспечению с открытым исходным кодом не только с философской точки зрения. Мы убедились на практике, что лучший способ создания программного обеспечения — это совместная работа с конечными пользователями. Все это восходит к идее создания наилучшего опыта для разработчиков — так что для нас это не имеет значения.
Наше сообщество так же важно для нас, как и наше видение, поэтому если что-то из этого резонирует с вами — присоединяйтесь к нам на discord.
Также, если вам интересно узнать больше о том, как мы это создаем — загляните на наш GitHub.
Время обсуждений!
Учитывая все вышесказанное, что вы думаете об Infrastructure from Code? Мы будем рады услышать ваши мнения и вопросы!