クラウド時代における API サービスの新トレンド
こんにちは、本間です。
selfree では、Twilio の技術を中心としたプロダクトを開発してきました。その中で感じた技術の選択やトレンドなどについて書いてみます。
オープンソースの先にあるもの
まず、 Twilio を使ったことのある方ならお分かりの通り、使用には料金が発生します。使った分だけの従量課金制ですが、事前にチャージをしなければならないため無料が基本のエンジニアには敷居が高いものとなっていることが事実としてあります。
エンジニアには Github を中心としたオープンソースの考え方が広く普及しているため、テクノロジーにコストをかけることを億劫に感じている部分があるように思います。
例えば Twilio IP メッセージングを例にしてみます。 IP メッセージングはチャットサービスを迅速に構築できる API を提供しています。課金体系としてはメッセージの取得や送信ごとに1円に満たない非常にわずかな料金が利用分だけ課金されていく仕組みとなっています。
これをオープンソースだけで構築するとなると、 Node.js の socket.io を利用し、スケールのために Redis の pub/sub などを用意する必要があるでしょう。そのためのサーバーも当然必要になります。
ここで比較してみていただきたいのですが、 自前でサーバーを構築して今後のスケールやサーバー運用などをコストをかけてやるのと、APIサービスを使って構築するのとで、どちらが効率的と言えるでしょうか？
両者の選定もせずに、ただ単にみんな使っているから socket.io という選択は非常に危険です。 Twilio のようなプラットフォームを活用すれば、もっとプロダクト開発にフォーカスできたはずだったかもしれません。
クラウドの利用環境の変化
今までのクラウドといえば、IaaS, PaaS, SaaS でした。IaaS の構築の手間を PaaS が解消してくれていました。しかし PaaS だとしても、そこで使うプラットフォームの選択をして機能実装のためのコードを書くだけで良いというので留まっています。Twilio のようなサービスは、開発しなければならない機能も提供してくれる、上記のどれらにも当てはまらないような新しい概念(API as a Serice)と言えます。
そして Twilio のような API プラットフォームを活用すれば、大企業だけができたような難しい実装を誰もが簡単に実現できるようになります。サーバー調達の困難さを IaaS が解決したり、サーバー構築の手間を PaaS が解決したように、機能実装の手間を Twilio が解決してくれるのです。
そこで必要なのは、”Twilio や他の API サービスにはこんなことことができる” というのを予め知っておくことです。知っておくだけで自分でサーバー構築するのか、サービスを利用するのかを比較検討できる状態に持っていけます。これがとても大切です。
API サービスの注意点
さて、Twilio のような API as a Service なクラウドサービスは今後ますます増えていくことと思われます。それらを全て組み合わせて使いこなせるようになるべきなのでしょうか？
そこに一つ API サービスの課題があります。たくさんの API サービスと連結してしまうと、管理がとても大変になります。サーバーは各サービスごとに分断され、どれかが止まったらあっちにも影響が出たというようなことが起こり得ます。また、それらサービスを利用するたびにクレジットカードの登録もあまりしたくはないですよね。
これは私の考えですが、選択肢はたくさんあった方がいいけども、実際の利用時には単一のプラットフォームに利用を限定する方がいいと考えています。私たちの場合はそれがたまたま Twilio であったというだけです。
コミュニケーション開発系なら Twilio, 機械学習系なら Bluemix, モバイルアプリ開発なら Firebase, 全部ひっくるめてフラットな感じにした AWS といったところでしょうか。(これは個人的な所感です)
そのプラットフォームを使うと決めたら、徹底的にマスターし、詳しくなり、広めていく。そのような活動が今後の自分たちのサービス開発にも良い影響をもたらすと考えています。
終わりに
今回は API as a Serivce という分野についての個人的な考えをまとめました。テクノロジーのトレンドはどんどん変わっていくので、私も頑張って付いていきたいと思います。
selfree は引き続き Twilio を 主要な API as a Service として利用してまいります。よろしくお願いします。