毎年やっている昨年の振り返りをしてみます。2021年はこれでした。
総合
2022年は、2021年にやったことの一部が成果として世の中に出た年でした。会社としては開示条件を得てなかったので公開事例にはできないのですが、喜ぶ人が観測できたのはよかったです。2022年も新しいことへのチャレンジに取り組んでいます。今もクライアントにフルコミットが必要で、自社の時間を設けるのが難しいのは変わらず、そろそろ自社に引きこもりも検討してほしいといわれそうで戦々恐々しています。
サービス全般を一手で見るのはやはり難しい、主に私が病気や事故で倒れた時に詰むというのを真剣に正面から考えた年でした。あくまでもクライアントへの協力なので、プロジェクトが真摯に取り組むことでもありますが、協力会社しては真剣に悩みます。幸いにして、IaC 100% 、かつ CI/CD を整備し続けてきたこともあり、運用や設計をほかの人に伝えることも進めることができたという側面があり、IaC は本当にプロジェクトの地力を高めるなぁと痛感した年でした。やっておいてよかったIaC、IaCは嗜み。
2022年もわからん殺しが多かったですが、今年も周りに助けてもらいながら一つずつ潰せしました。去年の自分から受け取ったもののうち、課題ではなくしたものと、さらに来年に投げたものがあるので来年早々に片づけます。目途をつけて寝かしつつ、優先順位つけて、完了させて次につなげるの繰り返し。
経営
実は自社でリリース目前でリーガルチェックも通して、あとは私の決断次第というステージまで来たサービスがありました。が、リリースしないという選択をしました。メンバーとも相談したものの、決断は私なので本当に申し訳ないと思います。リリースしなかった理由は、リリース後に取り消せないということにあります。
弊社ではサービスを作るときにホワイトペーパーを用意してサービス開発するか決定しているのですが、そこでもしかしてとチームでも一瞬触れつつ、まぁリリースしてみて考えるかと棚上げしたのです。リリースしたら取り消せないことの重要性に気付かずここまで来てしまった。ペルソナも用意したものの、今考えると都合のよいペルソナばかり用意した結果、サービス開発上はぶれなくいけたものの、リスクをおざなりにしてしまいました。リリースしたときに悪意を持った利用ができる余地があるサービスだったので、リリースがリスクとなります。悪意を持った利用を防ぐには、ホワイトペーパーと利用ペルソナから乖離することになり、サービスの性質が変わる。となったときに寝かせることにしたのでした。
ということで、別のサービスにピボットしてまた考えます。
プログラミング
今年はかなり C# メイン気味だった気がする。Go、Python、TypeScript も書いてたけど、C# メインだったなぁ。
C#
C# 11 が出て、required modifier のおかげで IaC (Pulumi) との相性がかなり良くなりました。呼び出し側に強制しつつ、利用側でもnullable を不要にするにはコンストラクタしかなかったのが解消されてよかったです。
フレームワーク基盤としては Source Generator がかなりよくいい感じだと思います。普通に便利だし、今後も使っていくし、いくつか用意したいものがあるので書いていきたい。C# サーバーの 負荷試験にDFrame を利用しているのですが、v2 はかなり良くなっているのでいいんじゃないでしょうか、v1 でしんどかった部分がほぼ解消したと思いますし、実践向きな構成になりました。Pulumi は良い感じですが、AWS-Native はまだ微妙に怪しいので AWS Classic を使っておくのがいいでしょう。
そういえば、C# の CI は GitHub Actions が完全に決定版という感じまで来たので、あらゆる C# リポジトリの CI は GitHub Actions を用意していけるといいなぁと思います。その割に setup-dotnet は微妙に環境変数回りとかは手薄で悩ましい。dotnet build 周りのプラクティスもちょっとたまってきたので、記事にしたいところです。
IaC
Terraform と Pulumi と cdk を使っていました。CDK いいけど、やっぱりセンスが微妙すぎる。
2022年に痛感したのは、IaC は地力ということでした。チームとして組むときに最低限のコードがドキュメントというのにいくには IaC が必要であり、ドキュメントや CI/CDやテストが一般的なソフトウェア開発のレベルまで高めるのでインフラをソフトウェア開発にするためにも IaC は最低限必要だと思います。
AWS Console や GCP Console、Azure portal でぽちぽちのほうが早い、わかりやすいはそうです。労力がどこまでそこにつぎ込まれているか考えれば当然です。しかし、再現性となるとコードに落とすしかなく、CLI ではだめなのです。ソフトウェア開発のプラクティスをインフラに持ってくるという側面には、再現性が重要なファクターであり、無視しようとするとどこかで誰かが割を食います。チームでインフラ基盤を鍛え上げるにはIaC は必須であり、価値を見失ってはいけないのではないかなぁ。
この側面からみるとBicep は IaC ではないといっていいでしょう。何しろ、インフラを継続的にアップデートできないんだからどうしようもない、IaC ではないワンショットとしてはいいんですけどね。IaC というなら顔洗って出直してくるといいと思います。
terraform は moved 構文によって、ほかの IaC から頭一つ飛びぬけました。コードのリファクタリングをインフラに依存せず安全に行える、そんな仕組みを言語レベルで用意したのは初めてと認識しています。これによって、HCL は現状 IaC を学びサクッと運用に持っていくには最適と言っていいと思います。Pulumi は state json を直接いじればできるけど、言語レベルの moved 構文が来ないと辛すぎるので頑張ってほしい。だが、HCL は制御構文がゴミなので、プログラミングのノウハウからすると、厳しいぞ、Terraform。
コンテナ
ContainerApps への AKS からの移行や ECS Fargate から App Runner への切り替えを行ってみた年になりました。2022年いいぞ、ついに Fargate を意識せず、AKS/ACI を意識せずにアプリを起動できるところまできた。Cloud Run に徐々に追いついたともいえる。実際この世界いいんですよね、Kubernetes や ECS を組むまでもなく、Fargate という仕組みを知る必要もない。コンテナの Build & Share さえすればアプリへアクセスできるというのは、ミニマムに必要なことへアプローチができます。開発環境や社内向けにはぴったりといえます。本番環境で使うには、となると FaaS を置き換えるぐらいならいいと思いますが、Zero to scale がイベントドリブンの前提になります。そういう意味では、App Runner はスタートラインに立てておらず、まだまだだめですね。
Kubernetes は クラウド環境で、1.24 がデファクトになりました。ずいぶん歩みがゆっくりになった気もするけど認識がバグってるでしょう、十分早い。1.25 が欲しい機能を3つほどピックアップしているので、年明けが待ちどおしいです。
Kustomize と Helm 問題は難しいですね、2022年、時々探したのですがいい方法は見つからず答えを探してさまよう日々が続きそう、だれか YAML をいい感じで管理できる仕組み教えて....
ネイティブ
ネイティブビルド、対応プラットフォーム増えると地獄だし、それを複数のOS でビルドサポートするとなるとさらに煉獄って感じで、なにそれ辛すぎます。頑張ったしある程度できたけど、修行足りないので出直してきます。
記事
22本、去年よりは増えた。なんか書きたいことをかけてないんですが、ドキュメントほかで書きまくっててブログに書けないんですよね。適当にもっとライトに書こうと思うので、はてなブログの更新方法も GitHub ベースにしていじっていこうと思います。
ライフスタイル
コロナだいぶんはやりましたね。ついに身の回りでもたくさん感染者が出ました。看病をしてみて思ったのですが、家でもマスクが必要になると導線含めて中々生活は難しいですね。とはいえ、9月以降は慎重にしつつも外に意識的に出かけています。随分と飲食店や映画館も緩くなったという感じがあります。私は意識して口に入れるとき以外マスクしたりしていますが、今のところ感染を避けられるなら安いものだと思います。ようやく食事を楽しめそうになってきてうれしいと思います。好きな店はいくつも閉店してしまったのですが、それも時代でしょう。
2023年は?
2022年は、クライアントに自分が SPOF にならないように働きかけつつ、リリースまでこぎつけたりと休みがほぼなく忙しかったです。そして、何気にリモートワークが終わった。(おわった)
2023年も協力している会社が頑張れるように微力ながら力を尽くしますし、自社の開発面白い感じになりそうなので、時間作るぞ、と。リモートワークになることはなさそうだな!? (信じられない顔をしている)
個人的には、Kubernetes と CaaS がどうなるかが2023年の大きな要になると思います。
