Azure Functions
serverless apps

MicrosoftがAWSのLambdaに続いてサーバー不要のイベント駆動型クラウドサービスAzure Functionsをローンチ

次の記事

MicrosoftのマイクロサービスプラットホームAzure Service Fabricが一般公開へ

Microsoftが今日(米国時間3/31)行われた今年のBuildデベロッパーカンファレンスで、デベロッパー自身がそのためのインフラを作らなくてもイベント駆動のトリガーを作れる、というサービスのプレビューを発表した。

ご存知のようにAWSは昨年のre:Inventカンファレンスで、Lambdaと呼ばれる同様のサービスを発表したが、競争の激しいパブリッククラウドプラットホームの業界だから、Microsoftもそれを黙視できない。Microsoftの、AWS Lambda相当サービスの名前は、Azure Functionsという。

Microsoftから見ればそれは、同社のPaaSサービスの拡張であり、デベロッパーはJava, Python, C#, phpnなど自分が使い慣れている言語でイベントトリガを作れる。そしてそれはAzure上はもちろん、そのほかのサードパーティによるプライベートやハイブリッドのクラウドでも使える。

Microsoftはこれを主に、IoT用と位置づけている。デバイスやセンサーから情報が来ると、それがイベントをトリガーして自動的に何かを起こす。

Azure Functions demo

なお、Googleも最近、Google Cloud Functionsという似たような名前で、同様のツールのアルファを開始した

ファンクションをプラットホーム側で(イベント駆動で)動かすわけだから、ユーザー(デベロッパー)はサーバーが要らない。この考え方は、なかなか魅力的だ。デベロッパーはイベントトリガーを作る、あるいはそれぞれ独自の意味を持った一連のトリガーを作る。するとクラウドサービスがそれら(から起動されるファンクション)を動かしてくれる。そのために必要な計算機資源やメモリ、ストレージなどはクラウドプラットホーム側が手配する。イベントそのものは、単なる引き金(トリガー)だから、一瞬しか存在しない。

それ(ラムダファンクション)は、小さな自己完結的なアプリケーションをデプロイする権限をプログラマーの手に渡し、デベロッパーがアプリケーションを壁の向こうにいるオペレーション(ops)に渡してデプロイしてもらう、という状況がなくなる。デプロイは、デベロッパーが自分でやる。なぜなら、オペレーション相当部分は、Microsoftなどのクラウドプロバイダが、適正なリソース配分を自分でやりながら担当し、アプリケーションのデプロイを行い、イベントのトリガーを扱っていくからだ。

もちろんこれによって、複数のイベントが同時並列的に発生したり、トリガーが別のトリガーをトリガーするといったドミノ効果が起きることもありえる。そして最終的には、いろんなイベントにトリガーされたアクティビティのコンスタントなフローが常在し、それら個々の小さな(大量の)イベントに課金するMicrosoftは、確実に収益を積むだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))