マイクロサービスとマイクロサービスアーキテクチャ、サービスメッシュについてはエンジニアの共通認識にしよう。
タイトル長い。
あ、RESTについても書きました
後で概要図だけ書いて追加します。
皆さん
おはようございます。
自分はシャイニーカラーズのプロデューサーだけでは生活出来ないので、副業でエンジニアをしている者です。
k8sしてますか？
こないだ↓の記事にマイクロサービスと、マイクロサービスアーキテクチャとサービスメッシュについて簡単な説明を書いたら、思ってた以上にアクセスしてもらって驚いています。
もしかしたら技術についてしか興味ない人かもだけど、
自分のモチベのためにも↓の記事も読んでみてほしいな。
このへんとか
このへんとか
よろぴく✌
前回は、マイクロサービスについて書いてみたらどのくらいアクセスつくのかなーって興味があって、タイトルで言及しないでおまけ的に書いてみました。
思っていた15倍くらいアクセスがありました。
というわけでこの記事として独立させました。(これも一つのマイクロサービス化)
こういう系は需要ありそうなんですかねー。
さて、
今回のテーマはこちら
マイクロサービスとマイクロサービスアーキテクチャ、サービスメッシュについては今を生きるエンジニアの共通認識にしよう。
です。
この辺、k8sやれって言われて、具体的な技術触ってる内にわけが分からなくなりがちです。
これってどういうことなんだっけ？
ていうか今俺何してんだ？ってなるわけです。
技術に使われてる人、いませんか？
しかも、3000円4000円払った技術書にも概念についてはほぼ書いてなかったりする。(書いてあってもさっくりだったり、結論しか書いてなかったり。)
最近そういうことが多いと思います。
本書いてる側もすごい技術を紹介するのに手一杯。
けど、頭悪い自分じゃ結論だけじゃ分からないわけですよ。
んで、自分なりに整理する。
てか、実際にやるだけなら便利なツールがやってくれるけど、
それなら別に
エンジニアがいる意味無くない？
考えるのが仕事では？
この辺は、みんなの常識にして、
k8sとかサーバーレス使ってこういうアーキにすればいいシステムが出来るよ！とか
今回のアプデの新機能が熱い！とか
そんな風に皆でわいわい話して、炎上無く新しい技術を使えるようになったら最高だと思います。
さて、
本文に移ろう。
この記事は上の方でも書いたが、↓の書きたいものリストから派生したわけだ。
今の記事同士の相関図を書くとこんな感じになる。
(いい感じの図。多分日曜に書く)
だんだん記事同士が連携しあうようになってきた。
簡単に説明
・記事単体がマイクロサービス
・記事(マイクロサービス)同士が連携しあってる構図(アーキ)がマイクロサービスアーキテクチャ
・その連携が「網みたいになってること自体」を、サービスメッシュ
Noteの例では、今の所自分で管理出来るね。人の手でちゃんと管理できてるならそれだってサービスメッシュだ。
簡単でしょ？
次はもう少しだけ詳しく
マイクロサービスとマイクロサービスアーキテクチャとは：
・1モジュール(ここではそれぞれの記事)のことを マイクロサービス
・マイクロサービス(記事)を組み合わせた構図のことを マイクロサービスアーキテクチャ
・マイクロサービスはそれぞれ機能として独立していて(単一の機能だけを持っていて)、マイクロサービス(記事)同士は疎結合な関係性
・マイクロサービスはコンテナやサーバーレスのみを指す言葉ではない
って感じ。
利点とかはK8sについて書く時にまとめたい。今回の主題ではないからね。
サービスメッシュとは：
マイクロサービス同士がそれぞれ連携し合うと、網みたいなつながりになる。
「そういう関係性自体をサービスメッシュ」という。
よく誤解されるのはIstio＝サービスメッシュみたいな認識かな。それは違うっす。
マイクロサービス同士が連携しあって蜘蛛の巣みたいになると、人の手には負えなくなる。
その連携(通信)を管理するのがIstio。
Istioがプロキシを使って、それぞれのマイクロサービス同士の通信を管理してくれる。
Istioはサービスメッシュそのものではなく、サービスメッシュを管理しやすくしてくれるツール
以上。
このくらい簡単じゃないと自分頭悪いんで分かんないっす。
クラウドネイティブは前提知識が多すぎっす。
本当はそれぞれもう少し詳しく書けるけど、本職がシャニマスPなので今回は許してほしい。
ちなみに、マイクロサービスアーキテクチャの反対、
VMを使ったシステム構成は、「モノシリックアーキテクチャ」って呼ばれる。
Terraformとかでモノリスって聞いたこと、無いです？
ま、この辺もk8sに関する記事で詳しく話そう。
すっすー。
ああ、摩美々のGRADどうしよう、、
さて、
それぞれ、
プロジェクトに革命を起こす魔法じゃないし、そもそも技術ですらない。
ただのアーキのパターンだ。
コンテナとかサーバーレスを使っていてもモノリス的な考えを捨てられなければ、モノリスアーキテクチャになる(特にサイドカー周りが多い所感)
その程度のもの。
パターンに則ったらイケてるシステムになりやすいよっていうだけなんだ。
どうやったら動くか。
どんな設定にすればいいか。なんてことは、Qiitaで検索すれば大体出てくる
何か踏んで困ったら全部英語にして検索すれば海外の掲示板でトラブルシュートの事例は拾える。
そもそも全容が見えていればどこでエラー踏むかなんてのは大体想定できるはず。
これからの時代はどんな作業をするかは重要じゃない。
イケてるのは技術そのものであって、設定する人じゃない。
具体的な作業(what)はどうでもいい。最悪、動けばいい。
顧客とエンドユーザーは何を求めてるのか(Why)
それをどうやって実現するのか。何を組み合わせるのか(How)
が重要だ。
そこは昔から変わってないけど、技術が便利になり過ぎて最近特に誤解しやすい。
この辺はいい加減、今を生きるエンジニアの共通認識にしよう
本当は、こんな風に偉そうに語るもんでもない。
そんなことよりイケてるアーキ図書いて来いよってレベルの話。
理解できたら周りの人に教えてあげてほしい。
面倒だったら、この記事のリンクを投げてもらえれば、自分のアクセスも増えるからWinWin😄
そこから新たなシャニマスPが増えるかもしれない。
こういうことを、みんなに知ってもらえるように、
少しでも人気な文書きになりたいなって思います。
それではまた次回。