この記事はFIXER Advent Calendar 2020 ( https://adventar.org/calendars/5587 ) 17日目の記事です。
前日はこちら( https://tech-blog.cloud-config.jp/2020-12-16-powerapps-torisetsu-code-indent-tips/ )。PowerAppsの小技ですね、こういうノウハウを積み上げれば誰でも凝ったアプリが作れるようになりそうで、プログラマー出身としては冷や汗が出ます笑

2020年、嵐のように過ぎていきました。33歳でこんなに新しいことをやるとは・・・いや、FIXERに入ったからには当然でしょうか。「SEの35歳定年説」みたいなものはFIXERには存在しないな、と改めて実感した1年となりました。

今年、技術のトレンドだなと感じたことを整理すると、2点に集約されるように思います。

インフラもアプリも、すべてを「コードで定義」する

インフラ、といってもクラウドですが、これはコードで定義できます。
IaCと総称される、AzureならARMテンプレート、AWSならCloudFormationですね。言語依存しないためにはterraformを使うのが良くて、terraformを書きまくる1年でした。
コードで定義すればインフラができるので、アプリエンジニアな私にはとても親和性が高かったです。
もちろんインフラの知識が無くて最初はかなり苦しみました・・・

また、コンテナ、Kubernetesといったインフラ寄りの技術もコードでの定義です。こちらはDockerfileやyamlでの記述になります。これも最初泣きそうでしたね・・・

つまり、クラウドを使う前提に置いて、コードが書ければサービスが組めるわけです。
おじさんにはすごく画期的な時代に思えました。若い人にはどう見えているでしょうか？

コードで定義するのは「処理の流れ」ではなく「あるべき状態」

コードを書く、というと、上から下に流れる処理を書くことを想像するかもしれません。
しかし、そうとは限りません。

terraformコードやKubernetesのマニフェストファイルは、「インフラをこういう状態にしたい」と定義するものです。
terraformの場合はその定義に沿って、現在のクラウド上の状態と異なる部分を変更してくれますし、Kubernetesの場合は常にその状態になるように自律的に運用してくれます。

これは本当にすごいことです。
今までは「こうなってたらこうする」という、条件式をいくつも用意していたものが、「こうしたいんだ、あとはよろしく」で済むのです。
業務の本質に集中できると思いませんか？

アプリケーションは処理の流れでコードを組みますが、ローコードやノーコードの開発も発展してきました。こちらもどうなっていくか分かりませんね。

まとめ

以上のことから、今後、「コードが書ける人」が強いことに間違いは無さそうです。
従来型のインフラエンジニアの人はきっと大変です。
アプリエンジニアの人は言語的なハードルは低いですが、インフラの勉強は必須です。
今年、いくつかのサービス運用に関わりましたが、アプリもインフラも知っていないと解決できない問題にいくつも当たりました。これからはどちらも見れる人材が求められるのではないでしょうか。

我々ITエンジニアは物理サーバーや電気が無ければ無力です。Kubernetesやterraformの裏では膨大なロジックが組まれていることも忘れてはいけません。そうした周辺にも感謝しつつ、クラウドエンジニアとして必要なものをスマートに素早く提供する役割を果たしていきたいと思いました。