Хотя различные технологии, из которых состоит то, что было названо «Web3», вряд ли заменят огромные инвестиции в инфраструктуру и программное обеспечение, которые мы сделали за последние три десятилетия, в них все же есть кое-что интересное. Первый вопрос, который нам нужно задать: какие проблемы они могут решить?
Сторонники Web3 предполагают, что по сути это огромный набор потребительских технологий, которые могут заменить транзакционные основы Интернета. Я думаю о нем как о более ограниченном инструменте, который может основываться на технологиях блокчейна для поддержки подмножества корпоративных приложений с упором на электронный обмен данными (EDI). Это потому, что как только вы очистите блокчейн до его сущности, это будет неизменяемая структура данных, которой можно делиться между ненадежными партнерами доверенным образом. Это делает его полезным в цепочках поставок, где электронные документы имеют договорную и юридическую основу, закрепленную в международных договорах, и где один конец цепочки поставок имеет только косвенное отношение к другому.
Работа Microsoft над согласованными блокчейнами с доказательством членства, которыми управляют консорциумы ненадежных организаций, является здесь интересным вариантом, предлагая быструю и малоэффективную альтернативу системам с доказательством работы и доказательством доли. В то же время последние выпуски SQL Server теперь предоставляют неизменяемый реестр для приложений, которые не нужно распределять между различными объектами.
Вы можете думать об этих услугах, основанных на блокчейне, как о чем-то вроде электронного эквивалента коносаментов, используемых для описания морского груза, о чем-то, что проходит через несколько различных бизнес-систем без изменений, и где вы можете не знать все различные сущности, которые взаимодействуют с документов и договоров. Этими субъектами могут быть любые из первоначальных производителей, грузоотправителей, складов, грузовых судов, таможенных агентов, таможни и многих других. Всем нужен доступ к документам, и многим необходимо добавить свои собственные подписи в рамках сложного многостороннего процесса утверждения.
Мы могли бы встроить их в корпоративную цепочку блоков, но нам нужно начать думать о том, как мы будем использовать их в современной среде разработки. Мы уже создаем масштабные распределенные системы для облачных приложений с использованием devops и CI/CD платформ, поэтому можем ли мы использовать эти методы для Web3?
Использование корпоративных инструментов с блокчейном
Доновану Брауну из Microsoft было поручено изучить, как разработчики должны работать с этими платформами распределенных приложений. Сейчас Браун входит в инкубационную команду технического директора Azure под руководством Марка Руссиновича и больше всего известен своей работой в области разработки, поэтому неудивительно, что он быстро начал внедрять популярные платформы Web3 в среду разработки. У него есть хорошие результаты. Недавно я разговаривал с ним о том, как он смог использовать эти технологии с корпоративными инструментами.
Если мы хотим сделать эти инструменты готовыми к использованию на предприятии, они должны стать частью того, как мы создаем код, интегрируя его как с нашими платформами разработки, так и с нашими инструментами сборки и тестирования. Важно, чтобы инструменты, которые мы используем, избегали многих публичных бедствий, связанных с Web3, особенно при обработке коммерции и другой ключевой информации и потоках ценности. Нам не нужен смарт-контракт на коносамент, который можно украсть, чтобы изменить груз, доставляемый на наши склады, или даже перенаправить в другой пункт назначения.
Часть проблемы, которую определил Браун, заключалась в стремительном росте количества инструментов, которые предлагали несколько отличающиеся друг от друга наборы функций. Это ландшафт, который затрудняет понимание, поскольку нет ни очевидного набора инструментов, ни реального набора лучших практик, которые помогут вам создать этот набор инструментов. Это означает, что необходимо определить зрелые инструменты, поддерживающие лучшие корпоративные практики, с намерением поместить их в GitHub Codespace или сделать их доступными в одной из виртуальных сред разработки Microsoft Dev Box. В противном случае начать работу сложно, и нет простого пути к привлечению новых разработчиков в вашу команду.
Выбор инструментов — это только часть проблемы, которую, возможно, легче всего решить. Самая большая проблема заключается в том, что если вы используете передовые методы разработки, очень сложно втиснуть эти новые инструменты в существующие конвейеры. Как говорит Браун: «По мере того, как я углублялся в это, я понял, ничего себе, эти инструменты даже не предназначены для внедрения в конвейер». Слишком много полагаются на простые техники публикации, самостоятельное написание кода и его простую публикацию без формального тестирования. Этот подход очень хорош для самостоятельных экспериментов и прототипов, но он не масштабируется для предоставления кода корпоративного уровня.
Создание конвейера devops для смарт-контрактов в Azure
Как вы можете включить их в devops-конвейер? Во-первых, нам нужно перестать думать о технологиях Web3 как об изолированных от остальной части стека корпоративных приложений. Как только мы это сделаем, мы сможем найти точки интеграции, например, поместив смарт-контракты в систему тестирования и используя методы разработки, основанные на тестировании.
Теперь Браун смог создать распределенную среду приложений на основе Ethereum, которая использует Azure Pipelines с выводами Dev, QA и Production, а Azure Static Web Apps размещает внешний интерфейс приложения. Развертывания для разработчиков выполняются в частном экземпляре Ethereum в контейнерах Azure. Самая большая проблема для разработчика, использующего этот подход, — развертывание смарт-контракта в разных средах.
Оказывается, в смарт-контрактах жестко закодирован адрес, который автоматически добавляется в контракт JSON при его компиляции. Это требует перестроения всего контракта при каждом развертывании, что требует нескольких перестроений для каждой среды. Как отмечает Браун, это антипаттерн devops. Вам нужно скомпилировать только один раз, добавляя значения, специфичные для среды, во время выполнения. Это потребовало некоторой работы, чтобы переписать интерфейсный код приложения для поддержки внешнего источника сетевого адреса. Такой подход упрощает использование службы, когда не удается найти адрес контракта, с помощью функции Azure для доставки адреса при запросе.
Это позволяет коду Брауна создавать внешний интерфейс только один раз, поддерживая его использование на каждом этапе конвейера развертывания. Затем он мог использовать стандартные среды тестирования JavaScript со своим приложением. Все шаги, необходимые для создания и развертывания каждой среды из репозитория GitHub, можно было бы встроить в единый конвейер Azure, удаляя среды по мере проверки каждого шага. Здесь помогают такие инструменты, как Azure Container Apps, позволяющие быстро развертывать артефакты сборки.
С самого начала можно добавить поддержку дополнительных платформ в каждой среде, а также инфраструктуру в виде инструментов кода, таких как Bicep, и сценариев управления системой в Azure CLI и PowerShell, чтобы гарантировать, что у вас есть воспроизводимая среда и что вы можете предоставить готовое к запуску приложение и все серверы и службы, необходимые для его поддержки. Работа в Azure с использованием инструментов «инфраструктура как услуга» и «платформа как услуга» позволяет удалять неиспользуемые среды после того, как они больше не нужны, экономя деньги и гарантируя, что ваше приложение и его среда являются идемпотентным дистрибутивом. каждое изменение кода требует полного повторного развертывания всего приложения и поддерживающей инфраструктуры.
На пути к модели зрелости технологий блокчейн
Работа Брауна имеет большое значение для демонстрации того, как технологии Web3 могут быть встроены в знакомую корпоративную среду как часть современной среды приложений. Нет необходимости выходить за рамки привычных инструментов — GitHub, Azure Devops, Azure Container Apps, VS Code. Однако ясно, что необходимы изменения в том, как фреймворки Web3 работают с переменными среды и динамическими ресурсами. Они не предназначены для работы в многоступенчатом конвейере, и изменения необходимы, если они предлагают соответствующий уровень зрелости для масштабного использования в корпоративных приложениях. Также необходимо улучшить телеметрию, чтобы разработчики могли получить более четкое представление о том, как работают их приложения и контракты.
В результате получился интересный гибрид знакомого и нового. Это хорошо, так как разработчику легче внедрять новые технологии и внедрять их в существующие процессы разработки. Для таких компаний, как Microsoft, важно внимательно изучить новые технологии, поскольку они могут ускорить созревание новых инноваций. Компании могут предложить инкубационный путь от экспериментального до корпоративного, основанный на многолетнем опыте разработки корпоративных приложений как внутри, так и вне их собственных платформ.
