GCPとAWSの価格競争

先週相次いで発表されました。

まずは、先週の水曜日のGoogleの発表からで。
http://japan.cnet.com/news/service/35045677/

1.値下げ
2.継続利用による値下げ（月単位）
3.開発者向けのツール拡充

の3点でした。

1点目は普通に嬉しいですが、GAEも値下げしてくれよ、、と思ったのは私だけでしょうか？2はまぁ嬉しいですが、月単位でのという話だと突発的な利用用途の場合のみ除くだけなので、月利用だと実質的に7割掛けになるだけと言う感じで、正直今ひとつ意図が組みにくい感じに思いました。3点目もまだしっかり使いこなした訳では無いので若干微妙な気がしています。

「ムーアの法則に従うべき」とは確かに、とも思いますが。でもBigQueryは単純なHW製品でも無いので、もともと安すぎて売る気にならないと言われるようなサービスだったのにもかかわらず85%オフって、、、おいおいと思います。

後は、Windowsが2008ってのが少しびっくりです。今更2008かよ、と。。。

さて、その直後にAmazonの方も対抗してなのか値下げの発表がありました。

http://www.atmarkit.co.jp/ait/articles/1403/27/news113.html

一応少しは使っているので、こちらも嬉しい話。

しかし、6年で42回って、節操が無いようにも思います。追随して行く販売代理店とかも大変だろうな、と。

これだけ巨人が値下げを繰り返し、大規模仕入れと効率的な運用でムーアに沿った値下げを繰り返すと、通常のPrivateクラウドではやはり単純な処理性能や容量の価格比較では全くかなわないでしょうね。。。。

置き場所という名の幻想的なセキュリティか、物理的な配置のターンアラウンドタイムくらいのメリットしか国内クラウドには残されないような気がします。セキュリティもGoogleが行っているセキュリティ対策と較べて高いものが提供できそうな気もしませんが。

後、上記とはあまり関係ありませんが、GCEではまだ2014年3月時点ではクラウドライセンスに対応してない製品が多い（というかそのような制限自体がある製品はまだ軒並みNGでしょう）ようなので、その辺りは要注意だなぁと思いました。皆さんGCEのご利用を考えている方はご注意ください。

最近のGCP周りのイベント参加

ここ2,3週でGoogle関連（Google Cloud Platform周り）で海外出張が続きました。
いずれも機密保持の関係上詳しいことはかけないのですが、大丈夫そうな部分だけ書きます。

まず、2月17日週は、Googleのクラウドプラットフォームのトレーニングで台北に。
丸々1週間で、GAE,GCS,GSQL,GCE,BigQueryと盛りだくさんのトレーニングでした。
今まで余り使ってなかった部分は試せて思ったより簡単にできるなぁ、と言う感想と。
使ってた部分も全般的な学びはしてなかったので、それらの補完にもなり、より万全になりました。

その他101に登ったり、懐かしのデカジョッキの店を探せたりで大満足の台北出張でありました。

Googleのオフィスが入っている101（台湾では「イーリンイー」と発音）

先週の3月3日週は、GooglePartnerSummit2014に参加しにサンフランシスコに行っておりました。
実はこのブログもその帰りの機上で書いております。
こちらは世界から1000人近いパートナーが集まるイベントで、昨年から開催だそうです。
私は今年はCloudPlatformでの参加だったのですが、かなり海外では盛り上がっているようで、
日本もこれに追いつけるよう頑張って盛り上げて行かねばとひしひしと感じました。
ちょっとびっくりしたのが、JAPACでのCloudPlatformでのパートナーアワードってのに、
ノミネートされまして。
特に気にせず、貰ったPixcelでメールの処理とかをしてたら、いきなり「Yoshidumi」とか呼ばれまして。
びっくりしましたー。
受賞はされませんでしたが、まぁ頑張れってことなんでしょうね。
来年は受賞出来るよう、頑張って参ります。


また、びっくりしたのが、サンフランシスコで東急ハンズの長谷川さんとお会いしたことです。
FBで着いたーとか書いたら、「あれ？一緒の便だった？」とか送られて来て。
どうやらIT研修とやらで来てたみたいで、偶然の遭遇でせっかくなので調整して飯食って来ました。
有名な蟹の店ですが、ダウンタウンの方の店だったのですが、やはりハズレの方にある本店の方が若干美味しかった気がします。
自分の舌が慣れてしまったのかも知れないので、またI/Oの時に行って、味を確認してみようかと思います。


パートナーサミット終わったら、台北で受けたトレーニングのテストを受ける締め切りが金曜迄だったので、
他の方々はみなさん観光されてたところ、ホテルに缶詰になってテストを受けまくりました。
無事、テストと名の付くものは得意なので、全部受かりまして。
以下の全てを名乗って良さそう（？）になりました。
・Google App Engine Qualified Developer
・Google Cloud Storage Qualified Developer
・Google Compute Engine Qualified Developer
・Google BigQuery Qualified Developer
・Google Cloud SQL Qualified Developer
めでたい。
これを持っている日本人もほぼ（この1,2週でとっている人が）初ですね。
特にGoogleAppsのCertified Deployment Specialystを持っている人なんか、
世界中探してもほぼ居ないんでなかろうか。当分出てこなさそうな気がします。。。
社長がこんなことやっとる場合かと言う話があるかも知れないけど。。
しかし、英語の試験は苦労しますです。

さて、次の海外はまたI/Oでサンフランシスコかなぁ。ブラジル行きたいなぁ。。。

ちょっと取り留めもありませんが。近況報告でした。
各種影響あり、色々作業が滞っているので、頑張っております。

GCE解説その1：GCE概要

今年はGCEもやってくぞと言うことで、何回かにわたってGCEについて書いていこうと思います。
まず第一回として、GCEの概要についてです。
基本はGoogleのGCEの概要ページを見ていただくのがまずは早いです。（日本語だと限定プレビュー版とかの記載が残ってしまってますね。。）

GCEとは

まず、『GCE』とは、Google Compute Engineの頭文字を取ったものです。（当然ながら）
当然ご存知とは思いますが、Googleのクラウドプラットフォームの中の一部として位置づけられております。
Googleのクラウドプラットフォームとは、これまたGoogleのクラウドプラットフォームの製品ページを見るのが早いですが、主に以下の6つの製品群から成り立ちます。
-Compute Engine（コンピュートエンジン）
-App Engine（アップエンジン）
-Cloud SQL（クラウド・エスキューエル）
-Cloud Storage（クラウド・ストレージ）
-Cloud DataStore（クラウド・データストア）
-Big Query（ビッグクエリ）

Googleクラウドプラットフォームについて

それぞれ簡単に説明しますと。
-Compute Engine

一言で言うと一般のIaaS（Infrastracture as a Service Wikipedia参照）です。EC2相当のサービスです。（本稿のメイン）

-App Engine

一言で言うとPaaS（Platform as a Service）なのですが、JavaやPython等のプログラムソースのみ準備すればすぐに動作させられるプラットフォームという点が非常に特徴です。

弊社でイチオシの基盤です。

-Cloud SQL

RDBMSレイヤのPaaSです。裏側ではMySQLが動きます。

-Cloud Storage

ファイルストレージです。AWSで言うところのS3と同等のサービスですね。

-Cloud DataStore

GAEでもともと使われていたKey-Value型のデータ保存領域です。GAEでなくても利用出来る様になったのですが、これと言った用途が思い浮かびません。GAE間で共有するような場合には良いのかも知れないですが、もう少しGAEが流行ってからだろうなと思います。

-Big Query

大規模なデータ解析を安価に高速に行えるサービスです。数Tというデータに対して全文検索（フルスキャン）のクエリかけても数十秒で返却される、というものです。ビッグデータ時代に対応したサービスです。アーキテクチャ的には全部読みに行くけど、大量のインスタンスを裏で立ちあげて並列処理するという力技というかある意味男らしいソリューションです。Googleのクラウドならではの解決方法だと思います。

GCEの基礎知識

さて、本題のGCEですが。まずは、Googleの概要ページの中の「特徴と機能」や、私の翻訳した「AWSよりGoogle Compute Engineを選びたくなる10の理由」をまずは読んで頂ければと思います。

私の現時点でのまとめとしては

1. 基本機能は揃っており、問題無く使える
2. OSとしてWindowsが選択出来ない点がかなり問題
3. 利用開始は非常に簡単且つ楽
4. 価格はAWSとそれ程変わらない（どっちもどっちな印象）
5. I/O性能は非常に高速
6. Googleの他サービスとの組み合わせをするなら非常に有効
7. 細かい機能においてはAWSに劣る面もまだまだあるように思われる

という印象です。

特に6点目についてはやはり、レイテンシの観点で、GoogleMapやGoogleApps等と連携するWebサービスを展開するなら是非検討に入れるべきと思います。Googleの高速なクローズドネットワーク内で処理が簡潔するので、インターネット経由とは比べ物にならないレイテンシになると思います。

この点については別途処理性能検証を行う予定なので、乞うご期待です。

次回はGCEの価格について

次回は価格について、以下の視点で評価してみようと思います。

-各インスタンスタイプ別のAWSとの比較

-ディスク・スペースの比較（Cloud Storageとどうなのか？等）

-In/Outのデータ転送量課金のAWSとの比較

GoogleAppsと業務システムと

最近営業とかに行くとで話題になるのが、GoogleApps及びGoogleソリューションを活用するアイディアって何だろう？という話です。
ちなみに、オチ無いです。。。

以下の観点からそのあたりのソリューションと言うか、具体例とかが求められているように思います。

・GoogleAppsの販売側の観点
　GoogleApps単体での販売ではGoogleApps販売会社間での差別化がしづらくなっていることと、さらなるGoogleならでは感を出したいと言うこと。

・GoogleApps導入済企業の観点
　GoogleAppsの利用をもっと促進したい、Google周りのソリューションをもっと活かしたい、けどいろいろ出来るんだろうけど何が出来るのか分からない。

・弊社のようなGoogleソリューションの提供ベンダの観点
　何でも作れるんだけど、具体的に営業をがっつりまわるだけの顧客に刺さるソリューションが無いと面展開しては売りづらい。

それぞれのステークホルダーが皆必要性を感じては居るのですが、明確に『これ』という解が無いように思います。
突き詰めると結局ASPやパッケージvsカスタムソリューションの話になってしまうようにも思うのですが、このクラウド時代、もう少しスマートな提案が出来ないものか正直、苦慮してます。
マーケットプレイス上に商品を並べて、組み合わせの提案だけする。とかってのが簡単に出来るとそれもひとつの手かなとは思うのですが、どうでしょうか。。。

取り敢えず目の前のソリューション提案や、普及活動をしっかりやって行きつつ、上記をスパッと解消するアイディアが何か無いものかと日々模索しています。
オチなくてすみません。

AWSよりGoogle Compute Engineを選びたくなる10の理由

Google Compute Engineについて興味深いブログがあったので、勉強を兼ねて和訳してみました。
原文はこちらです。

以下、超訳。

昨年（訳注2012年のこと）、GCEとしてGoogleがIaaSの提供を発表した時に、amazonは心配するべきかどうか聞いてみた。18ヶ月後、Google Compute Engineは一般公開され、信頼性、価格、革新性において間違いなくAWSの競合になったと見受けられる。混雑したIaaS市場には多くの新規参入があり、そのいくつかはマイクロソフト、HPとIBMのような十分に確立された企業·ベンダーである。しかし、大多数のそうしたサービス群は限定的な機能しか持たない。彼らはAWSに対抗することは諦め、Amazon EC2の2008年相当のものに見えた。しかし、GCEはそのアプローチからして異なる。Amazon EC2の類似機能に焦点を置くのではなく、GoogleはAmazon EC2に存在するギャップを埋めることにフォーカスした。AWSの顧客によって永らく、多くののフォーラムでこれらの課題が持ち上がっていた。GCEはAWSの既存顧客を惹きつけるために、これらを優美な方法で取り組んだ。
ここにAWSよりGoogle Compute Engineを選びたくなる10の理由を記載します。

1.価格と1時間未満での課金

Amazon EC2ではインスタンスの利用料が時間単位で課金されます。一部の時間しか使わなくても1時間に丸められて請求されるのです。GCEのマシンタイプでは10分が最小単位になります。10分経過後は、1分単位の課金（切り上げ）になります。まずこの比較ではGCEの計算能力とストレージのコストはAmazon EC2より安いと言えます。

2.ロードバランサーのプレWarmingが必要無い

AmazonのElasticLoadBalancer(ELB)は突然のスパイク（急激なアクセス増）を適切に扱うように設計されておらず、顧客はAWSにプレWarmingを申請し、ELBが想定リクエスト量に対応出来るように準備しておく必要があります。これはAWSサポートのサブスクリプションが必要ということになります。GCEのロードバランサーはプレWarmingは必要ありません。突然のスパイク的なトラフィックについても即座に対応するようスケールします。詳細は『ComputeEngineのロードバランサーは百万リクエスト/秒を処理（本文は英語）』を参照ください。

3.複数のVMに接続可能なPersistentディスク

GCEのPersistentディスク（PD）は一つのVMから読み書き可能でマウントするか、複数のVMから読み取り専用でマウントすることが出来ます。Amazon EBSは同時にひとつのインスタンスにしか紐付けられません。これだと静的コンテンツをインスタンス間で共有するための同期機構を顧客が用意する必要があります。この点については、『Amazon Web Serviceが直すべき5つの理由(本文は英語)』を参照ください。

4.優れたブロックストレージ

GCEのPersisitentディスク（PD)はAmazon EBSがサポートする10倍の10TBまでの容量をサポートします。Amazon EBSと違い、GCEのPDはI/Oの価格を含みます。これは、顧客にとって余計な推測作業を省き、より正確な価格見込みが可能になることを意味します。これは本当にゲーム・チェンジです！詳細は『新しい通常ディスク-GoogleComputeEngineのため、より速く、より安く、より予測可能な（本文は英語）』を。

5.統合されたネットワーク

Amazon Virtual Private Cloud（VPC）はAmazon EC2の公開から2年遅れて登場しました。Amazon EC2上のネットワーキングは後付であり、顧客がVPC環境にEC2の大規模なデプロイをするのを困難にしています。GCEにおいては、ネットワークは第一優先度で考えられており、顧客は仮想ネットワーク、プライベート、パブリックサブネット、ファイヤーウオール、ルーティング、ゲートウェイ、ACL等の環境を最初のVMを立ちあげる前に作成出来ます。Amazon VPCと異なり、ネットワークは別のサービスではなく、GCEの統合された一部なのです。GCEのドキュメントの『ネットワーキングとファイヤーウオール(本文は英語)』の章を参照ください。

6.よりよいネットワークスループット

GCEのリージョンを跨ったネットワーク I/OはAWSよりも断然速い。Googleがオフィシャルに認めたわけではないが、Googleのインフラのバックボーンとして使われているグローバル・ネットワークを活用していることは明白です。対照的に、AWSではリージョン間の通信に一般のインターネットを使っています。このGCEの能力により、リージョン間を跨いだデータベース同期機能のような興味深いシナリオを描くことが出来ます。

7.マルチリージョンイメージ

Amazon EC2では最近、リージョン間でのAMIコピー機能が追加されましたが、なお明示的にAMIのコピーを実施する必要があります。GCEにおいては、全てのOSイメージは一つのグローバルリソースとして存在します。それはGoogleが顧客から預かったカスタムイメージを含めてグローバルなイメージリポジトリを維持していると言うことになります。詳細はGCEのドキュメントの『リソース概要(本文は英語)』の章を参照ください。

8.持続性IPアドレス

Amazon EC2のElastic IP（EIP）と違い、GCEのリザーブドIPはVMの再起動によって変更されません。GCEではまた、既存の割り当て済一時IP（エフェメラルIP）をリザーブドIPに昇格させることも出来ます。これにより、一時IPについて作成した初期DNSレコードをそのまま保持することが出来ます。Amazon EC2上では、EIPはVMの起動時に紐付けられている必要があります。GCEのリザーブドIPアドレスについての詳細は『インスタンスとネットワーク(本文は英語)』参照ください。

9.より速い起動時間とVMの自動再起動

GCEのVMの起動時間は少なくともAmazon EC2の5倍は高速です。セバスチアン・スタンジル氏は言う、"VMのデプロイと起動は驚異的な速度でした（我々は広範囲に10クラウド利用している）。VMの起動コマンドをたたいてからrootでログインが出来るようになるまで、常に30秒以下です。"Google Compute Engineは自動再起動設定を利用することで、ハードウェア障害やすスケジュールメンテナンスイベントなどシステム依存の停止が発生した場合に自動的にインスタンスを再起動させることが出来ます。これによりインスタンスの自動治癒が有効になるのです。詳細は『インスタンス-Google Compute Engine- Google開発者(本文は英語)』を参照ください。

10.ライブマイグレーション

全てのクラウド事業者は必ずホストしているサーバやデータセンタをメンテナンスする必要に迫られます。これにより結果として、スケジュールドダウンタイムが発生し、クラウドベンダーはこのプロセスを完了させるために顧客にVMの再起動をしてもらう必要があります。『Amazon EC2 メンテナンスヘルプページ(本文は英語)』にこのプロセスについて記載があります。『広範囲に渡るAmazon EC2クラウドインスタンスの再起動により疑問や懸念が発生(本文は英語)』という記事でEC2インスタンスの強制再起動問題に触れられています。GCEではこれをVMをホスト間でグレイスフルライブマイグレーションを行うことで顧客に対しても明確に問題が無いことを示しています。より詳細についてはGCEドキュメントの『リージョンとゾーン-Google Compute Engine-Google開発者(本文は英語)』の章を参照ください。


以上、AmazonはGCEを恐れるべきでしょうか？皆さんのご意見をお聞かせください。

ここまで、超訳でした。

ここまでお読み頂いた方には、AWSとGCEのI/O比較した記事も参考になるかと思います。

個別の感想については後日書きます。いやぁ、久しぶりに和訳ってやったなぁ。
間違ってるとかありましたらご指摘いただけると幸いです。

新年の抱負2014

旧年中は皆様お世話になりました。

この一年はメンバを急拡大させたことや新規事業の立ちあげもあり、若干苦しい自分もありましたが、
昨年採用したメンバも含めて頑張ってくれたので何とか年を越せました。
本当にいつもお世話になっている皆さん、社員の皆さんには感謝しか無いです。

恒例の昨年の目標のふりかえり、今年の目標を記載したいと思います。

■昨年の目標のふりかえり

・GAEの業務システム開発No1の座を確固たるものにする！

>この分野では圧倒的なNo1を目指します。
>ベトナムとの協業体制も組み、柔軟な開発体制を敷けるよう、案件と両輪で拡大をしていきます。
確固たるところまでいけてるかどうかは分かりませんが、かなりイイ線迄は行ってると思います。
昨年の実績として、取り敢えず、実績の無い会社さんが一から全国で探して、ウチをパートナーとして選んで頂き、
50人月以上の開発のお手伝いをさせて頂く機会を貰ってます。
この調子で、案件開発と要員の調達の両輪を今年も邁進します。

・売上2億！人員20名！

>恐らく本年の売上着地が1.2億位になると思います。昨年対比で1.5倍くらいは行ってるので、
>この流れを継続します。もう少し欲をかいて2億の大台を目指したいと思います。
>今年こそは退職者ゼロを。。。。
ちょっと継続は出来ませんでした。。。ほぼトントンからちょっと上くらいかと。
具体的には新しくそこそこの規模の業務システム開発を始めたところ、正直いろいろトラブりまして、
売上拡大に力を入れる余裕が無かったことが原因でした。何とかその経緯を血肉として今年こそ。
退職者ゼロも達成出来ませんでしたね、1名は出てしまいました。
これはそろそろ15,6名まで来た現状はゼロってのは難しいですね。

・社長SI比率を売上の10%以下に

>これは今年こそは実現したいです。月150万位に抑えて、全体の売上が15Mをコンスタントに出せる感じを目指します。
>そして、全体に目が届くようにして快適・スムーズに業務が回るように整理する時間を取りたいです。
これはほぼ達成ですね。今年は1千万をちょっと切るのでは無いかと思います。
今後はマーケティングと売上拡大、社内体制の整備、新規事業立ちあげに注力したいと思います。

・スマセルの新規事業の立ち上げ

>まだ発表できませんが面白いのを企んでます。収益化は来年になると思いますが、今年とにかく話題にはなるように。
一応、9月に進学コムを立ちあげました。
が、現状利用者数もなかなか伸びず苦戦している状況。
何とか今年は打開していきます。

・ダイビング事業の単体黒字化

>現地サービス等の新企画もあるため、何とかなるのではと遂に目処が立って来ました！！！
こちらについては完全に失敗。。。今年こそ。。。

・外食事業の立ちあげ

>今年こそは夢の外食事業を立ちあげたいです。秋頃には！
無理でした。

■本年の目標

・GCP（Google Cloud Platform)の業務システム開発No1の座を確固たるものにする！

昨年のGoogleのクラウドプラットフォームの拡張に伴い、目標を少し大きくしました。
GAEについてはほぼほぼ固い状態になってきたこともありますし、そちらを確固たる状態にするたみにも、
GCP全体としてのサポート体制は必須と思います。
GCEについても事業として立ちあげ、AWSからの移行サービスも立ちあげます。

・売上2億！人員20名！

これは昨年と同じになってしまいましたが、今年はある程度固いレベルで持っていく予定です。

・定常の粗利を30%に

保守、ライセンス売上が現状相当低いため、経常が安定しない状態が続いてます。
来年末までにはそのぐらいになるように持って行きたいと思います。
そのためには、既存顧客を大事にしつつ、繋吉の拡販と保守を頂ける開発を取ることを優先して行きます。

・スマセルの黒字化

これは上記にも関連しますが、進学コム事業がうまく行かないことにはこれまでの投資も無駄になってしまうので、
何としてもスマセルの黒字化を必達します。

・ダイビング事業の単体黒字化

引き続き、です。

・新規事業の立ちあげ

新規でスポーツ関連で事業立ちあげを考えてます。
今年はこちらをやりたいので、一旦飲食は諦めます。
来年こそは飲食を始められるように頑張りたい。。。。

以上です。

プライベートの方はここに書くんじゃなくて、G+の方に書きました。

色々仕事も課題がありつつも、今年は景気向上に乗って良い年にしたいと思います！
本年も皆さん宜しくお願いします！

業務システムにおけるインフラ構築をGAEでやるとどうなるか？その1

『業務システムにおいてGAEでのインフラ費用が通常（オンプレミス）より安くなる訳：その1』が一部の方に好評でしたので、調子にのって、GAEでインフラ構築するとどうなるのか、従来の構築手法との比較で記載していこうと思います。
ちょっと繰り返しになっている部分もあるかも知れませんが。ご容赦ください。
全何回になるか分かりません。

何は無くとも要件定義

まず、システム開発の要件定義からですよね、やっぱり。
で、要件定義の中ってぶっちゃけあんまりインフラ的な話が出てこないことが多いです。
明らかに厳しめなものであることがわかっているものを除き（youtubeのようなものとか、証券取引システムとか）、ですね。
このフェーズでの話はやっぱり機能要件に走りがちで、非機能要件の洗い出しまでしっかりやることは結構まれです。で、それでも特に問題ないっちゃないでした、ある程度のパフォーマンスは最低限出せることが多かったから、ですね。
このフェーズについては特にGAEでも従来の構築手法でも特に大きく変わりがないように思います。
決めなきゃいけないのは、規模感がわかるものやパフォーマンス要件、特殊要件（ラインプリンタとか内部とのIF要件とか）の確認になります。
後はGAEが決まっている場合はどれだけGAEに合わない要件を先に切っておくか、これは必要かも知れません。（後述）

当然の基本設計

さて、要件定義が終わったら当然基本設計です。

ここで大きくGAEと従来型のインフラ構築の差が出て来ます。

GAEの場合

GAEでの手法の場合、ここで大きく舵を切ります。

要件定義で定義された要件がGAEで満たせるのかどうか？をざっと見ます。

あり得そうなポイントは

-Private環境とIFが取れるか？

　→IP制限の問題とか、ポートの問題とか。まぁ最近は問題にならないでしょう。

-極端に短いTAT（ターンアラウンドタイム）が定義されてないか？

　→本来はまぁ要件定義の際に切れる場合は切っておく、です。

-特殊機器等との特殊なポートでの連携がないか？

　→最近それほど私の周りでは聞きませんが、ある場合は間に何か挟んで解決出来ないか、検討。

-セキュリティ要件

　→これも最近ほとんど問題ないと思いますが、そもそも外に出しちゃダメとかって話だとアウト。

このくらいじゃないでしょうか？

これに引っかからなければ基本的にGAEでOKってことで、後は以下くらいを決めればOKです。

-フレームワークどうする？

　→弊社の場合ほぼIZANAMI一択

-支払い方法は？

　→うちでサポート含め代行するか、顧客アカウントで支払いしてもらうか？

-外部IFがある場合はちょっと調整

以上。

従来のインフラ構築手法の場合

えー、これに対してですね。通常のインフラの基本設計はと言うと。
都合上、データセンタ（サーバの置き場所）は既存の環境に空きラックがある前提とします。それはそれで別の話なのですが、実際はそれも当然考慮が必要です。

サイジング

だいたいの処理量の概算等からサーバ規模を見積る、という作業です。
大規模の場合だと、ベンダーさんにヒアリングシートを出して貰って、回答。1,2週間待って回答が帰ってくる、修正して・・・・というのを繰り返す可能性あり。

構成設計

サイジングと合わせて、主にNW構成を検討して、既存の環境に合うように機器含めて整理。
サイジングの結果を持って、各種論理サーバを並べて行く。
上記の論理サーバを物理サーバにどうマップするか考える。
OSを何にするか考える。

MWを何にするか考える。
各MWをどのサーバに載せるか考える。バージョン、OS等の組み合わせでサポートがされているかベンダーに確認調整する。
また、上記の単純な配置からさらに、仮想化した場合のライセンスの考え方等を含めどのように配置するのがパフォーマンス上良いか、ライセンス費用的に良いか、運用上の境界の取り方として問題ないかのバランスを取って決定する。

費用見積り

上記がだいたいできたら、ベンダーさんに見積りをお願いする。

見積りには以下を含める必要がある。
-HW費用
-MW費用
-OS費用
-SI費用（HWの設置費用、OS設計・導入費用、MW設計・導入費用が必要）

上記での調整

費用見積り等をもって、各種調整を行い、出し入れを行う。まぁ、それなりの規模感だとまず一発で決まるなんてことはありませんので。。。

このマネジメント

忘れちゃイケない、上記の作業をするにあたっては他の業務要件の出し入れなどの調整含め、スケジュール調整やベンダコントロールが必要になってくるのでマネジメントが必須になります。これもコストとして上乗せになる感じです。

基本設計まとめ

いかがでしょうか？基本設計のフェーズにおいてはとんでもない作業量の差異が生じます。
これちなみに、通常のIAASクラウド（EC2など）だとHWとOSの一部の部分に関しては非常に楽になりますが、それ以外は必要になる部分です。
私の感触ですが、縦軸にレイヤ、横軸に作業を並べると以下のような区分になると思います。

	設計	見積	導入	構築	テスト
MW	必要	必要	必要	必要	必要
OS	簡易	簡易	不要	必要	必要
HW	簡易	簡易	不要	簡易	必要
NW	簡易	簡易	不要	簡易	必要

ここで、「簡易」としたのはある程度簡単なGUIからの操作等で出来ようなレベルのもので。「導入」ってのはインストールする、というだけの部分で、「構築」はそれがちゃんと連携取って動くように細かい設定を行う、という意味合いです。
これ、基本的にGAEだと全部まるっとほぼ「不要」になります。

作業量=コストであり時間ですので、ここで決定的な差が生じます。
この決定的な差は運用フェーズにも引き継がれることになります。


長くなったので次は詳細設計フェーズから続けます。
今回から一応ちゃんと見出しを設定してみました。見やすくなったかしら？
頑張って表なんかも書いてしまいました。
しかし、この表、なんとスプレッドシートからコピペ一発でした！びっくり。