⇧「jQuery」はオワコン言われがちだけど、継続的にリリースされてるようですね。
大規模な「Webシステム」開発に向かなくなったというだけで、小中規模な「Webサイト」構築とかでは利用されてるってことですかね？
ちょっとした「ランディングページ」とかを作るのに、学習コストのかかる「Vue」や「React」を使うメリット思いつかないですし...
Kubernetesの構成をおさらい
「Amazon Elastic Kubernetes Service (Amazon EKS)」の前に「Kubernetes」の構成をおさらい。
⇧ 上記の記事で調査した感じでは、「Kubernetes」の構成は、
⇧ 上図のようになっており、大きく分けて、
- Control Plane
- Node（Worker Node）
の構成になってましたと。
Amazon Elastic Kubernetes Service (Amazon EKS)
AWSのドキュメントの説明で、
Amazon Elastic Kubernetes Service (Amazon EKS) は、AWS クラウドおよびオンプレミスデータセンターで Kubernetes を実行するためのマネージド Kubernetes サービスです。クラウドでは、Amazon EKS は、コンテナのスケジューリング、アプリケーションの可用性の管理、クラスターデータの保存、および他の重要なタスクを担当する Kubernetes コントロールプレーンノードの可用性とスケーラビリティを自動的に管理します。Amazon EKS を使用すると、AWS インフラストラクチャのすべてのパフォーマンス、スケール、信頼性、および可用性のメリットを享受できるだけでなく、AWS ネットワーキングおよびセキュリティサービスとの統合の恩恵も受けることができます。オンプレミスの EKS は、統合されたツールと AWS Outposts、仮想マシン、またはベアメタルサーバーへの簡単なデプロイを備えた、一貫性のあるフルサポートの Kubernetes ソリューションを提供します。
⇧ という構成になっていますと。
どうやら、「Amazon Elastic Kubernetes Service (Amazon EKS)」では「Kubernetes」で言うところの「Control Plane」部分のみ担当しているようで、「Node（Worker Node）」部分については、
- AWS Fargate
- Amazon EC2（Amazon Elastic Compute Cloud）
のどちらかのAWSサービスが担う形になるみたい。
Amazon Elastic Container Service (Amazon ECS)
「Amazon Elastic Kubernetes Service (Amazon EKS)」と似たようなサービスとして、「Amazon Elastic Container Service (Amazon ECS)」というサービスが用意されており、
Amazon Elastic Container Service (Amazon ECS) は、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを容易にするフルマネージドコンテナオーケストレーションサービスです。アプリケーションと必要なリソースを記述するだけで、Amazon ECS が柔軟なコンピューティングオプションで、アプリケーションを起動、モニタリング、スケーリングし、アプリケーションが必要とする他の AWS サポートサービスと自動的に統合します。カスタムのスケーリングルールやキャパシティルールの作成などのシステムオペレーションを実行し、アプリケーションログやテレメトリからデータを確認し、クエリします。
⇧ という構成になっているようです。
Amazon Elastic Kubernetes Service (Amazon EKS)とAmazon Elastic Container Service (Amazon ECS) の違いって？
ネットの情報によりますと、
⇧ とのこと。
どちらもコンテナ化されたアプリケーションを管理する用途向けのサービスではありますと。
「Amazon Elastic Kubernetes Service (Amazon EKS) 」と「Amazon Elastic Container Service (Amazon ECS)」のどちらにしろ、
⇧ 上図のように「Control Plane」のみという構成になるようですね。
う～ん、他のクラウドベンダーでも「Control Plane」と「Node（Worker Node）」で提供するサービスを分離した構成にしてるんだろうか？
「Amazon Elastic Kubernetes Service (Amazon EKS) 」って、名前に「Kubernetes」って含まれてるから、普通に「Kubernetes」と同じ構成になってると思っちゃうやん？
AWSが異端なだけなのかどうかは分からんのだけど、AWS的には「Amazon Elastic Container Service (Amazon ECS)」を推していきたかったから、分離した構成にしたんかね？
移植性とかを考えると、ベンダーの独自色を加えられるのは辛いんよね...
ちなみに、2018年頃に比較された情報らしいのですが、
数あるマネージドKubernetesサービスの中にあって、導入検討企業のほとんどがチェックするのがパブリッククラウド御三家 – AWS、Microsoft Azure、そしてKubernetesのオリジナルの開発元であるGoogle Cloudでしょう。ここではKubernetes関連の情報をひろく発信しているサイト「Kubedex」に掲載された「Google GKE vs Microsoft AKS vs Amazon EKS」という記事を紹介します。ここに載っている三大サービスの比較表はKubernetesサービスを探している企業にとっても参考になる部分は多そうです。
最強のマネージドKubernetesはどれ? スペシャリストが比較検証したGKS/AKS/EKS – G3 Enterprise
この記事を執筆したDevOpsコンサルタントのSteven AcremanがそれぞれのKubernetesサービスについて評価したポイントを以下、ざっくりと紹介します。
- Kubernetes”だけ”を使いたいなら迷わずGKE一択、なぜなら「安い、速い、うまい(cheaper, faster, better)」から。クラスタの作成時間はGKEは3分、ほかは20分。もし頻繁にクラスタを作成する環境なら、3分と20分の差は大きい
- しかしすでに他のクラウドサービスを導入済みの場合、たいていはAWSにロックインされている。Kubernetesのためだけにクラウドの移行を決定するケースはほとんどない。したがってGKEよりはできることは落ちるが、EKSは悪くない選択。また、ベアメタルインスタンス(i3.metal)にも対応しているので、ベアメタルでKubernetesを考えているケースならかなり有効なのでは
- よほど特殊な事情、たとえばActive Directoryにロックインされている環境などでなければAKSやAzureを使う意味はない。(Azureを選択することで)自分の人生をハードモードにする必要はないはず
最強のマネージドKubernetesはどれ? スペシャリストが比較検証したGKS/AKS/EKS – G3 Enterprise
⇧ とあるのですが、残念ながら、「Kubedex」というサイトが404になってしまっているので、今現在における各クラウドベンダーの「Kubernetes」に関わるサービスの比較評価がどうなのかが分からない...
「Kubedex」っていうGitHub については、
⇧ 活動が続いていそうだけども。
By the way、不思議なのが、
日本オラクルだと古くからの基幹システムを抱えている顧客が多い。そのためディスラプターのサクセスストーリーのような最先端最新鋭の事例は現実味を伴わないのかもしれない。そうは言いつつも古手川忠久氏は「取り組もうとしているお客さまがいるのは確かです。典型的な例はライフサイクルの異なるフロントとバックを分ける。モノリシックだけどAPIゲートウェイに取り組むなど、マイクロサービスに近いものを導入するケースは増えています」と言う。
日本のマイクロサービスの現在地は？ Javaはマイクロサービスに向いているか？ (1/2)|CodeZine（コードジン）
2022年の調査によると、アプリケーションの実装形態は、回答者の93%がマイクロサービスを実装していると回答（図1）。前年の94%に引き続き、モダンなアーキテクチャの採用が拡大する傾向が続いている。
Java開発部品「Spring」を使う開発者の93％がマイクロサービスを実装、主要用途はAPIの公開─VMware調査 | IT Leaders
⇧「マイクロサービス」に対する認識の乖離が凄まじいのよね...
流石に、「マイクロサービス」を実装してる割合が9割越えっていうのは盛っているとしか思えないが...もしくは調査したサンプルが偏り過ぎてるとしか思えない。
変更容易性が担保できていて、保守・運用の負担にならないシステムが構築できれば良いとは思うけども...
そもそもとして、
アジャイル手法とマイクロサービス(MSA)には妙な親和性があって、ほおっておくと簡単に結びつく。ユーザ企業にとっての顧客が直接利用するSoE系のソフトウエアであれば話は別だが、ユーザ企業のバックエンド業務を支える基幹システムの開発でこれらを導入すれば、事業のDX（デジタル変容）はさらに遠のく。
⇧「マイクロサービス」が向いてないシステムもあるっぽいので、「マイクロサービス」を実装してる割合が9割越えって話に違和感を感じるのかしらね...
やはりと言うか、
⇧ データの同期が一番のネックという感じでしょうか。
とは言え、
⇧ 成功事例はあるようなので、「マイクロサービス」を導入するかどうかは費用対効果に委ねられるといったところでしょうかね。
話が脱線したけども、
- システムが業務に何らかの利益をもたらすのがMUSTであり、要求/要件を元にシステムの必要性と必要な技術を検討する。
- 構築したシステムは安定稼働させ続けなければならないので、障害が起きたら復旧させなければならない。
- 機能追加の要求があれば追加開発が発生することもあるし、それに対応しなければならない。
の全てを担うのは人間ってことだからと、リスクマネジメント的な観点からも不確実性の少ない手段を選びたくなるのが人情。
というのと、やはりトータルで見た場合のコストを補って余りある利益が出せるかどうかに尽きるのかね。
開発者としては、納期がタイトなのに、複雑な仕様と複雑な実装を求められる状況は工数がいくらあったとしても精神衛生上、受け入れたくはないと思うし...
まぁ、
KISS の原則 (英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。
⇧ シンプルにするのって難しいよね...
とりあえず、コンテナには慣れていかねばですかね...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
