Cloud foundry что это
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Pivotal Cloud Foundry
Pivotal Cloud Foundry — платформа для облачных систем, которая выступает в качестве некоего слоя абстракции для виртуальной среды (как виртуализация для виртуализации). Данная платформа разработана совместно Pivotal и VMware. Готовая к разработке инфраструктура предоставляет предприятиям безопасные, управляемые программным обеспечением вычисления, хранилища и сети, а также операционные инструменты, оптимизированные для контейнерных рабочих нагрузок и микросервисов. [Источник 1]
Содержание
Обзор
Суть в том, чтобы создать унифицированную площадку, на которой можно запускать любые приложения без привязки к конкретному облаку или гипервизору. То есть строительным блоком служит не виртуальная машина, а контейнер приложения. На контейнерах подробнее остановимся чуть позже, а пока разберемся, чем CF лучше привычного облака PaaS. Основанная на технологии с открытым исходным кодом, PCF позволяет предприятиям быстро предоставлять клиентам новые возможности, быстро создавая и развертывая новые приложения. Команды могут использовать любой язык / среду выполнения и использовать различные вспомогательные сервисы, откладывая большую часть операционной сложности на платформу. Кроме того, платформа включает в себя множество встроенных функций безопасности, которые помогают командам придерживаться общих требований InfoSec даже при ускорении разработки программного обеспечения.
Pivotal предлагает некую абстракцию для всем привычной IaaS-виртуализации, когда ПО выпускается в виде своеобразного «строительного кубика» без привязки к платформе виртуализации. Теперь любой разработчик может запустить свое приложение в среде Cloud Foundry, выбрав конкретное облако по желанию: VMware vSphere, AWS или OpenStack.
Google приносит Kubernetes на стол, инструмент для оркестровки с открытым исходным кодом. Pivotal добавляет платформу как часть сервиса с Cloud Foundry, а VMware добавляет уровень управления, чтобы собрать все вместе.
Кроме того, компания предлагает безсерверный продукт. Беcсерверные вычисления позволяют разработчикам создавать приложения, которые получают доступ только к серверу, когда он им нужен, обычно, когда определенное событие вызывает требование. Это экономит компании от затрат на постоянный запуск сервера, когда они нужны только для триггеров событий. [Источник 2]
История
Pivotal представила в ноябре 2013 года корпоративный дистрибутив Cloud Foundary — кросс-облачное решение для компаний, которые стремятся переместить рабочие нагрузки в облачные инфраструктуры. Pivotal CF призван обеспечить возможность запускать ПО в частном облаке и подключаться к различным сервисам. Цель компании, по амбициозному заявлению руководителей, — создать кросс-облачную платформу для прикладного использования.
Те, кто желает охватить максимальную аудиторию, должны предлагать приложения, работающие во всех распространенных облачных сервисах. И ни OpenStack, ни AWS, ни VMware не собираются сдавать позиции. Платформа Pivotal, предоставляя переносимость между облаками, претендует на решение глобальной проблемы. [Источник 2]
Функции платформы
Основные функции платформы:
Pivotal и VMware обеспечивают трансформацию приложений и инфраструктуры с помощью мощного набора возможностей полного стека, которые ускоряют бизнес-инновации. Готовая к разработке инфраструктура предоставляет предприятиям безопасные, управляемые программным обеспечением вычисления, хранилища и сети, а также операционные инструменты, оптимизированные для контейнерных рабочих нагрузок и микросервисов. Готовая к разработке инфраструктура сокращает объем ручных процессов и помогает командам разработчиков сосредоточиться на создании и доставке облачных приложений. Передовая технология виртуализации VMware максимизирует инвестиции в центры обработки данных, обеспечивая безопасность и стабильность предприятия. Организации полагаются на виртуализацию VMware и сети, ориентированные на приложения, для повышения гибкости, безопасности и соответствия требованиям ИТ при существенной экономии средств. Рабочие нагрузки могут быть развернуты быстрее, производительность и доступность увеличены, а операции автоматизированы, что делает ИТ-инфраструктуру более простой в управлении и менее затратной для владения и эксплуатации. [Источник 1]
Архитектура
Архитектурно Pivotal CF строится из так называемых «микросервисов», каждый из которых выполняет ограниченную роль.Микросервисы — это такой подход к построению архитектуры, при котором каждое распределенное приложение строится из множества более мелких «кубиков», отвечающих за свой узкий круг задач. [Источник 3]
Микросервисы
Архитектурно Pivotal CF строится из так называемых «микросервисов», каждый из которых выполняет ограниченную роль:
Сами программы размещаются в изолированных контейнерах со всем необходимым для работы. Формат контейнера предоставляет широчайшие возможности распространения. Пользователю не придется разбираться с установкой, добавлением необходимых компонентов и драйверов. Вместо этого он импортирует новый контейнер в облако и получит готовое решение. [Источник 2]
Вся инфраструктура Pivotal управляется централизованно, включая приложения и микросервисы. Микросервисы — это такой подход к построению архитектуры, при котором каждое распределенное приложение строится из множества более мелких «кубиков», отвечающих за свой узкий круг задач. Например:
Коммуникации между микросервисами и приложениями происходят с помощью максимально простых протоколов вроде http API. Так как каждый микросервис может разрабатываться и обновляться отдельно, упрощается добавление бизнес-функций приложения. Кроме простоты разработки, микросервисная архитектура заметно упрощает масштабирование. Вместо установки и настройки новых серверов и ОС нужно просто добавить «кубики» и подключить их к одному логическому приложению внутри контейнера. [Источник 4]
Сервисные компоненты доступны в виде единой веб-консоли. CF работает с тремя основными облачными системами: VMware, OpenStack и AWS. Такая гибкость позволяет внедрить платформу в широком круге компаний — как раз тот вариант, когда ставка на лидеров рынка облаков и виртуализации оправдывает себя в долгосрочной перспективе.
Основные требования к инфраструктуре VMware vSphere
Приведем основные требования к инфраструктуре VMware vSphere :
PaaS для VMware: что такое Pivotal Cloud Foundry
Контейнерная виртуализация и специализированные облака — тренд нашего времени. Возможность выпускать приложение в унифицированном формате под любую платформу привлекательна сама по себе. А если добавить сюда открытость, поддержку всех основных систем виртуализации и фокус на разработчиков ПО, то получаем любопытное решение для поставщиков программного обеспечения и их клиентов. В этой статье поговорим о платформенном облаке Pivotal CF и поищем ответ на вопрос, зачем оно нужно.
Компания Pivotal — обособленное подразделение EMC, кoторое разрабатывает продукты для виртуализации и облачных вычислений. Наиболее известным из них можно назвать Pivotal Cloud Foundry, который предназначен для упрощения жизни разработчикам ПО. Pivotal предлагает некую абстракцию для всем привычной IaaS-виртуализации, когда ПО выпускается в виде своеобразного «строительного кубика» без привязки к платформе виртуализации. Напоминает контейнеры, правда? По сути идея очень близка, но имеет свои особенности.
Теперь любой разработчик может запустить свое приложение в среде Cloud Foundry, выбрав конкретное облако по желанию: vSphere, AWS или OpenStack. Подход сулит серьезную экономию времени и сил на предоставлении доступа заказчикам к новым разработкам. А возможность работы с облаками нескольких типов еще больше повышают гибкость и решения.
Платформенное облако
Pivotal CF — платформа для облачных систем, которая выступает в качестве некоего слоя абстракции для виртуальной среды (как виртуализация для виртуализации). Суть в том, чтобы создать унифицированную площадку, на которой можно запускать любые приложения без привязки к конкретному облаку или гипервизору. То есть строительным блоком служит не виртуальная машина, а контейнер приложения. На контейнерах подробнее остановимся чуть позже, а пока разберемся, чем CF лучше привычного облака PaaS.
Platform as a Service (PaaS) — модель предоставления облачных вычислений, при которой потребитель получает доступ к использованию информационно-технологических платформ: операционных систем, систем управления базами данных, связующему программному обеспечению, средствам разработки и тестирования, размещённым у облачного провайдера.
Фактически Pivotal предлагает прийти к любому облачному провайдеру с собственным облаком-платформой, которое ставится поверх всех популярных IaaS. Зачем нужно так усложнять и почему бы просто не создать десяток VM на той же vSphere? Все очень просто: а вдруг вы хотите работать с Amazon, а не VMware? Или нужно распределенное по миру решение, а услуги облачных провайдеров в разных странах отличаются по платформе или цене за нее. В конце концов, можно построить огромное распределенное облако сразу из нескольких типов IaaS и вообще ничем себя не стеснять.
Контейнеры приложений
Так как основной целью Pivotal было создание платформы ни от чего не зависящих приложений, за основу была взята идея контейнеров (App Container). Контейнерная виртуализация не просто один из трендов нашего века, но и довольно удобный инструмент распространения ПО.
Контейнеры по перспективности сравнимы с облачными технологиями, и лидеры индустрии вкладывают значительные силы, чтобы приблизить идею к рынку. Контейнерной виртуализацией приложений активно занимаются Docker, Google, Pivotal и VMware, что позволяет рассчитывать на адекватный результат. В конечном счете предприятия смогут запускать запакованные в контейнеры приложения на привычной для них инфраструктуре VMware и гибридных сервисах vCloud® Air. Это позволит серьезно упростить внедрение приложений, ведь отпадет необходимость в постройке сопутствующей инфраструктуры.
Основным элементом контейнера является Application Instance — само приложение или его часть, основной строительный кубик при масштабировании. Каждый контейнер может состоять из одного и более Application Instance (AI), которые все вместе образуют конечное приложение. Запросы ко всем AI распределяются внутри контейнера.
Сами контейнеры — просто средство логической изоляции приложений друг от друга с мощными возможностями абстракции от среды исполнения. В контейнере виртуализируется операционная система и все необходимые ресурсы. Таким образом, каждая программа считает, что работает на собственном сервере с эксклюзивно выделенными мощностями. А с учетом запуска множества Application Instance в одном контейнере плотность и гибкость при масштабировании становятся впечатляющими.
Использование контейнерной модели с множеством Application Instance дает предприятиям следующие преимущества:
Архитектура Pivotal CF
Архитектура решения изображена на рисунке ниже.
Архитектурно Pivotal CF строится из так называемых «микросервисов», каждый из которых выполняет ограниченную роль:
Сами программы размещаются в изолированных контейнерах со всем необходимым для работы. Формат контейнера предоставляет широчайшие возможности распространения. Пользователю не придется разбираться с установкой, добавлением необходимых компонентов и драйверов. Вместо этого он импортирует новый контейнер в облако и получит готовое решение.
Вся инфраструктура Pivotal управляется централизованно, включая приложения и микросервисы. Микросервисы — это такой подход к построению архитектуры, при котором каждое распределенное приложение строится из множества более мелких «кубиков», отвечающих за свой узкий круг задач. Например:
Коммуникации между микросервисами и приложениями происходят с помощью максимально простых протоколов вроде http API. Так как каждый микросервис может разрабатываться и обновляться отдельно, упрощается добавление бизнес-функций приложения. Кроме простоты разработки, микросервисная архитектура заметно упрощает масштабирование. Вместо установки и настройки новых серверов и ОС нужно просто добавить «кубики» и подключить их к одному логическому приложению внутри контейнера.
Сервисные компоненты доступны в виде единой веб-консоли, что вполне в духе времени и актуальных тенденций. CF сейчас работает с тремя основными облачными системами: VMware, OpenStack и AWS. Такая гибкость позволяет внедрить платформу в широком круге компаний — как раз тот вариант, когда ставка на лидеров рынка облаков и виртуализации оправдывает себя в долгосрочной перспективе.
С точки зрения поддержки слоя виртуализации Pivotal CF довольно гибок, но все же лучше свериться c требованиями и подобрать подходящие версии компонентов vSphere (если облако строится на решении VMware).
Приведем здесь основные требования к инфраструктуре vSphere:
Если вы решите собрать собственное облако Pivotal CF, чтобы как следует разобраться в возможностях, рекомендую начать с официальной документации по развертыванию. Например, с Getting Started.
Применимость и перспективы
Ключевое преимущество PaaS от Pivotal в том, что решение включает в себя все привычные сервисы мониторинга, конфигурации, application-серверы и прочее. Только в случае с облаком все это поставляется под ключ и не требует отдельных усилий по настройке и поддержке. Таким образом, любое приложение в формате Application Instance сразу получает такие возможности и преимущества:
Разработчики обязательно оценят возможность запуска на одной платформе любого сочетания приложений на Java, Spring, Ruby Node.js, PHP, Python, Go. Единожды настроенное платформенное облако позволяет запускать и распространять ПО без привязки к компилятору и среде исполнения. Pivotal CF избавляет разработчика от головной боли с организацией стендов и пересборкой приложения под различные платформы.
Помимо усилий и времени, продукт позволяет экономить и на оборудовании с программным обеспечением (ОС, сопутствующие приложения). Это возможно за счет унификации платформы и высокой плотности приложений в виртуальной среде. Проще всего оценить возможности Pivotal на простом примере.
Пример использования Pivotal CF
Представим, что есть некая компания-разработчик с собственным приложением для совместной работы пользователей (некий менеджер To Do для небольших компаний). С выпуском обновленных версий каждый раз встает задача тестирования, включающая несколько этапов:
Если речь идет о паре релизов в год для нескольких приложений, то все это прекрасно делается руками без дополнительной автоматизации. Но если мы говорим о компании, чей основной бизнес — разработка ПО, то количество версий и приложений возрастает по экспоненте.
Основной болью для разработчика становится следующее:
В случае с написанием приложения под Cloud Foundry оно может быть сразу развернуто в окружении для команды тестировщиков. Пользователям будут автоматически назначены необходимые права, к приложению сразу подключены вспомогательные сервисы вроде MySQL. Более того, если нагрузка на программу потребует больших мощностей, то управляющий инструмент OpsManager применит политики приложения и распределит нагрузку по нескольким серверам и Application Items. Система управления может динамически разворачивать новые контейнеры для приложения на выделенных для этого VM и «подчищать» их, когда надобность отпадет.
Вместо заключения
PaaS-облако может быть полезно не только самим разработчикам ПО. Если распространять приложения в удобном кросс-платформенном формате контейнера, то установка новых версий или вариаций пользователями также сводится к простому импорту в собственное частное облако. А экономить усилия и повышать эффективность любят все компании, не только производители программного обеспечения.
Cloud Foundry
Развертывание и масштабирование приложений, не требующее настройки серверов и управления ими вручную
Что представляет собой Cloud Foundry?
Cloud Foundry обеспечивает безошибочное координирование всех аспектов сборки и развертывания программ с подключенными услугами, помогая тем самым добиться быстрой, согласованной и надежной итерации приложений.
Три варианта развертывания
Cloud Foundry Public
Выполняйте облачные приложения с помощью Cloud Foundry для достижения максимальной простоты масштабирования и управления трафиком. Потребление ресурсов измеряется в часах и динамически адаптируется к потребностям.
Cloud Foundry Enterprise Environment
Профессиональная одноарендная среда PaaS с подготовкой по запросу и средствами самообслуживания, обеспечивающая эластичное потребление ресурсов и полный доступ к административным функциям.
Cloud Foundry Private
Платформа Cloud Foundry, работающая в вашем центре обработки данных на вашей инфраструктуре.
Cloud Foundry Enterprise Environment
Теперь корпоративные пользователи могут запускать Cloud Foundry в изолированной среде, пользуясь при этом встроенными средствами интеграции с другими службами IBM Cloud™, включая искусственный интеллект, блокчейн, Интернет вещей и инструменты обработки данных.
Cloud Foundry Enterprise Environment (CFEE) работает на платформе Kubernetes и предлагает разработчикам доступ к полному набору знакомых инструментов в единой среде с централизованным управлением. CFEE позволяет ИТ-отделам защитить прежние инвестиции в Cloud Foundry и в то же время приобрести новые навыки, позволяющие создавать приложения для реализации новейших форм взаимодействия с клиентами.
Воспользуйтесь этими пошаговыми руководствами
Развертывайте безопасные веб-приложения в разных регионах
Этот учебник поможет вам создать, защитить и развернуть веб-приложение в нескольких регионах с помощью конвейера непрерывной доставки. Помимо многих других базовых приложений в IBM Cloud™, в этом учебнике используется базовое приложение Node.js.
Современные приложения со стеком MEAN
Этот учебник поможет вам научиться создавать веб-приложения с помощью популярного стека MEAN. В состав стека входят база данных Mongo, среда веб-разработки Express, фронтенд Angular и среда выполнения Node.js.
Анализируйте журналы и следите за работоспособностью приложения Cloud Foundry
Получите практический опыт эксплуатации службы анализа журналов для мониторинга работоспособности приложений Cloud Foundry на Python, работающих в облаке, и диагностики потенциальных неполадок.
Родственные продукты
Исполнение в облаке
IBM Cloud Kubernetes Service
Оптимизированная платформа Kubernetes для развертывания и эксплуатации кластеров. Масштабируйте свои традиционные и облачные приложения.
IBM Cloud Code Engine
Выполняйте код по запросу в хорошо масштабируемой бессерверной среде
Cloud Foundry в Azure
Cloud Foundry — это платформа как услуга (PaaS) с открытым кодом, предназначенная для сборки, развертывания и эксплуатации 12-факторных приложений, разработанных с использованием разных языков и платформ. В этом документе описываются варианты запуска Cloud Foundry в Azure и инструкции по началу работы.
Предложения Cloud Foundry
Для запуска в Azure доступны две разновидности Cloud Foundry: Cloud Foundry с открытым кодом (OSS CF) и Pivotal Cloud Foundry (PCF). OSS CF является версией Cloud Foundry с полностью открытым кодом, которой управляет Cloud Foundry Foundation. Pivotal Cloud Foundry является корпоративным дистрибутивом Cloud Foundry от Pivotal Software Inc. Мы рассмотрим некоторые различия между этими двумя предложениями.
Cloud Foundry с открытым кодом
Развернуть OSS Cloud Foundry в Azure можно, сначала развернув директор BOSH, а затем — Cloud Foundry согласно инструкциям, приведенным на сайте GitHub. Чтобы узнать больше об использовании OSS CF, ознакомьтесь с документацией от Cloud Foundry Foundation.
Корпорация Майкрософт прилагает все усилия, чтобы поддерживать OSS CF с помощью следующих каналов сообщества:
Уровень поддержки ресурсов Azure, таких как виртуальные машины, на которых выполняется Cloud Foundry, соответствует вашему соглашению о поддержке Azure. Максимальная поддержка сообщества относится только к компонентам Cloud Foundry.
Pivotal Cloud Foundry
Pivotal Cloud Foundry содержит ту же базовую платформу, что и дистрибутив OSS, а также предоставляет защищаемый набор инструментов управления и корпоративную поддержку. Чтобы запустить PCF в Azure, необходимо получить лицензию от Pivotal. Предложение PCF в Azure Marketplace включает в себя 90-дневную пробную лицензию.
Оно содержит такие инструменты, как Pivotal Operations Manager — веб-приложение, которое упрощает развертывание платформы Cloud Foundry и управление ею, и Pivotal Apps Manager — веб-приложение для управления пользователями и приложениями.
Помимо каналов поддержки, перечисленных выше для OSS CF, лицензия PCF дает право на обращение в службу поддержки Pivotal. Корпорация Майкрософт и компания Pivotal также установили рабочие процессы поддержки, которые позволяют обратиться за помощью к любой из сторон и, в зависимости от того, где обнаружена проблема, передать свой запрос соответствующим специалистам.
Azure Service Broker
Cloud Foundry придерживается методики 12-факторного приложения, которая основывается на четком разделении процессов приложений без отслеживания состояния и резервных служб с отслеживанием состояния. Компоненты Service Broker позволяют согласованно подготавливать и привязывать резервные службы к приложению. Azure Service Broker предоставляет некоторые из ключевых служб Azure через этот канал, включая службу хранилища Azure и SQL Azure.
Если используется Pivotal Cloud Foundry, то Service Broker также доступен в качестве элемента из Pivotal Network.
Связанные ресурсы
Подключаемый модуль Azure DevOps Services
Cloud Foundry идеально подходит для гибкой разработки программного обеспечения, включая использование непрерывной интеграции (CI) и непрерывной доставки (CD). Если вы используете Azure DevOps Services для управления проектами и хотите установить конвейер CI/CD, нацеленный на Cloud Foundry, то можете использовать расширение для сборки Cloud Foundry для Azure DevOps Services. Этот подключаемый модуль упрощает настройку и автоматизацию развертываний на платформе Cloud Foundry, работающей в Azure или в другой среде.
Как разрабатывается Cloud Foundry
Я кратко расскажу о процессе разработки Cloud Foundry (CF), особенностях open source модели и немного личного опыта.
В 2013 году я стал активным пользователем платформы, когда IBM запустила внутреннюю бету Bluemix, в начале этого года я принял участие в портировании Cloud Foundry на архитектуру POWER8, а с середины октября я стал членом CF core team, пройдя CF Dojo. Но обо всем по порядку.
Не буду углубляться в историю или объяснять что такое Cloud Foundry, но вот необходимый минимум фактов. CF — это Platform as a Service (PaaS), разработанная VMWare и позднее переданная Pivotal Software. Исходный код был открыт, сейчас еще есть отдельный инкубатор CF проектов. Чуть позже была создана Cloud Foundry Foundation, в которую вошли Pivotal, IBM, VMWare, EMC, GE, Intel, SAP, настоящее время в нее входит более 50 организаций. Изначально платформа была написана на Ruby, позднее часть компонент были переписаны на Go.
Теперь продолжу мою историю. Весной у нас уже была немного работающая версия CF на POWER8 и мы решили поделиться нашим кодом с сообществом. Сделали pull request для одного из компонент (BOSH) и стали ждать. Но ничего не происходило. У меня был некоторый опыт разработки OpenStack и там все было живее, рано или поздно кто-то приходил в твой патч в Gerrit, комментировал, ставил оценку, ты обновлял патч, пару месяцев — и твои две строчки в апстриме! Если везло, то можно было и за пару недель успеть. Вобщем мы стали разбираться и поняли следующее.
Дело в том, что CF использует agile процесс, основными элементами которого являются TDD и парное программирование. Да, парное программирование, помните XP? Не Windows XP, а eXtreme Programming. Core team работает именно так и эта модель рекомендована для всего сообщества. Очевидно, это предъявляет специфические требования к индивидуальным контрибьюторам, поэтому команда CF ставит на обучение и доверие, а не фильтрацию через code review. Для этого была создана программа Cloud Foundry Dojo.
Доджо — это место, где японцы занимаются боевыми искусствами, но в CF Dojo драться не придется. Эта программа открыта для членов сообщества, участие бесплатно. Сама программа крайне просто устроена — новый разработчик (желательно пара) минимум 6 недель работает вместе с членами команды CF. Через 3 недели он или она получает отзыв от новых коллег о том что можно улучшить, через 6 недель, если команда видит прогресс, он или она получает черный пояс. На самом деле не получает. Получает некоторый кредит доверия и изменения от этого разработчика гораздо быстрее принимаются командой, более того, он или она становится частью команды и может работать над общими задачами.
Я проходил CF Dojo в офисе Pivotal в Сан Франциско. Еще один зал недавно открыла EMC в Кембридже, Массачусетс. IBM скоро открывает свой в Research Triangle Park. Обычно работаешь в одной команде, в моем случае это был BOSH, компонент управляющий кластером. Команды стандартного размера, 6-12 разработчиков, один product manager. Между командами есть ротация, поэтому существует старейшина — якорь (anchor), разработчик, который редко (или никогда) покидает команду. Неделя начинается с Iteration Planing Meeting (IPM), заканчивается Retrospective Meeting. На первом менеджер продукта рассказывает что нужно будет сделать, на втором команда говорит что пошло не так, а что было сделано правильно. Каждый день начинается со Standup Meeting, где каждый рассказывает что было сделано вчера, что будет сегодня и какие есть проблемы. Вобщем, более-менее обычный Scrum. На standup команда разбивается на пары.
Пара садится за пару маков, которые ведут себя как один. Все машины в офисе одинаковой конфигурации, личных почти нет. У многих разработчиков свои клавиатуры, в остальном все общее, такой дзен. Пара берет первую свободную историю (user story) из трекера и начинает, нет, не писать код. Сначала пишутся тесты, обычно unit, но часто и integration. Потом пишется код. Код должен минимально решать задачу и пройти тесты. Потом делается рефакторинг, чтобы было не стыдно. В итоге изменения комитятся напрямую, без code review. Их подхватывает CI (используется собственная разработка Concourse и немного Jenkins, если интересно зачем было писать свое, почитайте). Если код не прошел пайплайн, пара вносит исправления. Когда все стало зеленым, история отправляется к менеджеру продукта, который может принять ее или вернуть на доработку. В итоге изменения попадают в следующую версию компонента, которая создается раз в несколько дней. Пары меняются раз в 1-3 дня, иногда смена бывает, когда работа над историей еще не закончена. Также нет специализации разработчиков, например кто-то занимается только OpenStack, а кто-то AWS — такого нет в принципе, истории распределяются достаточно случайно. Один день пишешь на Ruby, завтра на Go, потом правишь shell скрипты для CI или конфигурируешь AWS.
Я постарался все кратко описать, есть еще много красочных деталей, но они не так интересны всем, могу ответить на конкретные вопросы. Как видно, модель CF требует гораздо более глубокого погружения, осознанно жертвуя массовостью. Каждый подход имеет свои плюсы и минусы. Конечно, это не значит, что для weekend warriors невозможно принять участие в разработке CF, читайе код, находите задачи и шлите pull requests.