クラウド運用管理、物理環境との違いは？
クラウド時代の運用業務はどうなるか？ものすごく簡潔に纏められた記事。
－－－－－
1回で分かる：クラウド運用管理、物理環境との違いは？
http://techtarget.itmedia.co.jp/tt/news/1403/05/news06.html
ーーーーー
まー結論は、物理の時とあまり変わらない。
ただ、コスト管理はなかったかな！
これまでは5年ほど利用することを見込んで、ドカッと投資。
どのサーバが、どのビジネスに利用されどのくらいの費用対効果があったか？など測定は困難だったのが、クラウド時代は可視化されるようになるのだというのが大きな気付きです(^^)/
【インフラエンジニアの将来】 メーカーエバンジェリストの見解!
先日、Microsoftのエバンジェリストである知人に会い、インフラエンジニアの将来について意見を伺いました。
以下、同氏の見解を備忘録目的で以下に記します。
▼最近では、開発環境（VisualStudio）上からクラウドの仮想マシンの立ち上げやスケールなどの操作が簡単に行えるようになった。
▼そして、仮想マシンのサイズ（パフォーマンス）も年々大きくなっているため、例えばロードバランサを絡めた複数台のサーバーなどの複雑な構成のシステムの需要も減りつつあるように思う。
▼また、あらゆる技術の進化によりインフラ部分を開発者でも操作出来るようになってきている。
▼小規模なシステムは上記の理由から、インフラエンジニアの出番がなくなっていくと思うが、それなりの規模のシステムは開発の片手間で出来るようにもなるように思えない。
▼現在、プロジェクトの現場では、開発側とインフラ側の乖離があるように思う。よってインフラのことが分かっている開発者、逆にアプリの都合を分かっているインフラエンジニアが少ないので、将来的には開発側の都合も理解したインフラエンジニアが重宝されるのではないかと感じている。とのこと。
【インフラエンジニアの将来】 キャリアアップするために
私が思う結論を先に言っちゃうと、これからのインフラエンジニアは
「上流」そして「マルチ」を旗印にキャリアアップを考えるべきだと感じています。
その理由を述べる前に言葉の定義をしておきます。ここで言うインフラエンジニアとはハードウェアやソフトウェアを調達（これからはクラウドプロバイダのサービスを調達）しユーザー企業のシステムインフラをインテグレーションするエンジニアのことです。またネットワークエンジニアやストレージエンジニアなども内包しインフラエンジニアとしています。
まず、ＩＴインフラの変遷を振り返ってみたいと思います。
ざっくりと、①大型汎用機時代 ②ネットワーク時代 ③モバイル・ビックデータ時代 に大別することが出来ると思います。
①大型汎用機時代
当時はビジネスに於けるITがカバーする範囲も限定だったことでしょう。
システムを定義・設計するシステムエンジニア、ソフトウェア開発を行うプログラマー、導入したシステムの運用・保守をするカスタマーエンジニアがいたとのこと。このころアプリケーション以外のOS やハードウェアなどのシステム管理はメーカーのエンジニアが自分たちで行っており、システム管理者と呼ばれていたようで、今のようなインフラエンジニアと呼べる職種は存在しなかったように思います。
②ネットワーク時代
この時代の特筆すべき事として「インターネット」と「ダウンサイジング」とがあるかと思います。
1995年のインターネット商用利用解禁を機にビジネスに求められるＩＴの範囲が拡大、企業はホームページを持ち、PCが1人1台配られオフィスアプリケーションを利用しメールでコミュニケーションするのが当たり前の世界に変貌。
またソースコードで配布されるUNIXの導入、Windowsに代表されるハードウェアとOSの水平分業、またその上に乗るパッケージソフトが充実など、オープン化した背景もあり、汎用機でシステムを維持管理するのは大変高価。またベンダーにロックインを嫌ってダウンサイジングの機運が高まった。
その結果、メーカーに頼らずシステム管理ができるようになった。このシステム基盤の管理を行うのが今のインフラエンジニアだと捉えています。
ＩＴの適用範囲拡大に呼応し、システムも複雑になりましたが一人のエンジニアがサポート出来る範囲は限られるため（中には全てを熟すスーパーエンジニアもいたとは思いますが）サーバエンジニア、ネットワークエンジニア、セキュリティーエンジニア、サポートエンジニアなる職種が出現。そしてこれらをひっくるめてインフラエンジニアと呼ぶようになったように思います。
③モバイル・ビックデータ時代
そして近年では、スマートフォン・タブレットのビジネス利用が浸透し、ＩＴの役割はコスト削減や業務効率化の枠を超えソーシャルやビックデーターなどに代表される新たな価値創出の重要手段となりました。このことからビジネスに求められるＩＴの範囲は更に拡大し、システムはより複雑になって来ていると思います。
ここまでを纏めると下表のようにまとめられると思います。
適用範囲 複雑性
①大型汎用機時代 低 低
②ネットワーク時代 中 中
③モバイル・ビックＤ時代 高 高
ここまでを見ていると、今後も益々拡大・複雑化したシステムを支えるため、更に職種も細分化されるように思いますが、注視しなければならないことがあると思っています。
それは技術革新による「抽象化」の視点です。
各種便利なツールが登場した結果、エンジニアは細部にまつわる知識が薄くても取扱うことが可能となり、生産性も向上しました。また、より多くのもの（機能）を扱うようになりました。
例えばGUIの登場によりコマンドを知らなくてもOSやアプリが操作可能になり、配布ツールの登場により多数のマシンを個別対応しなくてもよくなりました。反面、冗長化・仮想化などの新たな機能が当たり前のように求められるようにもなりました。
そしてこの抽象化は、昨今のクラウドの台頭によりさらに顕著になっているように感じます。パブリッククラウドを基盤にするのであれば、もうサーバやストレージ等のハードウェアに触ることもなくなるのですから。。
話の本題であるインフラエンジニアの将来に話を戻しますが、インテグレーターの本質的価値は、顧客の要望に対し実在する技術でインテグレーションし、その要望に応えることです。顧客視点でどのようなエンジニアを求めるかを問うてみれば、例えばネットワークのデザインもでき（上流）、CiscoのコマンドもYAMAHAやSONICのその他多種の機器に慣れ親しんだ（ディテール）エンジニアより、ディテールの知識はなくてもネットワークもサーバーもストレージも、良質なコミュニケーションで要望を引き出してくれ、クラウドやツールなど便利な手段を駆使し、要望も満たすことの出来るエンジニアが求められるのではないかと思うのです。
以上のことから「上流」そして「マルチ」を旗印キャリアアップを考えるべきだと感じています。
2014.03.14更新
---------
IPAがこのような報告書発表してたんですね(^^)/
クラウド時代の人材育成検討委員会報告書
http://www.ipa.go.jp/jinzai/itss/activity/itss_cloud_houkoku20110519.pdf
OpenStackDaysに行ってきました！
会場が御茶ノ水ソラシティカンファレンスセンターということもあり、この手のカンファレンスの中では小ぶりな感はあるものの、2年目の開催で講演会場も満席でしたので注目の高さがうかがえました。
「OpenStackクラウドを最大限利用するには」という講演を聞きました。
瞬時にサーバー・ストレージ・DB等のリソースを構成でき、状況に応じて調整出来きる点。また、管理するツールも多数リリースされOpenStackを基にエコシステムが、成熟段階にあることも分かりました。
ただ、OpenStackに限られたことではありませんが、複雑化するシステムインフラに仮想化に加え今度はクラウド管理と、管理要素が増え、益々複雑化するシステムをユーザ企業がオンプレミスで維持・管理することを考えると、大規模でないと活かすことが出来ないのだろうと感じました。
エンタープライズシステムとクラウドの相性 は悪い!
何故、エンタープライズシステムのクラウド化が遅かったのかを考えてみました。
【そもそもクラウドの価値ってなんだっけ？】
NISTの定義が前提とはなりますが、
クラウド（IaaS）導入ががもたらす主な価値として「アジリティ」「スケール」「アウトソース」「コスト」をあげることができるかと思っています。
従来のオンプレミスに比べ、圧倒的にシステム調達・構築時間が短縮、変化に柔軟・俊敏に対応できること。⇒「アジリティ」
需要の変動に対して自社では実現不可能なほどの大規模なプロビジョニングができます。⇒「スケール」
そして、耐震・空調などの設備・サーバやストレージ等のハードウェア（場合によってはＯＳやミドルウェア）を、自ら調達・維持管理しなくてもよい。専門家にお任せ出来ること。⇒「アウトソース」
また、規模の経済性が働き、コストを抑えて調達・維持管理できるということだと思います。⇒「コスト」
【WEB系システムと比較してみる】
そこで、先行して導入が進んだソーシャルやゲームなどに代表される、「WEB系システム」と、やっと導入事例が出始めた「エンタープライズシステム」との性質の違いを、上記クラウドの価値が享受できるか？という観点で比較してみました。
Enterpriseシステムには、WEBシステムのように、利用者の反応を見てサービスを変えることや、利用者が短期間で急増する等のことは少なく、比較的、予測や計画がしやすいのではと思います。利用するのが企業の社員が中心なので、1年で数十倍になる、」なんてことは考えにくい。
結果、エンタープライズもクラウドのメリットは享受出来るが、WEB系システムほどではないな～というのが率直な感想です。
如何でしょうか？
日本におけるクラウド普及のカギとは？
【Ｉａａｓは今後どの様に普及する？】
今、わたしの一番の関心事である。クラウドコンピューティング（IaaS）は今後、どの様に普及するのでしょうか？
アメリカは日本の数年先を進んでいる！とは、よく耳にしますが、だったら先が分からず困ったときは、アメリカを見れば解決！ってことになりますよね。
しかし、参考には出来ても物事そんなに単純には行きません。アメリカでヒットしたものが日本で同じように普及するわけではない。 それは多分、国民性や社会構造など「環境」が違うからなのでしょうね。この環境というフィルタを通して考えなければ見誤る可能性があると思います。
【クラウドにおける環境の違い】
昨年、AWS Summitで、アメリカのＩＴエンジニアは主にユーザー企業に所属しているということを知りました。
http://www.ipa.go.jp/jinzai/jigyou/global-report.html
日本はＩＴエンジニアの7割がＳＩベンダーに所属、残る3割がユーザー企業に所属しているのに対し、アメリカは全く逆で、7割がユーザー企業に所属、残る3割がＳＩベンダーに所属しているそうです。
この事実を知ったわたしは、日本でのクラウド普及には、クラウドプロバイダーと、既存ＳＩベンダーとの連携が重要だと思うようになりました。
【ＳＩベンダーも儲かるクラウド】
普及のカギは「既存ＳＩベンダーも儲かるクラウド」にしなければならないと思うのです。
何故なら、エンジニアの分布からも分かるように、日本のユーザー企業はＳＩベンダーに頼っている。ということが言えると思います。
ユーザー企業のＩＴ責任者は、既に信頼のあるＳＩベンダーが推奨する（責任をとってくれる）システムでないと導入出来ないというわけです。
つまり、アメリカのように、ユーザー企業が自己責任においてクラウドへ移行という訳にはいかなそうです。また、日本のユーザー企業ＩＴ部門が、ガバナンスを取れるようになれるとしても相当な時間を要するのではないかと思います。
そんなＳＩベンダー側の多くは、クラウドとどう向き合っていくのか？いまだ決定打のない状態なのではないかと思います。
例えば、「ＡＷＳは顧客にメリットをもたらすことは間違いない」とは理解しつつも、セルフサービス（＝既存ＳＩベンダーの存在を否定）を標榜するサービスをどう自社のビジネスに取り入れるのか？これはＳＩベンダーにとっては難しい問題だと思います。
ＳＩベンダーは、自分たちが主導権をもって顧客に提供出来るクラウド。そんなクラウドプロバイダを求めており、その辺りが整ったとき、クラウドはキャズムを超え一気に普及するのではないか？ なんて思います。
クラウドの普及について歴史から読み解く
歴史から学べとよく言います。
クラウドコンピューティングはどうなるのか？
メインフレームからクラサバ（C/S）その後クラウドへと向うシステムの変遷を振り返れり先を予測してみました。
ベンダー利益相反の抵抗はあっても、
時世が求めるものは必ず普及しているよういに思います。
ただ、たっぷりと時間をかけて。
以下、ITpro記事から抜粋
http://itpro.nikkeibp.co.jp/article/Watcher/20100426/347489/
--------------- ここから -----------------
かつてはコンピュータを新機種に入れ替えるたびにソフトを作り直していた。新旧のコンピュータでソフトの互換性が保たれていなかったからである。コンピュータ本体の値段がソフト開発費より当時は高かったこともあり、コンピュータ利用とはそういうものだとされていた。
しかし、コンピュータは安くなり続け、その一方でソフト開発費は上昇を続けた。いちいち作り直すのは大変だということで、機種間の互換性がとられ、開発したソフトをたとえコンピュータを入れ替えたとしても継続利用できるようになった。
それでもソフトにかかるお金は増え続けた。いったん動かしたソフトを使い続けるには、エンジニアを張り付けて保守しなければならない。新しい要求に応じて、新しいソフトを作る仕事も当然ある。
というわけで、ホストコンピュータ（メインフレームやオフコン）上にソフトを集中させていた時代においても新旧ソフトが混在し、ソフトの開発費と保守費は増大していった。エンジニアの数や生産性の向上には限りがあるから、利用者の要求に迅速に応えることが難しくなった。いわゆるバックログ問題である。
この問題の解決策として、1980年代の終わりから1990年代にかけて、クライアント/サーバー（C/S）という仕組みが言いはやされた。UNIXサーバーとパソコンを組み合わせ、サーバーに置いたリレーショナルデータベース管理システム（RDBMS）をパソコン上のソフトから利用する。C/Sはホストより価格が安くて済み、ソフトを開発しやすいと言われていた。
確かに、RDBMSに格納してあるデータを加工するアプリケーションの場合、C/Sは大変便利な仕組みであったが、販売管理や生産管理といった従来からあるアプリケーションについてみると、開発や保守にかかる手間はホスト時代からさほど改善しなかった。
ここに登場したのがERPパッケージソフトである。アプリケーション群と統合されたデータベースがあらかじめ用意されており、C/Sの仕組みで動く。パッケージソフトはホストの時代からあったが、C/Sの時代になって普及に弾みがついた。特に日本においては、ERPとC/Sを一緒に導入することが多かった。
だが、すべてのアプリケーションをERPとC/Sに置き換えるのは難しかった。バッチ処理や対外接続用途でホストを利用し続け、C/S上の新規開発ソフト、そしてERPパッケージが混在することになった。
1990年代後半になるとインターネットの利用が進み出し、Webを中心にソフトを動かすようになっていった。2000年代に入り、アプリケーションを自社で保有せず、インターネットを介したサービスとして使うやり方（ASP、SaaS、クラウドなど）が登場してきた。
--------------- ここまで -----------------
