誰もがIT機器や通信インフラ機器を所有していますが、それらは老朽化が進んでいます。時が経つにつれ、経理担当者によって正式に廃棄処分される時期が来た時に、全てを更新するための資金やリソースを持っている人はほとんどいません。
つまり、私たち全員が、何らかのレガシー キットをその存在にしがみついていることになります。たとえそれが、1997 年以来謎の挙動を続けている、埃をかぶった「重要な」ACC コンゴ ルータというステレオタイプに完全には当てはまらないとしてもです。
インフラを今世紀に適応させるための 7 つのステップ ガイドを紹介します。
1. ハードウェアの陳腐化のタイムラインを描く
最初にすべきことは、陳腐化曲線に先手を打つことです。そのためには、所有しているハードウェアのうち、すでに時代遅れになっているものと、いずれ時代遅れになるものの 2 種類を考慮する必要があります。
財務部門の減価償却モデルの観点から、何かが最新ではないと見なされたからといって、それを廃棄しなければならないわけではないことに注意してください。たとえば、私はランダムに Cisco スイッチを選択しましたが、販売が中止されてから 6 年経つまで正式なサポートが停止されることはありません。
ただし、依存しているすべてのデバイスのタイムラインを作成し、時間をかけて交換の予算を立てられるようにする必要があります。
2. ネットワークを標準化する
ネットワーク技術とベンダーが混在している場合は、できるだけ少数（できれば1つ）にまとめましょう。これは、スイッチ1台あたり5,000ポンドもかけて最高級のブルーチップハードウェアを購入する必要があるという意味ではありませんが、少なくとも知名度が高く、適切なネットワーク標準をすべてサポートし、適切な管理層と実績のあるパフォーマンスを備えた製品を選ぶようにしてください。
最近はイーサネット ネットワーク テクノロジー以外のものを見つけるのは稀ですが、私は eBay で 24 ポートの Cisco Token Ring スイッチを 56 ポンドで見つけました... 退屈な古いイーサネットを使い続けるつもりです。
ちなみに、すべての電話、プリンター、デスクトップに 10Gbit/s イーサネットを導入するなんて無理です。ベンダーを標準化し、アクセス レイヤーでマルチスピード スイッチを選択するだけで楽になります。
3. クラウドに目を向ける
ハードウェアの寿命が有限であるように、ソフトウェアにも寿命があります。繰り返しになりますが、アプリのアップグレードが必要となる相対的な日付を示すロードマップを作成し、各アプリの寿命が尽きるかなり前に、次のバージョンをどのように実装するかを検討してください。
たとえば、私は Office 365 と Websense (または最近は ForcePoint Triton と呼んでいます) のクラウド ベース バージョンが気に入りますが、どちらの場合も、標準のローカル インストール バージョンを放棄して、より使いやすく柔軟なクラウド ベースの代替品を選択することで知られています。
私もクラウドベースのストレージを強く信じています。少なくとも低パフォーマンスのストレージをクラウドに仮想化すること（たとえば、オフラインのデータ アーカイブ）は、今後数年間で急速に普及するだろうと思わずにはいられません。
4. アプリケーションを統合する
これは大したことのように聞こえるかもしれませんが、私が言いたいのは、できる限り多くのアプリケーションに認証機能を統合すべきだということです。独自の社内ユーザーデータベースを持つレガシーアプリは、サポートとメンテナンスに多大な時間を浪費します。さらに、社員が退職した際にアカウントを効果的に無効化するという問題もあります。
クラウドベースの認証エンジンを採用する場合でも、単に内部 AD/LDAP ベースのシステムを構築する場合でも、膨大な数の異なる認証データベースを 1 つ (または少なくとも可能な限り少ない数) に移行する必要があります。
5. サーバーとストレージを仮想化する
物理サーバー上で単一のオペレーティングシステムを実行するのは、もはや時代遅れの手法であり、巨大な単一用途のマシン（例えば、巨大なマルチプロセッサ演算エンジンや巨大なデータベースサーバーなど）が絶対に必要な場合を除き、サーバーのパワーを有効活用する上で非常に非経済的な方法です。仮想化ストレージも同様です。SANベースのストレージ（10Gbit/sイーサネット上のiSCSIを使用して実装するのは非常に簡単です）を使用すれば、パフォーマンスへの影響をほとんど受けることなく、重複排除のメリットを享受できます。
サーバーキットが高性能で比較的新しい場合は、仮想化環境への再利用も検討できます。まず、あまり使用されていないマシンを1台選び、そのワークロードを別のマシンに移し、そこに仮想化環境をインストールします。次に、残りのマシンについても同様に、物理デバイスを徐々に拡張していく仮想環境に移行していきます。
6. サプライヤーを統合して削減する
アプリケーション固有のプロバイダーの時代はほぼ終わりました。15年前なら、特にソフトウェアやハードウェアの要件がかなり難解な場合は、数十ものプロバイダーと連携しても問題ありませんでした。しかし今日では、平均的な組織は2、3社のパートナーと連携すれば十分でしょう。場合によっては、本当に1社しか提供元がないような案件であれば、1、2社の専門業者と連携することもあります。
これは、アプリケーション自体を統合する必要があるという意味ではなく、提携する企業を統合する必要があるという意味です（例えば、OracleとSQL Serverの両方に同等の能力を持つデータベース専門ベンダーを複数知っていますが、両方をカバーできる優れたベンダーを採用し、ワークロードの変化に応じてそれぞれの専門分野を多様化したり、少なめにしたりするのはいかがでしょうか）。すべての卵を1つのバスケットに詰め込むことを提案しているわけではありませんが、サプライヤーの数を少なくすることで、管理オーバーヘッドが削減され、規模の経済効果が得られます。
7. 限界に挑戦することを恐れない
マシュー・ピアース、Flickr
最後になりますが、「最先端」の技術を導入した企業が失敗に終わったという恐ろしい話は、誰もが耳にしたことがあるでしょう。しかし、実際にどれほどの頻度でそれが当てはまるでしょうか？数年前、私はある組織で働いていました。その組織には、確立された技術の活用にこだわる「安定したサービスを提供しなければならない」という立場と、限界に挑戦する「より新しく、より速いものを今すぐ求めている」という立場の2つの明確な立場がありました。
実際、後者の方が安定していました。ソフトウェア パッチがリリースされたとき、より迅速に対応しました。ルーティングされセグメント化されたネットワークを持っていたため、ブロードキャスト ストームによる打撃を受けなかった組織内の唯一の部分でした。また、非常に珍しい「承認済み」ルーターの到着を待つのではなく、革新的なトンネリングを実行することで、最初に高速 WAN 接続を実現しました。
私は新しい Windows リリースの Service Pack Zero バージョンを使用するほど愚かではありませんが、将来を見据えて何か新しいものを試すことを恐れてはいけません。
私たちが今「明日」と呼んでいるものは、まもなく「今日」と改名されるでしょう。®
