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だと全部まるっとほぼ「不要」になります。

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


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

エンジニアの技術力ってコーディングとかだけじゃ無いよね

昨日こんな酒を飲みながらエンジニア仲間の佐藤さん（仮称）と話をした雑談です。
たまにはGoogle関係無い話もしてみます。

以前一緒に仕事してた田中君（仮称）についての論評だったのですが、
佐藤さん曰く、非常に技術力があるんだけどなぁ、という評でしたが、僕的には違いました。
というか、「技術力」ってものの定義の違いかもしれませんが。

田中君は、技術力の中でもコーディング力や新しい技法やフレームワークに対する対応力は非常に優れて居ました。確かにそれだけを持って技術力が高いと言う見方もあるかも知れないのですが。
僕的には、技術力ってのはアウトプットというか他者と調整して技術自体が活かせる形に持っていかないと意味が無いのでそれも含めての技術力という考え方を持ってます。
残念ながら田中君は、狭義の技術力は非常に優れていたのですが、それを展開したり、自分が作ったものの意義を周りに理解してもらったりというところがあまり得意でないようでした。
新しいプロジェクトで使う新技術を習得して展開するというところの中で活躍してもらってたのですが、複数のオプションの中で彼の作成したものが採用されなかったということで、結果的にプロジェクトを離れてしまったのでした。

これは僕の反省でもあり、もっとうまく活かせるように出来れば良かったのになぁと言うところもあるのですが。
技術者としての能力として田中君についても、せっかくなのでもっと他の部分も伸ばせて行ければいいのになぁと思ってたんですよね。

昨日酔っ払った上でのたとえですが。仮に「計算能力」というので例えると。
暗算で四則演算がものすごい速度で出来たとしても（私もそろばんやってたのでそこそこ出来る）、国語能力ゼロだと小学生の算数も解けないんですよね。
A君が1000円持って買い物に行きました。100円払ってお釣りが・・・・って問題文があった時にそれを解釈する能力が無いとたとえ暗算で3桁×3桁の掛け算が一瞬で出来ても全く意味ありません。
同様に、「技術力」ってのもコーディングや新しいものの理解だけでなくそれを外部に伝えたり、プロジェクトの状況や達成したいことに合わせてフィットするように適用したりとか、いろんな能力が必要になってきます。

そう言った意味で、技術者の人にもコミュニケーション能力とか、国語とか英語とか、コーチングとか、デザインとか、周辺の能力も是非磨いてもらいたいなぁと思った次第。

難しいこと書いたな。。。

apps-gaeのお薦めコンテンツ

さて、今回は弊社で運用しておりますapps-gae上のお薦めコンテンツをご紹介したいと思います。

○EC2とGCEのDisk I/O比較
必読です！
色々なインスタンスタイプ別に調査してみました。
結構たくさんデータを取ったので、時間がかかりましたが、非常に面白いと思います。
この結果からすると圧倒的にGCEの方がお薦めと言うことになります。

○Google App Engine Modules のScalingを試す
24時間までは正しく動くことを確認しました。バッチ処理等でもまぁ十分な時間動かせると言うことのようです。


○たった1つのCloud SQLインスタンスで複数のWordpressを動かす
まぁ要は複数のGAE環境から1個のCloudSQLインスタンスだけを使って複数サイトをホスト出来るか、というところです。
GAE部分はある程度までは全て無料で1個のCloudSQLにだけ費用を払えば良いので、非常に安く運営出来そうです。SEO的にも良いので弊社は今後色々WordPressOnGAEでサイト展開していこうかなと思います。apps-gaeもGoogleサイツで今ひとつ見栄えとかがしっくりこないので、WordPressOnGAEにしてしまおうと思っています。

○Google App Engine コンソールの小技
これはGAE使って開発されている方は必読というか、必須のツール作りました。
是非入れてみてください。

○GAE負荷テスト その２「吉積情報株式会社の旧トップページ」
弊社のコーポレートサイトのトップページを無料範囲でどれだけ表示出来るか、という検証です。
結果、15万PVくらいはイケそうと言うことで。1日あたりなので大概の企業のコーポレートサイトはこちら（GAE）で良いのでは？と思います。

○Datastoreモデル変更の影響調査
Datastoreのモデルにプロパティを追加、削除したりした時の挙動を詳細に調査してみてます。ちょっと難しめですので、開発を真面目に検討されてるSEの方のみ向けかなと思います。

いかがでしょうか？
結構色々と調査してます。一応目指しているのは昔非常にお世話になった、「おら！オラ！Oracle － どっぷり検証生活」です。

今後も順次記事は追加して行きますので、是非チェックしてみてください。
何かこれを調べて欲しいとかのお題もいただけると嬉しいです。

業務システムにおいてGAEでのインフラ費用が通常（オンプレミス）より安くなる訳：その2

『業務システムにおいてGAEでのインフラ費用が通常（オンプレミス）より安くなる訳：その1』の続きですので、未だお読みで無い方はまずそちらをお読みください。

インフラに関わる費用としてざっくり以下がありますが、このAについてはお話しました。
>A.インフラ自体の購入・保守サポート費用
>B.上記の組み上げ・保守費用
>C.運用管理設計、導入費用・保守費用

Bについて書きますと。
ここはまさにSIerの構築ノウハウをベースに、必要な性能を達成させるべく購入した製品を組み合わせ、設定して、テストする、という一連の作業になります。EC2とかIAASのサービスを使っても通常このレイヤの作業は必要になります。
確かに、昔は（10年くらい前とか）色々なサービス毎に異なるSLAを設定し、それぞれに適切な構成、というのがあったしそうする意味もあったのですが。
ここ数年で言うと、業務システムに求められる要件て同じで、私がインフラ構築を提案する時にふと全く同じ事をしていることに気づきました。

簡単にいうと以下のようなものです。分かる人だけ分かればいいですが。
VMWareをベースにブレードを並べてリソースプールを作成して、DBサーバだけ別途4Uくらいのを購入、ストレージはそこそこ高価なものにしておき筐体単位でのバックアップは基本取らない（お金に余裕があれば2台構成にしてDR）、代わりに筐体内では全て冗長化される構成のストレージを購入。
DBMSにOracleを入れ、ストレージの機能との組み合わせでスナップショットを取って、テープにゆるりとバックアップしていく。
監視は監視サーバ・MWを入れて、JP1等を入れてスケジュール連携する。

これ、ほぼ全く同じで無いですか？
また、ここに関わるコストも馬鹿になりません。監視サーバとかJP1とかってそれなりに高価ですし、ストレージの冗長化とかの設計とかストレージの論理領域を切ってもらったり、ストレージの冗長化とかってびっくりするほど高価なSI費用を請求されます。（特殊技能だからでしょうけど）
繰り返しになりますが、これもGAEだと不要です。


私は行くプロジェクト毎に毎回9割方同じ設計書を書いて、ベンダーさんに組み上げて貰ってテストして。。。。
ばかばかしい、と。
このレイヤに価値がある時代は終わりました。
システム（インフラ）に求められる要件は、
-止まらない
-データなくならない
-スケーラビリティが確保されている
-セキュアである（データを持って行かれない）
-アプリの変更が容易
これで全てだと思います。皆ほぼ同じです。で、既にそのインフラはあるのです。
GAEではこのレイヤも全く必要ありません。これがEC2等の通常のIAASと大きく異るところです。


Cについて
監視やバックアップの仕組み、またそこで障害発生時やパッチ適用時に発生するコストです。
ここについては、GAEでもある程度（構築部分以外の運用）は必要になります。

運用って例えば、1回何らかエラーが吐かれたとしたら、
その調査を行い、再現性があるのか無いのか、リスクは？等の判断をして、対処の優先順位（対応しない）を決めて、
他の仕様変更とかと合わせてリリース計画を立てて、利用者側に告知して、（場合によっては夜間）リリース作業する。
という流れを全て調整してやってかなきゃいけませんが。

が、インフラレイヤの障害に対応する必要がほぼなくなりますので、その分まるまる対処必要無くなります。
実際、3年くらい全くノータッチで動いているものも弊社の管理している中にはあります。（そのぐらい通常システムでもあり得ますけどね）

まぁその部分はそれほどGAEと他とで違うってことは無いように多みます。
逆にAPIにはある程度依存するのでその変化の速度等が通常の枯れたフレームワーク等と比べると多いかも知れないので、それには対応する必要があります。
そこの点は敢えて書いておきますがデメリットになり得ます。

とは言え、総じてA,B分のコスト減がかなり大きいので、私としては構築難易度やAPI等の変更の速度が早いことに対する対処はプログラム上の工夫でかいけつしてしまって、インフラレイヤ迄クラウドで吸収する、という形で圧倒的な低コストが実現出来ると考えて居ます。

以上、インフラのコンサルタントとしての視点から見たGAEで安くなる理由でした。
次回は、apps-gaeの興味深い記事について私の目線から幾つか紹介させていただこうと思います。