Recent Tweets @
さてInfrastructure as codeを利用すると、IaaSにおいてPaaS同様にサービスを提供できてしまいます。つまり、IaaS上にOSやミドルウェアなどのプログラム実行環境を自動で構築・設定できるようにしておけば、IaaS上でもPaaS同様にプログラムをクラウドに置きさえすれば実行できます。その意味ではIaaSとPaaSを区別する必然性は小さくなるでしょうし、あたかもPaaSのようにお手軽に利用できるIaaSも増えるでしょう。
(新規のビットコインは採掘という作業で手に入れます。採掘というのは比喩で、実際は、ビットコインネットワークを健全に保つためのメンテナンスを請け負うことで、具体的には、コインの取引を監視し不正がないかを検証し承認する作業です。これを行っている人に報酬として新規のコインが発行されます)
システムはそのコストの費目でみて、三つに分類できる。まず、ITコストが一般管理費に計上される、会計システムなど基幹系システムの大部分とERPの大部分のモジュール。そして二つめが、原価に計上される生産管理システムや金融商品を組成するためのシステム。三つめが、販売費に計上される店舗販売やEC、Webマーケティングのためのシステムだ。  「システムを自分たちで開発している」という人たちは、原価や販売費に計上されるシステムの開発などを担っているはずだ。こうしたシステムは、企業の競争優位を実現するためのものであり、まさに内製化すべきものだからだ。
この開発に関与している企業の多くが、OpenStack Heat プロジェクトにおける OASIS TOSCA テンプレート記述のサポートを実装する作業にも連携して取り組んでいます。
オンデマンドリソースの利点はいつでもフレキシブルに再構成できることだが、それは同時にソフトウェア的にはチャレンジングなことである。
「インフラをコードで構成する」と聞くとまず第一には自動化される・・・ということがやっぱり思い浮かぶかも知れない。でも、そのうま味がもし自動化だけだったら、サーバーが1台2台しかないような環境にはまったく魅力的に映らない。作業手順がコードになるということは、それが(再生可能な形で)ちゃんと形に残るということである。形に残っているから、git や github で管理できる。いちいちサーバーに見に行かなくても、github 上で何がどうなっているか見ることができる。アプリケーション開発の世界で日常的に行われつつているワークフローを、インフラチームも取り入れることができる、というわけである。

Infrastructure as Code - naoyaのはてなダイアリー

これがビジネスに貢献するってことを、これから伝えていかないといかんね。

Chefで環境をコードで記述するようになると、ローカルの開発環境であろうが、検証・本番環境でも基本的にはコマンド1つで構築できます。しかし、気が付いてしまいました。ローカルの開発環境に、Amazon Linuxをインストール出来ないことに。このことはChefを使い出すと同時に、VirtualBox Vagrantを使いだしたことで顕著に感じるようになりました。

AWSのEC2でAmazon Linux AMIを使うかどうか? - プログラマになりたい

AMIだけじゃなく、AWSでしか使えない部品はみんなそう。

面白いのは、HPによるARMとオープンソースコミュニティによって拓けるサーバー技術の今後の展望。Fink氏は、サーバー側のメモリ&ストレージが9階層の複雑な構造からユニバーサルメモリへと進み、CPUが汎用CPUから用途に特化したSoC(System on a Chip)へと変化し、ネットワークが電子からフォトニクスへと変わり、データマネージメントがリレーショナルデータベースからオープンソースのプラットフォームに変化し、複数のデバイスからの個別のデータへのアクセスが統一されたコンテンツビューを各デバイスで共有する仕組みへと変わると説明した。

【後藤弘茂のWeekly海外ニュース】2020年には300億デバイスが予想されるIoT市場に賭けるARM - PC Watch

要するにサーバーの形が変わるということ。サーバーとストレージとネットワークの境界線は曖昧になり、処理に特化したSoCを混在、統合していくことになる。

もう一つのパラドックス。もしかしたら上のパラドックスよりも重要かもしれない。それは「フレームワークを使いこなせるのは、そもそも軽量フレームワークでちゃんとした実装の出来るところだ」ということ。この言葉も、元々は「アジャイルの開発を廻せるチームは、ウォータフォール開発も廻せる」という皮肉をちょっと変えたものなんだけど。