講演ビデオ
ビジネスモデルとして成り立たないBaaS
サーバレスといいながら多くのサーバで設定が必要になってたり、分散環境でAPI認証するために複雑な手続きをフォロントエンドに押し付けたりするのはありえねーだろというのが昨日の言いたいことだった。
しかし、たとえこれを全部解決するようなBaaSが登場したとしても決して流行ったりしないだろうなというのが今の正直な気持ちだ。
もしそれで流行るんなら「フロントエンドエンジニアだけでWebアプリが作れるBaaS vte.cx」がもうとっくにメジャーになっているはずだから。
たぶん、ビジネスモデル的にダメなんだろうと思う。BaaSは。
よく考えると世の中ではAWSなどのIaaSかSalesForceなどのSaaSしか流行っていない。
つまり一番下のレイヤー(IaaS)か一番上(SaaS)しかビジネス的には成功してないのだ。
（PaaSのHelokuはそこそこ使われているがSalesForceの配下にある）
IaaSは標準化されたOSの世界で非常に多くの人が理解できる一般的な環境を提供する。
SaaSは特殊な環境だがすぐに使えるパッケージがある。
そして何と言ってもセリングが強烈だ。
システム開発するよりはSaaSで十分と考える顧客も多いのではないだろうか。
標準技術の採用がむしろ本質をないがしろにする
一方でBaaSはパッケージほどの完成度はなく特殊なAPIの使用を開発者に強いるところもあって中途半端な感じが否めない。
もし特殊なAPIをOS並みに汎用的かつ標準的にできればIaaSのように多くの利用者に恵まれるかもしれない。しかし、そんなことは不可能に近い。
つまり、サービスをいかにJSON Schemaで作ってSwagger(Open API)で公開したとしてもすぐに多くの人に利用されるようになるわけではないことをよく理解する必要がある。
標準に準拠していく努力の方向性は認めるが、労力のわりに益が少ないのでそこをよく考えたうえで採用すべきとは思う。
これはMicroservicesやServerless Architectureに限らないことだけれども、標準技術を積極的に採用しようとするあまり、むしろ本質的なことに労力を割くことが難しくなっているように見受けられることがとても残念である。
独自スキーマと独自認証のすすめ
標準技術を使わないとしたらどうすればいいのか。
結論から言えば、もう「お勝手」でいいじゃんということ。
APIの設計ではURIとスキーマの設計が重要であると説明した。
一時、スキーマレスがもてはやされたことがあったが、業務アプリを作るにはスキーマは必須と考えてもらいたい。
かつてXMLでは数学的に厳密なRelax-NGなど優れたスキーマ言語があったがJSON主流の現在は使われなくなった。
しかし、代わりにJSONSchemaを使うべきというのは早合点である。
なぜなら、APIはJSONだけではないからだ。実際にReflexWorks/vte.cxのサーバ間通信ではMessagePackが使われている。
私たちの要求はXML/JSON/MessagePackすべてに共通して使えるスキーマ言語である。
独自にスキーマ言語を作ったのはこのような理由からでもあった。
また、Microservices化で分散システムになるとAPIにおける認証が必要になってくる。
「お勝手」認証はとてもリスキーだ。全然関係ない人から税金とるぞと脅されたりもする。
しかし、こういう議論「WebAPI認証について」をしっかりやって、セキュリティ的な脆弱性がないことを確認して自己責任でやる分には全然問題ないと思う。
約５年前、私の勧めでOAuth(v1.0)を導入したあるお客様システムが度々パフォーマンス問題を引き起こしているのをみて、あのときの判断は本当にそれで正しかったのか。ドメインが変わるとはいえ社内サブシステムの連携にOAuthはやりすぎだったのではないかと反省している次第である。
0 件のコメント:
コメントを投稿