Googleが、開発プラットフォームのFirebaseをCloud Platformへより深く統合

Googleが2014年に買収したモバイルアプリ開発プラットフォームFirebaseの大規模なアップデートが、 サンフランシスコで開催中のGoogle Cloud Nextで今日(米国時間3月9日)発表された。このアップデートの基調となるテーマは、Firebaseをより一層Google Cloud Platformと統合されたものにすることだ。例えば、AWS Lambdaに対抗する「サーバーレス」プラットフォーム機能であるGoogle Cloud Functions(現在公式ベータテスト中)へのサポートの追加などが挙げられる。Firebaseはまた、Google Cloud Platformが現在提供する全てのストレージオプションへのサポートを提供する。

Firebaseの共同創業者であるJames Tamplinが私に語ったように、Firebaseは常に、Googleのクラウドエコシステムへの簡単な入口としての役割を果たしてきた。基本的に、サービスの背後にあるアイデアは、開発者たちにシンプルなBaaS(backend-as-a-service)プラットフォームを提供し、開発者たちを独自のインフラの構築とサーバーの保守作業から解放するというものだ。しかしアプリのユーザーが増え、機能が成長するに従い、開発者たちは必然的により進んだユースケースをサポートするサーバーをセットアップしなければならなくなる。

Googleは、当然のことながら、そうした開発者たちにCloud Platformへの簡単な移行を提供したいと思っているが、Firebaseもまたこうした先進機能をサポートするように拡大している。このステップにおいてCloud Functionsのサポートは自然な流れだ、その利用により開発者たちはサーバーを保守することなく、より複雑なプログラムを運用することができるのだ。実際、Cloud Functionsのサポートが、Firebase開発者から1番要求の寄せられていた機能だと、Googleは言っている。Firebase SDK向けの新しいCloud Functionsは、Firebase Analytics、リアルタイムデータベース、そして認証並びにストレージサービスからのイベントを受け取ることが可能で、それに対応するCloud Functionsを起動することができる。

Firebase Storage(今回Cloud Storage for Firebaseと呼ばれるようになった)もアップデートされて、Googleの他のクラウドストレージソリューションと足並みが揃った。それが意味するのは、例えば、(あまり定期的にアクセスされないデータを保存するためのGoogleのソリューションである)NearlineとColdlineへのサポートが提供されるということだ。また開発者は、どのリージョンにデータを保管したいかを選べるようになった。これはデータの統治問題を気にしなければならない開発者たちにとって、特に重要である。

これに加えて、Googleは、Google Cloud Platformのサービス利用規約を拡張してFirebaseをカバーするようにしている。Tamplinが指摘したように、これは企業にとってとても関心が持たれる部分だ。何故ならこのことによって、彼らの弁護士たちが、Cloud PlatformとFirebaseの双方を1箇所でチェックすれば良いだけになるからだ。Google Cloud Platformのサービス利用規約はFirebaseのサービスを、認証、ホスティング、ストレージ、Functions、そしてFirebase Test Labに関するものとしてカバーする。Firebase Analyticsサービスは、近い将来に、Google Analyticsのサービス利用規約の下に移動する。

[ 原文へ ]
(翻訳:Sako)

「クラウドネイティブ」アプリケーションの真の姿

shutterstock_268614635

【編集部注】著者のRishi Yadav氏は、ビッグデータコンサルティング会社InfoObjectsの最高経営責任者 。

「クラウドネイティブ」の話題が盛んである。そしてそれぞれが好き勝手にその解釈を語っている – 要するにすべてのことをなんでもクラウドでこなすことだ、といった具合に。

Cade MetzはこのWiredの投稿でこの現象を正しく説明している:「この用語には最近本当に沢山の意味がまとわりついている。しかし忘れないで欲しい:大部分のそうした解釈はIBM、HP、EMC、Dell、Ciscoといったクラウドネイティブに『乗り遅れたくない』会社から発せられているということを」。

「クラウドネイティブ」とは簡単に言えば、オンプレミスで生まれ育つアプリケーションとは対照的に、単にクラウドで生まれるアプリケーションを指している。オンプレミスとは一群の車を所有するようなものだ。車を買うために多額の先行投資が必要なだけではなく、保守のためにも費用が必要となる。

足がかりとしてのIaaS

オンプレミスのアプリケーションをパブリッククラウドに移行する場合、その最初のステップは、単純にそれらをクラウド上に再配置することだ。本質的に、これは単にオンプレミスインフラストラクチャの再構築を意味している。このアプローチは、多くの未知数を減らし、起き得るリスクを軽減することができるという意味で、最初のスタート地点としては多くの利点がある。ところで、古い諺を改める時期だろうか:

「IBMを買って馘になった者はかつていない」

「AWSに移行して馘になる者はいないはずだ」に。

このアプローチを更に説明するために、仮にある会社が100ノードクラスタのオンプレミスシステムをクラウドに移行するとしよう。この場合単純に100インスタンスをレンタルし、全く同一のオペレーティングシステムとそれを支えるソフトウェアをインストールした後に、アプリケーションとサービスをオンプレミスと全く同じやりかたで実行することになる。インフラをレンタルするこのスキームは、IaaS(インフラストラクチャー・アズ・ア・サービス)と呼ばれる。

IaaSの提供する利点は2つある:スケーリングと抽象化だ。スケーリングの利点は、マシンをオンデマンドで追加および削除する際のやり方に現れる。オンプレミスの場合なら作業に数週間かかるであろう作業が、IaaSなら対照的にわずかのボタンクリックで手続きが終了する。抽象化の利点は、ハードウェア/データセンタインフラストラクチャレベルに現れる。IaaSは、同じ地域内や地域間に複数のデータセンターを作成し維持することなく、グローバルなインフラストラクチャを提供する。IaaSを用いれば、マシン、ラック、ネットワーキング、冷却、電力使用量その他諸々の管理について心配する必要はない。

特にIaaSによって加わる利点(クラウドコンピューティング一般の利点でもある)は、かかるコストを資産から経費に変えることができるということである。IaaSは、一群の車をレンタルすることと同等である。あなたが気にしなければならないことは、時間単位、週単位、月単位のいずれだとしてもレンタル費用の支払いだけになる。

IaaSは良い始め方であり、非常に基本的なものだ。IaaSの部分をスキップして、直接PaaSやSaaSの提供をしようとして来たクラウドプロバイダーは、みな課題に晒されてきた。たとえば、Microsoftは当初Azureの上のPaaSサービスの提供を始めたが、とても限定的な成功しか収めることができなかった。彼らは2012年にIaaSをAsureに追加し、それ以来振り返ることはしていない。

私たちがSaaSを話題にする一方で、インターネットの上で動作するもの全てを「SaaS」と呼び、それをクラウドビジネスにつなげてクラウド予算の拡張を狙う、新しい傾向が業界の中に生まれているようだ。Oracleによるこの記事を見て、実際のクラウド収益というものがどのようなものかを理解して欲しい。

PaaS

企業は通常、パブリッククラウドへの移行後、新しい環境に定住するためにある程度時間を必要とする。ある企業にとっては数ヶ月、その他の企業にとっては数年を要することがある。こうしたクラウドの地への入植者たちが、元のオンプレミスの地で感じていたような心地よさを感じることができるようになるのにも、またそれなりの時間が必要である。

入植者が新しい環境に同化して慣れてくるにつれ、彼らは興味深いものを発見するようになる。彼らが気付くのは、これまで自分たちが何年も手作業で苦労しながら行ってきたものに対する、既成サービスの存在である。IaaSはハードウェアを抽象化してくれたが、そうした既成サービスはオペレーティングシステムまでも抽象化して省力化の役に立つものだ。こうした様々なニーズに対応する汎用のプラットフォーム上のサービスの上に、単にアプリケーションを再構築することができる。こうした拡張機能は、PaaS(プラットフォーム・アズ・ア・サービス)と呼ばれている。

PaaSが提供するものはシンプルさだけではない。IaaSを大幅に凌ぐコストの削減も提供される。

一般にパブリッククラウドが目指す改良は主に2点に集約されている:コストの削減と単純化だ。

PaaSはクラウドネイティブへの最初の接触地点として、重要なステップである。このことにより、パブリッククラウド上で最大のポテンシャルを挙げるために必要な、アプリケーションアーキテクチャの再構築に向けての思考プロセスが開始されるからだ。PaaS上で利用可能されるそうしたアプリケーションは、広い用途をカバーしている。Amazon Web Services(AWS)は、IaaSであると同時にPaaS提供のリーダーである。データストレージとして、RDBMSの代替であるAWS Aurora、NoSQLの代替であるDynamoDB、そしてエンタープライズデータウェアハウスのためにはRedshiftを提供している。

PaaSは、必要とするときにUberを利用するようなものだ。車のレンタル代を払うのではなく、A地点からB地点に移動するサービスに対して支払いを行うのである。どのようなサービスを採用するかは必要とするもので決まる。もし目的が観光なら「大きなバス」に乗るのは良いアイデアだろう。

サーバレスアーキテクチャ

PaaSが提供しているものは素晴らしい、そして多くのアプリケーションは末永くPaaSの世界に住み続けることが可能だろう。しかし、いくつかのアプリケーションはコストを最小化し単純化を行うための更なる前進を続けている。Amazon Web ServicesによるAWS Lambdaの公開の発表は、まさしくその方向へ向けての一歩である。Microsoft Asureも対抗としてAzure Functionsを発表した。同様にGoogleが発表したのはGoogle Cloud Functionsだ。

これを実現するための鍵は、各アプリケーションを、構成されている個々の機能へとブレークダウンすることである。JVMやPythonといった特定のランタイム上で実行される、小さなコードブロックであるファンクション(Functions:機能)は素晴らしいものだ。アプリケーション開発者はそうしたランタイムの実行を心配する必要すらないのだ。これは、考え得る限り最も高いレベルの抽象化である(今のところは!)。

Dockerなどのコンテナファンの目から見れば、これはコンテナが行うことと大きく異るものではない。コンテナとは、アプリケーションが実行される基盤が抽象化されたものである。ファンクションは、この思想を受け継ぎつつ、その粒度が個々の機能単位に移動されたものである。

この考えに更に近付いたものが「マイクロサービス」である。実際に、人気のデザインパターンは、APIゲートウェイによって管理されるマイクロサービスを前面に立てたものである。

ファンクションは、丁度あなたが衣服を洗ってアイロンがけしてもらう目的のためにクリーニング屋に行くように、何故そこに向かうのかの理由をはっきりさせてくれる。ファンクションはあなたを、「どのように行うのか」ではなく「何を行うのか」を考えることに集中させてくれるのだ。

まとめ

一般にパブリッククラウドが目指す改良は主に2点に集約されている:コストの削減と単純化だ。IaaS、PaaSそしてLambdaはこのための成果を徐々に達成している。

企業がお馴染みのオンプレミスを捨てパブリッククラウドに運命を委ねようとするときには、どのようにコストの最適化を図るかに焦点をあてる。その際に クラウド ネイティブであることの利点を最大限に活用するために、以下のような方法でのアプリケーションアーキテクチャの再構成が含まれる。

  • 従来のデータストア(Oracle/MySQL/Teradataなど)からクラウドネイティブデータストア(Aurora/Redshiftなど)へ移行する。
  • コンテナおよびアプリケーション中心の抽象化を活用する。
  • 最後に(そしてこれで終わりではないが)、個々のアプリケーションを個別のファンクションに分解し、ファンクションレベルの抽象化で動作させる。

[ 原文へ ]
(翻訳:Sako)