Past, Present, and Future of Adobe Experience Manager

Transcript

Come back every anew Welcome, everyone. Welcome to the second day of developers live. Can you hear me okay? Thanks for joining us. Perfect. Hey, there we are. Let’s get going. Thanks and welcome everyone to the second day of developers live. Thank you for joining us from wherever you are. For some of you, it’s morning, afternoon, or even evening. I hope you’re all enjoying the event so far and getting ready for the second day. Today we’re here with two of my colleagues, Jean-Michel Petit and Cedric Cuthbert for a chat about the past, present, and future of Adobe Experience Manager AEM. To kick off the introductions, I’m Gina Casagrande. I’m a principal evangelist for Adobe Experience Cloud based in the San Francisco Bay area. I came to Adobe through the Offermatica and Omniture acquisitions in 2009 and have over 20 years experience in digital marketing focused on optimizing the customer experience. Today I’ll be facilitating this fireside or coffee chat with our two speakers. Next I’d like to introduce Jean-Michel who’s joining us all the way from Europe. Jean-Michel Petit is the VP of engineering of AEM. He joined Adobe via the acquisition of Day Software in 2010. For those of you who don’t know, Day Software and the Marquee product CQ is the precursor to what is now known as Adobe Experience Manager or AEM. Before Day Software, Jean-Michel held management and development positions at Silicon Graphics in Siemens. He’s the author of two Internet Engineering Task Force standards and is an Apache and Linux kernel open source committer as well. Talk about street cred, Jean-Michel. We also have here Cedric Cuthbert, director of product management for digital experience management at Adobe. He also joined Adobe with the Day Software acquisition in 2010. And in his role, he’s responsible for product direction and strategy of AEM with a focus on web content management and in-venue or in-store experiences. And prior to Adobe, Cedric was an engineering director at Local.ch, which is Switzerland’s version of the Yellow Pages. And Cedric has 20 plus years experience in the web content management program. Thank you both for joining us today. So we’re going to have a great discussion with Jean-Michel and Cedric. For everyone watching, I first want to mention that you should feel free to add any questions you might have directly in the chat. We’ll leave about 15 minutes at the end to answer as many as we can. And this is really your chance to have a direct line to the product leaders of AEM. So go ahead and send us your questions. And to start us off, we’re going to be talking about the product management and development of AEM. So first off, now both of you have collectively around 40 years of experience working on this. And I know both of you for quite some time too. We’ve traveled the world together and been on the stage showcasing the vision and value of AEM together. But what have you been doing to help customers stay ahead of the game and solve their challenges? Jean-Michel, how about you go first? Well, it’s always a great interaction. I think special moments, first of all, I hope you’re all healthy and staying healthy in these times. And coming to you out of my attic in Switzerland here, these are special moments. I think what I like to do is work with you out there, the key players in our customer experience, the developers, and get feedback. Love to do it here, love to do it in the forums. When I was very active in the open source, that was another way of doing it because this is how we evolve. Eventually, doing this for more than 20 years, we want to stay up to date. So we got a lot of cool things that we did that sort of get me going. I have my hair stand up. I’m so excited to share this with you. But in the end, I want to hear from you because change is the only thing that’s constant. So I’m excited. I think if you asked me to look back and actually saw back of 95, and at that point there, I got up in the morning and looked at sort of which listings were added in the last 24 hours to the internet. We’ve come a long, long way. I mean, here now we’re competing, we’re helping our customers compete for the end user’s attention. And I’m just very excited to do the stuff that we can to help you out in the audience be successful, make our customers successful out there. But I could go on for a long time as Cedric is gladly willing to chime me. So I’ll pass over the word to you, Cedric. Thank you for having me. It’s certainly great to have been enjoying yesterday’s sessions and I’ll definitely enjoy some more today. Hopefully you folks are doing the same. So I was kind of like when we kind of started talking about what are we going to talk about today? I was thinking about when is the first time I heard the word Web Content Management? And it was around 2000. I was working for a company called Optry at the time, which was actually competing against day software. So a little story there, but another time. But and then we had a meeting with the founders back then, it was a small company, founders. And they mentioned that they heard that word Web Content Management. We actually called it something else before that. And I think Communique also had a different way of describing it before that, before the term Web Content Management was actually established. And I think it was it obviously came out of the US. We Swiss companies were like, what is this? Oh, Web Content Management. Sounds good. Let’s do that. Let’s call it this way. Anyway, so that’s that’s definitely fun. Now to your question, Gina. So if there is so on one hand, it never gets boring. And on the other hand, there’s problems that repeatedly come again or challenges. So I just want to for everybody’s entertainment. Who still remembers baking versus frying websites back in 2000, 2001, 2002? There was a big topic wherever you actually going to bake your website or you’re going to fry it. So for those maybe not so long in the game here, the difference between them and is baking your website means you produce every HTML page and put it on a web server Apache or whatever and post it there. Frying means when the request comes in, you fried on the fly and you deliver the fried web page right away. So but, you know, whatever, 20 years later, we’re still having the same discussion. Should I use Gatsby for to bake my website or should I use whatever your favorite CMS framework is and fry it on the fly when requests are coming in? Right. So again, today we have obviously much more to see. And came in mind all the other things I got to go into that. But so it’s interesting that we still even though we’ve been in this in this space for so long, there’s things that come over and over again. And but, you know, never gets boring. So here we are. And definitely want to talk about what we’re doing today and what we want to do for you guys in the future. Perfect. And that’s interesting that you bring up that point. I talk to a lot of our customers and they often want to know what we’ve been up to. Thanks for that glimpse of the past. But how would you say AEM evolved or reinvented itself over the years? Jean-Michel? Sure. I think the point that’s really cool about this industry, which kept me and Cedric and Dan going, is that change is a constant. Now, everybody says that. But I dare you pick one or two of your favorite brands, chances are good they’re using AEM, and go back and look at archive.org. Go back a couple of years and you will see that the end consumers ask for newer and newer experiences, which gives us the opportunity to create new experiences. So what I found is that the velocity of change in the experience management industry is high and increasing. It’s higher than our peers 20 years ago, and it’s increasing faster. And so I think that leads us then to sort of think about what do we do two, three years ahead of the time. So we were thinking about getting into the cloud service and delivering the always on, always up to date service of a content management system that is fully extensible. Server side or client side in the headless, which is cool now, but we’ll get to that a bit later. Six, eight years ago, and then we put it into production, and now we have hundreds and hundreds of customers. And if you’re in the audience, go try it out. Love to hear your feedback on the forums. Ping us, ping me if you need to get access to a sandbox, jmp.adobe.com. I know that’s okay, not supposed to, but do I want you to try it out and test and let us know, because I think this is so completely unique because the customers then can take the budget of the upgrades of the enterprise software every couple years and invest it in you. So you with us together can build exceptional experiences. I mentioned headless, and I think we’ll hear a bit more after that. But this is one of those changes where the decoupling of the experiences into a head full. And we love that, right? Because you can have the classical backend integration work happen in the Java stack. You can go through the APS, get to the content through the headless applications and reuse content in multiple ways and multiple applications. As you heard an introduction from Cedric, it’s web experience and web screens is the other product. What did you call it, Cedric? Correct me if I’m wrong. This experience. In venue, in venue. You seem much swarver than me. Sorry. So that’s great. Jean-Michel, you talked a lot about the cloud evolution and I know we have a session on cloud too. And Cedric, he touched upon the current trend in headless. And we’ve had, AEM has had headless capabilities for quite some time. I’m curious what your thoughts are around the current uptick or increased interest around headless. Can you share your thoughts on that? Absolutely. So it was, I think a few weeks ago, I was checking on, you know, I was kind of wondering how many, like if it would, across all the customers that we’re hosting managed services or cloud service. How much are we delivering HTML pages to the CDN, if you want to call it that way. And how much are we delivering JSON files, just if you look at requests. It’s interesting that today, I don’t know exactly when we crossed the barrier, but today we’re delivering more JSON files than HTML files to that matter. So that’s interesting. So in this case, you get an argument you make, you know, it’s like when the traffic from desktop to mobile flipped, right? And suddenly there’s more mobile traffic. So basically a CMS, there’s more traffic, there’s more raw content access or API based content access, if you want to call it that way. Then HTML access today, at least for AEM, that’s the case. So I think we’re, you could call ourselves a headless CMS at this point because we’re delivering more JSON files than HTML files. So I think there’s certainly a transition that happened, not instantly, that happened over time. Gina, to your point, we over the years extended the product. And interesting, back when we shipped the first version of Sling in 2008, we had this default JSON servlet. So you could request any content as JSON, which an argument could be made. That was the first headless CMS. Anyway, talking about the future, for us, when we really saw how GraphQL took off, we were like, how did we come up with that? Well, that’s a separate story about the other thing. We can talk about any files. But GraphQL is just so great for a CMS because you have a content repository with like curated amount of content. And you got clients like apps, whatever applications you’re writing. And whoever writes that application knows what content he or she needs. So they can formulate this GraphQL query and get exactly one request back of what they need. They can do batching, ask for multiple things at the same time, whatever. GraphQL is just so amazing for a CMS. So hence what you’ve seen us doing in the last 18 months is really embracing that. Adding support to GraphQL, we’re going to add a lot more support to that. We’re going to extend it even further to what we have today in market. And for those who might have missed it, we initially launched a support, GraphQL support for content fragments on cloud service. And we just last month released the exact same code base because we have only one code base. So we shipped as part of the service pack for 6.5. So today you have, if you’re on 6.5.10 or on the laser version of cloud service, which is easy, you have access to our GraphQL capabilities that we have today. But more to come on that area because we really think for both, for the backend side of things for the CMS, but also for the delivery side of things, GraphQL is really ideal. So we’re going to definitely invest much more in that. So stay tuned for that. Or, I mean, you can play around with this right now already. We made a really good version of Ilma. That’s great. So we heard some key innovations here, cloud, headless, GraphQL. And I know we have a session later today on headless as well. So check that out. And at the end of the day, everyone that’s here listening right now wants to know that what they’re learning or investing so much of their time in, it’s going to be valuable. And these developers are actually excited and expected to come up with the latest and greatest programming languages and frameworks. From a customer point of view, the companies that use our platform have millions, if not billions of consumers interacting with the AEM developed sites every day. So of course, for the people here today, learning our technologies and tools can help tremendously. So how do we enable them to do that and even to go beyond just pure content management? Cedric, do you want to share your thoughts on this? Sure. It’s going to be a little… So I look at it as two dimensions. So when I think, how do I empower you folks and what I’m expecting you folks to learn? That’s just two things. So the vector number one is how many of the questions that we are getting as Adobe as a vendor, how much of those questions can we get rid of? So you’re not supposed to ask the question in the first place. So that’s the first kind of thing. So I give you an example, scalability. I mean, for years, the way we’ve been running our business, scalability had lots and lots of complicated questions, actually, where a lot of those, there was not really good answers either because, well, it’s our product, it’s your code. Then I don’t know, scalability is going to be up in the air, depending what you do. Now, we really changed that with cloud service, which is kind of like… So a lot of the scalability questions, you might still ask them, but the answers are a lot easier because it’s just going to scale. Don’t worry about it. It’s going to be fast. Just because we’re out of scaling, we can… I’d say a lot of the scale questions were taken out of it. So that’s vector number one. What we’re trying to do to make you successful is we’re trying to get rid of questions that you need to ask because we’re just going to solve it and it’s done. And number two is what are the skills that we’re expecting to do? And again, our stack originally Java-based, which you have seen us certainly doing over the years, we got less and less and less Java dependency. Now, while our platform is written in Java and works as well. We want to certainly make sure that you, as somebody who’s customizing or using the product, needs less and less, like Java, if I want to call it that way. And you see that with us introducing HDL, that’s still zero. And there’s more that is also going to come down the road of us doing that. And I think that comes together with the decoupling. So really the skills or I think another way of saying it, for example, we did this last year. This year, sorry. If you want to basically just use AEM as a headless CMS. You can basically get started with zero lines of code. You can go in, create your models, create a graphical queries, store them as persistent queries. You can start customizing the UI just with drag and drop the way the authoring should happen. And you can basically go end to end to a complete headless project with zero lines of AEM specific code. That’s what I mean. Right. So the same thing for site creation. We’re introducing site templates, which also allows you to basically create a new site without having to use the project archetype. And we’re really trying to architect and re-architect some of the processes. So it’s an easier learning curve to get into AEM. That’s the first place. And then also the skills are required on each of the steps. So this is not, this is a journey. We’re not done there. But you can expect a lot more in that area for us, for you folks, and make AEM more approachable, again, more easy to learn. And so I think that gives you the chance to actually focus on the fun parts instead of trying to figure out how the worst chance settings have to be configured. I’m sure they’ll appreciate having less of that work to do. So that’s great that we’re closing the gaps on some of these capabilities. And we know that developing these experiences is a two-way street. Jean-Michel, you touched on this at the intro. We can build the best and fastest technology out there. But at the end of the day, it’s a dialogue with the developers, like the people here with us today, that provides us with a competitive edge. So in my thoughts, it’s really that open line of communication that’s critical to that continued innovation. So Jean-Michel, do you agree? And is there anything you want to ask or say to them while they’re all here? Absolutely. Absolutely. It couldn’t be, I don’t know how to say this. It couldn’t be truer, right? So imagine yourself now that we are in the cloud, the velocity at which we can deliver changes and innovation to you in your hands has increased two to three hundred fold to anything and anyone who’s out there. Just because of our ability to actually try behind feature flags for some customers, if you are interested and sort of get the feedback from you in real life with real usage and get the stuff. This is fascinating. And it talks a little bit about the accelerating expectations from our customers that I said that because our customers and in the end, our end customers do want better experiences, better conversion on their experiences. And so as Cedric said, we try to get rid of as many of the stupid things that we have learned and we’ve been at it for a while. So hopefully the most ones are gone, but I’m sure we’re missed a couple. So I look for your feedback in this new world, in this new world of high velocity. And it is also of new development patterns. So, for instance, we had the GraphQL. We added the ability to actually add your headless projects, even if they weren’t initially developed there into the SPA editor. So the SPA editor, for those that don’t know, allowed the we looked at it. I remember the days when I was coding for money a couple of hours a day. And do I really want to write code to change to deal with a title text that’s too long because a business user had it? The SPA editor allowed us to actually get that back to the business users so they could see it. So I didn’t have to spin it again. And I think we integrated, we see that with the headless. So now we can bring both of these together. But we’re also seeing a decoupling, right? So you have a decoupling of the experience. It’s not server rendered anymore, but it is a client rendered. So a headless app, SPA editor to bring sort of the best of both worlds together. And then you say, okay, and what do you have for me if I’m a backend developer? Well, you know, don’t worry, that side of the hall may stand up a well. And no, you don’t. We are all in our homes. So please stay seated if you wish. But I think what we have is we’ve also innovated on decoupling those through the Adobe App Builder, what used to be called Adobe I O runtimes. So you can decouple these projects together, but still go at the velocity and leverage that you wish and leverage the common content across those projects. So there are the in venue screens that Cedric mentioned, you can leverage that content for those specific apps, you can leverage it for your own headless projects, and you can leverage it for the existing projects that are there. I think one of the things that was really important for me was you, especially that portion of you who have been working for a long time. Trust me doing a greenfield coming up with whoopity whoop, a wrap it up and not thinking about all the work you have spent with the customers out there and bringing those projects along bringing your experience along, that would have been almost too easy. So we try to do and we were called this is impossible to do to bring this into cloud and have this velocity with the knowledge that you have there. But also adding the new experiences, the new knowledge is the new patterns of doing it. And whether if we look at those capabilities, whether whichever SDK you use, right, Angular or React, or even UTS, we got an SDK for you there. So pick your favorite, we got you covered on it. I think the point here is, is that we want to bring all of you along for the ride, it would have been so easy for to go on to the green miles and forget about all the work that you do. Forget about all the work you have done, we have done, Cedric and I have done, the whole team has done, and just start over. But we it was essential for us that you have a path to come along that the projects that you’re working on, that they can work in the cloud with us and that you can add those new experiences. If you want to extend your skill set, or if you’re new to aem, and you come from that background that you can be successful with us, successful in building exceptional experiences. Now, content management, not about content management anymore, but now we have the opportunity to help you help our customers deliver exceptional experiences. Have you tried the exceptional? Have you seen or looked at the exceptional experience report in cloud manager? Again, something that you’d had to do separately, we try to bring it to you at the moment when you code into your heads, so that we together can help that you have the data and the information to pass on to the business users to together build exceptional experiences. Because exceptional experience are becoming more and more important to win the attention, the time to get the attention of the folks out there by optimizing the SEO through better experiences out there. And that report gives you, the developer, you see that you have access to it, you can use that to help the business folks understand how we can make better experiences. And I believe together, we can actually lose these experiences to make a better world. We’re just, you know, experiences. But I think as far as that goes, that’s sort of what keeps me going and gets me excited. So I think there’s a lot of things that are out there. But if you have not tried to try get your hands on a sandbox, try the project you have worked on in the past, try there, see what’s going on. The intention was that you can bring it along. We have a lot of tools for those as well. But the intention is to get what you’ve done in the past for those that have worked on a long time to use that. And for those that are new, welcome to the best experience product, at least that’s my personal humble opinion. Not so Swiss, pardon me, and, you know, out there and join us for the next couple of dozen years, I don’t know. But I think this is sort of it’s working with you getting your feedback, what we can make better, etc. So take away the pieces that you already had to ask questions, let us automate those. And I need we need your help to build the experiences for our customers to build those great exceptional experiences out there. And I invite you please give us your feedback. Because right now we’re operating at a scale where we just can’t meet up even independent of COVID. And so therefore electronic means of feedback is what we’re looking for. And we take you seriously, we’re listening, we’ve been listening for a long time. It may take us a day or two to do it. But I think our velocity has increased. And that’s so really cool. It’s increased two to 300 times to when we were on premise. And with that, Gina, maybe we already have some questions. Otherwise, I will point you to the Experience League forums. That’s a way we can engage. I think we’ll also, as you said, hear more about Headless later today, where I’d like to point you to. And so just let’s keep the feedback going, right? We’re excited to work together with you, because only together with you and us can we build exceptional experience for our customers. And that’s what’s in it for me. Yeah, perfect. And so for everyone listening here, Jean-Michel has basically just rolled out the red carpet for you and given an open invitation for you to share your thoughts and feedback with the team here at Adobe. So excellent. And thank you both for your time today. Now we have about 15 minutes left for questions. We see a couple in the chat pod. If you haven’t already, please add them to the chat now. First, we have one that says, is there a plan to discontinue on-prem AEM fixed? That one just okay. Is there a way to get a sandbox for cloud service for us to try out? Yes, there is. Don’t ask me how, because I ask internally. But if you posted to the forum or sent me a mail and I’ll figure it out for you. All right. And is there a plan to improve I18n dictionary feature? I can take that one. So, I mean, we’re going to kind of little features here, but I think just generally when I talk when we talk about the features to help with translation, which is generally with maintaining strings. The current implementation is pretty okay. One of the things that we certainly want to do there is we had a UI at some point to help manage that. And it was kind of like disconnected from the CMS. I think one thing that we definitely want to look at the way we manage these dictionaries is that they’re just regular content. They’re not that the separate thing that’s somewhere on the side. I think that’s certainly one thing that we because, you know, I mean, those might not the history there. This is actually something that we built actually for our product because we use this to translate all our product UI strings. So that’s why it’s kind of like on the side. But I think we see a demand of folks that want to use this for the content. And it’s kind of so in this case, we should actually kind of move it into the CMS instead of having it separate. But, yeah, that’s a good point. It’s only a good question there. We definitely look at we want to look at this I18n more as content versus the way it is today. OK. Another one that we have. Sure. Sorry. Do you know? OK. Another question we have is if there is any plan we have to upgrade the AM based jQuery version. Oh, I was looking at different Cedric. I’ll let you take that. I’ll take the 6x development. Yeah, sure. So the jQuery version we have today is basically mainly there because of our because of our UI dependency. We have not I don’t think right now. I mean, let’s say the plan is actually get rid of jQuery, not to not to update it. So I think that’s more of what probably was going to happen that we don’t use it or not having a dependency to jQuery at all. I mean, the reason why it’s there, it’s mostly because we have some, again, features that are relying on it. But I think most of the things that you see us doing and change that we’re doing is we’re actually removing that dependency. So I think that’s all that’s going to happen. And it’s going to take us a little bit of while to do all that. But we’re probably going to face that out. OK. And then Jean-Michel, you mentioned you’ll answer this one. Is there a plan to discontinue on prem AM 6.X development and support sometime in the near future? And I think you say no. OK. But let me elaborate why. I mean, you can always listen. They can say whatever they wish. And then it gets run over by a car tomorrow. You don’t remember, please don’t run me over with a car tomorrow. But I think that the reason what we wanted to do with cloud services, we figured out a release model in the cloud that doesn’t require upgrades. And we reflected on what can we do for our on prem and managed services customers. And what I’ve learned over time is that applying a service pack is much less arduous than sort of doing a full upgrade. And so that’s why we changed to that model as we change to the cloud service. Now, in the question there implied is also that there is an ability to there is a different level of velocity and there is a different level of ability. So, for instance, we have the image transformation service, which allows for a infinite scale on image ingest, because we’re using cloud native, which is difficult for us to make available on premise. And so there are features which inherently are more cloud native and are difficult to make available on premise. Also, that velocity, you know, think about fixes or changes when we are done with them. They actually go live and in a prerelease immediately in the cloud while they’re still being worked and quality reviewed to make it into a service pack. So there is an inherent delay on the on premise ones. But we feel if the customers, we want to make them see the cloud service and choose when they go and based if they see the value given I’m so convinced of the higher value, they’ll make the right choice will support them as long as they feel that this isn’t the right choice for them. And so therefore, you’ll have a future there. So that’s yes, we wanted to switch to an up no upgrade zero upgrade model, both for cloud and we figured a service pack. And we believe that the value in the end is going to pull the customers over, but I can’t predict when the thousands and tens of thousands of projects are ready to move over. And so therefore, I hope you help analyze what what it would mean to move over to a cloud and then work with the customers to figure out what the right timing is. And we’ll be here until the last ones decide to go. And, you know, we don’t we’ve been doing this for 20 years. So we’ve been doing is taking at it for a long period of time. Great. And are there any plans to support containerization for on prem? I can take that one. So and the answer short answer is no. And the reason why is because I mean, you have to really have to set back a little might actually be interesting. What do we do when we moved to cloud service? We didn’t just stick the quick start into a container. We actually thanks to JCR. That is kind of a good abstraction layer in our architecture. I just JCR, which is a nice abstraction architecture. We were able to rip whatever was underneath JCR kind of like away. Now we kept some things, but we removed quite a bit of stuff and rebuilt that. But we rebuilt that in a way that you can’t just run in one container and then, you know, you just stick it into another container that you’ve done. We architected that in mind because we knew that to Jean-Michel’s point just now, we are going to want we want to and is our goal. We want to host any and all of you folks in the cloud in order for us to do this efficiently. We’re going to have to, you know, not just re-architect the bottom of a.m., but another good make we may need to rip it apart in a good way. And so that’s what we did. And we’ll continue doing now. You don’t really see much of that because you get the application. Does JCR, that’s your insurance policy, if you want to say that way. And we keep innovating. So but now if I want to say, well, hey, how can I like what we built for cloud service, can I give this to you folks to run yourself? It’s actually going to be quite expensive for you to do that. Why? Because we build it in a way that we can run tens and thousands of customers on it. So you build something different if you want to run it for tens and thousands of customers and you want to be efficient versus if you want to do that just for one or two of your websites. Anyway, you go on and on and on. But that’s kind of like we architected the next version of a.m., again, the foundation of a.m., which is running in cloud service, which is again compatible from the JCR up layer. So your application sold lines in a way that we can scale that highly. And but it’s not efficient to actually just run for a few websites. So hence, it doesn’t really make too much sense for us to make that available. And actually, it would be probably pretty hard to run to just because that’s that’s the problem with cloud native applications. They’re getting like this lot more dependencies to other services. I don’t even know how many of the cloud native cloud services that we use behind the scenes to actually make a cloud service run a whole lot more of like in this case, Azure and other cloud service that we’re using to make it run. So anyway, long, long story there. But I think it’s important for you to understand that it’s not we can’t just wrap all the stuff that we did for cloud service into a container. We’ve done it would be a lot more complicated to run. And as we feel like it’s not worth the effort for you folks to do that. Hence, we’re not we’re not applying to release. Okay, let me give a couple of data points to that one. And so I think if you look at the Quick Start, you take the lines of code as a proxy for work or complexity that’s in it, and do note that I had a size check on it to control for complexity. But we reduce that by about a third to the what we call the the style line Quick Start or the Quick Start that’s in the base. And that’s sort of the reduction that Cedric play to we pull them out, but in a backward compatible way services that were backward compatible, like the image transformation that I just mentioned. But what we also did, we build all of that machinery around it. That is order of magnitude about twice as many lines of code and the Quick Start hat, to actually fully automate all the machinery around it. I have the real numbers, but I just want to give you the order of magnitude that you have there. So a third reduction, and you we actually doubled that amount of code and features that you have visibility into into the machinery that does what Cedric is referring to here, to allow us to do this at scale to actually also do regression tests after every of my engineers does a check in, but not more often than every five minutes, we actually take a copy of all the customers that are willing to participate in the program. And we run the end and plus one versions on it and we look for regressions. And so therefore we can guarantee a lowest risk or no risk to even though we have a very broad extensibility surface. So it’s a really cool engineering Marvel, slightly proud of it. Team did a good job. Try it out. Give us feedback. Wonderful. Okay, we have time for just a few more questions. So one I’ll ask here is, could you talk about the years old challenge with globally distributed authoring team, example Europe and Australia. This has been a challenge due to network latency to centralize or clustered a em instances. And from your perspective, is that solved with a em in the cloud service? And if not yet, is it a priority to improve upon it? I think I can take half of it and then I’ll give you the other half. I mean, first and foremost, it’s a hard problem. Okay, to state that. Okay. It’s, I mean, you can ask any computer science distributed databases. Good luck. Okay. Hard. Now, that aside, what are we doing? For us, it’s really, I mean, you look at our authoring UI and also capabilities, just kind of two things are happening. Well, you know, whatever, eight, 98% of them is reading, browsing around the site and doing things. So on cloud service, we did certainly a good step there, given that the CDN is always enabled and is always there. And also for authoring purposes, the CDN is always included. We’re hosting our product UI. And a lot of the things that you’re doing, we’re doing that on the CDN. So it feels very quick and fast when you use the UI. Because even though let’s say the servers in the US and US, you know, the servers in the US, you’re in Australia, you’re actually having pretty good experience. Now, what happens if you change content, because the change has to go all the way back? What happens if you upload assets, and they all have to go back? So this is where we started really be innovative. And again, using the CDN as a thing. So for example, if you’re uploading an image, let’s say you’re uploading a 500 megabyte file, giant, right, for CMS, and you’re in Australia and the servers in the US, what is happening with cloud service? The file actually doesn’t get uploaded to the server in the US, what actually happens, the file gets uploaded to the closest CDN pop, which is probably if you’re in Sydney, it’s in Sydney, so it’s very close. And it gets uploaded right away onto the Fastly, sorry, we’re using Fastly as CDN, but I’m just kind of explaining you that right, the CDN pop, whatever, it’s gonna, it gets uploaded to be concrete, it gets uploaded to the Fastly pop. And then from the Fastly pop, it gets streamed to their private network, which they have between their pops, and delivers it to the nearest pop which our servers are wherever the server is in the US, whatever. And then it gets to the server. As an end user who uploaded the 500 megabyte file, you getting the feedback that the files finished uploaded when the server when the file was reached, and the file is arrived at the pop in Sydney, versus in versus having to upload in the US. So if you’re, for example, use a traditional CMS, whatever, including managed services, and you’re uploading a file, it would maybe take you, I don’t know, like 15 minutes, whatever, 500 megabytes. You’re gonna make a much file depending on what your bandwidth is. If you do that with cloud service, it’s probably going to be 30 seconds. Or even depending what bandwidth you have at home, if you have fiber, whatever, it’s like 30 seconds or a minute. So yes, we are improving on that situation to make global authoring better. Now, we’re then we’re not going to stop there. There’s much more that we want to do there. But I do want to say there’s no syllable in distributed databases. I mean, I mean, yes. What I say engineering is a engineering is is a, is a conundrum of of trade offs. So you have to figure out what trade off you want to make. Okay. So in this case, we’re really trying to make sure we leverage the edge for as much as we can, in order to simply to not over overcomplicate our architecture, again, trade offs architecture complexity, if you really want to do multi multi multi repository, anything global. Two things. What Cedric is describing is a absolutely right. It’s sort of the engineering opposing requirements. The cool thing is with moving am in the cloud and an opposing requirement instead of keeping backward compatibility to everything that you had, which was part of it designed before cloud and how you do that. But so one of the things that we did is, for instance, replication services. In the old times, you when you install that on premise, you had to look for the infrastructure. And so you could serialize these deserialize the packets, then sort of re serialize them when they come back at the seat, serialize and deserialize. And when they come back, and you get and look at sort of the bandwidth and the trade offs and the messaging. So what we’re doing right now is we did couple that we had we are using an internal messaging service that as part of the Adobe experience platform. And we are using CDN technologies, and it actually doesn’t matter which one we we use, we abstracted that internally, as to make that process a lot more efficient. And to your earlier point, Cedric, you don’t have to worry about it anymore. Now, but to the original question, what’s the effect on distributed offering? Well, it makes it feel faster. And in the end, let me take parentheses here, how do we get at that partially it’s through the experience of leaders like Cedric on the team who are giving us feedback and seeing what’s going on and serve all of you in the audience. But do remember that the am engineering team also transitioned into a cloud native team. So we merged the role of developer, QA and operations, there is just DevOps. Now, all of us across the whole world, everybody that’s on the am team is on call, which then means that as an engineer, and somebody else asked the question, do you look at metrics? Oh, boy, do we look at metrics, the data point that I have earlier, between February within a six month period, the amount of monitors last year, this has grown again, that but I don’t have to latest it grew from 20,000 automated monitors to 100,000 automated monitors without any leader having to ask for it. And this was just the engineers that were on it, measuring all the activities and where we can optimize. And I’m giving you these order of magnitude in this cultural change. So you can get a sense we can talk about feature functionality, but you get the whole massive change that I’d like to get your feedback your interaction on it, this this acceleration of velocity required for us to have a conceptual change of how we operate as an engineering team. And so now we can put our the features behind feature flags, we can get feedback, Cedric and the PMT bring in the customers, you can give us the feedback in production, and all the other customers already have that code sitting next to you. So we know there is no impact there as well, because otherwise it wouldn’t go out. Remember our release strategy that I mentioned before, etc. So it’s a it’s a fundamental shift that’s happening, it’s not on a feature functionality basis, but across all of a EM and stuff that we can talk about here, the stuff that you can look into daily release notes. But generally, it’s just a change of culture. It’s a change in speed. It’s a change in ability to create exceptional experiences. Gina, do we have time for one more? One more. We have a question here. Hopefully it’s a quick one. Do we have a plan to introduce extensions or plugins in AM cloud service example, connected to Cosmo DB? Yeah, so not sure about the example here. But so maybe I can talk a little briefly about extensibility. So what you have seen us doing in the past is I would refer to as extensibility as a platform. So you were able to extend any and all parts of AM by going into the machinery and, and overlay things or something like that. So you see it’s going to switch more. We have some of those features already introduced. And what we’re using is what I refer to as extensibility as a feature, which means there’s particular places where we say this is a good place to extend. So there’s going to be ideally a remote API, where you can say you get a webhook where you get a callback for extending something when whatever you deploy, instead of deploying an OSGI bundle into AM to run the extensibility, it’s going to be a webhook. And you can run the code, whatever you want to 40 extensibility. So what you see is we’re going to shift to a cloud native extensibility model. If you want to say so versus the model that we have today, and we’ll keep supporting is, you know, an argument could be made an old extensibility model where you can go and fiddle with the software instead of having having a clearly defined extensibility model. So again, we’re supporting both, but we’re going to switch to the other ones because I think the other one is also more easier approachable versus kind of really, I mean, there’s there’s a lot of things that you can potentially break. And I can break if you do go and extend their product and and folks spend cycles kind of fixing this stuff. And so we want to avoid that again, we want to make it easier for you folks to achieve the goal. So I think that’s really going to change with extensibility too. Great. Thanks, Cedric. And thank you, Jean-Michel. That’s all the time we have for today. So we hope everyone had a great, we hope you all have a great second day at developers live. A couple quick points. Remember to head to the experience league to add all your questions and feedback. You’ll see the link for that in the chat. Jean-Michel and Cedric both really want to hear from you. Also, don’t forget to fill out the survey in the chat for a chance to win a backpack and learn more about our SDK offering. And we look forward to seeing all of you again next year. Thanks for joining us. Thanks Cedric and Jean-Michel. Have a great rest of the conference. Thank you. Thank you. Bye bye.