新機能と相違点 what-is-new-and-what-is-different

長年にわたって、AEM の利用形態は次の 2 通りでした。

これら以前のアプローチと AEM as a Cloud Service には、次の点で本質的な違いがあります。

アーキテクチャ architecture

AEM as a Cloud Service には次の機能が追加されました。

このアーキテクチャには次の特長があります。

これにより、様々な使用パターンに応じた自動スケーリングが可能になります。

AEM のアップデート aem-updates

AEM as a Cloud Service では、継続的統合および継続的配信（CI／CD）を使用して、プロジェクトが確実に最新の AEM バージョンで稼働できるようになりました。これは、ユーザーへのサービスが中断されることなく、実稼働インスタンスとステージングインスタンスが AEM の最新バージョンに更新されることを意味します。

AEMバージョンのアップデートは、次の 2 種類があります。

Cloud Manager cloud-manager

Adobe Cloud Manager は、インスタンスに対するすべてのアップデートを制御するので（必須）、AEM as a Cloud Service の継続的アップグレードアプローチに欠かせません。

Cloud Service の新しいバージョンが使用可能になったら、アドビがアップデートをトリガーできます。または、Cloud Manager から提供されるパイプラインを使用して、ユーザーがアプリケーションのアップデートをトリガーすることもできます。

Cloud Manager の役割は次のとおりです。

特に、Cloud Manager から作成できる AEM プログラムの数と種類は、次のいずれかに基づいて決定されます。

Cloud Manager は、AEM as a Cloud Service の主要コンポーネントを作成および設定できるセルフサービスポータルとして進化しました。

Cloud Manager は、多くの地域をまたいでデータセンターに環境を作成し、グローバルな取り組みを提供します。CDN のプレゼンスポイント（PoP）により、世界中の顧客に待機時間の短いコンテンツを配信できるようにします。

オンボーディング onboarding

AEM as a Cloud Service を使用すると、次のように作業の多くの側面がアドビの担当になるので、AEM プロジェクトの開始と管理は簡単になります。

また、現在は次の要素もあるので、作業自体が大幅に異なります。

開発 developing

AEM as a Cloud Service をサポートする新しいアーキテクチャには、開発者のエクスペリエンス全体に対するいくつかの重要な変更が含まれています。AEM as a Cloud Service の主要な目標の 1 つは、（AEM をオンプレミスまたは Adobe Managed Services のコンテキストで使用したことがある）経験豊富な顧客が、カスタマイズしたコードの大部分を書き直さずに、できるだけ迅速に AEM as a Cloud Service に移行できるようにすることです。ただし、若干の調整が必要になる可能性はあります。

クラウド開発 aem-as-a-cloud-service-developing-cloud-development

既存の AEM アプリケーションを AEM as a Cloud Service 上で動作させるには、次の手順が必要です：

このプロセスは一般にクラウドファースト開発と呼ばれます。所要時間は全体で数 10 分（アプリケーションの複雑さに応じて 20～50 分）と見込まれるので、保留中のコードや設定変更がクラウドで試行される前に、迅速な開発手法を採用する必要があります。

OSGi バンドルとその関連設定を管理する web コンソール（以前は AEM QuickStart の一部）は、AEM as a Cloud Service では使用できなくなりました。新しい Developer Console には、ほとんどのランタイム情報に対する読み取り専用のインターフェイスが用意されています。このコンソールを使用すると、開発者はオーサーサービスまたはパブリッシュサービスの特定のノードを直接選択してログインし、関連情報を閲覧できます。

開発者にとって、もう 1 つの共通の要件は、様々な環境のログファイルにすばやくアクセスできることです。AEM as a Cloud Service では、オーサーノードとパブリッシュノードに含まれる様々なノードのログファイルが、ダウンロード可能なファイルの形式または API 経由で Cloud Manager を通じて利用できるようになっています。

コードとコンテンツが明確に分離されているので、開発者は、特定のプロセスを使用して、デプロイメントの一環としてコンテンツを更新できます。可変コンテンツの典型的なユースケースは次のとおりです。

ローカル開発 aem-as-a-cloud-service-developing-local-development

迅速な反復と開発をサポートするために、AEM as a Cloud Service のコンテキスト以外で AEM アプリケーションを開発することもできます。このために、次のアーティファクトが開発者に公開されています。

運用とパフォーマンス operations-and-performance

AEM as a Cloud Service では、サービスの中断が不要になるように、このような操作は自動化されています。

これらの操作では、

AEM as a Cloud Service の運用も、監視、レポート、警告用の新しいインフラストラクチャでサポートされています。これにより、Adobe SRE（サイトリライアビリティエンジニア）はサービスの健全性をプロアクティブ（予見的）に維持できます。アーキテクチャの様々な要素に様々なヘルスチェックが備わっています。何らかの理由で、アーキテクチャの特定のノードが異常と見なされた場合、そのノードはサービスから削除され、ユーザーへの通知なしで新しい正常なノードに置き換えられます。

Identity Management identity-management

AEM as a Cloud Service の重要な変更の 1 つは、Adobe ID を使用したオーサー層へのアクセスが完全に統合されていることです。

それには、Adobe Admin Console を使用してユーザーとユーザーグループを管理する必要があります。ユーザープロファイル情報が Adobe Identity Management System（IMS）に一元化されてすべてのクラウドサービスで共有されるので、ユーザーはユーザーアカウントを使用してアドビ製品およびサービスにアクセスできます。AEM へのアクセスを割り当てられると、ユーザーアカウントを（以前と同様）AEM as a Cloud Service で参照して、例えば、AEM セキュリティユーザーインターフェイスから役割と権限を定義できます。

これは次の利点を兼ね備えています。

オーサリングユーザーインターフェイス authoring-user-interface

AEM Sites についても AEM Assets についても、オーサリングユーザーインターフェイス（UI）の基本原則は、これまでに AEM を使用したことがある人にとってはなじみ深いものです。

主な違いは、UI が完全にタッチ対応であることです。クラシック UI は使用できなくなりました。それ以外の点では、基本はそのまま変わらず、見た目のわずかな変更があるだけです。

AEM Sites aem-sites

Adobe Experience Manager Sites as a Cloud Service は、AEM コンテンツ管理システムの機能と AEM デジタルアセット管理を組み合わせて、コンテンツ主導のパーソナライズされたエクスペリエンスをユーザーに提供できます。

詳しくは、AEM Sites as a Cloud Service の主要な変更点を参照してください。

AEM Assets aem-assets

Adobe Experience Manager Assets as a Cloud Service は、クラウドネイティブな PaaS ソリューションです。企業がデジタルアセット管理と Dynamic Media 操作を迅速かつ効果的に行うだけでなく、常に最新で常に可用性が高く常に学習可能なシステム内から AI や機械学習などの次世代スマート機能を使用するうえでも役に立ちます。

Assets が提供する機能には、クラウドでの次世代アセット処理やパフォーマンスの高いアセット取り込みおよび検索などがあります。

詳しくは、AEM Assets as a Cloud Service の概要を参照してください。

Adobe Experience Manager as a Cloud Service の理解 getting-to-know-aem-as-cloud-service

詳しくは、次を参照してください。