Introduction to Episerver Delivery Core; What It Is and Isn’t
As many of you fellow Episerver aficionados out there already know, Episerver will soon go to market with a new and improved approach of enabling content management and content delivery. It is, at this time, referred to as “Delivery Core”, and it fundamentally changes the delivery-approach, compared to what the Episerver stack today relies on.
While I am sure there are more questions than answers out there at the moment, the intent with this introduction is to start a series of informative content, to help technologists, marketers, merchandisers and business executives to gauge what this introduction means for them.
Within this series, I expect to cover information on Episerver Delivery Core like so:
- Introduction to Episerver Delivery Core; What It Is and Isn’t – This Post
- Initial Thoughts on Episerver Delivery Core – Coming
- Looking In To The Crystal Ball; My Thoughts On The Future of Episerver – Coming
- Gauge Your Readiness; Prepare to Implement Episerver Delivery Core – Coming
- Migrate Your Existing Experience to Episerver Delivery Core – Coming
Introduction to Episerver Delivery Core
Episerver Delivery Core is the first step in enabling best-practice, and more modern, ASP.NET 5 (previously referred to as .NET Core) technology. It will, from a technologist point of view, be the preferred path forward, as per the recommendations¹ from Microsoft. With this opportunity, Episerver initiated a transition to this technology, by introducing the notion of Episerver Delivery Core.
Episerver Delivery Core is in a few words a new component, which will be responsible for delivery of content and functional experiences to your visitors. Think of it this way; in the future, content delivery and content management are two separate concepts, getting Episerver closer to a more distributed and scale-able setup.
Instead of re-writing or re-engineering the entire Episerver product, hence introduce trouble in upgrades and backward compatibility, Episerver took a more nimble and respectful approach with the introduction of Episerver Delivery Core. It introduces an optional approach to only the part of the platform that benefits the most from the power of the new technology: the experience and content delivery layer.
Comparing the Future with Today
While we all prepare for the ‘new era’ of Episerver, our insights through EMVP-channels, and our close partnership with Episerver, allows us to further share perspective on what the shift in approach really encompasses. While this isn’t a holistic representation of scope, by any mean, it should enable you, as an Episerver customer or partner, to better understand the extend of Episerver Delivery Core.
What it does
- It allows graduate adoption, giving you as the customer the opportunity to choose the right time to take on the change (based on value/opportunity/pain)
- It keeps content delivery channel agonstic, enabling your future digital channels to benefit from your content/functional evolution as well. Episerver Delivery Core operates as a headless content consumer, natively integrated to an optimized version of the headless Content Delivery APIs supported by Episerver.
- It enables the benefits of the new .NET technology, giving your visitors improved page-load performance (like via HTTP2.0 support) – at least on paper – and your business added simplicity with a new way of coding.
- It somewhat enables a headless-first design, at least if you approach it right. If you are too single-minded in how you approach the design of your solution on this new concept, mistakes can be made, requiring re-work later when you want to capitalize on the headless maturity Episerver Delivery Core natively should enable.
- It requires change to your existing solution, to migrate to Delivery Core. It is not a ‘flick the switch’ introduction and it does require you to engage a partner or your digital team to get it going.
What it does not
- It does not re-position Episerver as a headless CMS, with a channel agnostic content-first model. It theoretically gets Episerver closer to a content-as-a-service type approach, which may be the aspiration. More to come on that later.
- It does not compromise future upgrades of existing solutions, because no customer should be forced in to adopting it. Regardless of you using Episerver Customer Centric Digital Experience Platform (formerly known as DXC-S), your own Azure subscription or on-premise, the existing way of managing delivery of content continues to be supported.
- It does not introduce twice the amount of platform maintenance. The notion of cross-cutting concern has been a fundamental thought in the architectural design-process, meaning that best practices for shared concerns, like content models and templates, exists.
- It does not optimize the authoring experience for your business users. Like described above, Episerver Delivery Core is a content delivery concept.
- It does not compromise the utility you bring to your editors, meaning on-page editing etc. remains as a key value-add within the Episerver stack.
Said in a few words; the introduction of Episerver Delivery Core is not a reason to have sleepless nights. Instead, you, regardless of your relation to Episerver, should see it as an opportunity to move towards a better performing, more scale-able and more maintainable investment. It first and foremost allows you to crawl towards omni-channel maturity, while it also, second, allows you to excite developers and technologists with top-notch technology.
More to come – tune back in later for more in-depth thoughts on Episerver Delivery Core.