2件のコメント

(主にインフラ系エンジニアから見た)コーディングやスクリプティングに関しての流れ

主にインフラエンジニアからみて、過去から現在までの流れ…のようなものを私が見えている範囲で記載してみました。昨今はクラウド化の流れと相まって非常に高度な自動化やインフラのコード化まで実現可能となっており例えば「スクリプトも書いたことありません」という人に対してどの領域から飛び込んでもらうのが効率的か…をちょっと悩んでいます。

もうコーディングレスでLogic Appとかそういうところに飛び込んでもらった方がはやいのかもしれないし、仮想基盤のことやWindows, Linuxの中の事はすっ飛ばしてTerraformとかコンテナとかそこに注力するところから入って必要が出たところで仮想マシン内部の処理に入ったほうがいいのかもしれません。でも、現実的にはシェルスクリプトとかPowerShellスクリプトの基礎とかは抑えておかないとだめかもしれないし・・・。結構悩ましい所です。

  1. 昔はバッチファイルやシェルスクリプトで繰り返し実施する作業の効率化がありました。
  2. その後Windows的にはWSHの時代があり、vbscriptでスクリプトを書いたひとも多かったと思います。
  3. その後Microsoft的にはコマンド毎にオプションが違ったりコマンドがなかったりすることを解決し、全て統一するものとしてPowerShellを生み出しました。(私の大好きなJeffery Snoverさんの仕事です。)
  4. これでMicrosoft系はPowerShellで全てオブジェクト指向の管理となりました。(バックグラウンドにあるのは.net framework)
  5. 一方UNIX系は当初からなんでもかんでもテキストであるという思想でした。
  6. MicrosoftはPowerShellを標準として様々な製品を開発しました。GUIではできないことでもPowerShellでなら操作できる。GUIで操作しても裏ではPowerShellコマンドが自動生成されてそれが実行されている…というものも多くありました。(結果、仕方がなくPowerShellを使うようになった方も多いと思います。)
  7. Microsoftはクラウドサービスにもその流れを取り入れました。PowerShellにてクラウドサービスの管理も行うことになりました。
  8. Chef, Puppetなどに代表されるような冪等性を備えた仕組みが登場してきました。(Infrastructure as code, Configuration as code)
    1. 何度実行しても「記載した望むべき状態になる」ことを特徴とします。
    2. これ以前は「これを実行したらこうなる、やって見る前に状態を確認して、やってみて、やった結果を確認する」というような作業の流れを記述するようなイメージでした。
  9. MicrosoftもPowerShell DSCにて冪等性を持つフレームワークを提供しました。
  10. Microsoftのオープンソース指向が進む中でよりマルチプラットフォーム化を意識した取り組みがなされるようになっていきます。
  11. PowerShellの継続開発が打ち切られ、PowerShellCoreに舵がきられます。PowerShellCoreはWindowsだけではなく、Linux, Mac等でも動作するマルチプラットフォームなPowerShellです。(バックグラウンドにあるのは.net core)
  12. AzureにもCloudShellの機能がつき、ポータル上でもコードで制御できるようになります。これまでのAzure PowerShellよりも先にAzure CLI(UNIX系の文化)の方が先に搭載されました。Azure管理はPowerShellよりもCLIの方が優先されるようになってきています。
  13. クラウドサービスも普及する中で、大規模な環境ではもう個別に1台づつターミナルで作業するなり、RDPではいってGUIで操作するなりすることが現実的に不可能な規模になりました。このような環境ではコードで全てを制御可能な環境にすることは必須条件となりました。
  14. WindowsもWindows Server Coreが出てGUIがなくなり、さらにNano Serverにてどんどん軽量化していきます。
  15. Windows Server 2016, 2019となると継続的に進化するモデルはGUIが利用できなくなりました。
  16. 更に軽量化を推し進める中で仮想マシンではなく、コンテナに大きくトレンドが傾きます。
  17. コンテナの標準であるDockerはDockerfileというコンテナをコードで定義できる機構を備えています。
  18. クラウドサービスも冪等性をもったテンプレートにて展開可能な構造となります。AzureであればARMテンプレート、AWSであればCloud formationなど。
  19. ARMテンプレート、Cloud formationによるInfrastructre as Codeと仮想マシンの内部を構成するChef, Puppet, AnsibleのようなConfiguration as Codeによって仮想マシンベースの環境構築の完全自動化が可能となりました。
  20. ARMテンプレート、Cloud formationによるInfrastructre as CodeとDockerによるコンテナコントロールで完全自動化が可能となりました。
  21. 複数のコンテナプラットフォーム自体のコントロールという観点ではKubernetesが標準化してきています。
  22. AWSLambda, Azure Fuctionsのようなインフラ自体を意識せずアプリケーションロジックのみを記載すればそれでおしまいとなるようなサービスも出てきました。ここではInfrastructure as CodeやConfiguration as Codeすら必要ない世界があります。(これですべてまかなえるわけでもないですが)
  23. DevOpsという流れもありますが、NoOpsに向かう流れの方が強そうに感じています。(私の感想)
    ※NoOpsはインフラ管理者がいらないという意味ではなく、極力インフラの面倒を見なくていいアーキテクチャを採用する、くらいの意味で捉えています。

時系列はかなり微妙なのですが、私の観測範囲ではインフラ技術者は7程度のところで止まっている人が多い印象です。私個人としては、ARMテンプレート、Docker、Kubernetesを抑えてAzure/Azure Stack上でのコンテナ含めたインフラ提供の勘所をつかまなくては…と思っていたのですが、ARM直接書くよりもうTerraformの方がいいのかも?調べなきゃ?というのが現状です。(コードを書くということとはちょっとずれてますね。)

皆さんはどうでしょうか?是非コメントいただければと思います。

子供3人。家族優先。都内SIer勤務。Windows系中心のインフラよりの何でも屋。脱原発。 Microsoft MVP for Cloud and Datacenter Management.

2件のコメント

  1. 鬼島さん、コメントありがとうございます。
    たしかにそういう面があるかもしれないですね。

    苦手でも自分で考えてコードを書ける、書こうという人ならそれはもうその時点で素晴らしいということもありますが…。

  2. コーディングを苦手とする人の共通点として、そのプログラムが操作する対象の内部構造を理解する前に、その記述された意味の理解から入ろうとする傾向があると思っています。
    そのため言語が実装として持つ特徴の理解にはまり込み、システムとして上手に動かすという目標を見失いやすいのではないでしょうか。

    一例としてシステム状態に依存する処理を記述するとき、状態遷移表で記述すれば簡潔化できるものを、複雑な判別式の集合にしてしまい、記述者本人にもメンテナンスしにくいコードを作り上げてしまう、などがあります。

    〇伽藍とバザール
    https://cruel.org/freeware/cathedral.html
    >賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
    >
    >またもやフレッド・ブルックス本の第 11 章から。「コードだけ見せてくれてデータ構造は見せてもらえなかったら、わたしはわけがわからぬままだろう。データ構造さえ見せてもらえれば、コードのほうはたぶんいらない。見るまでもなく明らかだから」
    >
    >ほんとはかれが言ったのは「フローチャート」に「テーブル」だった。でも 30 年にわたる用語面・文化面での推移を考慮すれば、ほとんど同じことを言ってる。

コメントを残す

メールアドレスが公開されることはありません。