Episode Transcript
[00:00:11] Speaker A: We're back with RB digital experiences. This is the first time back in the studio in quite some time. And I'm here with Dwayne Hale, who is a AM infrastructure engineer, has been in the Am land for years and years and years and years and seen literally dozens of different websites, hosted, well hosted, poorly hosted strangely and all that sort of stuff. Cloud on premise mixer, both should have been in the cloud, should never have gone to the cloud, all that kind of stuff.
So we're going to talk AEM and Adobe related infrastructure today.
Again, I'm Tad Reeves. I've also been in amline for a long time and have been in infrastructure basically my entire career.
Whatever. I'm in year 14 of working in AMCQ land.
Here we go.
Today, what we're going to talk about is the fact that in the past if you were hosting your website, doing your content management, all that sort of stuff in Adobe land or CQ land, there's basically one path that you kind of had in front of you in terms of upgrades and hosting and so forth. You were probably doing it on premise to start with and you were eventually going to go to the cloud once you were all good and ready, and if you were on a current version, then you were going to go to the next version and that was your upgrade path.
Now this is where it gets interesting.
Now, Adobe has really depends on how you want to think about it, but a minimum of three completely separate infrastructures, completely separate platforms to run your website on, and the reasons that you might want to go with any one of them, none of them are deprecated, they're all alive well and have reasons for being alive.
Now it gets really interesting as to which one should you go with based on what you're doing, where should it go? Should you have gone to the cloud? Should you be in the cloud? Should you use one of these new hosted platforms, is serverless. Okay, so that's what we're going to talk about today.
So Dwayne, do you want to give a little bit of background of some things that you've worked on in the past and where your view is kind of coming into all this?
[00:03:11] Speaker B: Yeah, so I've been in the Am space now for I'd say ten plus years very early on. Started as kind of a mixed role where I would come in as an infrastructure person, set up AM for the customer, and then transition over to the development team. So I've seen kind of AEM from both facets of it, both the infrastructure side and the development side. I've worked with customers in multiple different industry verticals such as healthcare, manufacturing industry, publishing industry. So I've seen quite a varied amount of Am implementations, both in terms of size, some of them being just standard websites that have a couple of dozen pages up to.
One that comes to mind is the manufacturing industry that I helped them with the AM implementation. And that one was quite large. They managed like somewhere around 230,000 products within AEM. And this was before the commerce integration framework and anything along those lines. So you kind of had to build the wheel before Adobe was able to provide that framework. So I've seen quite a bit in terms of the Am landscape and I've seen it change over the years. Right. So the very first project I was on was day communique CQ five four. And I've been in the space ever since then all the way up through the latest 65 service packed and implementations.
[00:04:42] Speaker A: Yeah, I think that's probably a good time to just talk a little bit about what these products are and what are they supposed to do. Because in some cases people, you got a company that needs a website or they need Internet internal, they need some sort of externet system to tie in suppliers and customers and stuff like that. And everybody wants something ideally that they can skin and hopefully not spend a ton of effort. But they come to any one of these kind of platforms and realize that instead of getting something prefab, it's more like going to needing a house and then ending up at Home Depot and grabbing lumber and a screw gun and bags of saccharite and all that kind of stuff and starting from there.
[00:05:30] Speaker B: Yeah. And that's one of the things that I've kind of come across with customers especially, is they end up purchasing am. They think that it's something like WordPress where they can just get in and start building and it has these kind of building blocks already built into it. And what they fail to understand is that it's more, I like to reference it as like a content framework engine instead of actually being a full fledged CMS because there is some groundwork that you have to do before you ever publish a live page on the platform.
[00:06:01] Speaker A: No, totally.
And the things that people need out of it, the things that they need the website to do, they're like, oh yeah, this is a standard website that we're doing, just like everybody else is doing. And then they go to list 25 completely unique bespoke requirements that they alone have, that nobody else has, and then that has to be built and you need a development team that does that.
But yeah, let's talk a little bit about just to kind of set the stage because in terms of people who are going to watch or listen to this, assuming somebody's going to listen to this, what is it that AEM does for people?
Aem, in this case, Adobe experience manager. It's a long word that doesn't mean a lot of things, but what does it do?
The main thing that people are using this for is first and foremost as a content management system and an application server for serving complicated websites. Websites that aren't just necessarily a WordPress site, but that have a lot of different requirements and potentially are going to need to go and talk to a lot of different back end systems in order to deliver up what they want. Like you said, you take something like a big company that has 200,000 skus and you need to have a corporate face, a nice about us page, it's got to be multilingual. It's going to have some nice content heavy pages that talk about what it is that they do, where they source their gear from, where are their factories, all that sort of thing. But then you got 200,000 skus to also display and potentially ability to order, potentially the ability to go and create pos that need to go and link up with some back end system, all that sort of stuff. So the requirements can start shallow and go deep really fast.
But it's that sort of thing that AEM is usually targeted for. It's usually targeted for the big companies that have a pretty deep feature set that they need and potentially a lot of different things that they need to go and connect.
So, and that's where you get into kind of the start of the story.
There's more than one way to put that together and to assemble the Legos into something that actually works for a company. And where a lot of us started from is that being hosted in a corporate data center and a bunch of big application servers that it's easiest to just go say, good, well it's going to need to talk to our product database or our product information management system, our PIM setup or our Salesforce or whatever, the thing that prints out the things that the person is going to need to go and order online or whatever, then it's going to be easiest if that's just sitting in our data center hosted on servers that we control.
And that's where a lot of people started with. But as that gets into all kinds of problems, Adobe's had a version that comes out every year. You got 6061 6.26.3 all the way on up. And every single one of those required a massive upgrade evolution to be able to get up to the next version. And that's as far as a lot of companies were able to see. And when I was dealing with these ones, they would envision some grand future where eventually they're not managing all the hardware themselves. They've got it in the cloud. They have an idea that somehow the cloud is going to save them money because they're paying a lot of money to host a data center, not really realizing that the cloud is just somebody else's data center. And they're going to have to pay for that. And it's generally not a cost savings, it's a convenient savings. Maybe a personnel reshuffling of who you need. You still need infrastructure, architects and DevOps guys and all kinds of stuff. You need all those guys.
They're wearing slightly different colored hats, but they're the same types of folks solving the same types of problems just in somebody else's data center.
And then you've got then starting in 2020, you had this new player that came on the scene, which was when Adobe rolled out am as a cloud service.
And that's had its own set of things. Initially, when that was rolled out to us, the line that we were getting from our sales and partner management folks is that's what everything's supposed to go to.
[00:10:48] Speaker B: That was the future.
[00:10:50] Speaker A: Yes, that was the future. Everything goes to this new cloud service as folks pushed on that too. As you go, good, everybody move, let's all go. Then you start to pull up the use cases of like, that's not going to work. That's not going to work for XYZ reasons. And some of those reasons are political. Some of those reasons are pretty like, okay, we're going to have to redo almost everything that we have behind the scenes so that we can use your new content management system. And is that worth all of that rejiggering just so we can use the new content management system? It's possible. It's all possible. Everything's possible with enough money.
But is that desirable? And so then you have a lot of companies like, I've dealt with another manufacturing company that has never made sense. They're still on an on premise am six five, they've got a presence in China. It doesn't make any sense.
There's just too much.
[00:11:55] Speaker B: And that's the other kind of facet of that is that there can be some hard technical reasons, depending on the organization if you think about european banking institutions, given the european data laws, they can't host outside of the european continent. So there can be a lot of just non starter issues where it excludes the cloud service from being a viable option right out of the gate.
[00:12:20] Speaker A: That's right. And I mean, I've got a diagram so far, some people are going to listen to this on audio and so they're just going to have to visualize diagrams in their mind.
But here's a diagram of am cloud service.
So this whole setup that Adobe created, which really is a gargantuan amount of engineering that Adobe had to do to undertake to take something that initially was a really complicated Java application server, extraordinarily complicated, that plugs into all, like you could write anything and plug it into AEM, all kinds of different heavy lifting that you have to do behind the scenes and to take that complicated Java application server and stick it out in the cloud so that it was containerized, auto scaling, auto healing, super upgradable, this list of requirements that basically you're like, okay, does it also need to fly?
My hat is still off to the engineering teams that made this happen.
It's ridiculous.
But meeting all those requirements means it's definitely got limitations as well.
And it is by definition then a lot more prescriptive in terms of how to get in and use this, for one thing. So as you can see from the diagram here, so it's got a bunch of gear that's in here. You got the back end data structure, the JCR, the Java content repository, which is hooked into a series of containerized pods and so forth, you've got the authoring instances which have all their data stored in MongoDB, Atlas, you've got all of this running inside of Azure and all of this. You can't necessarily put your finger on, like if you take a piece of data, like let's say I author a piece of information and stick it in the AM author in the cloud service, it's very difficult to put your finger on. Where does that information now? And if I wanted to retrieve any remnant of that information, if I wanted to track it, or like you said, with european data residency laws, how am I really going to make sure that this, let's just say you're talking about a swiss bank, right? How am I going to make sure that this data that I uploaded, let's say I've got a shareholder report that has stringent laws and restrictions and so forth about how it's going to be portrayed, where it's going to be stored? How do I track accesses to it.
[00:15:09] Speaker B: The time that it's put out, timing of the publishing.
[00:15:12] Speaker A: Yep. So people don't speculate upon it, all that sort of stuff.
How do I really control that? And if it's going to be in Mongo Atlas, if it's going to be over there in Azure, if it's going to be sticking up here in Azure blob store and is there a CTO or a chief security officer or any of these kind of people who are going to be down with that? Or are they going to say, yeah, can we just keep it on our gear?
You worked for some of these financial services infrastructures too. That kind of, they had those as a hard stop. They were like, sorry, sounds like a great deal, but we can't use that work for us.
[00:15:56] Speaker B: Yeah. We can't track the lifecycle of it or know exactly what system it's in at any given time.
[00:16:02] Speaker A: Yeah, that's right. Or if you say, we think we have a breach, you need to send us the hard drives that this thing is on. And when it's in that many disparate places, you're like, that hard drive doesn't, that doesn't exist, it's everywhere.
That creates a problem.
But there are companies that absolutely plug in well to a cloud service like this, and there have been ones that I've seen that have done quite well because it scales very well.
You can reuse a lot of the work that you put into your earlier am implementations. Because if you look at, I got another slide here, this is an older am, this is like an AM 65 type of infrastructure. And this shows also an older way that we had to solve problems on this, which is where if you had a ton of assets, you might need to offload those into an assets author that could run workflows and stuff like that. This is no longer a problem with am cloud service. These are all done with microservices. But if you took a lot of the work that you put into components and things that do this. Okay, I made a great, we put all this development work into a location finder so that people can find the nearest location to them. Can we just take this location finder and stick it in the cloud service? And a lot of times the answer is, yeah, you can just go and it's still the same code, it's still Java, it's still the same sitely or however it was created. And so it makes sense for a lot of folks.
But that kind of gets into one problem that we haven't really touched on, which is you've been in am for a long time. I've been in it for a long time. I don't know about how you got into am in the first place, but for me, it was completely by accident. I was working for a company way back in the day, and I wanted to learn all about load balancers and stuff because I thought that was the future. I'd get myself all certified in f five and stuff like that. And they're like, yeah, we're running am I like, okay, fine, I'll learn about that, too, but that thing seems terrible, but I'll learn about it. And then next thing you know, my next job is like, do you know about CQ? I'm like, I do. It's terrible, but do you want a job in it? I'm like, oh, it's full remote. Okay, fine, I'll do it. But I just kind of just fell into it.
There's no great entry mechanism to get into this universe. You just kind of have to almost jump into it or be handed know. There's not really a know, hey, download a free trial and get your hands know sort of a thing.
[00:18:45] Speaker B: Yeah. And that's how I got into it, was a very similar story. So I worked at a university in the it department, and they were moving from Serena collage to a gay communique that's kind know dating my experience with it. But I knew the infrastructure guy. He was right across the hall from my office. And so nobody on the team really knew anything about the application stack besides that it was a Java application, right. So they thought, hey, we'll just go in and we'll run Java in the jar and just start building. And that's basically my first experience with, well, it's Adobe experience manager now, but it was day communique back then was, you're a two person, three person team, one developer or two developers, one infrastructure guy. We're migrating to this, and we need to stand it up. So it was a really, I would say, steep learning curve, especially given the documentation back then that was available on Adobe site. It was fragmented, and not all the details were there. So it was a lot of on the job training, I suppose you would say, with the application stack itself, and that has improved over the years, but that's essentially my vector into the Adobe experience manager ecosystem.
[00:20:04] Speaker A: Oh, totally. And because of that documentation, there was not really a really strong community to tie into so that you could tell whether or not you were doing it correctly or in a complete anti pattern. And you're like, well this is how we created it because this is how it, I mean, look, it works.
You bring it to some Adobe guy and they're like, oh goodness gracious, why'd you do it like that? We're like, because it works.
[00:20:33] Speaker B: Yeah. Or you come to revisit, know, a year or two into the future because it's upgrade time to another major version and then you're starting to read some of the upgrade paths and notes and then you realize, oh, I may have built this incorrectly and this is our time to reset to some of the best practices that are starting to emerge.
[00:20:54] Speaker A: That's right. But it's that, I guess this barrier to entry that just really just, I don't want to say that it's repellent, but in some ways it is kind of like I've had a couple of guys that were moving into the tech field, they were in some other field and they moved in, they went through a developer boot camp, maybe they even learned Java. And I'm like, dude, I need am developers. Do you want to come on in here? And they look at it and they're like, that looks really hard. And you mean you basically have to secretly slip me a CRX quick start.
There's no actual way that I can get into this and it has to be basically not above board for you to learn me on as a developer. Like, no thanks, I'll do something else because it's like how do you get into this field? So that's been a problem all the way along the line when it comes to getting companies muscle to do some of these upgrades and migrations and stuff like that where you say good, give me 02:00 a.m. Devs and a QA guy and let's rock and roll. And the talent pool is really thin.
Getting a hold of, it's fine. It's been good for our salaries, I guess, because it makes us so rare, but it still doesn't help us get anything done.
That has been something that Adobe has been looking to handle because they made am cloud service.
One of their goals initially that they stated was this will be great for SMB, for small medium business because we can just provision it. There's a lot of this buffering of the infrastructure guy stuff that to stand it all up, we stand it all up automatically by pushing a button. So should be good, right? You don't realize that whatever, 75% of your expense then is on the side of trying to find the guys who are going to build it and run it. It's extraordinarily expensive to build it and run it, which is what leads us to this next infrastructure that Adobe really has been kind of slow drip releasing and working on kind of under the covers, which is now called Am Edge delivery services, which has had many other names.
It was originally this project called Helix, and Adobe secretly took some AEM sites that we didn't really know that they were doing this and they switched them out for Helix and they were running on Helix. And like for example, the Adobe blog blog, adobe.com was one of the first ones that went over there and we all thought it was AEM. And they're like, this has been Helix, it's been helix for two.
So it was then renamed to Franklin and even before release. And we started talking about Franklin at Adobe summit last year and they're like, okay, well actually we're calling it AEM next generation composability features. And that is a mouthful. I assumed they were going to call it launch because launch is always what Adobe calls everything that doesn't have a name. There's been so many different things called launch, but they didn't go with that. They went with Am edge delivery service or services and that was launched in this past fall.
So what this is is a lightweight, extraordinarily fast, basically a document based content management and delivery service which allows you to go and plug in either like Google Docs, SharePoint, you can plug in even am as a source for documents which gets run through kind of a simplification and marked down interpreter, which then goes and spits it out to a pretty complex content delivery tier which uses aggressive caching in a really intelligent way to be able to deliver pages super fast.
The benefits of this are that, like I said, it's extraordinarily fast. Basically the target is to have a lighthouse score of 100 all time.
It's basically the design goal all along was the fastest to just make it every page that is hosted on eds to be the fastest sites on the Internet just flat out.
So that's one. The other is that the barrier to entry of getting into this is going to be really low. If you know how to use Google Docs or SharePoint and you know how to do just a lot of really commodity Javascript frameworks in terms of UI, you can get in and get dirty and start making a site as a testament to this. So just last night, so I got a resume for a developer who's still in college, and he, you know, you got a job for me, I'd love to work for you. I said, okay, tell you what, you want an interview?
Take your resume. Here's the AM eds website. Take your resume, make yourself a website on eds and stick your resume on there and then I'll give you an interview. He totally did. He did it in hours and his resume was up on the website. He's like, oh, that was really fun.
To me, that is a testament to the fact that you've got now something that is the opposite really, of AEM Land, where you can take developers who are just trained in almost anything and get them up and running and start making you a website off of this.
[00:26:52] Speaker B: With virtually no infrastructure that you have.
[00:26:54] Speaker A: To set up or virtually no infrastructure. Like for example, we're running our blog on this right now and the only infrastructure that we're really supporting is the CDN because you have all this feeding into and you're responsible for the CDN part in front of it with your SSL certificates. And so we're responsible for that. There's no backend gear, there's no vms, there's no load balancers, data stores, data sources, and we're sitting there running it on Google Docs, we're not paying for that either. So it's super lightweight on that, super pluggable with that. It's got limitations. So obviously by the fact that it's serverless, it's serverless. So that means with Am, you get an infrastructure based on the fact that you've got a server that people aren't talking to that can connect in the back end and grab stuff and crunch it and deliver it to any of these back end systems. So all that connectivity to some back end 20 year old postgres monstrosity that stores all this whatever it stores or PIM stuff or ERP stuff or Salesforce stuff, whatever stuff that you don't necessarily, you've never gone through the work and you maybe don't want to go through the work of exposing to the Internet your server can talk to and the public don't need to talk to it.
If you're doing this on EDS, and you're assuming that EDS is serving all this up and you don't have a server to make that connection, then the client is going to need to be the one that's compositing all that data. So let's say you've got a table of, okay, let's say you've got available, let's say you're running a site and you've got available classes, training that you're providing, right? So you've got a database that has this list of class schedules and when they're available, right? And that's some backend database someplace, right? So if you're going to run this on EDS now, as opposed to just having a JDBC data source on a server, and that server talks to the database, goes, queries it, and then goes and crunches it and displays it, now you have to have a publicly available front end data source that can spit out a JSON that your EDS site can consume, which that's cool.
But now if you want to run your entire website on this, that means refactoring all of your back end infrastructure to have front end delivery so that you can use this new coolness, which I guess that brings us back to this point of, is this for everyone or is this for every workload?
And do you need to go all in on this also?
And I guess that deserves a lot of thought and consideration because like AEM, right? So you got your license, ridiculously expensive licenses per server, right? So the likelihood that you're going to run am on premise and AEM in the cloud at the same time is like you'd have to be a very wealthy, very prosperous, very big company to be able to afford things like that because you're just throwing a lot of money at licensing at that point.
But EDS comes with your cloud service license, so you potentially could run workloads that make sense on eds and then keep the rest of it in AEM for your hardware core type stuff that need backend connectivity.
[00:30:54] Speaker B: Yeah, and that's one of the things where I see eds probably accelerating or excelling beyond on prem or cloud hosted AEM or even AEM as cloud service is if you're doing something small like a blog for your company, or maybe even like knowledge base articles, if you're not putting them behind some sort of paywall or authentication mechanism.
EDS fills all those checkboxes, right? Where it doesn't is where, like you said, you're having to pull information from multiple disparate systems. Some of them you may not, for security reasons, even want to put on the Internet, right? You may not want to even expose that. And so that's where I think EDS kind of lacks in use case functionality is being able to connect multiple disparate systems like you mentioned, PIM system, or even like a booking system if you're some sort of vacational industry, things along those lines. But it does work for your smaller sites that you may not want to wrap up your development team with building article list or blog list or some of the more simpler feature sets where you can just hand it to your content team with a little bit of training and say, hey, upload your docs into this sharepoint or Google Doc location and they'll automatically get published essentially.
[00:32:17] Speaker A: That's right.
And one of the other things too, that it's a monstrosity in terms of how much that it does and can do and so forth and how much that's got in terms of features. So one of its classically good features that it's been good at for whatever the 15 years that I've or 14 years that I've worked on it is workflow management and being able to do really complicated business logic having to do with content when it comes to approvals, translation workflows, sending an uploaded piece of content off to a work management solution like workfront, getting it crunched on and then thrown back into it and then published and so forth, all this really complicated business logic. AM does extraordinarily well.
And if you're something like, let's say you're an insurance company and you've got 50,000 pdfs that all have to do with disclosures and agreements and all this kind of stuff, and they're different ones for different states and they have all this stuff that has to be done for approving it and putting it online and so forth.
So EDs isn't going to really handle that. It's not really for that. Am is for that. But if you've got a microsite that says you're launching a new initiative in Georgia or in South Carolina and you just want to just have some pictures, some video and all that kind of stuff and throw it online and it's only in English, do you want to try to engage an Am developer and an AM development and expensive Am development team to make that, or just throw that together on eds and then send them back to AEM when they need to sign up, they need to get those translated, updated pdfs that have the stamp on them that says that they are approved and all the stuff that needed all that back end gear, send them to that for that sort of thing.
[00:34:23] Speaker B: Yes. And that sounds like a typical use case for EDS, right? Something that you're not wanting to necessarily personalize to the level you would of your main corporate website or simply, like you said, news announcements of new features or new programs that your organization offers. That's kind of eds's bread and butter, right? Is kind of the more sites of the traditional websites of, I guess the past, right, where they're more static. They don't really have personalization that kicks in. They don't really have very much interactive functionality. That's where eds kind of shines, right? Because your content team can throw that together with, I don't know, what would you say? Maybe a couple days training on how to format the actual Google Doc or the Microsoft Word doc and then they can publish their content with a lot more velocity than typically going through an Adobe experience manager channel, regardless if it's adobe as a cloud service or even know Adobe AEM, because then like you said, you're engaging specific content authors that have been trained on how to use the components that have been built within AEM. And the content velocity can be slower, right, versus just being able to upload a word document that's properly formatted with your tables and et cetera, and then that gets published out pretty much instantaneous.
[00:35:58] Speaker A: Yeah, exactly.
And the number of teams that then have to wait for budget to be available for development teams who are these super in demand? Because once you've got a couple of AM developers on staff, those guys are never lacking for work. There's always remedial work and new components. So being able to get in line with one of those, like, oh hey, I've got a new microsite that's supposed to launch our new summer special. Like, okay, man, get in line. Those guys are busy.
[00:36:32] Speaker B: Could be the end of the summer by the time they get it out the door, depending on the team and the velocity and like you said, the backlog of work they have.
[00:36:40] Speaker A: Yeah, that sort of thing is great. Now, one other thing though, too, just coming back to does it solve every problem? One of the thing that we've looked at is that EDS does not have any real mechanism in place. I mean, coming back again to this whole workflow phenomenon of an analog to Adobe's multi site manager and language copy frameworks and all that sort of thing. So if you've got a site and you're doing mechanical translation in 16 languages or something like that, and you've got good, you want to author once, send a bunch of this, or make these components once, and these layouts once send them out for mechanical translation, they come back and all that kind of stuff and they're managed.
There's not really a way of doing that out of the box with EDS, unless you're talking about really duplicating huge trees of sharepoint folders for every single language and every single one of these is monster.
And also when it comes to asset management for all those, a lot of the way that you get this content velocity with edge delivery services is people. You can make a word, doc, drag a photo in there, drag this in there and just hit it and goes and it's up. But now that photo is living within the context of that document. If I say, hey, we're going to change, know, we're the whatever shoe company and we need the spring colors, not the winter colors. So we're going to change out every one of the shoes that's everywhere. An am that's relatively straightforward to do that across languages with EDS, you're doing a find and replace of documents all across this massive tree.
It's not really for that.
You're really using a serving spoon to do excavation kind of a thing. It's just the wrong tool for the job.
[00:38:48] Speaker B: Yeah, and that's where it gets a little clunky and there could be ways around that. I can already hear some of the more enterprising developers being like, well we could host the images somewhere else and then just link to a generic link. And that may work for a small website, but if you're talking tens of thousands of products, that's a lot of manual touch points to have to go in and replace image one, two, three, ABC so that you have your spring colors of your shoes. And then even then you may still have to go back and touch the original source material if you didn't do that out of the box when you first deployed the eds.
[00:39:28] Speaker A: And that adds to the fact that in all of trying to figure out what you're doing with websites and sites and sites, the one thing that has been a constant factor over the last maybe five, six years is Adobe's focus on their assets product. So assets really started to really pick up steam in am six, four and 65. And then the assets cloud service is really, I mean, I think assets am assets in the cloud service is one of Adobe's top three products, period.
Even including all their desktop products that really are just monstrous assets. Cloud service is a great product for managing assets. The feature set so strong, all the appropriate use of AI in limiting workloads of things like all this stupid stuff that you got to do, crops and tagging and taxonomy and all this stuff that really, when the rubber meets the road on trying to manage a brand's assets, it's really good. And so you want to leverage power like that to limit the amount of labor that you're putting against this and really increase your asset velocity and being able to like, oh, hey, why did you pay this guy to do a brand new video shoot? Well, I thought we didn't have any photos of that. We did just our asset management and taxonomy and search capabilities was so terrible you thought you had to do another photo shoot. That is a real life problem that a lot of companies have, but with how good the search has become and all that sort of thing in assets, cloud service, you want to leverage that. So how to leverage that and how to plug that into the right cms, the right tool for the job, really.
I guess to me what comes out of this is you got to spend more time not really thinking through what are your use cases? What are the things that, the features that you have that you really want to have?
What are the ye old systems that you have that you do or don't ever want to expose to the Internet or you may or may not want to ever reengineer?
And then what are the right current tools for the job? And where do we go with all of this? Because it's not just the CTO or whatever says we got to go to the cloud, so we have to go to the cloud. It's not just a simple migration or, oh, we're not a data center company, so we wouldn't keep a corporate data center. Because sometimes it might really, really make sense to keep your corporate data center in some cases, I've totally seen this because storage is cheap these days, it may really make sense to keep that corporate data center for certain workloads.
So the importance of evaluating all this and taking a really hard look before buying a license for something is, I think, important.
[00:42:30] Speaker B: Yeah. Doing your groundwork very early on in the initial stages of reviewing, what are your requirements? What are your nice to haves? What is the future going to be like? That's one thing I see a lot of customers not really thinking about when they first jump into AEM is what are we going to do in five years or ten years in terms of what our online presence should be like and what we want customers or consumers of our content to be able to interact with. So they get into a situation where they look at eds, for example, and they're like, well, we're just going to build a semi static website.
It's going to be more for informational purposes. We're not going to collect user data or have users book trips or anything with us or order components that we manufacture. And then in two to three years, after they've started to grow out of eds or similar system. They're then looking at reinventing the entire thing because it doesn't meet what the goals of the organization were in the long.
[00:43:41] Speaker A: I'm really so we've got Adobe summit coming up. So I think again Adobe is going to further tip some of their hand and what their future plans are. But I think it's never been more important to understand the offerings that are out there, the options that are in front of everyone in terms of where to stick all this, the resources that each company has. Like do you have a bunch of Javascript guys? Do you have a bunch of Java guys already?
It may make a lot of sense to go and take this on premise system and retool it into AEM if you've got the Java muscle to be.
[00:44:19] Speaker B: Able to do that.
[00:44:20] Speaker A: If you don't, maybe it doesn't sort of a thing. But it's exciting. It's exciting. We are in a land of much flux right now.
[00:44:32] Speaker B: Yeah. And it's been exciting watching the ecosystem grow because like we talked about at the beginning, originally it was AEM on Prem, right? If you wanted to use AEM, you had to have a server. You had to put it on that server. And now Adobe is offering, what I'd like to say is three different flavors of AEM essentially, and two of them are, like you said, really easy to get into. Now that with Adobe as a cloud service, you don't really have to worry about having a bunch of infrastructure guys that know AWS or they know VMware and they know Java applications and they know how to monitor them and how to respond to any issues that come up with Adobe as a cloud service that's kind of handled for you, really. You just need the development side of the house. And with eds it's even simpler because you kind of don't really, I don't want to go as far as to say you don't need developers, but at the same time it's very approachable given that it's Javascript and regular word or Google Doc documents or even an AEM author can be your source of truth for that particular system. So given these options, like we mentioned earlier in the podcast, it's really kind of adobe opening up the floodgates to appeal to more than just your large corporations that have a lot of that development or infrastructure muscle that can then get into the Adobe ecosystem and really leverage it.
[00:46:02] Speaker A: Yeah, indeed.
All right, well, I think we're going to have to do version 2.0 of this particular podcast right after Adobe summit.
[00:46:10] Speaker B: Yeah, that's why I was just thinking we'll have to do a part two and see how well this one age, depending on what Adobe unveils or reveals and what their future roadmap looks like.
[00:46:25] Speaker A: Indeed. All right, well, thanks for the discussion, Dwayne. And like I said, we'll take this up again.
[00:46:33] Speaker B: Yep. Thank you. And have a good one.
[00:46:35] Speaker A: All right, see ya.
[00:46:40] Speaker B: Our channel.
