today::エンジニアに憧れる非エンジニアスマートフォン用の表示で見るtoday::エンジニアに憧れる非エンジニア今のところは、エンジニアとは言えないところの職種です。エンジニア的なものの考え方に興味津津。冪等性(べき等性)とは、「同じ動作を何回行っても、常に同じ結果になる」という性質を表す、数学由来の語です。昨今の開発・運用最前線における重要概念であるにもかかわらず、恥ずかしながら、今までこの語を知りませんでした。亀田氏は、「人間にやらせるとバグります」「定常的に作業を行うものは、API経由でスクリプト化してくださいね」という趣旨のことをおっしゃっていました。私としては、「冪等性の実現は、メカニズムを以て行われなければならない。人間というのは、間違えるのが本質であるから。」という趣旨であると認識しました。常に物事を改善させるとは限りません。仕組み(メカニズム)が必要です。Japanが翻訳したものです。確かに、自己改善が風習として根付いているような組織であれば、自己改善の目的意識や方法論といったものも仕組み化されていますよね。ベンダーロックインについて基幹系ではないサービス系のシステムについて、亀田氏は「そもそもベンダーロックインは問題にならない」という趣旨の発言をされていました。いうのも、「昨今のユーザーエンゲージメントは、非常に足が速い。ベンダーロックインされるされない以前の時点でサービスが陳腐化するものと考えるべきである。」とのことだそうです。逆に、そうそう陳腐化しないサービスというのは、多くの場合は社会の根底に関わるサービスであり、そっちはそっちで「社会的影響の大きさから、失敗が許されないので、現場が精神的に疲弊する」といった問題があってつらいです。モノリシックアーキテクチャ大きな単一の機能により、一つの処理を実現するアーキテクチャのことをモノリシックアーキテクチャといいます。恥ずかしながら、今までこの言葉の意味は知りませんでした。モノリシックアーキテクチャは、スタートアップ期においてはメンテナンス性に優れる利点の恩恵が大きいモデルです。サービスが大規模化してくると、一人の手には負えないほど爆発的に問題が肥大化・複雑化していくのが大きな欠点です。亀田氏の話によれば、AWSも「モノリシックアーキテクチャの壁にぶつかり、マイクロサービスアーキテクチャに移行した」という歴史を経たのだそうです。マイクロサービスマイクロサービスの開発モデル亀田氏の話を聞いた限りにおいては、アジャイル開発モデルというよりは、むしろスパイラルモデルやインクリメンタルモデルのような繰り返し開発型のモデルに類似している、という認識です。伝統的な繰り返し開発型モデルに比べて、各モジュールがより疎結合であるというのが大きな違いでしょうか。単一責任とドキュメンテーション亀田氏の話を聞いた限りにおいては、サービス実装においても、単一責任の原則は重要であるようです。その帰結として導かれるのが、マイクロサービスにおいて、ドキュメンテーションは極めて重要であるという原則です。アジャイル開発モデルとは一線を画する話ですね。以下で自分なりに説明してみます。各マイクロサービスにおいて、外部との唯一の接点はAPIです。APIの仕様は、外部から完全にわかるものでなければなりません。単一責任の原則により、APIの仕様変更を伴わないマイクロサービスの仕様変更はありえません。ゆえに、マイクロサービスにおいて、ドキュメンテーションは極めて重要である、ということになります。こんな感じでしょうか。マイクロサービスとステートレスマイクロサービスにおいて、ステートレスは必要条件である、とのことでした。私としては、各マイクロサービスが内部状態を持ってしまうと、サービス全体として冪等性が破綻する、ということが問題だという認識です。されすぎた業界」としてのNTT通信建設業界NTT加入者線路の光クロージャ月別アーカイブはてなブログをはじめよう!rapidliner0さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。