Seit vielen Jahren steht AEM in den folgenden zwei Versionen zur Verfügung:
On-Premise
als Managed Service
Es gibt wesentliche Unterschiede zwischen diesen bisherigen Ansätzen und AEM as a Cloud Service:
Diese Übersichten erheben keinen Anspruch auf Vollständigkeit, sollen jedoch eine Einführung bieten.
Weitere Informationen zu den Versionen On-Premise und Managed Service finden Sie in der Dokumentation zu AEM 6.5.
Weitere Informationen finden Sie unter Architektur.
AEM as a Cloud Service verfügt jetzt über:
Diese Architektur:
wird basierend auf dem tatsächlichen Traffic und der tatsächlichen Aktivität skaliert.
enthält einzelne Instanzen, die nur bei Bedarf ausgeführt werden.
verwendet modulare Anwendungen.
enthält einen Autoren-Cluster als Standard; dadurch werden Ausfallzeiten für Wartungsaufgaben vermieden.
Dies ermöglicht die automatische Skalierung für verschiedene Nutzungsmuster:
AEM as a Cloud Service verwendet jetzt die kontinuierliche Integration und Bereitstellung (Continuous Integration und Continuous Delivery, CI/CD), um sicherzustellen, dass Ihre Projekte auf der aktuellen AEM-Version basieren. Dies bedeutet, dass Produktions- und Staging-Instanzen ohne Unterbrechung des Services für Benutzer auf die aktuelle AEM-Version aktualisiert werden.
Wenn die Aktualisierung der Produktionsumgebung fehlschlägt, setzt Cloud Manager sie automatisch auf die Staging-Umgebung zurück. Dies erfolgt automatisch, um sicherzustellen, dass nach Abschluss einer Aktualisierung die Staging- und Produktionsumgebung beide auf derselben AEM-Version basieren.
Es gibt zwei Arten von AEM-Versionsaktualisierungen:
AEM-Wartungsaktualisierungen
Neue Funktionsaktualisierungen
Weitere Informationen finden Sie unter AEM-Versionsaktualisierungen.
Adobe Cloud Manager ist integraler Bestandteil des kontinuierlichen Upgrade-Ansatzes von AEM as a Cloud Service, da er alle Aktualisierungen Ihrer Instanzen steuert – dies ist obligatorisch.
Aktualisierungen können von Adobe ausgelöst werden, wenn eine neue Version des Cloud Service verfügbar ist. Alternativ können Sie Ihre Anwendungsaktualisierungen über die von Cloud Manager bereitgestellten Pipelines auslösen.
Cloud Manager:
wird zur Verwaltung von AEM-Programmen und -Umgebungen verwendet,
ist ein wesentlicher Bestandteil von AEM as a Cloud Service; jeder neue Mandant wird zunächst für den Zugriff auf Cloud Manager bereitgestellt,
ist die zentrale Anlaufstelle für Ihr Betriebs- und Entwicklungspersonal.
Konkret werden die Anzahl und die Art der AEM-Programme, die aus Cloud Manager erstellt werden können, abgeleitet:
von der Lizenzvereinbarung des Kunden,
von intern gesteuerten Akteuren, wenn AEM as a Cloud Service zur Befähigung oder Schulung eingesetzt wird,
von extern gesteuerten Prozessen, wie z. B. auf Adobe.com gestarteten Probe-Abos,
Cloud Manager hat sich zu einem Selbstbedienungsportal entwickelt, in dem die Hauptkomponenten von AEM as a Cloud Service erstellt und konfiguriert werden können:
Erstellen und Verwalten neuer Programme. Weitere Informationen finden Sie unter Grundlegendes zu Programmen und Programmtypen.
Erstellen und Verwalten der AEM-Umgebungen in diesen Programmen. Weitere Informationen finden Sie unter Verwalten von Umgebungen.
Erstellen und Verwalten der Pipelines für die Bereitstellung des Kunden-Codes und der zugehörigen Konfiguration in einer bestimmten Umgebung. Weitere Informationen finden Sie unter Konfigurieren der CI/CD-Pipeline.
Benachrichtigung über wichtige Lebenszyklusereignisse für diese Komponenten (z. B. Produktaktualisierungen).
Cloud Manager erstellt Umgebungen in Rechenzentren in vielen geografischen Regionen und ermöglicht so eine globale Abdeckung. CDN Points of Presence (PoPs) sorgen für die Bereitstellung von Inhalten mit niedriger Latenz für Kunden in der ganzen Welt.
Das Starten und Verwalten eines AEM-Projekts ist bei Verwendung von AEM as a Cloud Service unkompliziert, da Adobe für viele Aspekte verantwortlich ist:
AEM-Basisbilder werden für bestimmte Anwendungsfälle optimiert.
Viele der manuellen Konfigurationsaufgaben wurden überflüssig gemacht.
Weitere wichtige Unterschiede sind:
Eine Bewertungsphase, um sicherzustellen, dass alle Voraussetzungen erfüllt sind; einschließlich:
Rechtliche Anforderungen
Vertragliche Vereinbarungen
Technische Anforderungen für alle bestehenden Inhalte und/oder vom Kunden angepassten Code
Implementierungsanforderungen:
Code-Aktualisierungen; alle Kundenanwendungen, die für eine frühere Version von AEM entwickelt wurden, müssen überprüft und gegebenenfalls aktualisiert werden.
Inhaltsmigration
Eine vollständige Übersicht über den Onboarding-Prozess erhalten Sie in der Onboarding-Tour.
Für weitere Informationen beginnen Sie mit den Entwicklungsrichtlinien und Entwickeln – Das WKND-Tutorial.
Die neue Architektur, die AEM as a Cloud Service unterstützt, beinhaltet einige wichtige Änderungen am gesamten Entwicklererlebnis. Eines der Hauptziele von AEM as a Cloud Service besteht darin, erfahrenen Kunden (die AEM entweder in der On-Premise-Version oder im Kontext von Adobe Managed Services verwendet haben) die Möglichkeit zu geben, so schnell wie möglich zu AEM as a Cloud Service zu wechseln, ohne den Großteil ihres angepassten Codes neu schreiben zu müssen. Es könnten jedoch noch einige Anpassungen erforderlich sein.
Für bestehende AEM-Anwendungen, die mit AEM as a Cloud Service laufen sollen, werden die folgenden Schritte erwartet:
Dieser Prozess wird häufig als Cloud-First-Entwicklung bezeichnet. Da die End-to-End-Dauer voraussichtlich Minuten dauern wird (je nach Komplexität der Anwendung zwischen 20 und 50 Minuten), ist es notwendig, schnelle Entwicklungsmethoden einzusetzen, bevor die anstehenden Code- und Konfigurationsänderungen in der Cloud versucht werden.
Die Web-Konsole, in der OSGI-Bundles und ihre zugehörige Konfiguration verwaltet werden und die früher Teil des AEM QuickStart war, ist in AEM as a Cloud Service nicht mehr verfügbar. Die neue Entwicklerkonsole bietet eine Oberfläche, die nur lesen kann, für die meisten Laufzeitinformationen. Mit dieser Konsole können Entwickler einen bestimmten Knoten eines Autoren- oder Veröffentlichungs-Services auswählen und sich direkt dort anmelden, um die relevanten Informationen anzuzeigen.
Weitere Informationen finden Sie unter OSGi-Konfiguration.
Eine weitere gängige Voraussetzung für Entwickler ist der schnelle Zugriff auf die Protokolldateien der verschiedenen Umgebungen. Bei AEM as a Cloud Service werden die Protokolldateien der verschiedenen Knoten in den Autoren- und Veröffentlichungsknoten über Cloud Manager zur Verfügung gestellt, entweder in Form von Dateien, die heruntergeladen werden können, oder über APIs.
Aufgrund der klaren Trennung von Code und Inhalt können Entwickler ein bestimmtes Verfahren zur Aktualisierung von Inhalten im Rahmen einer Implementierung verwenden. Typische Anwendungsfälle für veränderliche Inhalte sind:
Standardinhalt, der Teil des Kundenprojekts sind (z. B. Ordner, Vorlagen, Workflows usw.)
Suchindexdefinitionen
ACLs und Berechtigungen
Service-Benutzer und -Benutzergruppen
Um schnelle Iterationen und Entwicklungen zu unterstützen, ist es auch möglich, AEM-Applikationen außerhalb von AEM as a Cloud Service zu entwickeln. Zu diesem Zweck werden den Entwicklern die folgenden Artefakte zur Verfügung gestellt:
AEM as a Cloud Service QuickStart: ein .jar
-basiertes, eigenständiges Installationsprogramm der neuesten AEM-Code-Basis, mit der gleichen Funktions- und API-Oberfläche.
AEM as a Cloud Service SDK: ein bildbasiertes Verfahren zum lokalen Testen und Validieren von Dispatcher-Konfigurationen.
Beachten Sie, dass Cloud QuickStart nicht alle Funktionen von AEM Sites und AEM Assets zulässt. Es besteht aus einer einfachen Autorenumgebung, in der die meisten Erweiterungen entwickelt und getestet werden können.
Für weitere Informationen beginnen Sie mit Backup, Indizierung und anderen Wartungsaufgaben.
Bei AEM as a Cloud Service werden solche Vorgänge automatisiert, sodass eine Unterbrechung des Service nicht mehr erforderlich ist.
In diesen Bereichen:
Viele Aufgaben wurden automatisiert.
Die Topologien sind auf maximale Ausfallsicherheit und Effizienz optimiert. Beispielsweise ist die binärlose Replikation die Standardeinstellung.
Aufgaben mit hoher Auslastung wie Warteschlangen, Vorgänge und Massenverarbeitungsaufgaben wurden aus der AEM-Kerninstanz verschoben, um von gemeinsam genutzten und dedizierten Microservices ausgeführt zu werden.
Der Betrieb von AEM as a Cloud Service wird auch durch eine neue Überwachungs-, Berichts- und Warninfrastruktur unterstützt. Auf diese Weise können die Adobe-SREs (Site Reliability Engineers) den Service proaktiv aufrechterhalten. Die verschiedenen Elemente der Architektur sind mit einer Vielzahl von Konsistenzprüfungen ausgestattet. Wenn ein bestimmter Knoten der Architektur aus irgendeinem Grund als fehlerhaft erachtet wird, wird er aus dem Service entfernt und durch einen neuen, funktionierenden ersetzt.
Weitere Informationen finden Sie unter Sicherheit – IMS-Unterstützung.
Eine wichtige Änderung an AEM as a Cloud Service ist die vollständig integrierte Verwendung von Adobe IDs für den Zugriff auf die Autorenebene.
Dies erfordert die Verwendung der Adobe Admin Console zum Verwalten von Benutzern und Benutzergruppen. Die Benutzerkonten ermöglichen Ihren Benutzern den Zugriff auf Produkte und Services von Adobe, da die Benutzerprofilinformationen im Identity Management System (IMS) von Adobe zentralisiert sind und von allen Cloud Services gemeinsam genutzt werden können. Nach der Zuweisung des Zugriffs auf AEM können die Benutzerkonten in AEM as a Cloud Service (wie bisher) referenziert werden, z. B. zur Definition von Rollen und Berechtigungen über die AEM Security-Benutzeroberflächen.
Dies kombiniert die folgenden Vorteile:
Verwendung des Adobe Identity Management Systems (IMS), um eine einheitliche Anmeldung für alle Adobe-Cloud-Anwendungen zu ermöglichen.
Lokale Benutzervoreinstellungen für jede bestimmte Instanz von AEM as a Cloud Service.
Für weitere Informationen beginnen Sie mit Grundlegende Handhabung.
Die Grundprinzipien der Authoring-Benutzeroberfläche, sowohl für Sites als auch für Assets, werden jedem, der AEM in der Vergangenheit verwendet hat, sehr vertraut sein.
Der Hauptunterschied besteht darin, dass die Benutzeroberfläche exklusiv Touch-fähig ist. Die klassische Benutzeroberfläche ist nicht mehr verfügbar. Ansonsten bleiben die Grundlagen unverändert, wobei nur kleine Änderungen sichtbar sind.
Adobe Experience Manager Sites as a Cloud Service ermöglicht es Ihnen, Ihren Kunden personalisierte, inhaltsgesteuerte Erlebnisse bereitzustellen, indem das Potenzial des AEM-Content-Management-Systems mit AEM Digital Asset Management kombiniert wird.
Weitere Informationen finden Sie in der Übersicht über die Änderungen an Sites.
Adobe Experience Manager Assets as a Cloud Service bietet eine Cloud-native PaaS-Lösung für Unternehmen, mit der sie nicht nur ihre Vorgänge in Digital Asset Management und Dynamic Media schnell und effektiv durchführen können, sondern auch intelligente Funktionen der nächsten Generation wie künstliche Intelligenz und maschinelles Lernen nutzen können, und zwar innerhalb eines Systems, das immer aktuell, verfügbar und lernbereit ist.
Das Asset-Angebot umfasst die Verarbeitung von Assets der nächsten Generation in der Cloud sowie die hochleistungsfähige Erfassung und Suche von Assets.
Weitere Informationen finden Sie unter Übersicht und Einführung in Assets as a Cloud Service.
Weitere Informationen finden Sie unter:
Sobald Sie einen Überblick über AEM as a Cloud Service haben, können Sie sich schnell einarbeiten werden, indem Sie die Onboarding-Tour absolvieren.
Sind Sie bereits dabei oder bereit, die Funktionen von AEM zu testen? Installieren Sie das AEM-Referenzdemo-Add-on, um die leistungsstarken Funktionen von AEM anhand von umfangreichen Beispielen zu erkunden.