技術選定の基準は課題解決

多様性あふれる世界なので、ひとえに技術選定と言っても様々な理由でされるかと思います。
そんな中、自分は 過去直面して苦労した事がある課題を解決させるため という理由で技術選定を行ってきました。

例えばどんな技術を選定している？

Go言語

サーバーを実装する時はGoを使っています。
理由は サーバーを開発/運用してて、複雑で色々できる言語よりも、コード量が多くなってもいいから単純でやれることが少ない言語が良い と思ったからです。
サーバーサイドはインプットとアウトプットの形式が限られ（ほぼJSON）、更にデータ破損という最悪のケースを防ぐために堅牢でわかりやすいロジックを書くことが推奨されます。
そう考えると継承等の機能がなくて個性が出にくく 誰が書いたかわかるコードではなく、誰でもわかるコード になりやすいGoが選択肢に挙がりました。
もちろん速度が出る、シングルバイナリ、並列処理が書きやすい等のメリットも素晴らしいです。

GCP

過去にAWSで複雑なインフラの管理で消耗して、サービスの開発が遅々として進まない経験をしました。
もちろん元のインフラを構築した専門のSREが付いてくれれば良いが、残念ながら既存の儲かっているプロジェクトに吸い取られ、新規開発はサーバーエンジニアが頑張るスタイルになります。

だったらGCPで CloudRun や Appengine 等のオートスケールなものを使って、周辺の便利ツールである PubSub, BigQuery, Logging とGCPのCredentialが合えば特に設定不要でまんま使える構成を採用し、JOINして１時間でキャッチアップできるような構成でやった方が幸せになれる事が多かったです。
今の所、弊社エンジニアはほぼインフラ気にせず、全員サービス開発に集中できています。

Firestore

バックエンドで起きる障害の８割がDB負荷による障害だと思っているので、勝手にスケールしてSELECTパフォーマンスが劣化しない Firestore は課題を解決してくれています。
RDBが得意な部分は、BigQueryと連携すればかなり補完できるので、今の所困っていないです。
価格的にも機能的にも、二度とRDB触りたくないくらいの感覚になってきてしまっています。

逆に使わなかった技術

k8s

CloudRun や Appengine を基本的に使い、要所で GCE を使えば事足りるなと思っています。
逆になんであんなに流行ってるのか知りたいです。価格/学習/運用コストとても高くないですか？

CleanArchitecture, マイクロサービス

エンジニアが数十人で、入れ替わりも激しい現場であれば非常に効力を発揮するんだと思います。
ただ大抵の現場はエンジニア１〜３人、多くて５〜６人だと思うので、ほとんどメリットを享受できずに、コード量と制約の多さにツライ思いをするだけなのではと思っています。

BigQuery以外の分析環境

BigQueryが安くて早くて多機能で優秀すぎて、他を検討する気すら失せてしまった…マジで１強…

gRPC

既存のサーバー間通信（HTTP1）で、特に課題を感じていないので採用していないです。
確かに速度は早くなると思いますが、サーバー間通信で遅いといっても数ミリ秒なので正直どうでもいい範囲だと思います。
また世の中に充実しまくったHTTP1関連のノウハウやツールを捨ててまで採用する気が起きないというのもあります。

GraphQL

少し頑張ったのですが、わざわざ使いたい値のクエリ作るのが面倒なので、もう全部返せばいいじゃんと思ってRESTに戻ってしまった。
またバックエンドの設計がGraphQLに沿ったものにしなければ行けないのが地味にだるかった。コード自動生成とか使えばもう少し楽になるのかな。
あと弊社はreadの部分はFirestoreから直接読んでいる（write、複雑なread、センシティブな情報はバックエンドでGetAPI作る）事が多く、そもそもあまり使うメリットがなかった。

まとめ

今は友人と起業して開発会社やっていますが、一貫した技術選定すると本当にパフォーマンス出ます。
もちろん現場にあった技術選定が大事だと思うので自分のやり方は一例に過ぎませんし、他に便利なものがあったら乗り換えるかと思います。
ただ、大事なことは流行に流されずに、自分の課題が解決できる選定をするのが、相手にも説得力あるし、自分も嬉しいし、良い事だらけなのではと思いました。