SaaSの実行方法:EZ-Loginの例を使用してクラウド製品を構築する方法。 パート1.分析について



免責事項

この記事では、クラウド製品の作成における経験を説明する資料のサイクルを続けます。 このサイクルは、包括的で普遍的なふりをするものではなく、ゼロから製品を構築するためのアプローチの1つ(効果的であることを願っています)を示すことを目的としています。 記事は、個々の開発者、アーキテクト、プロジェクトマネージャーだけでなく、商用製品の作成に関与するチーム全体にとっても興味深いものです。 質問の背景はここにあります。



アイデア



チャレンジ:

すべてのIT製品は、対象読者のビジネス上の問題(または技術的な問題)を楽しませるか、解決するように設計されています。 エンターテインメントは別として、エンタープライズの世界に進みましょう。 主催者の仕事は、カバーできる問題の範囲を決定し、それらを正確に定式化することです。



EZ-Loginでの実装例:

会社のインスパイアであるアントン・マルチェンコは、企業が外部サービスでアカウント管理を整理できるようにするSAAS製品を作成したいと考えていました。 大企業には独自のデータセンターがあり、インフラストラクチャの外部への情報の流れを避けたいため、製品は公開され、特定の企業内で個別のコピーとして非公開で使用される可能性があります。

この記事では、EZ-Loginが解決しようとしている問題をより詳しく説明します。



さらに、大幅に簡素化されたEAP方法論を使用して、用語とドメインモデルを決定する必要があります。これにより、アプリケーションアーキテクチャ、データアーキテクチャ、および技術アーキテクチャの一般的なスキームを理解できます。







用語。



チャレンジ:

使用するすべての用語をまとめて決定する必要があります。 これは、開発されたシステムの要件の策定に役立ち、誤解を避けるのに役立ちます。 用語辞書(用語集)は、製品の開発に応じて更新および更新されます。



EZ-Loginでの実装例:

例として、辞書のいくつかの用語。

出発点-SAAS製品を構築しています。 これは何?



2011年10月、米国国立標準技術研究所 は、多数の「クラウド」用語の独自の定義を公開しました

しかし、これまで、RuNetの多くの記事で、「クラウド」と「SAAS」の概念はさまざまな方法で解釈されています。 ジャーナリストや実務家との継続的な紛争があります。

基本的に、これらの紛争は「NISTの公理を受け入れるかどうか」という境界に沿っています。



NISTの文言によれば、ソフトウェア製品は次の基準を満たす場合、SAASとして分類されます。



•曇り

•製品には明示的なクライアント/サーバーアーキテクチャがあり、消費者は何らかの個別のユニバーサル(典型的なWebブラウザーの例)または純粋に特殊な(例-4sync、Dropbox、Yandex.Diskファイルサービスのクライアント部分)クライアントプログラムを通じて製品を使用します

•パフォーマンスの監視、更新の適用、チューニングのためのすべての操作は、サービスプロバイダーによって実行されます。



2回目と3回目では、明らかなようです。 しかし、曇りは何ですか?

NIST仕様によると、サービス(製品)は、次の5つの機能を備えている場合、「クラウド」として認識されます。



•消費者は、サービスプロバイダーの従業員の一般的なケースに参加することなく、セルフサービスベースでサービスと対話します(セルフサービスオンデマンド)

•消費者は、任意の端末デバイスからネットワーク経由でサービスを使用します(広域ネットワークアクセス)

•サービスは、マルチテナントモデルのさまざまなコンシューマーにサービスを提供するためのプール(ヒープ、グループ)の形で編成されたリソースを顧客に提供し、コンシューマーのニーズに応じてこれらのリソースを動的に割り当ておよび再割り当てする機能(リソースプーリング)

•消費者は、いつでも必要のないリソースを購入して返却することができます(迅速な弾力性)

•サービスには、報告(測定されたサービス)を伴う、消費者によって提供および使用されたリソースを計算するための自動メカニズムがあります。



「曇り」の定義では、マルチテナントという用語に出会いました。

辞書に入れましょう:



マルチテナンシー -複数の家賃、製品の1つのコピー(インストール)を許可する情報システムのプロパティは、独自のユーザーセットを持つ多くの異なる消費者(テナント)にサービスを提供します。







サブジェクトエリア。



チャレンジ:

製品が動作するすべてのエンティティとそのプロパティを決定し、ユーザーカテゴリ、エンティティ間の関係、ユーザー、および相互を分類する必要があります。 サブジェクト領域の説明に基づいて、用語(用語集)が更新されます。



EZ-Loginでの実装例:

ユーザーのサークルとその可能な役割を定義します。

最初に、サービスは所有者( プロバイダー)によってインストールおよび構成されます。

さまざまな地域市場(さまざまな通貨、さまざまな財務諸表、さまざまなドメイン、さまざまなサードパーティサービス)で作業するには、個別の代理店(リセラー )が必要です。

このサービスは、ビジネス構造(会社)と一般の人(家族や友人など、他の人が関連付けられている可能性があります)の両方で使用できます。

サービスの公共利用の場合、企業と人々の両方サービスのテナントです

プロバイダー-サービスの可用性を提供します。 テナントは、国の再販業者とやり取りします。



ただし、支店(または、たとえば、部門が分散している省庁)を持つ大企業の場合、閉鎖された企業コピーでサービスを使用する場合、他のグラデーションが表示されます。



•企業自体がサービスプロバイダーになる

•別の支店/部門がリセラーになります

•また、部門/サービスがテナントになります。

すべてのユーザーの機能に従って、条件に応じてクラスに分割します。



•プロバイダーの従業員-書記官

•再販業者-マネージャー

•優先テナント従業員-管理者

•テナントの普通の従業員-消費者



このサービスの主な目的は、テナント従業員のサードパーティサービスへのアクセスの管理を整理することです。 したがって、用語集では、使用するエンティティの新しい説明を追加する必要があります。



アクセス -テナント従業員がユーザー名とパスワードを入力せずに外部サービスにアクセスできる能力。



「クラウド」のプロパティに基づいて、サービスのテナントが使用できるリソースを決定する必要があります。

たとえば、EZ-Loginの場合:



•テナント従業員の最大数

•テナント全体の最大アクセス数

•テナントがアクセスできるサービスの最大数

•従業員リストと企業ディレクトリActive Directortyとの同期の可用性

•ワンタイムパスワードの可用性

•USBトークンの使用の可用性



上記は、対象領域の分析のほんの一部です。



分析を扱ったので、次の記事では図とアーキテクチャに移ります。



All Articles