ロックイン

Rebuild.fm の mirakui さんの回聴いてたんだけど、インフラの世界観だと、ロックインさせたい Amazon/Google VS 自由を手に入れたいDocker みたいな構図がある、な話があって、思うところがあった。

rebuild.fm

勿論、話はそう単純じゃないし、それぞれがそれぞれの成果を利用しあってるので、どっちが正義だみたいな話にはならない。第三者目線としては、寡占にならず競争が続くのが望ましい。僕個人の意見としては、金が生まれるところには、正しく金が生まれてほしい。それで全体としての健全性が育まれるなら。日本にいてあんまり面白くないのは、その辺の基盤技術に関われる機会があんまりないことだが…。

とはいえ、利用者目線としては、できるだけ自由なポジショニングを可能な限り選び続けるべき。だが、自由を手に入れるには、それだけの知識が必要となるし、そこを諦めたところをアウトソースなり、ロックインされることになる。

何にBetするか。これは難しくて、第一言語に引きずられるし、フロントエンドやってる僕も、「最近のお前の技術選定はFacebook党だろ」と言われたら否定できないが、別にFacebookから金をもらってるわけではないので、その点では自由ではある。いいと思ったらいくらでも鞍替えする。CoffeeScriptを諦めたように。

で、最近困ってるのが、フロントエンジニアとしての専門性を高めた結果、インフラをやるにあたって、何にBetするか、で、やはり自分の今の競争力を担保するために、少ない時間で最大限の成果を、という判断基準になる。必要なのは、DB抽象とオートスケール。そうすると、ある程度ロックインされた方が、やはり幸せなのではないか?という気持ちがある。

最近調べたのは AWS Lambda/DynamoDB と Firebase で、ラピッドプロトタイピングで邪魔されない程度に機能が揃ってると良い。そうなると、ロックイン度が高いFirebaseがやはり選択肢になってくる。

でもなー、やっぱFirebaseはなー、クソーという気持ちにはなる。ストレージに掛けられる制約もゆるいし、それによって実装できるアプリの性質が結構変わってくる。Todoアプリぐらいだったら問題ないけど、ゲームのセーブデータを預けろ言われると無理そう。あとなんとなくGCPとかGKEとかGAEがこっちを見てる気がする。

AWS Lambda もそんな嬉しくはなくて、結局あの膨大なAWS関連サービスを使いこなさないとちゃんとしたデプロイまでたどり着けなくて、それに試してわかったけどDynamoDBもかなり特殊なデザインだし、あれをNoSQLとして長期的にメンテ出来るかよくわからなかった。調べた感じMigrationに難がありそうだった。難というか、何も支援がない、という感じで。

ここで個人として取れる戦略は、とりあえず Storage Pattern とかでDBへのアクセスを抽象化しといて、プラットフォームごとに実装を切り替える余地を残しておく、みたいな、とても普通の結論になる。

まあ大抵は僕一人で作るわけじゃないので、AWS系だと扱えるエンジニアが多いの考慮してS3とLambdaとDynamoでちょろっと作るか、最初はFirebaseで作ってあとで切り替えるみたいな展開を想定しておくといい気がする。って感じで今はFirebase使おうとしてるけど、どのぐらいスケールして、どのぐらい金を払うことになるか、の肌感がないので、提案するにも怖いなぁ。いやー金払うのを躊躇するレベルになったらインフラの専任付く余地あるから別に考えなくてもいいんじゃない?いやそういう発想が逃げなの?恥ずかしくないの?いやー僕は基本はフロント沼掘ってるんで任せますよー。えーどうなんでしょうね。

結局アプリケーションエンジニアはDBアクセスを抽象化しましょうねーという当たり前のゴールだけしか見えなくて辛いなーJSにいいORMないからなーActiveRecordほしいなーでもRDBMSだけじゃなくて各NoSQLやIndexedDbという対象がプラットフォームとしてあるから難しいなーという感じです。

オチはないけどこのへんで悩んでます。知り合いが多いGoogleやトップゲート社方面からFirebaseやれよと言われるのまでは見えてる。