日曜日, 12月 13, 2015

Enterprise API とPlatformについて このエントリーを含むはてなブックマーク

「Enterprise APIs Advent Calendar 2015 の13日目の記事です。」

日経新聞(11/17) 柳川東大教授の「エコノミクス・トレンド」という記事を読んだ。
それは、これまでのパッケージアプリケーションなどの機能を部分的に切り出してオープン化し、他企業の利用を促進することで思いがけない「組み合わせ」を期待するという話であった。

想定しない新たな組み合わせが新しい大きな価値を生むが、そのためには他社をひきつけるプラットフォームが重要ということらしい。

今回はこのプラットフォームの実装面についてAPIとアーキテクチャーの観点から述べてみたい。

オープン化とプラットフォーム戦略


概要は次のとおりである。

  • 自社の強みのある部分、いわゆるコアコンピタンスの部分に特化してしまって、他は優れた外部を組み合わせた方が良い場合も出てくるだろう。
  • また、単にコアコンピタンスを生かすだけでなく、他が参加しやすい「舞台」を用意する「プラットフォーム戦略」がポイントになる。
  • 多くの他事業者あるいは消費者が積極的に利用するようなシステム、サービス、あるいは規格といったものをプラットフォームと呼ぶ。
  • 強力なプラットフォームは新しい企業が参加しやすい「舞台」となり、新しい組み合わせをひきつける力となりうる。
  • 開発の基盤となるようなシステム、利用しやすいサービスや規格はプラットフォームとして外部に提供できる。
  • それを利用する事業者やベンチャー企業をできるだけ増やすことができれば、プラットフォームの魅力が高まり、新しい組み合わせの可能性も広がってくる。

これはまさにEnterprise APIが狙っているところであり、コアコンピタンスのオープン化とはつまりAPIを公開することに等しいのだろう。
ここまでは誰にでもわかる話だが、問題はそのような魅力的なプラットフォームを具体的にどのように実装するかということである。

プラットフォームにおけるAPI利用の形


それぞれが単にAPIを公開しただけでは「他社をひきつけるプラットフォーム」が自然発生するなんてことはないだろう。それほど甘くないことはわかる。
少なくともプラットフォームではAPIをどう利用するかについて標準的なデザインパターンを用意する必要があると思う。

ここでまずAPI利用の基本的な形について整理しておきたい。



最上段の①がモノリシックな3階層のWebシステムで、真ん中の②がそれをMicroservicesにした形、最下段の③がいわゆるサーバレスアーキテクチャーといわれる形である。

重要なのはControllerであり、プラットフォームがそれを提供しなければならないということ。また、Same Origin Policyを基本とする標準的なWebのルールに則る必要がある。

③のサーバレスアーキテクチャーは今注目されているパターンだが個人的には筋が悪いと思っている。
それは、XHR2のCORS対応で頑張って異なるサーバ同士を繋げることができたとしても、クライアントから直接モデルを更新できるため、例えば、ECにおける商品金額のマスターチェックを回避するなどの不正を防ぐことができない。
金額を正確にチェックするにはサーバ側でマスター参照しなければならず、そのためにサーバ側にもロジックを置く必要がでてくる。となると②と大して変わらないということになる。(※ 金額チェックはモデルで実行すべきと考えられるがサーバ側に固有のロジックを置くのは馴染まない)

というわけで、基本的には②の形がプラットフォームの標準的なデザインパターンになっていくのではないかと思う。

Controllerを跨ぐ連携の必要性


APIの利用は上述したようにcontrollerを介して行われるが、今後はControlerまたぎのAPI連携をも想定する必要があると思う。
つまり、異なる企業がそれぞれの機能をコンポーネント化して外部に公開することを考えると、異なるドメインにおける画面遷移を意識した作りにならざるを得ない。

例えば、ECにおける受注機能と出荷機能の連携では、出荷画面に遷移して伝票を印刷してまた受注画面に戻るといったような画面遷移を伴うアプリケーションの事例もある。

このように、API連携だけでなく異なるドメインの画面遷移を伴うようなWebアプリケーション連携についても標準的なデザインパターンを考えていく必要があるように思う。

この場合、もはやAPIと言っていいかどうかはわからないが。

ところで、12/16(水)にセミナーをやるので、興味のある方はぜひご参加ください。 Qiitaの記事も毎日更新しています。

木曜日, 11月 26, 2015

新BaaS論 ~ロックインされない仕組みを考える~ このエントリーを含むはてなブックマーク

BaaSがいま萎えている。 

このエントリでは、まずBaaSの現状、とりわけロックインについての課題点を説明し、私たちの新しいBaaSであるvte.cxのアプローチについて、提供する立場から解説する。

スケールしないBaaSの現状


とにかくBaaSは運用が大変なのだという。 

BaaSなのに、人が手厚くサポートしないと何も作ってもらえないか、すぐに見放されることが多いとのこと。 

また、放っておくと乱暴なユーザによってリソースが食いつぶされる事案がよく発生するらしい。 その場合、お客様に直接言って原因となっているクエリを改修してもらうようお願いすることもあるとか。

 当初の理想からかけ離れた事態に陥っているのが今のBaaSの現状だと思う。
 BaaSは既にバックエンドそのものが提供されているのでバックエンドを開発する必要性がない。 その分、工数が削減されるので、少ない人的リソースでサービスを素早く構築できる可能性が広がる。
 また、クラウドの特性を生かして自動化できればスケールメリットも生まれる。 

ところが、いちいち人が客対しないとだめな現状では、このようなBaaSのメリットが生まれないし、請負開発と実質的に同じことである。 

むしろ、BaaSでは制約がある分、妥協や苦痛を強いられるので、それだったらBaaSを使わないで最初から自分たちでサーバ立てる方がましではないか、となる。
 

逆ベンダーロックインの恐怖


また私はあるBaaSベンダーに聞いた。
「どうして自動化してスケールする仕組みにしないの?」

衝撃的な答えが返ってきた。
「曲がりなりにも既存のお客様が利用されているので機能改善ができないのです。」

実は既存のシステムがあるせいで進むことも止めることもできないという硬直した状態に陥っていたのである。

この状態に名前をつけるとしたら「逆ベンダーロックイン」というところか。

ベンダーに囲い込まれて身動きが取れないユーザの状態をベンダーロックインというが、逆ベンダーロックインは既存ユーザに囲い込まれて身動きが取れないベンダーの状態をいう。


ユーザはロックインが怖くて踏み込めない悩みがあるのではと思いきや、ベンダーもユーザのロックインで悩んでいたというオチ。

反吐が出そうなお仕着せAPIと押し付け仕様を強要し、お互いに辛みを抱えながら何も改善できない状況が永遠に続く。


なんという痛々しい状態だろう。

フロントエンジニアを救うはずだったBaaSはミイラ取りがミイラになっている。
BaaS界隈はこのようにダメダメ感満載の現状なのである。

その彼に「弊社もBaaSに参入しますのでよろしく」といったところ、
「それはご愁傷様です」と返された。まじかよ。(><;)

vte.cxのアプローチ


結論からいうと、vte.cxであれば、ベンダーロックインも逆ベンダーロックインも発生しないので心配ない。
vte.cxは、これまでの「バックエンドAPIを提供することだけに特化している」というBaaSの概念を覆す、極めて自由度の高いBaaSである。

その理由は、そもそもAPIやSDKライブラリを提供しないからだ。つまり、SDKがなくても使える。それがvte.cxのよいところ。

なので、よくBaaSのデメリットとしていわれる「ユーザはただBaaSが提供するWebAPIやクライアントライブラリを使用するのみであり自由度はありません」といった説明はvte.cxに限っては当てはまらない。

「バックエンドAPIを提供する」ための基盤を提供するのがvte.cxの役目で、あるのは規約だけ。サーバの導入・設定、テーブルの設計、O/Rマッピング等の構築は一切必要ない。

また、マイクロサービス的にプラグインで拡張していくことが可能なため、よほどのことがない限り、別途バックエンドの構築が必要になるようなことはない。

リソースとデータモデル


他のBaaSでは、例えば、ユーザ管理用API、ACL管理用API、データ管理用API、ファイル管理用API・・・といったように、それぞれ別のAPIを用意していることが多い。

このように、BaaSのAPIには設計した人独自の感性による「お勝手API」が定義されている。そこにはデータモデルが存在せず、ひどく散らかっている印象がある。
それに、与えられたAPIの範疇でしか使えないし、そもそも用意されているAPIの機能が貧弱だ。

 APIではなくて管理画面を使うものもあるが、管理画面を操作する≠便利ということがわかっていない。

APIにせよ画面にせよ、こういった固定的でお仕着せなのがロックインの元凶だと私は思っている。
そのBaaSを使うということは、永久にお勝手APIに付き合わないといけない。
よほど洗練されたAPIじゃないとお近づきになりたくないと思うのは私だけではないだろう。

一方のvte.cxは「バックエンドAPIを提供する」ための基盤であり規約である。
その規約の一つがリソースとデータモデルになる。

重要なのはAPIではなくリソース。これは、RESTの原点でもあったはずだ。

リソースというのはデータの集合であり、RESTによる操作でJSONになったりXMLになったりMessagePackになったりする。
ACL、プロパティファイル、HTMLやCSS、JavaScriptや画像などもすべて同じようにリソースとして扱われる。

また、リソースはすべてがデータツリーの中で表現される。
データツリーは、Unixファイルシステムのディレクトリ構造と同じと思えばよい。直感的で非常にわかりやすい構造だ。






vte.cxではACLも設定ファイルも単なるリソースの一つであり、他のリソースと同様、RESTで操作できる。

余談ではあるが、Open API Initiativeが結成されて、「RESTful APIのためのWSDLとも言うべき、RESTful APIのインターフェイスを記述する」なんて記事が出た。 我々はいつまでAPIの標準化に振り回されつづけるのかという残念な気持になるが、そもそも問題点を見誤っていないか?

JSONでAPIを記述できるSwaggerをベースにしており、「APIのオープンな相互運用性を促進すると同時に可能性を拡大するためのもの」とのことである。
WSDLでやろうとして失敗したことを単純にJSONでやるだけで成功するのか?私はそうは思わない。
前述したように、お仕着せお勝手APIをSwaggerで晒したところで、「オープンな相互運用性を促進できる」ほど甘くないことは明らかだろう。

また、WebAPIが単なるRPCではうまくいかないことはCORBA IIOP、SOAP-RPC等の歴史が証明しているし、開発者はこのことにもっと注意を払うべきである。

このあたりについては、過去の記事「IsomorphicとAPIファーストについて」なども読んでもらいたい。


ただしフロントエンドエンジニアの責務は大きくなる


フロントエンドエンジニアは、バックエンドの処理を考えないでフロントエンド駆動で開発するが、サーバで必要なものはAPIを参照しながら開発していく。

しかし、API一覧のようなものがないと戸惑うフロントエンドエンジニアは意外に多いと思う。これについては、過去の記事「RESTとJSON、スキーマ定義について思うところ」にも書いた。

vte.cxでは、リソースを操作するAPIを規約に則って実装するのはユーザの責務である。
 

 つまり、APIを作るのは YOU 。

とはいっても、サーバサイドのAPIが既にあることが前提で開発することが多いフロントエンジニアに、いきなりAPIを作れといって戸惑うのも当然かもしれない。

これは実質的にサーバサイドを作らされているのと同じ意味であり大きな負担であることは間違いない。


しかし、vte.cxのAPIはURIとスキーマだけ設定すればいいため、ゼロからサーバサイドを立てるよりはるかに楽なはずである。


スキーマは画面の項目をそのままスキーマの項目に落としていけばいいし、RDBのテーブル設計に伴う正規化などは一切考える必要はない。

稀にスキーマレスを主張する人がいるが、ログ収集などは別として業務アプリケーションではスキーマをしっかりと設計するのは常識である。

BaaSはスキーマレスのMongoDBを使っているところが多いのでスキーマ設計ができないものが多いのだが、これをしっかりやらないと後でイタい目にあうことはココとか、ココとか見れば明らかである。

最後に


ここまで、既存BaaSの問題点とvte.cxのアプローチについて述べてきたが、具体的なAPIの実装方法についてはQiitaの記事にまとめていくつもりなのでぜひ読んでもらいたい。


また、12/16(水)にセミナーをやるので、興味のある方はぜひ参加してください。


フロントエンドエンジニアの価値を高めるBaaS(vte.cx)
~ フロントエンドだけで作るこれからのWebシステム開発 ~

http://acrovision.connpass.com/event/22816/






金曜日, 11月 13, 2015

フロントエンジニアの価値を高めるBaaS vte.cx βの発表 このエントリーを含むはてなブックマーク


ReflexWorksは、選択と集中の話に書いているようなスタンスで、企業向けミドルウェアとして開発をすすめてきたが、今回、もっと多くの方に利用してもらうべくBaaSとしてリリースすることにした。

フロントエンジニアだけでWeb開発できるようにしたい。
これが、BaaS vte.cxを作った動機である。

やっと今年の年末にβリリースまでこぎつけることができた。
思えば長い道のりだった。
私たちは投資をうけておらず受託の仕事をやりながらBaaS開発をやっている。
それはとても大変で、すごく時間がかかることだ。
基本的な構想まで含めるともう10年近くになる。

2006年、Reflex coreを作成
2009年、Reflex iTextを発表
2010年、TaggingServiceを発表
2011年、あるお客様の大規模トランザクションシステムがサービスイン

その後、いくつかのお客様システムに導入され、様々な要求に応えるべく機能が追加されてきた。

そして、
2015年12月、BaaS vte.cx β リリース

2006年当時からBaaSの構想があったわけではないが、サーバサイドで画面をつくるのはやめてAPIにする設計は当時から一貫していることだ。

つまり、サーバサイドは、SPA(Single Page Application)のためのバックエンドサービスに特化するということ。

HTML、CSS、JavaScriptなどのフロントエンドコーディングだけでデータの保存・更新・取得を伴う動的なWebサービスを作ることを可能にする。
フロントエンドだけでWebシステムを作ることができるため、開発者はクリエイティビティな作業に集中できるようになる。


また、重要なのがトランザクション処理。

複雑な業務システム開発ではトランザクション処理が必須になるが、ReflexWorksはACIDトランザクションと楽観的排他制御(Snapshot Isolation)をサポートしている。

デプロイも簡単だ。
gulpコマンドで実行するか、GithubにpushするだけでCircleCIが自動的にデプロイする。

slackで会話しながらGithubにpushしてデプロイする開発スタイルをあたりまえにしていきたい。

このようなアーキテクチャーと開発スタイルは、開発生産性や品質の向上をもたらし、とりわけフロントエンドエンジニアの価値を高める。
そして、楽しく素早く開発することは、お客様からの評価にもつながるだろう。

ところで、セミナーやるのでみなさんぜひ参加してください。

フロントエンドエンジニアの価値を高めるBaaS(vte.cx)

QiitaのAdvent Calendar

vte.cxの仕様

月曜日, 6月 22, 2015

マイクロサービスで守るべきたった一つのこと このエントリーを含むはてなブックマーク


最近、マイクロサービスという言葉をよく聞く。  一つだけ言いたいことがある。

マイクロサービスとSOA

かつて私はIBMのSE時代にSOAを広めようとしたがうまくいかなかった。 
一言でいえば概念先行の「絵に描いた餅」から抜け出すことができなかったからだと思う。

それが最近ようやく、マイクロサービスという形で本物になってきた。 

マイクロサービスはSOAと目指すところは同じだと思うが決定的に違うものが一つある。

それは、SOAのような概念先行ではなく、実際に存在する優れたウェブサービスのアーキテクチャーに付けられた名前であり、後付けの理屈であるということだ。

「優れたウェブサービスを観察したところ同じようなアーキテクチャだったので、それをマイクロサービスアーキテクチャと名付けた」ということらしい。

I/Fを決めて疎結合にすることが重要

モノリシックなアプリをコンポーネントに分割して、小さなサービスの集合体として構築する方法といえば、SOAと同じだと言えなくもない。

しかし、単に分割してWebサービスで繋いだとしても実質的にはモノリシックのまま変わらないだろう。 

ポイントは、I/Fをきっちり決めてコンポーネント間を疎結合にすることである。 
疎結合とは、実装面でいえば、自コンポーネントに何かしら影響のあったとしても、他のコンポーネントへの影響がないようにすることだ。

 I/Fから先は関知しないというのが鉄則であり、サービスの実装がどうなっていようと実行結果が保証されていれば問題ないという立場を取る。 
また、非同期実行により遅延などを許容する仕組みにすることも有効かもしれない。 

このように突き詰めていくと、おのずと「プロジェクトではなくプロダクト」という考え方になっていくのだと思う。

SPAと疎結合

SPAにおいてもこの考え方は有効だと思う。

I/Fを元に疎結合にすればクライアント開発者とサービス開発者は並行して開発できるようになる。 

それが、I/FではなくRDBのテーブルをクライアント開発者がイメージするようになると、すぐに密結合に陥るので要注意である。
(そうなるとクライアント開発者はRDB設計者に大いに振り回されることになる) 

ただ、クライアントもサービスも同じ人が設計するような小規模開発の場合は、I/F分割などを考えずにモノリシックに作った方が効率的かもしれない。 

開発効率を優先して、最初は敢えてモノリシックに作っておき、後で大規模になったときにマイクロサービス化して分割するという方法もありだ。 
 

追記:マイクロサービス ⊂ Reactive Systems?

最後に、Reactive Systemとの関係について。

私はESBに代表されるようなほとんどのSOAが失敗に終わったのだろうと考えているが、以下に言及されているように、SOAもまた「同期的な文法で非同期プログラミングができる」というコンセプトの一つであったように思う。

レイテンシや処理の失敗、ネットワークの不安定性、あるいはそれを補うための運用監視といった話題は無視できません。過去に、「同期的な文法で非同期プログラミングができる」というコンセプトを打ち出したプログラミングモデルが大体失敗に終わったのは、そういった事情でしょう。 http://okapies.hateblo.jp/entry/2015/06/26/024505
また、この資料によれば、マイクロサービスはReactive Systems、つまり、「大規模システムの要求に対応できるような設計原則を備えるシステム」の具体例の一つと考えることができ、そこには、非同期メッセージングで疎結合コンポーネントを連携させるといった適切かつ現実的な実装方法が含まれている。

「同期プログラミングにとっての異物」をプログラマの目から隠してしまうのではなく、少し考え方を変えて明示的に扱った方が、最終的には幸せになれる気がしてきます。そして、Future/Promise や(Rx の)Observable のような関数型インタフェースは、非同期な実行モデルに基づくデータフローを記述する上で、優れた抽象化を提供してくれます。
マイクロサービスは後付けの成功パターンということであったが、Reactive Systemsのような設計原則に基づいた話でもあるというのは新しい発見である。

 
参考記事
 
© 2006-2015 Virtual Technology
当サイトではGoogle Analyticsを使ってウェブサイトのトラフィック情報を収集しています。詳しくは、プライバシーポリシーを参照してください。