Брайан Гарри (Brian Harry), занимающий пост Technical Fellow (аналог технического директора) в Microsoft, рассказал об успешной миграции разработчиков операционной системы Windows на свободную систему контроля версий Git.
Ещё 3 месяца назад стало известно об инициативе Microsoft под названием «виртуальная файловая система для Git» (Git Virtual File System, GVFS), в рамках которой инженеры софтверного гиганта адаптировали систему Git для работы над очень большими проектами/репозиториями: масштабирование Git осуществляется с помощью виртуального представления служебного каталога .git и рабочей директории, что позволяет программистам скачивать только нужные фрагменты из репозитория вместо его полного содержимого.
Текущую кодовую базу операционной системы Windows составляют 3,5 миллиона файлов, которые при загрузке из Git-репозитория занимают около 300 Гб. Над кодом работает команда, состоящая из 4000 инженеров. В 440 ветках Git-репозитория Windows ежедневно производится 1760 сборок, а также тысячи сборок для валидации pull-запросов. Когда весь этот код был помещён в репозиторий Git, к работе с ним приступили несколько сотен инженеров. Их число было увеличено на 2000 человек три месяца назад с переводом на Git команды Microsoft Windows OneCore, ранее использовавшей систему Source Depot. Проведенный среди них опрос показал, что около 72 % инженеров были удовлетворены работой с Git, а сильное неудовольствие это новшество вызвало лишь у 7 % разработчиков.
Дальнейшие поэтапные «подключения» к Git новых сотрудников привели к тому, что на сегодняшний день 3500 из 4000 инженеров Microsoft, работающих над Windows, пользуются Git. Статистика этого репозитория такова:
более 250 тысяч Git-коммитов в истории репозитория (за 4 месяца его использования);
8421 push в день;
2500 pull-запросов и 6600 инспекторов кода в рабочий день;
4352 активных topic branches;
1760 официальных сборок в день.
Обеспечивающая такие масштабы репозитория разработка Microsoft — GVFS — является Open Source-проектом, доступным для всех заинтересованных под свободной лицензией MIT на GitHub. В Microsoft предусмотрели, чтобы следующие инструменты для разработки поддерживали GVFS: Atlassian SourceTree, Tower, Visual Studio, Git for Windows. С подробностями о масштабировании Git с помощью GVFS можно ознакомиться в этой статье (англ. яз.).
Вчера компании Google, IBM и Lyft анонсировали новый Open Source-проект Istio, реализующий функции service mesh («сетки для сервисов») для приложений с микросервисной архитектурой.
Service mesh — это новая категория программного обеспечения, обретающая актуальность в связи с растущей популярностью облачных приложений (cloud native), микросервисов, контейнеров и инструментов для их оркестровки. По своей сути это выделенный слой инфраструктуры, обеспечивающий взаимодействие (доставку запросов) между сервисами, разнесёнными по контейнерам с учётом имеющейся топологии. Известная реализация службы service mesh — это проект linkerd, развиваемый фондом CNCF (Cloud Native Computing Foundation).
В основу анонсированного вчера Istio лёг другой Open Source-проект Envoy, разработанный в Lyft и написанный на языке C++11, характеризуемый как «прокси седьмого уровня (L7) и шина для взаимодействия». Envoy позволяет создавать фильтры как подключаемые плагины, работающие как на сетевом уровне (TCP/IP), так и HTTP (поддерживается и HTTP/2), поддерживает gRPC, имеет парсеры для сбора статистики в NoSQL-базы данных MongoDB и DynamoDB, поддерживает множество методов для обнаружения сервисов (Service Discovery) и балансировку нагрузки (с учётом доступности бэкенд-серверов).
Istio называется «открытой платформой для соединения микросервисов, управления ими и обеспечения безопасности». Istio позиционируется как готовое решение для решения таких актуальных для микросервисных и облачных приложений задач, как обнаружение сервисов, балансировка нагрузки, отказоустойчивость, мониторинг конечных точек, динамическая маршрутизация для экспериментальных возможностей, общая согласованность и безопасность.
В Istio для каждого сервиса разворачивается прокси-сервер Envoy как sidecar-контейнер внутри того же пода Kubernetes. Это позволяет не только изучать поведение трафика и применять нужные политики «на месте», но и разворачивать Istio в существующих инсталляциях микросервисных приложений без необходимости переписывать код или менять архитектуру. На данный момент Istio работает только с Kubernetes, но в ближайшем будущем авторы обещают добавить поддержку Cloud Foundry, Mesos и физических серверов (bare metal). Сайт проекта с подробной документацией на английском языке — https:istio.io. Исходный код Istio написан на языке Go, распространяется на условиях свободной лицензии Apache License v2 и опубликован на GitHub.
P.S. Подробнее о том, что такое service mesh и зачем он нужен, можно прочитать в этой статье (перевод материала от создателей Linkerd, опубликованного к релизу 1.0).
