« いいねをもらえなくて鬱になる負のインセンティブが働くという事象 | トップページ | ソフトウェアPJの企画フェーズの責任者は誰なのか? »

2021/10/30

AWSサービスとSW品質特性のマッピングはどうなるか

ふと思いついてメモして、Blogに書くまで昇華できていないアイデアを書き殴っておく。
AWS初心者のロジカルでないメモ。

AWS Fargate とは?「コンテナ」と「仮想マシン」の違い|AWS上のコンテナ関連のサービス | FEnet AWSコラム

AWS Fargateとは?Amazon ECSとの関係性やメリット・デメリットを解説|コラム|クラウドソリューション|サービス|法人のお客さま|NTT東日本

AWSサービスとSW品質特性のマッピング一覧を作ることで、クラウドが何を解決しようとしているのか、整理したいと思っている。

AWSの最大の恩恵は移植性だろう。OSパッチやセキュリティパッチの作業から基本は解放される意義は大きい。
他にも、障害耐性などの機能性やAutoScalingなどの効率性もあるだろうが、盲点なのは保守性ではないだろうか。

Infrastructure as Codeにより、サーバー構築は全て構成管理の配下に置かれ、保守性を大きく担保する。
しかし、それはアプリケーション層のApacheのhttpd.confの構成管理を意味しているわけではない。
むしろ、AWSがNW機器の物理的実体からデータプレーン、コントロールプレーンという論理的実体へ分離することで、膨大なネットワーク機器を一括管理し構成管理できるようにした点が大きな利点のはず。
AWS上で「データプレーン」を提供しているのは「AWS Fargate」と「Amazon EC2」、AWS上で「コントロールプレーン」を提供しているのは「Amazon ECS」と「Amazon EKS」です、という文言を偶然拾って、ああそういうことなのか!と気づきを得た。
だから、Kubernetesが画期的な技術なわけだ。
CCNAを取得したおかげでこの辺りの意義がなんとなく実感できたから。

インフラ関係のPJをレビューしていていつも思うのは、専用回線の切り替えやDNS切り替えだけのNWリプレースの作業のPJで割と本番障害が多くて、なぜたかがNW機器の入れ替えぐらいでそんなに作業ミスが多いの?といつも思ってた。
DNS切り替えなんて所詮、向き先を変えるだけでしょ、と思ってた。
たぶん、その背後には、数多くのNW機器があり、その設定ファイルを手作業で書き換えて、手作業で検証する必要があって大変なのだろう。
だから、NW層のレベルで構成管理できる意義はとても大きいのだろうと推測している。

|

« いいねをもらえなくて鬱になる負のインセンティブが働くという事象 | トップページ | ソフトウェアPJの企画フェーズの責任者は誰なのか? »

構成管理・Git」カテゴリの記事

ネットワーク・クラウド」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« いいねをもらえなくて鬱になる負のインセンティブが働くという事象 | トップページ | ソフトウェアPJの企画フェーズの責任者は誰なのか? »