AEM Forms as a Cloud service
A cloud-native solution providing access to Adobe's web-based forms solutions
Adobe Experience Manager as a Cloud Service
In addition to the various options for running Adobe Experience Manager Forms, the "as a cloud service" variant has been added in recent weeks. It is true that Adobe has had "managed" solutions in its portfolio for some time, so that customers do not necessarily have to operate AEM Forms in-house ("on-premise"). But now there is a true containerized solution that not only hosts and manages servers (virtualized), but has numerous automations that contribute to the stability and scalability of the platform.
Adobe Experience Manager Forms as a Cloud Service is a cloud-native solution that provides access to Adobe's web-based forms solutions. Some of the services around the PDF document format are already available; Adobe is in the process of adding more functionality. The solution is based on Adobe's "AEM as a Cloud Service", which brings its benefits to Forms, including automatic scaling and rollout of updates without interruption.
The foundation: AEM as a Cloud Service
Adobe did not start from scratch when implementing AEM Forms as a Cloud Service. On the contrary: AEM as a Cloud Service for the "Sites" (Web Content Management) and "DAM" (Digital Asset Management) modules has already existed since the beginning of 2020, which our Head of Sales and Marketing, Martin Brösamle, also reports in his blog article.
The central added value that Adobe praises and which should not be overlooked here are:
- Permanent availability („always on“)
Without downtime, content can be created by authors, delivered and made available worldwide.
- Scalability („always at scale“)
During operations, additional container instances are automatically added as needed to balance increased loads and enable fast response times.
- Up-to-date („always current“)
Due to the clever separation of author-created content, developer-implemented code, and Adobe's platform code, it is possible to update the latter with the latest version on the fly. Security updates are rolled out on a daily basis if necessary, and regular updates on a monthly cycle.
- Further development („always evolving“)
By constantly analyzing the content and code it delivers, Adobe can both drive best practices and adapt its processes to make the platform even easier for its customers to use.
Further details on the cloud service as well as the other operating options of AEM (Forms) on the OSGi platform can be found in an article by our CEO Michael Deißfrom February 2021.
Range of functions
The above are good reasons to consider using AEM Forms in the cloud. For a large part of the use cases, this is already possible today. However, there are some functionalities that are (still) reserved for "managed" or "on-premise" installations; however, Adobe is in the process of adding more features to Forms in the cloud.
The following overview is intended to illustrate the differences. The individual points are linked to Adobe's (English, since most current) documentation, if already available with that from the cloud area:
Explanations of the basic functions are also available on our website.
Even as an Adobe partner, we cannot say exactly why individual functions are not (yet) available. But if you've been involved with AEM Forms and the AEM Cloud platform for a long time like we have, you can imagine the challenges for Adobe's engineering team at this point:
- Similar to the Assets Compute Service for the cloud-based DAM module, it is to be expected that Adobe will move the Document Services, which essentially contain operations for creating, modifying and evaluating PDF files, as microservices into one or more separate containers. This has already happened for the creation of the Document of Record from Designer templates. This approach is only logical: on the one hand, the performance of the web operations is decoupled from the PDF operations taking place at the same time, and on the other hand, the necessary instances can be scaled specifically if necessary. In addition, Document Services has always been based on its own C++-based computing core (the same as Adobe Acrobat), which is not dependent on the OSGi platform.
- The storage of user-generated content, such as cached form states or data from submitted forms, directly on the externally accessed containers (publish instances) is not feasible, since Adobe's Replication Service only works in one direction. Adobe may provide its own storage service to make this possible.
Probably the most promising integration, with Adobe Sign, is already in place: This makes it possible to implement application sections completely online with legally secure signatures and optional subsequent decision steps. In addition, integration with Adobe Analytics and Adobe Target (which are themselves already cloud services) is not expected to be long in coming.
Migration "to the cloud"
Many of our customers run AEM Forms installations themselves on OSGi or JEE platforms. For the first mentioned, if the above matrix covers the features used, Adobe provides a set of tools to simplify the migration.
Those who cannot yet imagine moving to the cloud, either because the necessary features are not yet available or because operation in their own data center is required for operational or legal reasons, can still get started with AEM Forms as a managed service or "on-premise" and, if desired, migrate at a later date.
Those already using AEM Sites in the cloud may be interested to know that AEM Forms can be "plugged in" to existing instances if required (but can also be run separately from the Sites environment).
Internal or external users, as site visitors, will hardly notice the move to the cloud (except hopefully through increased availability and improved response times).
The same applies to authors of content and forms, as well as to clerks with tasks in workflows: the move hardly means a change in the user experience or way of working. At most, a version change from AEM 6.4 to 6.5 is noticeable due to the redesigned and optimized interfaces since then.
For software developers who customize or extend AEM Forms, the changes are most noticeable: Adobe provides a Cloud Service SDK, by means of which an environment can also be operated and tested on local computers. Nevertheless, tests should always take place in the cloud environment in the end; separate development instances with their own build chain are available for this purpose, which run independently of the production environments. Code and content must be separated during development, and a number of best practices must be observed. Those who, like us, have been designing their projects based on Adobe's Maven archetype for a long time have already taken a big step towards this. However, depending on the type and extent of customizations and the initial version of AEM Forms, you can expect to incur corresponding expenses during migration.
No matter which variant of AEM Forms you are interested in or decide to use (or perhaps have already decided): We will be happy to support you in analyzing and implementing your requirements. We will continue to closely follow the development of AEM Forms as a Cloud Service and keep this article up to date accordingly.