 Thanks, Christina. Today, we're going to be talking about Git-based headless CMS platforms and how they can solve the challenges that we find with traditional database-centric CMS. Let's go ahead and break that down a bit. First, we're going to make a bit of a comparison between Git-based and database-backed CMS platforms and try to understand where some of the issues are with traditional underpinnings and how Git-based platforms can address those issues. Then we're going to discuss how we can improve developer and content author workflows using Git. And after that, we'll look at how we can integrate our CIECD process and the DevOps processes that we have with content to achieve higher efficiencies while we're innovating. And after that, we'll go on to touch on some APIs and why they're essential with a Git-based headless CMS. And after that, we'll look at some real-world use cases and some success stories and whatever time we have, we'll take some questions. So let's go ahead and jump in and compare these two architectures. So databases are the traditional underpinnings of CMS. And there have been some attempts to create different types of content-specific repositories over time, but with really limited success for a variety of reasons. The main reason being that most contenders have been too tightly coupled with specific technologies or that the standards have been designed by committees that are too large with too many different concerns. So as a result, SQL and NoSQL databases are the dominant choice of storage for the CMS backend. And we're going to explore why that is and look at some of the shortcomings that are becoming more acute over time. Now, all of the CMS business kicked off back around 1995 just to give you an anchor in terms of a timeline. Early on, CMS systems or what you might call proto-CMS systems were rudimentary file-based platforms that could only manage HTML or bake HTML. And by 2002, we had seen the dot-com bubble come and go. And at this time, well-established systems emerged that we would all recognize today as CMS, including proprietary players like Interwoven and open-source platforms like Drupal. Nearly all of these were Git-based. By 2007, the scale and the size of many enterprise sites have pushed CMS systems to decouple authoring from delivery so that dynamic and personalized content could be rendered effectively at scale. The point of decoupling this was really to allow the authoring and the delivery system to scale independently of one another. And the way this is implemented with database backend systems is really to kind of create a read-only replica on the delivery side. By 2014, the need for proper multi-channel support was becoming much more critical. The vision for multi-channel had begun moving beyond M.dot sites and even responsive sites for smartphones to true multi-channel. And at the same time, CMS vendors were hitting a stride with built-in tooling for marketing departments that included rich support for managing targeting, metrics, experimentation, marketing automation, so on. So this is really the height of the DXP sort of hype curve. And by 2018, it had become clear to everyone that was developing for and around CMS that some kind of significant architecture change was badly needed. Head of DXP solutions could not really support the innovation around the emerging channels and something had to give it that point. And we really see headless CMS take center stage. So what we're going to basically be looking at in more detail here is how the headless architecture has changed things, like for example, it's changed the presentation here, but since the early 2000s, there's been no significant change on the back end. Now Drupal is an excellent example of this because it's widely known. It's an open source CMS with a GPL style license. And like many others, it's backed by MySQL, which is a very popular SQL based database. And it's been that way since 2001. And still over 20 years later and nine major versions later, it's still backed by MySQL and has pretty much the same back end. Now, if we roll the clock forward all the way to today, if we pick the most modern headless CMS platform out there, if we just think something that was born to be headless, maybe even something that was whether it's self-hosted or SAS, but maybe even it was born to be SAS, if we look at the underpinnings of that system, we're going to find that it's also backed by a database. Again, headless architecture doesn't change the back end. Instead, it removes the presentation layer of the CMS and the underpinnings remain the same. So the obvious question here is why? And that answer is probably because so far that back end has been good enough. Databases are sort of the obvious place to store things. They are readily available. They're freely available in many cases and they're well understood by a majority of developers. That said, SQL databases and no SQL databases are far from a perfect fit for storing content. They just weren't designed for CMS use cases. However, as you might guess, with all the other requirements a CMS implementation has to satisfy, leaning into a technology that's well understood like SQL databases is really not a major stretch of the imagination. So with that in mind, let's build up a little bit more of a cultural context and more importantly, a technical context for where we came from and where we're headed. So when CMS technology was first introduced, the president of the United States was Bill Clinton. The original iMac was the top selling PC on the market. These guys here in sync were topping the charts much to my chagrin I might add. And the best mobile device your money could buy was this indestructible Nokia phone. And the number one movie at the box office was Titanic and the battle for the browser was still between Netscape and IE. So it kind of gives you a sense of where this all started and you can gauge that with where we are. This is not a exercise in trivia. It's to say that for those of us who know and honestly for those of us who are new to the space that so much has changed since the beginning. We live in a completely new landscape at this point. And it's almost hard to imagine that we still use the same backend storage paradigms. Now the objective facts here are that headless CMS has been possible technically since 2000. Rest was introduced at that time yet headless CMS architecture does not dominate until about 2018. So it's taken about 18 years for that pressure to build up enough to really force a major shift on the front end. By 2018 we had really rich responsive web app frameworks and companies wanted to put these into service to create much richer customer experiences including websites. We had new mediums like video that were wildly popular at this point but more importantly cost effective to support. We also have rich content connected native experiences that had also become very easy and inexpensive to build and deploy. And we've seen the emergence of a wide scale adoption around things like digital assistance wearables and other opportunities that really embody the meaning of multi-channel including big data support and integration capabilities required on the backend to truly connect the customer journey across channels and touch points. So in short by 2018 developers basically have had it with building on traditional head full CMS and DXP platforms. It's just not working for them in terms of meeting their requirements in the real world. Traditional CMS and DXP platforms were conceived to build and manage content for websites and managing content intended for other channels and presentation layers other than pages just had to be forced or hacked. So that wasn't working very well. Also head full CMS platforms dictate the presentation tier with proprietary channel specific I think maybe even website specific development frameworks which is a major challenge when your goal is to support a device that maybe doesn't operate in a web browser or doesn't operate a web browser or doesn't even have a screen like a digital assistant. So as good as DXP solutions had become for website managers, the whole omnichannel customer experience tower as you might think of it was really beginning to crumble at its technical foundations. Developers just couldn't respond quickly enough to the business demands, okay? So there's no question why we arrived at the consensus around headless CMS architecture. And while it's been possible to arrive here long before traditional headed CMS and DXP platforms simply put were kind of good enough. Like I said, it took about 18 years for the dam to break. Now that said, we wanna take a sort of note here of the acceleration that we see in the technology. And this is part of the reason why I put up so much of that context. So much of the major change has happened in the back half of that 18 years. So things, the curve here, the change curve is not slowing down and it's not a linear curve and it's not slowing down. So it's gonna get faster. Headless CMS has been insanely great for developers of multi-channel experiences from a pure coding perspective. Using them developers are free to code for any platform, any programming language, and any process that's really suited, well suited for that job. And that's a huge relief for programmers that are under a deadline and a budget as all programmers are. Headless CMS is great, but it doesn't solve all of the problems and the problems are architectural. So what I wanna do is kind of dig into that architecture and kind of understand it just a little bit more closely. So let's do that. So with Headless CMS, you design a content type. So what that means is you define sort of objects or nouns, things that you wanna represent and give them properties, let's say like an article with a title, a body, some images and so on. That content type is then leveraged to render a content entry form or some other kind of content entry interface so that can happen automatically based on that definition. The end user puts the content in and it's captured and stored in a repository backend. In our case, typically a SQL on databases we've been talking about. And once we've got that content stored, then we can request that content as a consumer, as a REST API in a format like JSON without presentation and that frees the consumer layer, the presentation layer to format and present that content however they like. So you can see here that there's no fundamental backend changes to the underpinnings, the repository required to make Headless CMS work. Consequently, and I think quite reasonably, implementers have stuck with traditional solutions up to this point. Headless CMS solves the two problems we've talked about that developers have kind of suffered under with traditional CMS. And as a result, the multi-channel development is moving faster. But if you've ever optimized a system, you know that optimization is almost never completed in a single iteration. Removing one block only exposes the next. So now that developers are free to use any front-end framework and any language they want, we see an entirely new kind of roadblock standing in the way of development efficiency and that's DevOps. And specifically, with respect to DevOps, with respect to content, the content in our Headless CMS platforms is kind of trapped in the database and doesn't fit into the modern development CICD processes environments that we have. And moving content between those environments to support development has never been easy with CMS and it's always been a problem. And Headless CMS architecture doesn't do anything to improve that outlook. So for those of us, another issue here, for those of us that run and operate CMS infrastructure is that we know that databases are difficult to scale out. And even if we are on a SaaS platform with Headless CMS and the scale out is not our direct problem, we need to know that the SaaS vendor that we're using can handle that scale out or distribution. This is kind of another issue of optimization. If we can build new channels and capabilities and we can build anything we want, does it matter if we can't roll them out easily and scale them up? Are we really going to get the results that we want to achieve? So that's an important factor there. Further, we find that Headless CMS leaves us with much of the same friction that we felt all along between authoring and development teams with individuals and processes interfering with each other and stepping on each other's toes with cumbersome but often required activities like content freezes. We also see that although faster than it used to be, the development process efficiency still isn't what is expected from us based on the rest of the industry and the gains that have been seen elsewhere in software development with better and more modern CI CD support. And another lingering issue is that databases still can version the way that we need them to. The kind of versioning that maps to our content management problem domain. Versioning needs to span many objects and be auditable. And the more connected our journeys are and the more channels and touch points we add, the more these kinds of capabilities become necessary. And we still find ourselves with clunky processes like double publishing when we're supporting redesigns and other similar use cases. So we'll look at that later as well. Now, as I mentioned, Headless CMS is a significant improvement, but it certainly doesn't solve all of the issues that developers and product teams have. The problem remains on the backend. So at this point, it's time to look behind the API. It turns out that architects and developers are now looking behind the API. And over the last several years, there's been a major growth in the use of Git to replace and or supplement databases as the backend for content management, versioning and DevOps requirements. And if you're researching this topic, one of the things you'll often see here is that Headless CMS and Git-based CMS are kind of compared and contrasted as if they're mutually exclusive. But this comparison is a false dichotomy based on specific CMS platforms that only do static site generation. There's nothing about Git-based CMS systems that says that they can't also have a server component and an API. Further, if you think about it, much of what we serve through digital channels are created and managed and stored as files, such as images, videos, CSS, JavaScript. These are all files, not database records. And they're more suited to systems that manage files. As Git-based CMS has shown us as well, even our copy, which has traditionally been stored as rows in a database can be stored in file formats like XML, Markdown and JSON. Now, Git-based, so it's Git-based and Headless CMSs are not mutually exclusive. Hopefully that becomes clear as you kind of think through that problem. Now, where does Git fit into the CMS? Let's think a little bit about the CMS domain. So first, we have authoring capabilities. These are capabilities that let authors and developers create and edit and manage content, perform workflow and collaborate. And we could kind of simply call this authoring. We also have delivery requirements like serving dynamic and personalized content, executing searches, enabling shopping, capturing reviews and so on. And this set of services are the customer-facing services and we could simply call these delivery. Now, typically the authoring and delivery services are connected to one another through some kind of publishing or deployment process. So if we think about it, Git provides the most value on the authoring side where you have authoring workflow, versioning and you also have DevOps workflows. Here we can see that we have a Git in this reference architecture as the underlying store behind a set of services. And if we think through this to the delivery side on the delivery side, where authoring and workflow and versioning and DevOps are not as relevant, we see simple storage like disk and S3 that can be used behind a set of delivery services. Okay, now that we're starting to talk a little bit more about things inside the CMS and authoring services and versioning, let's dig into that a little bit. So this is an illustration of the kind of versioning that we typically see in database-backed CMS. The CMS can usually version one content object at a time. So we kind of see the stack of content objects there or in some rare cases, you've got versioning that's a little bit more sophisticated and can manage a cluster of objects as a single version. But this really rarely maps to real-world situations for us. In the content space, our work products for releases are usually tens or even hundreds of objects. And there's really no database-backed CMSs that allow us to manage this kind of inner object and inner file relationship together as a single version. Also, it's exceedingly difficult to build that kind of versioning with standard SQL and no SQL database technology because the technology was never meant to support it. So you've really got to build up a lot of abstract data structures that become really complex and don't perform very well. Git, however, was born to version artifacts precisely in the ways that we need them to meet this requirement. So if we look at the diagram here, we can see that each right is captured like a sort of a time machine. Very efficiently, we capture the state of the entire repository at every moment and every commit that we make to the repository. A Git-based content repository can very effectively handle use cases like rollback of deployments and full audits of a precise state of the repository at a given moment in time or even entire sites or entire apps at a given moment in time. So they really help with that auditing and rollback. And these two features are killer features that are very difficult to deliver without the Git sort of backend. And as powerful as these two capabilities are in their own right, the manner in which Git stores versions is even more powerful than it appears on the surface. And that's because the versioning system is like a time machine and it enables sync between repositories natively. Repository sync is the true killer feature here. Sync enables decentralization of the repository and branching. So decentralization can improve performance. Think about a traditional database backend. If you have one database sitting somewhere on the globe and you have rights elsewhere, these can be very slow for people that are geographically distant from the server as we see here in the picture. It's true that we can distribute the most database technology geographically but this is often technically challenging to set up. It's also kind of not, I would say impossible but almost impossible to achieve a very high degree of performance on rights. And that's really because of the fundamental way that these systems work and are designed, the nodes themselves tend to be very chatty. There's a lot of locking. So as soon as you add distance to the equation, it's really becomes a recipe for performance issues. Git based systems, however, are designed at a fundamental level to be distributed. They innately understand how to synchronize change sets over time and how to deal with conflicts. Further, Git based systems can help you deploy content globally in a very reliable fashion. There's no such thing as a partial Git pull or Git push. These things happen transactionally. And further, because of how the version system works, any change, no matter how small is sort of is tracked. We can tell what has changed. And this change detection can be leveraged to detect inconsistencies with a deployment across many nodes and even things like the facements. So there's all kinds of benefits there as well. Another thing we need to think about is environments, right? Or what some organizations call landscapes. No one does any significant amount of development in production. Not that we would admit, of course, we often joke about it. We always develop in lower environments, we test in lower environments and that's a proper process. So with traditional NoSQL databases and SQL databases, moving code and content between these environments means exports and imports and performing these sort of cumbersome processes. And oftentimes it means content freezes that are very cumbersome and time consuming. The other issue is that they're often all or nothing. Basically, if you're gonna bring the content from production back to a lower environment, if you've got content in the lower environment, you're about to lose that. You can really only just completely overwrite it. So that can be an issue. Now Git supports moving content back from production natively and moving code forward from lower environments to production natively. So there are no more content freezes necessary. And the other thing here is that you can merge work. So when you do a Git pull, you can perform a merge so you don't have to blow away work that you have in your target environment. And what about those tricky double publishing use cases that we talked about like site redesigns? Well, if you've ever lived through a site redesign with a CMS, you know that you have basically two things going on at once. You've got the live site that you're maintaining and you've got the new thing that you're building and you've got to keep the content up to date. And the most common solution to this problem is to sort of simply bite the bullet and have authors double published to both environments. And really the truth is everybody hates that and you do what you can to avoid it, usually delaying the process but eventually it comes down to that. With Git, however, we have branching and branching allows us to perform all of our daily content work for the current live site in the main branch, right? And all of our rebranding or redesign work can happen as in a child branch that is intended for the redesign. So we can see that here in the diagram where at some point we decided to do a redesign, we created a branch with that initial state and we just started to do our work, right? Now every day or every hour, our team or our automation can pull the content from the main branch, the live work into the redesign so that there's no need to do double publishing, right? And the redesign team can decide how to treat that content as it comes in. And when we're ready to go live with the redesign, we simply merge our branch back and we're done, okay? So yes, there are some pretty significant differences here between Git-based repositories for CMS and traditional SQL and no SQL databases that we've been using over the last 20 years. And I think it's also fair to say that Git offers some real solutions for longstanding fundamental problems that we have with most current systems as the pace of innovation increases. And I think it's gonna be those issues are gonna become more and more of a problem as we try to get past those roadblocks. So to understand this a bit further, let's dig a little bit more into detail on developer and content workflows and understand how a Git-based CMS can help us with that. So in recent years, we've made a lot of progress with automation and containerization and our development and operations practices, but with CMS, content is a significant piece of that puzzle. But because of the architecture, the database backend, it's been kind of left out of the equation just simply difficult to deal with so we don't. And DevOps is all about bringing developers and operations together to eliminate friction and efficiency loss between them. And we've talked about some of the things that are longstanding points of friction with content management. When you're dealing with content oriented experiences, we need to include content as an equal constituent. And this is what we would call dev content ops. We need authors, developers and operations to work together as equals without friction or loss of efficiency. And Git is a great foundational architecture to enable this kind of collaboration. So let me get into this a little bit for you. So here we can see authors working with a user interface, so easy to use interface that enables them to create and manage and edit content stored in Git. They don't need to know anything about Git. That's a big thing here. We're not suggesting anybody a business user should learn to use Git. The user interface can translate all the key concepts like versions and branches and so on into business oriented terminology and lexicon. We can make this simple for them, but give them the power. Developers can similarly be enabled to create new features and access content from production to conduct testing by leveraging these Git mechanics. All while using the tools and processes that they are already familiar with and that are making them efficient. And here it can be a little bit more direct. Developers already understand Git branches, Git based workflows and so on. So they can take full advantage of these capabilities to support teams and parallel development of many features. Ops using tools that are already integrated with Git out of the box as so many are can very easily and natively automate the CI CD process. And the whole frictionless collaboration is what helps us to deliver new experiences and capabilities to our teams much sooner, kind of breaking down those new roadblocks that we talked about. So hopefully that gives you a high level sense of things. Let's dig into an example workflow and understand this at a sort of deeper, more technical level. And what we'll do is we'll start with content back, okay? Here we see a production authoring instance with authors creating new content. The production system is operating on a local Git repository under the authoring service. And we can then connect that local repository to a remote Git server, something like GitHub, GitLab, code commit, Bitbucket or some other Git. It doesn't matter which one. They all sort of talk the same language. And given that connection, we can then push content up from production authoring to that remote repository. And developers can pull that content from the remote Git into their local machines to support development. And when testing is required, the production content can be moved to any testing environment in a similar fashion. To do so, the given environment simply pulls the production content from the remote repository into themselves. Developers may also want to deploy templates, CSS, compiled JavaScript and so on. And they're gonna have to move this up through the lower environments towards production. And we call this code forward. So developers will work locally in a code forward scenario, will work locally with their tools to code and may optionally have a local version of the CMS to create things like content types or test templates, et cetera. Sort of an optional component there. And as the developers work, they can share their efforts with other team members or other environments simply by pushing their work to the remote. This works with any Git based workflow and branching strategy that you like. And for simplicity here, we might imagine that we're working like on a simple feature branch and we're gonna push that feature branch to the remote. To get the feature branch to QA or other testing environments, it's a simple Git pull process that we would use. And moving content to production is also just a Git pull. So we can see how easy it is to support developer and content workflows with Git mechanics at our disposal. There's no content freezes here. It's just simple mechanics. And we're always able to detect the conflicts and handle situations that are very difficult in a traditional database scenario. There's no meaningful equivalent in a traditional database world either. We're stuck with sort of these all-or-nothing database exports and imports or some kind of wonky handcrafted ETL process where we kind of build our own sync and that's gonna be a very implementation-specific effort. Okay, so hopefully that makes some sense. Now let's turn our attention to headless APIs. And specifically, I wanna look a little bit closer at why Git-based CMS needs to support APIs. Now, the first reason is to have content-up support. We just talked about that. We definitely want to be able to support content back and code forward situations using automation and APIs along with pure Git mechanics to do that. And APIs make it possible for us to have that easy-to-use authoring interface, right? We do not want authors to have to understand how to use Git, so this is a big reason here. Another important thing to understand is that some Git-based CMS systems are just simple Git backends as a content store that kick off static site generation. And that's fine, they have their place, but enterprises need a lot of dynamic and personalized content and these sort of simple Git-based systems with no API can't serve all kinds of channels that, for example, don't consume HTML or they can't serve things like personalized content or dynamic content effectively. So we need an API layer, a service layer to do that. Another important use case is just generally speaking, integration, almost all enterprise CMS use cases involve some kind of integration with CRM, ERP, e-commerce, marketing automation, and so on. So APIs are the heart and soul of proper integration and that's a very important reason to have API support. And while we're on the topic of APIs, I just want to kind of point out that as a headless CMS, Git-based or not, I really feel that the CMSs should support GraphQL today. And GraphQL is basically a backend agnostic query specification and I'm greatly oversimplifying what GraphQL is here, but we want to think about it as it's a specification that allows developers to query content and data from any store with a common query language and a common calling convention. And it's become very widely adopted in recent times. And I think that's huge. GraphQL is essentially the closest thing to real standardization of interface that CMS has seen in a very long time in terms of adoption. So it's real, it's very powerful and I think it's becoming essential. And if GraphQL is not part of your CMS selection process, that's not something your CMS supports. And I think it's something that you want to add to your list to go learn about. And if you are looking for CMS technology, add that to your requirements. Okay, now with this, let's look at a couple of real world use cases and success stories of large scale organizations implementing Git-based headless CMS. And we're going to start by talking about Git-based headless CMS architectures where Git serves under the authoring component and is servicing the authors and the dev content ops processes we've discussed earlier. And since we're highlighting some real world examples here, I'll quickly mention that these examples that we're going to talk about are all based on and running Crafter CMS, which again is an open source Git-based headless CMS. Now, if we expand this diagram a bit, we can see that Git here is under Crafter Studio, which is our authoring component, which provides a REST-based API and direct Git access to the content repository. Okay, and on the delivery side, we're deploying content to disk and S3. And on top of that, we support a variety of services and service capabilities, including REST APIs, GraphQL as an alternative to REST APIs and the ability to script your own REST APIs. We think that's an important feature too, but not something we have time to get into today. That enables Crafter CMS to serve dynamic and personalized content to any channel and any technology and support a variety of rendering models like client-side rendering, server-side rendering and even static site generation, which you can see going from the authoring to maybe say HTML5 there. And with that in mind, let's talk about our first use case, which is Marriott. Now, Marriott uses a Crafter CMS to support many digital channels, ranging from headless content served to the .com site, as well as personalized content served to their global extra net. Marriott's a perfect example of why headless CMS alone does not meet the needs. And several of their use cases at Marriott are such that they require really strong versioning and auditing capabilities. And as we've seen, standard database-based back-end CMSs can easily produce a snapshot of the entire CMS at a given moment in time. But with Git, this is a pretty straightforward operation. A Git-only CMS would also not be an appropriate solution at Marriott for most of their use cases. Git-only CMSs are fairly limited and tend to serve only a single channel by baking HTML. But personalization, large volumes of content, supporting multiple channel types and technologies are common requirements at Marriott and they require API support. So for example, Marriott's extra net is a personalized platform that's personalized for the associates role. And it's personalized for over 31 brands that those associates work at. It contains 30,000 pages of content as well. So a lot of content there. And its services and capabilities span multiple devices as well. So perfect example of why we need a server. Our second use case here is PapaJohns, which is a leading restaurant chain. I'm sure you know them. And like Marriott, PapaJohns leverages Crafter CMS to meet their technical requirements. And they serve content across a lot of channels. In some ways, they're kind of the poster child for multi-channel. If you think about it, they're serving content for the web, native mobile. They take orders over the phone through digital assistance and even in store. So very, very omnichannel. They also personalized their menu content by locale. So headless CMS capabilities and server capabilities are critical. At PapaJohns, innovation is also a key strategy for better serving existing customers on an ongoing basis, as well as a means for attracting and retaining new loyalty. And in digital, innovation means software development. That's the way you want to read that. And as you can imagine, developing a large-scale e-commerce platform like PapaJohns is pretty serious business. So architecture, process, tooling, all of these things are paramount. And it helps PapaJohns manage that development process across multiple teams working on independent sets of features, all in isolated branches, and gives them the ability to pipeline those features out to production through the testing process, which, again, very rigorous, as you can imagine, and often flows through more than six environments. So that dev content ops piece, very critical there. OK, now with that, let me sum things up here, and then we can take a few questions. So again, you kind of want to think about here that that database back end was really put in place in the early 2000s and has remained that way since. And relational databases, again, are kind of the easy answer, but they're not necessarily the correct answer. They have many disadvantages, including the fact that they're not meant to support files. They have poor version handling. They're not multi-environment. They have scalability issues, workflow issues, and so on. Headless CMS is definitely a significant improvement to CMS architecture, but it doesn't solve all of the challenges, especially those that come from the underpinnings. And I think, as you've seen here, a Git-based CMS platform is designed to leverage Git's distributed repository back end and support this advanced versioning and content syncing and branching capabilities that help solve the lion's share of the remaining kind of CMS back end issues that we see today. So with that, let's see if we have some questions. So I'm going to take this one here. OK, so the question here is, would a Git-based CMS maybe even crafter CMS be well suited for AR, VR content and immersive experiences? So the answer to that question is yes. I think, as a headless CMS, we can really support content. And I think this goes into headless CMS architecture. We can support content for any type of digital experience. In particular, AR, VR content is absolutely file-based and large files to boot. So this can be a great use case for the CMS. Now, one thing we didn't talk about is large files and Git. And that's often a question around Git. And you can store large assets in Git. And you do need kind of an approach for that. Maybe it's Git LFS or it's kind of a blob store that goes along with Git, just a simple bucket or so on. But Git can be a very effective platform for that. And I think headless CMS is absolutely the right type of back end for those types of experiences. OK, we've got any more questions here? Maybe we'll give it a minute. I'll also put up my contact information here. If anybody would like to reach out, be happy to answer any questions that you might have offline. OK, go on once. OK, here we go. What's the overhead in transitioning to a Git-based architecture? It's a great question. I'll go ahead and we'll go ahead and answer this one here. So it depends on where you're coming from. If you obviously if you don't already have something, then there's no migration. But I think the big bit of work is in migrating from something to a Git-based solution. The good thing is that creating Git-based content is pretty straightforward. If you're storing content as XML or JSON, those things are easy to produce. There's tons of tooling to support those file types and even common ETL tools, which are extraction, transformation and load tools support those things. They also reach into databases. So basically standard ETL tools are a good option for transitioning if you are doing a migration. The complicated part is usually understanding the database structure in the previous CMS. Another question here. Let's see. So there's a question about scaling the authoring side of the CMS. And I think for the number of authors, and I think the answer to that is yes, the authoring side can be scaled. It scales out differently than the delivery side of things. Of course, it's easy to vertically scale anything. And Git is sort of naturally a distributable platform. It can be scaled that way. There are some thinking to do about where people live, what times they work, and so on, and how to kind of organize your work but can be scaled in a fairly simple and cost-effective way. The question now, I'll just go back and say, the question is it talks about the authoring side for tens of thousands of users. And I'd be interested in that use case. We should talk about that. That's not something that we typically see. There's a question here about can the problems of traditional database that we see with CMS be overcome with distributed database? And I think the answer is no. I mean, basically, traditional database and distributed databases are, they're designed to handle the same types of problems. I mean, databases are not designed to handle content. That's, we've got to kind of understand that first as a first kind of principle. Like I said, the versioning doesn't map to the way that we want to version content. The flowing things between databases is not a common database requirement when we think about data. So I would just say that no, the things that databases are optimized to do are to handle large sets of tabular data for standard kind of crud operations and number crunching operations, not managing and work flowing content. And that's why we're really looking for a different kind of store and why we've arrived at Git. Okay, well, we're just at almost 50 minutes. So I wanna say thank you for your time. I really appreciate everybody tuning in and listening to this presentation. And with that, I'll turn things back over to Christina. Great, thank you so much to Russ for his time today and thank you to all the participants who joined us. As a reminder, this recording will be on the Linux Foundation YouTube page later today. We hope you're able to join us for future webinars. Have a wonderful day.