3

私たちはオープンソースの ID 管理システムの実装を検討しており、ForgeRock のスタックが実装に最適なテクノロジであると判断しました。

ただし、ForgeRock サポートの高コストとそのユーザーごとの価格設定モデルは、潜在的な障害となります。現在のユーザー ベースは 45,000 人ですが、今後 2 年間で 100 万人に増加すると予想しています。

そのため、FR サポートなしで続行するシナリオを検討しています。FR メンテナンス リリースの欠如は、それを妨げているように見えるので、他の人がその道を進んでいるかどうかに興味があります.

  1. あなたの経験は何ですか？
  2. どのようなプロジェクトでこれを行ってきましたか? サイズ等
  3. FR のメンテナンス リリースがないため、独自のパッチを簡単に作成できましたか?
  4. 潜在的な落とし穴にはどのようなものがありますか?

このトピックを扱っているブログやその他のコミュニティがあれば、その一般的な方向性を教えてください。

ありがとう。

4

1 に答える 1

5

コミュニティ ユーザーとして、私は過去 6 年ほど OpenAM(/OpenSSO) と OpenDJ を使用していましたが、それは非常に小規模な展開でした (10,000 ユーザーに対して、両方の製品から 1 つのサーバー インスタンスのみ)。

1) 初期の段階で OpenAM に信頼性の問題がありましたが、サーバー インスタンスを再起動することでほとんど解決しました。当時の調査に必要な知識）。製品を学ぶために実際の努力を費やした後、私たちの問題のほとんどは自傷行為 (不適切に書かれたカスタマイズ、または構成ミス) であるか、実際には OpenAM プロジェクトで最近解決された比較的単純なものであることが判明しました。私たちのバージョンにバックポートします。

もちろん、エクスペリエンス自体は、展開で構成を変更する頻度に大きく依存しますが、長年にわたって多くのことを変更していなかったため、OpenAM は、メンテナンスを一切必要とせずに長期間にわたってうまく機能しました。

3) 実際には新しい問題に遭遇しなかったため (構成はほとんど変更されませんでした)、しばらくするとあまり多くの驚きはありませんでした。セキュリティ パッチはほとんどバックポートが簡単で、それほど大きな問題は発生しませんでした (1 年半後に FR の従業員になり、OpenAM の問題に積極的に取り組みました:))

4）サブスクリプションなしで実行することにはリスクがあると思いますが、それらは主に次のことに関連しています。

  • その 2 年間に OpenAM 機能に基づく新機能をロールアウトする予定はありますか (つまり、展開を常に変更する予定ですか)?
  • これらの機能に取り組む優れた開発者はいますか? たとえば、OpenAM を使用する場合、ソース コードを調べて動作を理解する必要がありますが、ドキュメントの品質は何年にもわたって大幅に改善されています。いずれにせよ、バックポート修正は時間の経過とともにますます困難になるでしょう。なぜなら、リリースの違いが大きくなるからです (開発チームはプロジェクトごとにますます大きくなっているからです)。遭遇する問題は、定義上、トランクで既に解決されています。いくつかの問題を自分で解決する必要があることは、考慮に入れる必要があるコスト/リスクです。
  • 展開に必要な SLA の種類は何ですか? あなたのビジネスは 1 分間の停止で倒産しますか? サービスを頻繁に再起動することは許容されますか (奇妙な問題が発生した場合に備えて)。
  • 3 つの製品すべてのサポートが本当に必要ですか? たとえば、私のバックグラウンドでは、OpenAM のサポートがなくても簡単に作業できますが、プロビジョニング システムで何か問題が発生した場合、深刻な問題に直面することになります...

そして一般的な発言：

2 年以内にユーザーが 20 倍に増加するというのは、少し非現実的か、少なくとも非常に希望に満ちているように思えます。おそらく、もう少し合理的な目標数の 1 年間のサブスクリプションを探して、ビジネスにおける顧客の成長をよりよく理解したら、更新することをお勧めします。

于 2015-04-28T16:47:28.590 に答える