Jenkinsは先頃，Azure上で自身のインフラストラクチャを実行するために，Microsofrtと提携することを発表した。特に注目されるのは，Jenkinsの開発者向けインフラストラクチャ – 開発者Wiki，イシュートラッカ，データベース，静的なコンテンツ – が含まれていることだ。Azureへの移行により，Jenkinsサービスのワークロードの柔軟性が向上するだけでなく，従来以上のリソースが利用可能になる。
Jenkinsの現行のインフラストラクチャは，仮想マシンと物理マシンの混成で構成されている。コアマシンはOSUOSLがホストし，それ以外はAWS，Rackspace，物理的なデータセンタに分割されている。InfoQはJenkinsコミュニティのリーダであるR. Tyler Croy氏とコンタクトを取り，Jenkinsにとって今回のパートナシップが持つ意味を詳しく聞いた。
組織的に成長するプロジェクトの常として，Jenkinsのインフラストラクチャは無統制な拡大を続けている。それらを単一のクラウドプラットフォームに統合することにより，さまざまな領域でのメリットが期待できる，とCroy氏は言う。この統合によって，インフラサービスの稼働方法が大幅に再設計されることになるのだろうか？この疑問に対するCroy氏の答は，“配布/ダウンロードセンタのインフラストラクチャ設計と，コア開発者およびプラグイン開発者に提供中のビルド/テストサービスの再評価”を行なっている，というものだった。さらに，
マイグレーションそれ自体のメリットもたくさんあります。多数のサービスにおいてスケールセットを既定として利用であること，さまざまなDB利用サービスをサポートするスケーラブルなデータベースバックエンド，実際のインフラストラクチャトポロジをコードで定義可能なことなど，すべてがAPIで解決するようになります。既製サービス(CDN, Azure Container Service, SQL Serverなど)を活用することで，インフラストラクチャの部分的削減や，運用に関連する負荷の低減も可能になります。
クラウドへの移行は，予測不可能なトラフィックへの対応性も改善する。Jenkinsの場合，トラフィックはサービスによって異なっている。開発者用インフラストラクチャなど一部の(Wikiやイシュートラッカなど，さまざまな)サービスは，コミュニティの発展とともに，今後も段階的に拡張される。分散ネットワークやビルド/リリースインフラストラクチャなどにおいても，これまでより柔軟なワークロードに対応可能になる，と氏は説明する。このような柔軟性が，計算とネットワーク両方のスループット要件に適用される。先日のJenkins 2ローンチに伴って，現在は配布ネットワークに対する要件が大幅に増加している状況だ。
ワークロードをクラウドに移行する場合，もうひとつ考慮が必要なのがセキュリティに関する部分である。Jenkinsは先月報告された，セキュリティ問題と考えられる事象について報告している。この件での攻撃は，現行のアーキテクチャにおいて，単一のアセット上で過大なサービスを実行することによるものだった。
“Jenkinsnでは，プロジェクトのインフラストラクチャリソースに不足が発生すると，マシン上に配置されるサービスの数が過大になります。当社のインフラストラクチャをAzure内に分散して，サービス単位のインスタンスを(通常はサイズ的に)最小にすることと，さらには複数の仮想ネットワークを階層化することにより，システムに内在する将来的な問題の解決を図ることができるのです。” この問題の結論として，氏はこのように述べている。