title: "Arukas.io について思った幾つかの疑問"

なんか、気がついたら何時の間にか、

が、βが取れて Public Release になってたんだけど、サービスの機能紹介を見て、

これ、本当に使いモノになるのか?

と疑問に思ったので、幾つか書いておく。

現状 ([2018-03-27 時点) の制約だと、ほとんど使い道ないのでは?]

まず、現状 ( 2018-03-27 時点) の制約だと、ざっと下記の様な機能は 公式から提供はされていない :

  1. コンテナ間でプライベートなネットワークを作る機能
  2. コンテナから利用出来る、外付けなミドルウェア環境
  • 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 で利用する際に必要となりそうな事柄

まず、

  1. コンテナ間でプライベートなネットワークを作る機能
  2. コンテナから利用出来る、外付けなミドルウェア環境
  • 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 が流行ってきたりすれば、割となんとかなるんではないか、とも言えそうだな、と思うんで、そういう意味では、 少しずつ改善はされている のではないか、今の時点の僕は考えています。はい。


  • ま、個人的には使うかどうかはまだ分からんのですが、使ってたらポシャってサービス終了、
  • というのも困るので、うーん、うーーーん、って感じですね。
  • まぁさくらインターネットには頑張って欲しいところでは有るのですが。

nyarla が大体

Scrapbox でコメントや意見を書く