リソース効率で考えるアーキテクチャ設計：機能要件を超えた技術選定の本質

はじめに 技術選定やアーキテクチャ設計は簡単な仕事ではありません。 資格の勉強を通して各クラウドサービスの機能がわかるようになったから・プログラミング言語を勉強してアプリコードが書けるようになったからといって、では次のステップとしてアーキテクチャ設計ができるか？と言われると必ずしもそうではないことの方が多いのではないでしょうか。 このサービスを用いることでシステムの機能要件を問題なく満たせるという理由で技術選定した結果、全然パフォーマンスが出ない・コストがかかり過ぎるといった問題が発覚して、運用やビジネス遂行に支障をきたしてしまうこともあります。 このような失敗を未然に防ぎ、システムがその役割を十分に果たすために必要となるアーキテクチャを先んじて確実に見通し設計するには、私たちは一体どのようなことを学び、気をつければいいのでしょうか。 この記事では、アーキ設計・技術選定において大きな失敗を

[hogetax]

この文章内で出てくる「ハードクオータ」ってキーワードは一般的な定義があるのだろうか？ざっとググった感じ、この文章に適合する意味で使われている例が見つからなかったんだけど

[syu-m-5151]

リソースの有限性という根本原理から技術選定を捉え直す視点がよき。表面的な機能ではなく、背後にある物理的制約を意識することの重要性を、具体例を交えて説得力を持って示している良記事だと感じました。

[JackP]

quota （割当）って言葉、私は割とキャリアの早い内にメールサービスの開発で利用ユーザ毎にストレージ上限を割り当てる必要があり、そのときに知った。それからもリソースの割当量を指定する文脈で割と目にしてるが…

[diveintounlimit]

クォータっていうの初めて聞いたが、あまり一般的なワーディングではなさそうだ。

[clairvy]

ソフト/ハードは設定可能かどうかで使い分けてんのかな。limit みたいな