なんか、気がついたら何時の間にか、
が、β が取れて Public Release になってたんだけど、サービスの機能紹介を見て、
これ、本当に使いモノになるのか？
と疑問に思ったので、幾つか書いておく。
現状 ([2018-03-27 時点) の制約だと、ほとんど使い道ないのでは？]
まず、現状 ( [[2018-03-27]] 時点) の制約だと、ざっと下記の様な機能は 公式から提供はされていない :
- コンテナ間でプライベートなネットワークを作る機能
- コンテナから利用出来る、外付けなミドルウェア環境
3. プライベートなコンテナイメージを Deploy する機能
追記 : [[2018-04-16]] 現在、 Docker Hub の Private Repository からの pull にも対応しているっぽいです
僕が考えるに、 [[Arukas.io]] の現状での制約では、単純な機能の Application 、例えば、 Slack の Webhook へ Post する様な Bot 等と言った、
[データストア 等で [[状態を持たない]] [[アプリケーション]] ]
なら、利用に特に問題となる様な制約ではない、とは思う。
追記: [[2018-04-16]]
下記の取り消し線した制約の部分は、 DockerHub の private repository の pull に対応している事によって、
ある程度は緩和されたのではないかと思います。
ただ、もし本格的に、Arukas.io を使ってサービス運営する、とか考えると、- ソースコードを非公開にする必要があるアプリケーション
は、制約 (3) によって、基本的に Deploy しようがないし、あと、
制約 (1) (2) が有るが故に、状態を持つ様なアプリケーションで、
ミドルウェアを利用しようにも、それがインターネットへ剥き身になる
と言う、 ちょっとそれセキュリティ的にどうなの？ と言う状態になるのは、 かなりの Weak Point じゃないかなぁ、と今の僕は思ってます。
他の Container Runtime as a Service と比べ、機能が見劣りする
少なくとも、一般に著名な [Heroku]] だと 制約 (1) は有っても、制約 (2) と (3) が無いため、特に Production への採用に差し支えないだろうし、また、国内ではあんまりメジャーではないと思われる、 [hyper.sh でさえも、制約 (2) が有るけど、(1) と (3) は存在せず、また、docker-compose 的なツールは使えるので、その辺り Arukas.io は、ちょっと見劣りするよなぁ、と僕は思ってます。
っていうか、コンテナ技術って、幾つかのコンテナイメージを用意し、それを組み合わせることによって、インフラ面でのサービス運営を楽にしますよー、みたいな方向性だと、僕は思ってるんだけれども、 [Arukas.io は、コンテナイメージの連携がインターネットを経由してしか行えない]、という、ちょっと考えさせられる構造になっている上、また、そういったネットワーク面での制約が有るにも関わらず、 現状では、公式に Middlware を提供する仕組みもないっぽい ので、そういう所を鑑みるに、
これ、Production の Web サービスで利用される事を想定してるのかな……
と、個人的には思うのでした。
Arukas.io を Production で利用する際に必要となりそうな事柄
まず、
- コンテナ間でプライベートなネットワークを作る機能
- コンテナから利用出来る、外付けなミドルウェア環境
3. プライベートなコンテナイメージを Deploy する機能
と言う上記の機能は、 [2018-03-27 現在、公式では提供されてない]ので、少なくとも、Arukas.io を Production Ready として使うには、
AWS Lambda 等 と言った様な Function as a Service に 相当するサービスとして使う
しかないのかなぁ、と思っています。また、もし仮に TCP 接続などが必要な Middleware を Arukas.io で使うと思うと、
非特権コンテナでも動かせる VPN みたいな機能
が必要となるので、その辺りも工夫が必要だよな、と思います。
ただ、Middleware を使うには工夫が必要、と言っても HTTP-based API で TLS Client Auth か、あるいは [[JSON Web Token]] とか、そういうった Server-to-Server な通信する時に使えそうな認証が使える Middleware なら、まだ使えないでも無いので、そう言った、 HTTP-based な API を叩けるモノなら、まだ、なんとかなるかなぁ、とは思います。
また、実装の難易度的には高いでしょうけど、Server-Side P2P でクラスタ組んで、みたいな Middleware であり、かつ P2P Node の認証機能を備えている類いのモノであれば、まぁこの辺りの制約は問題にならないかな、と、僕も考えてはいます。
が、そうではない Middleware は、正直 Arukas.io に向かなさそうな感じな印象なので、そういったモノを使いたい場合には、 [Heroku]] か、あるいは、先に上げた [hyper.sh 辺りを使うかなぁ、と言った感じですね。はい。
以上
まー正直、 [[Arukas.io]] はリリースしてまなしなのを差し引いても、 [[Function as a Service]] のリッチ版、みたいな感じにしか、ならないんでは……？ という印象が僕は拭えないので、もうちょっと、こう、 なんとかならんかったのかな 、と個人的には思います。
って言うか、Arukas.io の提供先が国内向け Only だとしても、海外の競合サービスを追い越せ追い抜け、というぐらいの機能は欲しかった、というのが正直な所です。
っていうか 、 現状 ([2018-03-27 ) の Arukas.io で 勝算が有るのか]、って感じに機能が無いので、その辺り、もうちょっと詰めてリリースした方が良かったんでは……？ と僕は思ってます。はい。
追記: [[2018-04-16]]
個人的には、この記事を書いた [[2018-03-27]] 時点での arukas.io が提供している機能では、Production Ready な Web Services を載せるのは無理じゃね？ と思っていたんですが、 [[2018-04-16]] 現在、
Docker Hub の private repository からの pull
に 対応した 事によって、 ある程度は Production でも使えるのではないか 、と、 考え直しています 。
と言うのも、 arukas.io では stateful なデータを扱うには向かない ( これは他の Container 環境でも同一である ) にしろ、 Private Repository が使える事によって、ある程度はソースコードを機密に出来る し、また、
[gRPC の Endpoint を建てる]
と言った様な、
Stateful なデータは取り扱わない けれども、 永続的に Port を Listen する必要が有る
と言った場合には、 割と向く のではないか、と考えているからです。
また、 [[Redis]] とか [[Memcached]] とか使えない事もないけど、使うのは難しそうだなよなー、と考えてもいたんですが、この辺り、 [[gRPC]] on [[HTTP/2]] で [[TLS Client Auth]] とか使うタイプの Middleware が流行ってきたりすれば、割となんとかなるんではないか、とも言えそうだな、と思うんで、そういう意味では、 少しずつ改善はされている のではないか、今の時点の僕は考えています。はい。
ま、個人的には使うかどうかはまだ分からんのですが、使ってたらポシャってサービス終了、というのも困るので、うーん、うーーーん、って感じですね。まぁさくらインターネットには頑張って欲しいところでは有るのですが。
