Episode Transcript
[00:00:11] Speaker A: Welcome to Arboret Digital Experiences. This is lucky number episode 13 being recorded on a Friday. I'm Tad Reeves, principal architect at Arboret Digital. I'm joined here by Marta and Michal from Streamx and we just finished the Adapt2 conference in Berlin and want to give you a overview of what that conference is all about, what we liked about it, what we learned from it, things that you can use, etc. So thank you for joining me, Marta and Michael. I. We were going to record this podcast. Maybe yesterday I was at your office in Poznan but now we're back in two separate cities, separate countries. I'm still in Berlin and you are in.
[00:00:51] Speaker B: But in the office.
[00:00:53] Speaker A: Thank you.
[00:00:54] Speaker C: Thank you for having us.
[00:00:55] Speaker A: Yeah. I'm sure your kids were glad to have you back.
[00:00:59] Speaker B: Yeah. Yeah.
[00:01:02] Speaker A: Okay, great. Well, I wanted to go into first because. So this is my first adaptive and it was not your first adaptive. You've been. You're.
[00:01:10] Speaker B: You're.
[00:01:10] Speaker A: You guys are into a few of them but this is my first one so I want. It. Was it. You've been to a few or, or just. Well, we've been.
[00:01:17] Speaker C: This was our second.
[00:01:19] Speaker A: This is your second.
[00:01:20] Speaker B: But, but Marta was a. Presented last year. Presented last year. So it's current twice.
[00:01:25] Speaker C: Yeah. Because I kind of list the. No, no, it's actually the other way around. I. This is the first one that I actually remember because, because like you know, all the stress and, and all that.
[00:01:37] Speaker A: Yeah.
[00:01:37] Speaker B: On the other hand I, I like I got all the recordings of the previous adapts too. So I feel like I've been being there together forever. Like you know, this is like when you're an IAM developer, this is actually your single source of truth. What's happening? What's.
[00:01:55] Speaker A: It's true. It's true. I've watched so many ADAPTIVE videos and so. And so. Okay. During COVID so that Adapt To I actually really wanted to go to. And then Covid happened and then so I, so I went to that one online. So I kind of feel like I participated. So that's kind of like a 0.5.
So. Yeah. So. So it's kind of like being in Adapt to. But so for everybody who doesn't know what Adapt to is is it is a it. It's pretty much like like Michael said, it's. It's the. It's pretty much the highest visibility developer centric AEM related conference. It's all developers, all tech people, zero marketing and it's just all about tech stuff that tech people, people who are implementing AEM for customers need to know. And it's mostly just developers presenting to developers. So the conferences can get pretty technical. Much more so than the more marketing centric ones that are in at Adobe Summit. Because Adobe Summit can get kind of like businessy, you know what I mean? It's just a little bit too, you know, fluff. Sometimes you feel like the conference talk was generated by chat GPT or something like that with just, you know. No, no, same script, more buzzwords and you know, like yeah, still.
[00:03:17] Speaker B: But you know, in this year there was a Shaq, Shaquille O'Neal. So it was good as well.
[00:03:24] Speaker A: No Shaquille O'Neal at Adaptive though.
[00:03:26] Speaker B: Yeah, we don't have Shakil barely.
[00:03:29] Speaker A: Yeah, yeah, yeah. I don't know what the closest thing is we have, but, but, but. So that was one of the things that I really liked about this that was, is it was all, it's basically all content. It was not, not any fluff, it was just all, it was all content.
[00:03:43] Speaker B: And I think that it's especially imported now because you know, recently it was just about the slink updates and if you are into a slink, you could actually try the, you know, the changes in the repositories, what they doing, et cetera. So it was nice to be there but you could have some sneaky peeks of what are planned to be done. But it was not so crucial to be in Adapt 2 because you could actually see that in a project. So in here it's not only about Apache Sleek, it's still about aem, but it's about experimentation, it's about Edge delivery services of course and it's about Universal Editor. So it's, it's much more and you got it in one place. So yeah, I think it's great to be there.
[00:04:32] Speaker A: And one. Oh, sorry, go ahead.
[00:04:34] Speaker C: No, no, no, I just said, I was just about to say that you get to learn from engineers and what they did on their project and they now, they are now sharing that experience and knowledge. So that's, I mean are so many problems that you usually encounter and then you have someone going on the stage saying, well I had this problem, this is how I approached it.
Here you go.
[00:04:57] Speaker A: But also you had both sides though at the conference. You have implementers and these are very high end implementers, not just implementing dinky sites, but implementing really big problems. But then at the same time you had a lot of people who were the backend engineers at Adobe busy making these features. So it wasn't like we were removed for, you know, so Far. And it was just some product marketing guy or something like that. And when you asked a question, they can't say oh well I'll have to get back to you. It was the guy who wrote it was there for the most part and it was like, oh, the reason I did it like that was like this and didn't, you know, you also worked on that. What was that? Oh yeah, well I worked on, I did that because of this. It's like straight from the source. Which I thought was really special.
[00:05:45] Speaker B: So you can say thank you in person.
[00:05:48] Speaker A: Yeah, yeah, thank you. Or you know, usually not other words. But.
[00:05:55] Speaker B: You know, I mean I see that three layers. So sometimes when you do work on your site, in your company and you work in that company, you see only the word that is like around you, around you. So one call.
So when you work in a consulting company you may see what your colleagues do, but in general they will do similar stuff to you. And you still got broader visibility, but it's still you and your colleagues. So in here you can see what other tips, what other companies so you know, other ideas, visions and everything is like different or maybe different from the way you were thinking.
[00:06:36] Speaker A: Yeah, oh totally.
[00:06:38] Speaker C: And then get to ask the questions. I mean it's, I mean the presentation and that is again just one, one piece of it because you get to interact with all those people and you get to interact with them discussing, you know, technical problems and seeing, well, they've made certain decisions, what kind of trade offs they did, why they chose this way and not the other one, what kind of use cases they had. So yeah, I think there are so many different ways of taking value out of this conference Deck.
[00:07:10] Speaker A: Yes. And the other part about that is that almost everybody's presentation, when they talked about a solution, almost everybody brought up challenges that they had. It's all because at Adobe Summit, sometimes at other, other conferences where you're trying to sell a product, you're going to bring up all the reasons why your product is great. You're not going to say oh yeah, there were challenges that you're that but each one of these implementers said, oh, so this technology, okay, let me be clear. This technology is really, really, really, really cool, but it's not perfect. And here are things that you need to be aware of, you know what I mean? Like, like Georg's talk about a bunch of these, a bunch of those talks. They said, yeah, it doesn't, it's not magic, there's still work to do, but it is cool. And here are the Cases where you should totally use this.
[00:07:57] Speaker B: So from that perspective, I really liked presentation about how they implemented Adobe.com because it's like a huge challenge to do that. And the number, I don't remember the numbers, but they're astonishing. That number of pages, number of resources, numbers of visitor sites and, and they did that on edge delivery services.
[00:08:19] Speaker C: So you, I think they have proved a certain point with that. You know, this technology may also serve.
[00:08:28] Speaker B: Large websites, but at the same time, you know the challenges now. So we know that.
[00:08:35] Speaker A: And it's, yeah, it's not, it's not, it's not perfect. It's not for everything, but it definitely is not a toy either. It's not, not just a toy because it kind of, it felt like a toy at first. The first time I heard of it, I'm like, publish a website with Google Docs. That's yeah, that's a party trick. That's not a, that's not a real tool. But this is a tool.
I mean and I, luckily I'm working with somebody right now who has been kind of a primary on adobe.com for a while. So I had a lot of the backdrop to that. So the tool that I got to present on was, was. Is one that is going to be put to use on that as well. But there's one. Before I go into presentations, there's one other point that I wanted to make about, just about ADAPT to in general is that so at Adobe Summit you've got like a really small percentage of people who are presenting like whatever, like maybe a hundred or maybe tops 200 people who actually have a presentation to give out of like 15,000 people were attending, right At ADAPT to, it's like a quarter of the people who were there were presenters.
Like, like, like most of the people you, you would run into, they probably had a presentation also in addition to being in the audience. So it was, it was really, it felt like just like a, I don't know, felt it was a very different vibe. You know, it was like everybody kind of like, oh, I really liked your thing. Oh, okay, I'm next. I'm super nervous, but here I go. Like, so, yeah, I, I really enjoyed that.
[00:10:04] Speaker B: I really think that if they closed us there, we could solve any problem in the world. Like if you think about people who.
[00:10:10] Speaker A: Can do like this, yes, there is. Well, that's the thing is that there is, there's so many people there that like sometimes in my own circles, like, I, I, you know, I'm like, okay, I can be, I'LL be an expert on this. I'll, I'll. You know. But in, in, in that circle there's so many individual experts that I know that I pretty much got the best person in the world in the room on that thing.
You know what I mean? Like there, there were some like, like you said almost any, anything could be solved with that. Like we could, we could almost like fly a rocket ship using aem.
[00:10:46] Speaker B: I think that could be the help.
[00:10:51] Speaker A: Like yeah, you know, we've been doing.
[00:10:55] Speaker B: Card their things I guess.
[00:11:00] Speaker A: All right, well, individual talks because, because I want us to go over some, some individual things that we really liked about individual talks. I think one of the ones that a lot of people had an interest on is this whole AM maybe it's going to be called 6.6 eventually, who knows but AM and JDK17. So I wanted to just kind of get the. Now the news is out now it's not just rumor or supposition because I got a whole bunch of comments after that one. That bike riding podcast that I did about six, six people going okay, okay, how do you know like who. Okay, really? Like, like what? Where's the actual like. So now that it's actually out, I can can say so, so here's the data. So sometime by the end of the year or early Q1, there's going to be a new version of AM65 that is going to run on JDK17.
There's reasons that they talked about on why that is. That's that, that Java 11, Java 8, they're on the EOL list. EOLs in the future, but at least it's going to be EOL. So we got to AIM's going to have to get off at anyway. It could just indefinitely run on 8 and 11.
There's also other upstream vulnerabilities, packages that they can't patch, et cetera. So there's reasons so they want to move to an LTS version of the JDK moving to 17 which has got support. It's got. Have regular updates and so forth.
So they haven't announced the name for it yet.
So we can't tell if it's actually really going to be AEM 6.6. The code name that they've given right now is AEM 6.5 2025 Edition, which is like a terrible code name because it's going to be 6.5.25 and then in a few months we're going to have AEM 6.5 service pack 25. So it'll be 6.5.25 also. And so we're going to have two things anyway. It'll get confusing. So hopefully they call it 6.6. I really hope they call it something beside 6. 5 20, 25 edition, because that's the worst.
[00:13:09] Speaker B: I really believe it's like a marketing decision. So should we tell the clients that they get a new version? Especially do we want them to go into cloud?
[00:13:19] Speaker A: I know, I know, but that's the thing. So if you finish this whole adapt to, there's tools for every workload, there's 6.5tools. And the people who are still using 6.5Now, it's not because they're afraid of the cloud, it's because that's the right tool for the job.
You know what I mean? It's same with cloud service. Like the people are on cloud service. I mean some people are on it because they were afraid that they were supposed to move, but other people, it's because it's the right tool for the job and edge delivery. Now there's, there's sites where that's the right tool for the job. So.
[00:13:57] Speaker B: Yeah. So why, why Java 17, not 21?
[00:14:01] Speaker A: Well, so they, they said they're still trying to make it work with 21. They said 20 because 21 has only. I mean, when was that released? It was, that was last year that it came out, right?
[00:14:09] Speaker B: Yeah, it's pretty fresh last year.
[00:14:11] Speaker A: Yeah, it's pretty fresh. So, so, so getting Slang and Oak to work on JDK 21, I think they're. I think the eventual plan is to make cloud service run on 21. But they're still working on that, is what they said.
[00:14:23] Speaker B: Yeah, I mean, you know, when you think about bumping up Java version, it's pretty simple when you got a single repository project and you can just change it, run tests and okay, maybe do some small tests and okay, it runs. But when you think about a product that is like 357, I guess, repositories in Slink only.
[00:14:48] Speaker A: Yes.
[00:14:49] Speaker B: And you got thousands or tens of thousands of customers using it all around the world and you need to be sure that it doesn't break anything.
[00:14:57] Speaker A: Right?
[00:14:58] Speaker B: Yeah, they mentioned that they want to go step by step, so 11 to 17 and then from 17 to 21 eventually.
[00:15:05] Speaker A: Right, right.
And they said too that, yeah, their plan was to get cloud Service running on 21. But I mean there's so many people who went to cloud service assuming that there's never going to be. Because one of the selling points of cloud service is no big Jumps.
[00:15:24] Speaker B: Yeah.
[00:15:24] Speaker A: And no big upgrade projects. Right. And so if you give somebody a big upgrade project, you're basically breaking the sales contract that you made with them when, when you sold them the service. So. So it has to not be a big jump, it has to be a pretty. I mean, it's not gonna be perfect, but it has to be pretty small in terms of the lift, the developer lift, to get people onto 21. Okay.
[00:15:47] Speaker B: I think also it's because of the pace. So when you upgrade 6.5, everyone can do it in their own pace. And with AM as a cloud service, they push the updates to all of the repositories at once. So they need to know upfront that every single customer won't have any problems with that. So that's probably a challenge.
[00:16:10] Speaker A: Yeah, I'm sure that's a. Yeah, I mean, they can probably, there's probably ways that they can do staged rollouts and so forth or early access customers or something. Like, you've got a simple site, can you do it first? Yours is a more complex case. Can you put your stage environment on, or can we run your code on this thing to make sure it works and things like that.
But evidently they're saying it's going to be faster.
I mean, because, I mean, you got speed enhancements natively really, in the jdk, so.
And the procedure to get there. Evidently also you're going to have. Oh, oh, oh. The other that they were talking about is that they're going to have both WAR and JAR versions of it released. So, I mean, I don't know who does this anymore.
[00:17:00] Speaker B: War, exactly.
[00:17:02] Speaker A: Who is.
What is this type of person that is going to run AM on tomcat?
[00:17:12] Speaker B: There are clusters because they got the data. If anyone knows about it, they know it.
[00:17:17] Speaker A: Yeah, yeah. So, yeah, I'm only.
[00:17:22] Speaker B: You know, it gives you the perspective that it's like, you know, when you think about library, it can be easily upgraded, but, you know, there are people still using tomcat to run IAM so or Web is gear. Right, right. So think about how backward compatible it has to be and how many, you know, checks has to be done before really upgrading to Java 17.
[00:17:44] Speaker A: That's right.
[00:17:46] Speaker B: So from the other end, sir, and.
[00:17:49] Speaker C: I think that there was one thing that you mentioned is that there was an announcement about this beta program or something. Right. For the. If you want to register interest into trying out that with your customer.
[00:18:06] Speaker A: That's right. And they shared it. They shared a link and I got a. I, I saved it.
[00:18:10] Speaker B: Someone shared a link.
[00:18:13] Speaker A: It was in There it was in there. But there was. They. I think we may have to wait for the slides because I mean I took a picture of it. They had a QR code. So. But yeah, but there's. So, but they're going to have a new pattern detector for. Specifically for this upgrade because they, because you know. Yeah, the old pattern detector that we've been using forever, you know, but obviously there's going to be things that they're going to bring up on this that are like oh yeah, you shouldn't do this, this is going to explode if you try to put this one on the 652025 edition.
[00:18:45] Speaker C: Let me just put down the shades because it's.
[00:18:48] Speaker A: Yeah, it looks. Yeah, you get sunset route.
[00:18:50] Speaker B: I already know because. Yeah, exactly.
[00:18:53] Speaker C: I tried to reposition myself.
[00:18:57] Speaker B: I succeeded. But actually the sun is moving and we get the window just over right here. Yeah, no, yeah, no we are, we're just moving slowly. I don't know.
[00:19:06] Speaker A: It, it, it looked beautiful. Yeah.
But yeah, they, they said they're going to have two different mechanisms for getting onto the new version which is going to be an upgrade or a side grade. So you can basically you, you can do an in place upgrade for, for folks that, that, that's the right idea or to, to, to have kind of an oak upgrade style upgrade process similar to like a 64 to 65 migration. So it seems like it's going to be straightforward but can't wait to get my hands on it.
[00:19:39] Speaker B: Yeah. So I think that what's interesting for people is that AEM will be maintenance for a long, long time and so Adobe is prepared to run that for a lot of customers. Even on prem. Right. Yes. So not everyone is moving to the cloud and even though there was not so many innovations around Sling, like most of the innovations I would say was around Edge delivery service or the universal editor or experimentation. We'll get to that. I guess so. Yeah. It's like AEM is like a feature ready product. Yes. Yeah. Especially prime and it's actively maintained. It actually get fixes and it's not moving anywhere.
[00:20:32] Speaker A: That's right. And I think that this is probably.
There's been all this like rumor around is Adobe really going to get rid of this?
Is it going away? Are you serious that it's not deprecated. But if you just take just that datum about oh yeah, this is going to support, you know, Jetty or Tomcat and Websphere. Like if you just look at that, like look at the customers that Adobe has to continue to support. On this. This is for the customers that are still running their own 6 5. They're going to be running this for a while. And so this is a pretty. It's got its set of use cases and it's going to be around for a bit.
Yes. So what other, what other ones? I brought this one up. What were some of your other favorite talks? There's, I mean we were three packed days. Those were very packed days of talks and they were all interesting. What's. What, what was one of the other ones that, that you guys found interesting?
[00:21:34] Speaker C: Well, for me one of the, one of the most interesting ones were this by g about moving 40 terabytes of assets from one place to the other. Well where the other place was AM assets and one place was some legacy built in house platform and it locked how Georg told his story because. Well, it was.
He gave everything in terms that. Well, I had this problem. There were, you know, those challenges that we had with our approach. I actually had a pretty decent approach but well, it wasn't the right one. Finally then he showed us the approach that he took.
Showed the comparison between, you know, how it might be done and then how it actually was done and showed the numbers afterwards.
[00:22:31] Speaker B: So like reasoning. It was like conceptual approach. Not only here is a code look, but you know, you will be in that position, you will have that problem. If not that, you will have a similar problem. So how can you give the best possible solution? And I like the Excel sheet like.
[00:22:52] Speaker C: Everyone that's actually super interesting because you know, you have, well, you run an experiment, okay, that's for this sample of data. This will be that long, let's say. Well, but we have so much more data so let's extrapolate on that. Well, okay, that seems to be 60 something days. We're not going to do that like that.
[00:23:12] Speaker A: Right.
[00:23:14] Speaker B: I mean especially with a customer you need to talk. It's nice to talk about opinions, but.
[00:23:21] Speaker C: Sometimes you just need to have hard data. Well, you know, with the constraints that we have. Well, with the fact that you'll need to freeze code or freeze content production or something else. Well, we can't do it that long. So let's think about some creative ways of doing it differently.
[00:23:36] Speaker A: Yeah, because we have something like that. When you have a massive assets repository like that, you can't, you can't do one migration which is, which is part of the problem that he was trying to solve. Right. You have to do it more than one time. So. And the problem he's trying to solve also is how Do I get the entire thing over in a weekend basically. And all 40 terabytes. There's other problems like cloud service recycles those instances every day. And so you have to be able to know that any one of these big, you know, 700 gigabyte single assets could, you know, while you're transferring it over the instance you're transferring it to could die.
So and be recycled. So it has to be resilient to that. So that was just a fascinating set of just really just like so many of our problems that we try to all solve as consultants. We're like, well, my way. And I think it's really nice. But you have a way that when it's hard numbers like that it's like, okay, we have a way. That's right. It's a good way. It'll take 20 days to do this. And then if we do it this way, I ran the numbers. This will take six days. That's longer than one weekend in my country.
And then so. And then this way only takes two and a half days. And that's the best, you know. But it's this and it, but it's complicated in this way. But yeah, it's.
[00:24:58] Speaker B: Yeah, but still the approach was to do a continuous migrations like they were migrating deltas as well so people could still use the old system and you know, after they disabled it after some time, I guess so even if you forgot that all the data was mitrated and you still used your old system, that data was eventually moved to a new one. So yeah, that was fascinating.
[00:25:27] Speaker A: He had a couple of quotes that I thought were like these zinger quotes. I'm like, oh, I'm going to use that quote later on.
The purpose built platforms tend to age quicker than products. That was one of those. That was a great quote. I liked it.
[00:25:46] Speaker C: Yeah, it will be used quite often, I guess.
[00:25:49] Speaker A: Yeah, I'm stealing that. And the other, the other one which I'm like I had never really thought of all the way. But it's true is that he's like migration code is always throwaway code.
[00:25:59] Speaker B: Yeah, that's true. I also noticed that in fact you're right. I meant I will use it once.
We don't need to spend days in, I don't know, like making sure that the name of the variable is just perfect because there will be like thousands of engineers looking at it and thinking why he made that name like that. I mean just throw away. So don't.
[00:26:24] Speaker A: That's right. Or, or does it need to be the most Elegant solution, you know, like, does it work? You're going to use it this time and then throw it away?
[00:26:33] Speaker B: Yeah. And you are the only one who is going to use it. So it's not like a product that will be distributed to thousands of people.
[00:26:39] Speaker A: That's right. You're not going to say, yeah, yeah, it's not going to be your, your like open source side side project that you brand later. Like you know Tad's migration script, you know, come check it out. Like it's. No, it's gone now. But he also talked about. And there was, there were. He, he led into it and then there was another talk afterwards about dynamic media with Open API, which I was really interested in that because that was one of these ones that was announced at Adobe Summit and I was like, I can't wait until somebody really, really tries to use this. And like tell me if it's any good because it sounds cool that you could use like basically with an API you just, you just, you upload everything because like I've always had this idea that you could use AM assets and make sure you stick everything in there. And it's. Once it's there you can use it anywhere, any site, any. Like you're sending emails, you got your websites, non AEM websites, you could just use it wherever you want. And that was always the dream. But you know, like do you ever implement with connected assets? No. Do you remember that?
It was terrible.
[00:27:52] Speaker B: I haven't, but I believe you.
[00:27:55] Speaker A: Yeah, you'd upload it and it would make a copy on any other AEM system would actually physically copy the assets out to all the publishers. So any assets you have, you need like 10 times as much storage because you're copying it out.
[00:28:10] Speaker B: Yeah, yeah, I did.
[00:28:12] Speaker A: Yeah. But, but yeah, so, but I mean it didn't work on everything. Like for example, the OpenAPI doesn't support smart crop on video. So if you use smart graph on video, like if you're, if you're using it to serve your like you know, YouTube and then your TikTok ones or whatever like it. That doesn't work so.
[00:28:33] Speaker B: But doesn't support kts probably. Right. Was that, is that it's not yet supported?
[00:28:40] Speaker A: Because yeah, it's not supported yet. Yeah, I mean who knows, that might be right around the corner. But yeah, no, that was a great talk. Another one of my favorite talks was the, the Open Telemetry talk for AIM as a cloud service. I love that because I love like you've showed me your stats stuff on Stream X And it's like super cool that you can get into like all this, you know, nuts and bolts of exactly what's happening. And I always hated when just, even the idea that just somebody else is watching cloud service. And I don't need to worry about it because it's like, it's like Google Docs. Like you don't, I don't know what the stat, the backend telemetry is on Google Docs, but I just, I just use it. The idea that cloud services like that is always, it's just wrong because you need to know what's actually happening. You need to be able to debug it.
[00:29:34] Speaker B: I mean, because you are an engineer that changes the internals, you do not change the bundles within the, you know, Microsoft that do something with the documents. I mean, that's right. This is what you do exactly with iem. So IEM is a distribution together with your codec.
[00:29:55] Speaker A: Yeah.
[00:29:55] Speaker B: So, okay, you don't need to monitor oak. We can trust that it's done and it's implemented and working and someone else is monitoring that. But if you are the one that implement a service, you need to make sure, I mean, no one else will take care of it. Like you need to be able to observe it, to find issues to react.
You will be the one that is cold in the middle of the night when it's blow.
[00:30:24] Speaker A: Yeah, yeah. And the Adobe engineer who's on the job, all he'll be able to do or he or she will be able to do is just say, apparently after you deployed that it started breaking.
But then now you need to find out why. You need to say, oh well, this is, this is where this started climbing or whatever it was. You need to be able to get in there and with nuts and bolts.
[00:30:48] Speaker B: So in general, I liked two things about that presentation.
The problems that they solved that gave observability to AAM instances is one. But it was very informative. Like they give you introduction what is open telemetry? Sorry.
In general with monolithic systems, it's not a problem to see if you get access to the Linux box and you can do the memory dump, you can check the stack traces, you can use JMX to connect to the Java or you can even connect your debugger. If you are in a control of a process, you can do editing. Especially that historically it was a single machine. Like, you know, we got single AM outer, you got two or three publishers and you could physically, you know, the URL address or IP address of that machine, you could physically log in there and check what's happening. Yeah, so opentelemetry, just for the couple, is, is a protocol that is vendor, not protocol, but a tooling edit protocol that is vendor neutral that allows you to collect telemetric data. And those data are metrics, traces or locks. So yes. So metrics are what you can see in for example, Grafana. So yeah, charts, et cetera, CPU memory usage, disk usage, or your custom metrics.
Logs are the logs, of course, but you don't have access to it. I mean now you can call Explanat, I guess, but you can connect Splunk.
[00:32:37] Speaker A: But what the person giving the presentation was noting is that so on cloud service what happens is like you've got all of the services together that are in their kubernetes cluster and they're logging to Splunk. They log to a backend service that ends up getting pushed eventually to you. There might. And those are chunked and sent over. So it's chunked and delayed. So when you're sitting there telling, because you're like, okay, my hypothesis is when somebody hits this page, then memory probably spikes because this is happening. So let's tail it when it's happening. So you try to tail it on Splunk or something like that and you're waiting for 30 seconds, for 45 seconds and then, and then 10,000 lines come over and you're like, okay, was that my request? Was that the 50 other requests? You don't, you don't know and you don't know even if it was the same machine like you were saying, it could be because you're getting it with all these other machines too. So you didn't because you don't know what machine you just hit.
[00:33:41] Speaker B: We have hit that too, so maybe getting that. I'm a real advocate of the real time data processing and not much loading, loading experts, etc.
[00:33:51] Speaker A: Yeah.
[00:33:52] Speaker B: So the last part, just to close the previous, there are traces. Like we got lots, we got metrics and we got traces. And traces are when, for example, customer make a request, it goes through cdn, then dispatcher publishers and when it's on the publisher, it can go down to the sling servlet and can run your components. So what they did, they sent everything. I guess using code telemetry. It doesn't matter what tool you use to visualize the metrics or to collect them. I mean OpenTelemetry is collecting them and then exports to the tool of your choice. It can be eurelic. They use a datadog and these data.
[00:34:33] Speaker A: Of course Datadog would love you to use it because think of all those metrics. I mean, Datadog, you might plug that in. That's tens of thousands of dollars per day for Datadog. Of course it works on data.
[00:34:44] Speaker B: Yeah, I will get back to. It was actually my question. So what was cool about it that they gave a demo that when you get an exception, you can actually correlate a trace. So the user request with an exception in lock locks with the exact moment and the path that the request was going to to reach that point. So which services was it cached? Was it not cash? Was it? I mean, there was a couple of things still to be done, I guess. One thing is that what you say if you got like millions of visitors, you probably do not want to store every trace in a system.
[00:35:20] Speaker A: Yeah, it'll be way too expensive.
[00:35:23] Speaker B: I mean, if you're not the one who is paying still, there's a better.
[00:35:28] Speaker C: Way to spend that money.
[00:35:29] Speaker B: Yeah, I mean, so there is possibility to sample traces. Like if you got millions visitors, you can just collect 1%. It will be just good enough for you to know if there are any errors or not. Because if you got like millions users, one exception is not a problem. When you got like 20% of requests with an exception, that's a problem.
So there is that sampling that can make you some savings by not spending all the. Sending all the telemetry data to datadogs. That's just in a response of that.
[00:36:06] Speaker A: Yeah, totally. And. But at least having that available because that's. Because what the presenter was bringing up is that if you just have, like, if you've got regular AEM on premise and you're running New Relic. Right. Because cloud service also comes with new Relic. But if you're running it yourself, you can do all that distributed tracing yourself. You get all the logs yourself, you get all the, you can get CPU and all that kind of stuff. You get it all yourself. And it's not delayed because you run the platform. You've got the Java Agent plugged into that AIM environment, so you've got the whole thing. You can't plug your own Java Agent into this. You have to use the new Relic that Adobe provides and it's hamstrung. It's like, it's, it's, it's a, it's, you know, it's kind of partial New relic. It's, it's not, it's not the whole thing. So it's definitely much more limited.
[00:37:01] Speaker B: Yeah. So I think that in a demo they share Their repository with the project that you can use actually and upload and they do send those traces logs and metrics. I guess I haven't seen metrics there to the data Using. Not Java Agent but a regular open telemetry client.
[00:37:21] Speaker A: That's right.
[00:37:22] Speaker B: And I was using open telemetry collectors to fetch that. Yeah, that was super cool. I mean definitely. And getting back to that, it's like a monolithic systems. The IAM instance that runs on a single box for physical address and it runs there for 10 years. We all know clients that uses that. And this is like a. It's got a.
[00:37:46] Speaker A: It's got a name, it's called, you know, I'm going to log into Pete or whatever its name is, you know.
[00:37:52] Speaker B: Yeah.
[00:37:53] Speaker A: And okay, good.
[00:37:55] Speaker B: Like the patch, right? Yeah, that's right. And really care that it's got an app memory and it's bad with a cpu.
[00:38:04] Speaker A: That's right.
[00:38:05] Speaker B: And we can even check. Okay. From app to time. Yeah. So it's age. So the whole process. So it's completely different in a cloud when you got kubernetes like you said and you got pods and those pods can be down anytime and if something is wrong with the pod you just kill it and the new pod will screen off. So you cannot just.
[00:38:26] Speaker A: Which can hide problems too. So. Because when they're being recycled all the time you're like, you know, is for 50% of the day are they unacceptable? But you just always. Because they get recycled all the time, you just don't know like.
[00:38:42] Speaker B: Yeah, exactly. I mean that's why in distributed systems observability is the key. Like, and to do it right, it's like a lot of effort but at the end it's not something that you sell while selling a product. But.
But when you are in trouble, it's something that saves you and your customer. So definitely, if anyone is watching that, go to that presentation, check that cool open telemetry stuff and go to the repository, check it by yourself. Because it should be a standard and I feel everyone should know that how to do that.
[00:39:25] Speaker A: Absolutely. Now another part of working on the cloud service, or I mean any cloud service, but specifically on AAM cloud service, a challenge has been the difference between a local development environment and deploying into the cloud. It's because you get all these dev environments and they act differently than your local. And so Adobe's solution for that was these rapid development environments which are in the cloud, but they're kind of a hybrid between cloud and your local. Like they're Both running kind of TAR mk. They're not running, so they're not running a Mongo author. So you can push things into it whenever you want to. There's a bunch of things that were advances and enhancements that were made to RD environments that were talked about at Adapt to.
There's a new AIO endpoint for, or command for getting RDE logs in real time because the RDE logs used to be chunked and so forth, just like the ones out of production. So when you're trying to use it like a dev environment, you're like, wow, why is my thing broken?
It was the same problem, basically. Now you run the command and it basically spits the logs out in real time. You're hooked right into it and it's just tailing them right to the console, which is really nice.
But also one of the challenges before too is that. So you spin up these RD environments in the cloud, they're blank. And so you have to go and deploy all your code to it. And now you finally got it set up because it doesn't have pipelines, so you're just basically running commands to deploy your code straight into it, but it's still blank.
And so you got to copy all of your content from production or whatever down onto it. And you're like, good, now it runs like production, but then if there's another update, like a version update, which happens every month, you have to do the whole thing again.
So now they've got a functionality for resetting the AM application without blowing away all the content and then also to allow snapshot restore points for your rd. So let's just say you're doing something where it's doing a bunch of destructive, potentially destructive changes. You're trying to test that before you go to dev, then you can do that and then hit the restore point. Say, oh, I totally, I totally bricked it, basically. Okay, good. Let. You could go back to a restore point.
[00:41:49] Speaker B: So does it happen on the data and the code level? So if you.
[00:41:54] Speaker A: Yeah, well, because already you've got, you've. You've got the mutable and immutable parts of the repo, which is the same for this, except for it's different in that while the machine is running because it's this RD environment, not the way that it is in the cloud. You can push code into it while it's hot. So it's kind of like this in between lives thing.
And. But then also, yeah, so. So yeah, I, I haven't worked with that yet. That particular bit because if, but anyway I'm it, it. It potentially is going to solve problems like that. Like if you had enough money. Well, this is the other thing too is that. So you get 1rd environment when you get cloud service and if you want more, you got to pay. And so people are like, oh, why do I got to pay? It's always already so expensive. Why do I got to pay? Well, you know what also is expensive is, is all the tooling to set up local environments. That's also expensive.
[00:42:51] Speaker B: And try to give the most expensive is the engineering time.
[00:42:55] Speaker A: Yeah.
[00:42:56] Speaker B: So you want to make them up and running and solve problems and having back on production that cannot be resolved because someone cannot reproduce that on its environment. This is costly. So I believe that yeah, RD should be cheaper for sure. We offer that. But when you compare being able to fix, you don't have to use rds.
This is an option, you can spin off another one and just use it. So yeah, I think it's good to have an option. Regarding your snapshots, I Remember workspace, sorry VMware workspace. You got that button, take a step. So you do whatever you want and you couldn't break it because you got rested. In a couple of seconds I can start.
[00:43:45] Speaker A: I see all these awful looking errors. You're like, yeah, that's right, give me more life.
But another one too. That was a neat use case of this. So, so Quentin and Marius gave their whole talk on the managed cdn, which, which, that was one of my bike riding podcasts, talk about managed cdn, because I got to use that on, on, on one of my clients. And it's really, it's fun.
But one of the things that is a little bit challenging with it is that you always have to like the only place you can test your CDN configurations is with the cdn.
[00:44:27] Speaker C: Yes.
[00:44:28] Speaker A: You know, is there any way to do it without a cdn? Well then it's not the cdn, but, but, but to push it straight into the RD environment, you can basically have just run the config pipeline, you know, just immediately like that. So, so you could basically, you're basically running. It takes like 30 seconds or something like that. So I mean that's pretty easy way to just iterate and just say, oh, oh, my syntax is a little wrong. Oh, whoops, my YAML, you know, is busted. Okay, fine. And then. And get it done. So it's about as close as you get to local development for a cdn, which is also kind of cool.
[00:45:04] Speaker B: I think that, I mean, if you Think about undiscovered problems that happen in production. Most of them happens because the production environment is different than the lower environment. And I'm not even saying about situations when someone, you know, uploads the code directly to production environment without we skipping or they even don't have a lower environment.
[00:45:29] Speaker A: We won't talk about that.
[00:45:34] Speaker B: It happens. But there are things like okay, we got the same set of bundles or more or less the same. I mean experience that deltas that, let's patch it directly on production and someone else in the future will worry about that. But the CDN was always a problem. You could test your AEM publisher dispatcher setup locally, but then you deploy your code and it happens that one user read the session. Not the session, but the content of logged in user, then another user. Right. Because it was cached on the layer that he didn't have locally. So I think it's crucial to being able to replicate the state of the production environment also in lower level environments. Because production cannot be the first environment that you can test.
[00:46:25] Speaker A: That's right.
Especially since so, so one of the pieces of functionality with, with the managed CDN is you can programmatically set set environment variables and a lot of times those environment variables are needed to be able to control things like your logged in user experience. So, so it's, it's as much critical functionality. It's not just you know, oh, I want, you know, longer cache lifetime or something like that. It's actually functionally changing the behavior of the application and you need to be able to test that way like as early as you possibly can and iterate on it as early as you possibly can.
[00:47:03] Speaker B: So that's, so you said that you can inject an environment or variables into the configs, right? Yeah. So probably you can just inject your domain name and have everything else just similar for staging and pro. Yes, I just replaced the part that is checking.
[00:47:23] Speaker A: Yep.
Yeah, yeah. Which would be. Yeah, that's, that's, that's super cool. So anyway, excited there.
The other thing, the.
What do they call them, those experts sessions were also amazing.
[00:47:42] Speaker C: Yeah. Did you mean the lightning thoughts or.
[00:47:44] Speaker A: The panel discussion was three different ones? We had, we had the lightning talks, we had the panel discussion which you, you wanted to bring something up on.
[00:47:53] Speaker C: Yeah, well, right, okay. Yeah, I, I mean I, I really enjoyed the panel session. I mean the, the fact that they took the questions from the audience and in that audience you had plenty of people that work with am, as in, you know, hardcore Java developers that learned AEM and the entire first day was mainly about edge delivery services. So that there was this kind of difference between, well, my experience or not my experience, but attendees experience and what was talked about. So I do feel like them responding to all those questions was super cool. And it also gave us insight into, you know, what is the priorities that they're looking at. And one of the, I think one of the things that I remember most is that, you know the use of front end frameworks. How like. Yes, I think Lars pointed it out that you know, it so much depends on how long a user will interact with given experience because, well, there is an overhead of using front end frameworks.
[00:49:09] Speaker A: Right.
[00:49:09] Speaker C: So if you have someone using a car configurator, well, that's a point where you well want that experience to be, you know, super cool so that all that leather can be chosen and all that. But that lasts for like 10 minutes. But you don't necessarily want to. And for that experience a user can wait a little bit, but you don't really want them to wait when you're loading a landing page or your, you know, homepage or whatever. So they're ruthlessly prioritizing performance and you know, that's.
And the front end frameworks now have a slightly different place in all that.
[00:49:49] Speaker A: They have a different place. But I loved, I mean it's so practical when you get to ask questions like that and then just say here's a practical, here's a practical problem. But like the example of the car configurator, you've got a user that will probably be interacting with your page nonstop for 10 minutes on that one user session. So yes, of course you want that like you said that particular experience to be exactly the one that you want so that they do actually interact with it for 10 minutes.
But the first page load, you want to be fast.
So they're not actually talking about doing things for some nonsensical reason, you know what I mean? Like just because it's. That it's the way that they wanted to go. It was, it's nice to see him, to see all the engineering reasons for it.
[00:50:36] Speaker B: Yeah, I think the exact question was like, why should I use edge delivery service, not some front end framework with this bucket. Right.
And I think there is more to that. Like the performance, I mean that was great. Like you want the fast performance, use edge delivery service. If you want a car configurator, use Angular. And actually that plays well.
[00:51:02] Speaker C: I mean that goes back very well with, you know, there is a tool. Well, there is a Problem. There's a tool and don't use the one tool for everything.
[00:51:11] Speaker B: Yes. So even before edge delivery service there was something like single page application, which is an application and there is, there are content pages that should be about content and most probably HTML pages. So for example, in airlines your booking or Fairfinder pages would act more like an application because you need to have those calendars choose tickets, prices, seats, etc. So this is a spa. So this is great for angular React.
When the blog pages or the corporate pages, text and images. You don't need to have angular or react there, you need to have performance. Good lighthouse scoring. Especially that most of the content comes from that pages. Right. I mean if you want to Google to index you and to position you, you're looking for landing pages and content heavy pages and yeah, all that stuff.
[00:52:17] Speaker C: They should be performant.
[00:52:19] Speaker B: So yeah, so it doesn't have to be static HTML. It still can, but it doesn't have to be.
It can be, but it shouldn't be angular react because then you put additional layers on top of your site and if it doesn't have to, you know, have a lot of logic, moving parts, etc. Just yeah, use something performance. But there's more like, I think you mentioned that, like who's the, who's the person deciding to use angular react and who's the person deciding that we should go with edge delivery service? Right?
[00:52:57] Speaker A: Yeah.
And should, yeah, should every single page be done with it? Because when you see some of these conversations about how to SEO an spa, like how do you do search engine optimization on an application? And you're, and you kind of get into these like, it's almost like, okay, so if I've got, if I've got a cordless hacksaw, I mean, but what if I need to hit a nail into the wall with my cordless hacksaw? Like, what do I like? Do I like. No, it's the wrong tool. Use a different tool for that. Right. Ed.
So I feel like it's very similar though for a lot of these things. And, and, but with, with the tools that we have available right now and the ways to stitch them together, I, I don't feel like there's any need to be defensive or, or anything about, about any of these tools because they just, they have their purpose and there's, there is a supported really and a lot of times a very elegant way of making them all work together. Yeah.
[00:54:00] Speaker B: Yeah. I saw a blog post like 2 weeks ago maybe and it was about like, if you talk with people who are integrating stuff, they would solve everything using ESB like mulesoft. Right. If you talk people who did one or two or three sites on the front end, if using elasticsearch as a bucket, they will tell you to index everything. Just throw it in an index and it will work.
If you look, I mean if you talk about cloud native advocates, just use cloud functions and it will solve all of the issues. We'll cache it on CDN cloud functions super fast and it, you know. Yeah, so let's not be that guys that telling that. I mean we were, I guess, you know how many decisions around aem, especially traditional AEM was wrongly made only because we are the per people knowing aem.
[00:55:00] Speaker A: That's right.
[00:55:02] Speaker C: You would use AEM for all the wrong things.
[00:55:05] Speaker B: I mean it's.
[00:55:05] Speaker A: Yeah, yeah, yeah.
[00:55:06] Speaker B: Like so, so, so AEM is great for content authoring, publishing. It gets certain advantages over edge delivery services especially when you need like approval processes. When you got, when you need strict content structure or more or less strict. We want to maintain the content for a long time then you need to have a proper repository. You need to have granular access culture rules, you need to have workflows, approvals and all of that. Right.
But yeah, there is a tool and every tool got it proposed and I think with delivery services we got one more tool in our toolbox.
[00:55:49] Speaker A: That's right. That's right. And I thought, I thought that. So I guess if I'm gonna, if I, if I have a minute or two to bring up one more. One last talk. I think it kind of summed up some of that too. Is there, there's a lot of. So one of the, one of the new tools in the toolbox is the new universal editor in aem. And that's. I mean universal is a strong word because it's not actually universal. Like you can't, I can't edit my close using that. So it's not really universal. But the, but that the fact is that, that there are, there are ways now of structuring a project so that if you want to have things some, some stuff in AM yet some stuff that you edit with universal editor and that that makes the most sense because you have a lot of content governance that you're trying to put into it and say good, yep, this, the editors, they can do this, this and this and absolutely nothing else. And this is going to be stored and I'm going to control my permissions very granularly because I'm going to say that this set of Content editors can only do these things and that's that. And it's, it's totally the right tool for that. There are other, other parts, maybe even of the same exact website, the same domain where it's like, oh, we're prioritizing speed here. We want, we want people to be able to just take one copy paste, get it up there and where a document based edge delivery type setup is just perfect for that because you can just take it a whole document edge. For somebody who knows any kind of document, they're, they're throwing things together. You can have the same code base run both of these things right now. You can have, you can have your am, you can have your assets, you can have your edge delivery, you can have all of it and nobody needs to fight.
You know what I mean?
[00:57:24] Speaker B: It's like, you know, Adobe is the most composable company in the world because if they, if they stack, they got like, how many CMSs do they got? They got AM, of course, which is the king. They got the document based authoring, which is a young prince.
That was actually a pretty interesting presentation about Dark Alley.
[00:57:51] Speaker A: Yeah, some guy made that presentation.
[00:57:55] Speaker C: I mean you could see all those people collaborating on that content all at the same time and didn't break.
[00:58:02] Speaker B: Yeah, actually, yeah, he was crazy enough to invite 200 people to go into an editor and they were editing at the same time. Right.
[00:58:11] Speaker A: Even got our Adobe folks who worked.
So yeah, so just a little background. So just because I don't know, eventually this video will be up there and we'll be able to show people it. But so I get your presentation on this document authoring and one of the features of this, in addition to all its other features is that you can collaboratively edit.
And we had always used that to have maybe two to five people looking at something at the same time. And theoretically it's very resilient. So you could have many more looking at that at the same time. And so we just said, you know what, be crazy. What if we ask everybody in the audience to edit this document at the same time? And so yeah, it didn't light on fire. That was amazing. Know the little icons all the way across the screen of all the people editing it at the same time. But yeah, that was, that was good. Shows. Yeah, it's a, it's a tool, it works.
But yeah, yes.
[00:59:07] Speaker B: Actually there was one more talk that I really like and it was.
You like it too?
[00:59:16] Speaker C: Oh, the one, the one from bmo.
[00:59:20] Speaker A: Yes, yes, yes, that was good.
[00:59:23] Speaker B: I mean, what they did they actually implemented static site generator on AWS and.
No, driven through. A key part is that they can do a release 10 times. 10 deployments a day. 10 deployments a day, yeah.
But then they describe how they build that architecture. It was very cloud native like AEM as a content source and then a lot of logic using lambdas. So cloud functions, CDN heavily utilized and they would put that content on a stream as free.
[01:00:04] Speaker A: Yeah.
[01:00:05] Speaker B: And even real architecture to actually connect all those things. So it was refreshing in a way that it was a little bit different from what you usually see. But when I was looking at it, I knew that there are people who can close their laptops at 4pm and go home and no one is like.
[01:00:31] Speaker C: Because that is a resilient and very scalable solution. I mean it can handle loads and loads of traffic and you're not relying on AEM runtime to respond to that.
[01:00:45] Speaker B: Yes. So we still get back to that previous conversation, like that one with the open telemetry. I mean time flies. You know, 20 years ago we used to rely on Tomcat on application servers, Whip sphere, maybe monolithic applications that run on a single machine. And when you wanted to scale it, you just add more CPU or ram. That's right.
So a one step forward because you got publishers that you can distribute the content to multiple machines. But still at the core, this monolithic application that can break if you put enough load. If you use search a little bit too much, it gets out of memory or out of processes or anything. So with that solution we got cloud right now and we can use cdn, we can use cloud functions, we can use containers, kubernetes and actually get much more resilient performance and scalable solutions. And so they did that for a customer and it looked great. But when you think about what Adobe is doing, they're doing just the same, like edge delivery services, they get comfortable about moving content from IEM or from documents into S3 and they got CDN in front of it and CDN is serving the content, making it performant still. They got some events running here or there to invalidate the cache, to push the content to S3, et cetera.
So yeah, I think that this is a general direction, like make AEM a cms, like a content source because it's the best cms. Yeah, best. I'm sure that there are a lot of content authors and marketing teams that love it. Loves it. You know, all that master site management stuff, versioning and you know, language copies.
Yeah, workflows, all of that. Like it's still a king.
[01:02:51] Speaker A: Yep, I agree with that. Well, I think that basically wraps up the amount of time we got. But that was a. That. It was a fabulous. It was a fabulous conference. I. I think I'm. I'm more pumped than I've been in a long time on. On our. Our chosen profession.
[01:03:10] Speaker B: It's a.
[01:03:11] Speaker A: It's a very fun profession to be in right now. This. I mean, you could solve. I mean, like we were saying, you could. You could. You could almost. I mean, with the. With the people that we had in the room, we could virtually fly a rocket ship using the cms. So it was. It was.
[01:03:27] Speaker C: Yeah. But they did talk about using the right tools for the right thing, so.
[01:03:30] Speaker A: Okay, good. So I'm not suggesting. I'm just saying it might be able to be done. I'm not suggesting that we should. Okay.
[01:03:35] Speaker B: So. Sorry, I'm removing it from my to do list.
[01:03:39] Speaker A: Okay, good. Yeah, yeah, yeah. I mean, unless you want to just do that as a side project, in which case that would make for adapted presentation next year.
[01:03:46] Speaker B: Yes, that's. That's that. We get it.
[01:03:49] Speaker A: Yeah. Well, thank you guys for being on. And I'll. We'll. We'll. We'll talk more next time.
[01:03:56] Speaker C: Thank you for having us.
[01:03:57] Speaker B: Thank you.
