Initial Thoughts on Optimizely Delivery Core

What to Really Look Forward to

Headless Approach

You will like the headless approach. As you are introducing Optimizely Delivery Core, it will enable a content-model-first design approach, helping you establish parallel work-streams of experience design, content creation and platform development. Opposed to platforms like Contentful which also enable a content-model first design approach, with Delivery Core, Optimizely removes the complexity in the technical connection between content, experience (visual, interactive, functional) and the domain/logical layers of your application.

Continued On-Page Editing Experience

Your editors will love the continued on-page editing experience, which most other decoupled or headless CMS' severely lack (without added efforts or dedicated preview environments). Because of the way Optimizely continues to give you an SDK for the implementation of the experience layer (via .NET 5 and Razor), we expect the on-page editing to activate out of the box.

Dedicated Web-App

Dependent on how you're running/operating your Optimizely platform today, the Optimizely Content Cloud offering is designed to remove the infrastructure complexities and logistics this type change requires. If you think about it, Optimizely Delivery Core will introduce a dedicated web-app (logical infrastructure component), with the responsibility of delivering an interactive, end-user facing web experience. It relies on a fast and secure connection to an underlying Optimizely Content Delivery API (headless component) to satisfy the content and logical needs (personalization, a/b tests etc.) your new experience requires.

Ease of Upgrade

We expect this approach to ease the upgrade of your Optimizely CMS/platform further. If you consider below reasons, the introduction of Optimizely Delivery Core softens the dependency between between your end-user facing experience and your underlying platform:

• The content delivery APIs (headless component) rely on semantic versioning to control the impact of platform change, hence negative effects introduced by platform change will be more predictable compared to today. At the end of the day, Content Delivery APIs will be the glue between your experience and your platform implementation going forward.
• Content delivery and management are logically separated, meaning you can deploy minor-upgrade packages to the two independently.
• Optimizely Delivery Core will most likely rely on a light and very strict version of the platform’s underlying framework, which means the majority (if not all) of the change associated with an upgrade targets the management side of your application. It means your experience stays untouched for the most part.

What to Have in Mind

Migrate Your Existing End-User-Facing Web Experience

Your existing end-user-facing web experience must be migrated to adopt the new Delivery Core approach, which includes planning for changes such as:

• Migration of your Razor views to adopt the change to helpers introduced by .NET 5 (Core).
• Introduction of .NET 5 (Core) compatible dependencies, to replace existing .NET Framework optimized packages.
• Lessen your dependency between Optimizely and your new Content Delivery component through the more light-weight packages.
• Depending on how tightly coupled your existing Optimizely solution is, Delivery Core requires a clear separation between the layers of experience (visual, interactive, functional via MVC and client-side code), content (content models via page types and block types) and domain/logic. It may require you to re-factor certain aspects of your solution.

Customization Might Be Required

E-commerce transactional elements, like a simple add to cart, are not supported by Content Delivery API, meaning the headless nature of e-commerce, required to adopt Delivery Core in an Optimizely Commerce-heavy project may require customization and/or adaptation on your end at first.

Additional Web-App Might Be Needed

If you are running Optimizely on a self-hosted cloud, you would need an additional web-app for the dedicated delivery application, hence you should expect to change your logical setup.

What to Monitor and Validate More Carefully

With a headless approach, an increase in the amount of networking traffic required to serve up your experience should be expected. Instead of a database connection (and cache) being used to retrieve content, we will now see an added layer of HTTP traffic to power Delivery Core as well. It is of course something Optimizely will ensure is being managed properly (performance, content cloud subscription etc.), but if you are self-hosting, it may increase your average data usage, hence bring up your operational costs. It ultimately depends on how you run your solution today!

At the end of all this, it is important for me to state how exciting this additional delivery option is. It is not something you're forced to adopt—so instead of you looking at it through the lens of concern or need for technical change, you should see it as an opportunity for gradual adoption of new technology, when you and your Optimizely solution are ready for it.