A presentation at Sitecore User Group - Composable DXP update by Stijn De Vos
Sitecore Experience Edge Running Sitecore “high available at scale” made easy delaware / 23.12.21
Outline 1 2 3 4 2 Scaling Sitecore From a traditional .NET MVC perspective Sitecore Experience Edge Global reach Demo delaware POC showcase Questions ??? we commit. we deliver.
Today’s challenges “The evolution of the internet” ??? • More channels more visitors Wearables
Traditional Sitecore on prem Limited infrastructure • “Fixed” hardware (specs) • “Fixed” topology (in a single region) Flexible application • Multi-site • Multi-device Sitecore solved complex business needs at application level Infrastructure was limited / simple (and may still be valid for your current use case) 4 we commit. we deliver.
Traditional Sitecore in the cloud Less limited infrastructure • Scalable hardware • “Less fixed” topology (still single-region) Flexible application • Multiple CD • CDN Cloud infrastructure comes with vertical scaling out of the box Sitecore application supports horizontal scaling 5 we commit. we deliver.
Sitecore and global reach Traditional Sitecore in the cloud makes it easy to scale at regional level • Keep adding more hardware resources • Is this the most cost-efficient way? Regional presence might not be what business wants • Does regional make sense from ROI perspective? • Marginal cost for regional reach increases • Is your business (still) regional? • Growth, industry changes (e.g., covid), … Global presence might be expected • Customers, Google (Core Web Vitals), … How to get global reach with Sitecore in a cost-effective way??? 6 we commit. we deliver.
Traditional Sitecore cloud w/ global reach Replicated infrastructure • Setup per region • Load balancer routes visitors to nearest region Application supports • Multiple regions • Publish to multiple DBs • Index multiple indexes • Infrastructure replication • Azure DB geo-replication 7 we commit. we deliver.
Modern Sitecore: headless Moves rendering from Sitecore CD to separate rendering host(s) • Sitecore content is exposed through an API (true Content Delivery) • Rendering host renders HTML from exposed content • Rendering host can be anything: server (site), app (client), device (client), … This improves • Scaling on regional level: first scale rendering host, then scale Sitecore CD • Rendering host is probably more lightweight than your Sitecore CD • Development agility: rendering expertise instead of Sitecore expertise • Faster delivery / release (debatable) • Modern frameworks and delivery infrastructure 8 we commit. we deliver.
Modern Sitecore w/ global reach This does not solve • True global reach • Infrastructure complexity • Infrastructure cost? 9 we commit. we deliver.
Sitecore Experience Edge “High available, scalable, SaaS delivery solution” • Content As A Service • Think CDN + GraphQL Replaces CD/SQL/Search • Publish from CM to EE • RH gets content from EE • GraphQL or SDK Not only for Sitecore XM • Exposes Content Hub • Exposes ??? 10 we commit. we deliver. Publish GraphQL or SDK
Sitecore Experience Edge w/ Edge network Rendering on edge network • Deploy once • Handles global reach Examples • Vercel: Next.JS • SSR (Node.JS in edge) • Azure Static Web Apps • CSR • ??? 11 we commit. we deliver.
Demo How does it work? • Configure publishing instance • Illustrate .NET core headless implementation with AI timings across the globe Possibilities • Easily switch from .NET core to JSS • Not just for green field projects: legacy MVC supported (SC10.2) Limitations • What’s not possible? 13 we commit. we deliver.
Demo Timings • (No caching) 14 we commit. we deliver.
Demo Limitations (1) • The EE Connector publishes a static snapshot of the Layout Service output • No personalization rules, content testing • No dynamic/contextual output (user, querystring) • No enforcement of security (!) • No Sitecore analytics/tracking • Some settings are applied to the whole EE tenant; not per site • API Key cannot be restricted to one site • Language fallback enabled/disabled 15 we commit. we deliver.
Demo Limitations (2) • Media limited to 50MB per item • Media manipulation limited: h, w, mh, mw • Publish process works differently • “This means that all dynamic content structures in Sitecore (standard values, language fall-backs, rendering data source(s), template inheritance, and so on) are flattened at publishing time. Therefore, publishing a single item can lead to hundreds of items being published. For example, if you publish a template item, all items based on that template directly or indirectly […] are also published.” • No easy view on what is currently published (need to use GraphQL item query for that) 16 we commit. we deliver.
Demo Interesting links • Install Experience Edge Connector https://github.com/nickwesselman/Helix.Examples/blame/aspnetexperienceedge/examples/helix-basicaspnetcore/docker/build/cm/Dockerfile • GraphqlLayoutServiceHandler https://github.com/nickwesselman/Helix.Examples/tree/aspnetexperienceedge/examples/helix-basicaspnetcore/src/Feature/ExperienceEdge • Publishing static output of legacy MVC component https://doc.sitecore.com/xp/en/developers/hd/190/sitecore-headlessdevelopment/walkthrough—statically-generating-an-mvc-application.html 17 we commit. we deliver.
Why you would want to use Sitecore Experience Edge, starting from a a traditional Sitecore perspective.
for free. You
can too.