向こう15年、そしてその先のソリューション
Hellekson氏によると、未来のRHELにとっては次の3項目が「必須」だという。
利用可能なソフトウェアを増やし、プリインストールソフトウェアを減らす
RHELは今や、信頼されたシステムと依存性、ライブラリなどの供給源となっている。顧客は、Red Hatが検証済みのソフトウェアライブラリを提供することで、自らで検証作業について考えなくても済むようにしてほしいと願っている。このような顧客の要望に応えることで、Red Hatのサブスクリプションモデルは価値を増すわけだ。つまり、ハードウェアとソフトウェアのエコシステムを維持しつつ、新たな開発者を引き付けるために、かつ新たなインフラをサポートするためにプラットフォームを拡張することが目標となる。
その一方で多くのシステム管理者は、インストールディスク上のソフトウェアを減らし、例えばカーネルとglibc（標準Cライブラリ）だけにしてほしいと考えている。これにより依存関係が減少するとともに、最小構成が平易かつ自明なものとなる。
混乱を来さないアップデートを目指す
Hellekson氏は「アプリの動作に混乱を来さないよう、OSとAPIのやり取りを明確にしておく必要がある」と述べた。同氏はまた、Red Hatがリリースのペースや、ソフトウェアのライセンス条項、ライフサイクル関連の規則を簡素化する必要があるとも述べた。
同氏は「例えば、Red Hatのサブスクリプションモデルについて何も知らない場合、アップデートサポートの延長が必要だと言わない限り、そういった必要性があるとは分からないはずだ」と述べた。この他にも、プラットフォームを安定化して新たな環境やバージョンを導入しやすくしたり、ハードウェアとの依存関係を減らして混乱をもたらさないようにするといったことも含まれる。
さらなる自動化を推進する
Hellekson氏は「手作業によるシステム管理は時代遅れだ」と述べるとともに、「20台以上のマシンを前にした場合、『Red Hat Satellite』のような自動化ソリューションが必要となるはずだ。現在のRHELでは『Chef』や『Puppet』『Ansible』といったロボットによる管理の機会がほとんどない。われわれは人間だけでなく、ロボットも対象としてRHELを自動化していきたい」と述べた。
当てるべき焦点の1つは効率になるだろう。このような自動化は、JavaやC++、.NETといったテクノロジを用いてオペレータが配備するものになるはずだ。この場合、ライフサイクル全体を通じて、アプリケーションとハードウェアをサポート（ハードウェアベンダーと足並みをそろえることになる）し、セキュアで安定性の高いAPIとツールチェインを用いることになるだろう。
もう1つの焦点はアジリティだ。これは開発者の手により、「コンテナやクラウドといった抽象階層を積み上げたかたちで実現」されるはずだ。こういったアジリティの実現により、OSとOSソフトウェアの責務が再構成される。その実現にはJavaやNode.js、Ruby、Pythonといったテクノロジが活用される。これは、継続的にビルドや統合、配備が行われる環境で、手軽に使用できるツールと最新のセキュアなコンテンツを用いて、開発サイクルを高速に回すことで実現される。
RHELにとっての難関は、標準化され、仮想化されたIaaSやクラウドのソリューションを通じて、効率とアジリティという2つのニーズを満たすことだ。
