Episode Transcript
[00:00:10] Speaker A: All right. Welcome to Arbery Digital experiences. This is episode ten. I'm Tad Reeves, principal architect at Arbery Digital, and I am joined today by Brett from DxRoi. And we're today going to talk about monoliths, and that sounds like a super boring thing to talk about, but we are both, uh, we've got a lot of interesting things to say about it. Um, uh, before we get into that, Brett, you want to. I don't think that I can give you an adequate introduction because you've been in the space, um, even significantly longer than I have, uh, on, especially in Adobe experience manager slash CQ land. So do you want to, uh, give a quick overview of what you've been up to and what you're doing now?
[00:00:50] Speaker B: Sure. Sure. So my name again is Brett Birshbach. Um, I'm executive director of our technology practice at DX Roi with a really high focus on process and predictable results. With DX digital experience technologies, I've been in the aim face or the Adobe space for nine years, was in the drupal space before that. I've worked with a lot of different enterprise implementations, fully custom, headless, composable, monolithic, you name it. I done a lot of things, been in the industry for 20 years. And so, yeah, I mean, I have a lot of practice. I've seen, seen all the different ways of build the different systems, and it's really kind of interesting in this industry, watching the pendulum swing from point to point. I know we were talking earlier today about even just things like PHP, where like 20 years ago, I remember having conversations and this thing's dead. It's old garbage technology, and we need to get rid of it. Um, and here we are, 2024. It's still here. It's still prolific, and so it's, it's, it's really fun to be talking today about, uh, the concepts of monolith and headless and composable, and I really look forward to this.
[00:02:00] Speaker A: Awesome, awesome. Yeah, I, yeah, this is one of these things where, where when you're an architect, you know, you try to, try to, try to put yourself across as somebody who is, you know, calm and methodical and logical and you going to be swayed by what other people think and stuff like that. And you're not like, you know, it's not like high fashion or, you know, I wouldn't be seen with one of those or something like that. But it, unfortunately, in our space, I feel like it does come across like that sometimes and that you're like, oh, you're using that.
We don't do that anymore, you know, like, why? Why would you do that? Like, like, and you, and you get almost dinged for presenting something as being old or something like that when it's. It's the right tool for the job. It's like saying hammers are old and no longer need it. No, real contractors hammer. Real, real contractors don't carry hammers, as, you know, you know, sort of a thing.
But I was trying to come up with it with a, with a name for what we're going to talk about. And, you know, we end up with all kinds of, you know, title references. Like, you know, we going, like, with the, the Monty Python. Like, okay, you know, monoliths are. Aren't dead, you know? Well, yeah, you're not fooling around. You'll be stunned in a moment, you know, sort of a thing or so. But I don't know. I've had enough money, Python references, and I was even going to go with something like, you know, how I learned to, you know, stop worrying and love the monolith, but I don't know if I can. I don't know. I don't know if I can roll with that either. But, so, but in any case, but first, before we, like, really dive into what it is that we're talking about, I wanted to kind of get some definitions out of the way for anybody who might want to brush up on this, because we're going to talk about a couple individual concepts individually. We've got the concept of a monolith, the concept of something that is composable, the concept of something that's headless versus head full, things like that. So I want to. Let's. Let's just see how well we can do it at defining those. Just if I was just going to. If you're going to explain this to a technologist, they have basic technology, but, you know, it's kind of like a, you know, that Eli, five, that. Explain it like I'm five and read it. Like, let's just, let's. Let's see what we can do here. So, so a monolith, how, how would you explain what a monolith is?
[00:04:23] Speaker B: I mean, monolith is kind of, no matter what system you're doing, they're going to do a whole bunch of different tasks. And I think with the monolith, the monolith's tasks that it does, how it gets its data, how it presents that data to the end user, how it accepts data back from the end user, how it gets, if we're talking CMS, how it gets imagery and how it stores the imagery. All those features are so intertwined in such a way that even if you broke them apart, any software can be broken apart. They really can't attach to anything else.
So the front end is the halt into the assumptions of how the back end works. And it talks a certain language. So, like, it'd be like people, if I'm talking Spanish to somebody that can only speak Spanish, then that's what I have to speak. We only understand each other. We're speaking that one language versus where you go composable. And now you're talking people that are multilingual. Hey, if, if I'm talking to a spanish backend, I'll talk Spanish to that one. If I'm talking to an english backend, I'll talk to English to that one, or vice versa. Different front end to the same back. And is usually how it is.
[00:05:34] Speaker A: And. Yeah, I mean, and the whole idea in this case too. I mean, I don't know. Sometimes I feel like somebody who's using the term monolith has already made a decision about how they're trying to portray it. Like, I was looking up to try to see if there's a great definition for it. And like monolith, like in the dictionary, it is, it is a structure that's regarded as intractably indivisible, something that's impersonal. So you're already kind of like, you can hear it.
[00:06:00] Speaker B: It's that they throw the negative. There's different ways of saying that, but it's like that, this horrible trusty big thing that, that unflexible and can't be broken apart in this, you know?
[00:06:12] Speaker A: That's right. Like, that's right. It's the one piece. It's like, you know, like big brother sort of like, you know, you're, you're never going to win. This thing is, is always going to be. It's, it's thing. It's intractable. Yeah. It cannot, cannot be divided. But that's the thing. It's a piece. So, and if you're looking for like an example of something that would be a monolith. Right. One example. And this also kind of hearkens back to the earlier discussion on, on things that should be dead and really, really aren't, is like WordPress, right? If you look at something like that, like WordPress is one thing, and even the author experience and the publishing experience are all part of the same thing. It's a monolith. And I think I did my first WordPress impl in like, what, 0405, something like that. If I told 2004 self that, okay, in 2024, what's WordPress going to be running on? I'd be like, dude, something besides PHP, that's for sure.
[00:07:09] Speaker B: Or you might have said it's going to be running. Not at all.
[00:07:12] Speaker A: It's going to be right. It's going to, yeah, it's going to be right. It's going to be a memory is what that's going to be. And here it is, basically the same thing as it was then. Essentially.
[00:07:21] Speaker B: And my wife uses it too. It's, it's great. What it's great for. I'm telling you.
[00:07:25] Speaker A: That's right. That's right.
[00:07:26] Speaker B: Yeah.
[00:07:27] Speaker A: If you want to spit up a whole, if, like, if you wanted to spin up a blog, like is there, is there something else that's going to be, give you as much of a predictable, predictable result as quickly? Right. So again, we're already making a case for it.
It's a tool for a job. So, you know, it might be a hammer, but you know, it's, it's, it's still, it's still useful for what it is. So then you got, okay, then you have composable, right? So obviously you're, you're just taken from the word here. Something that is composable is built up of multiple disparate parts. And, and as, as opposed to being one big chunk, it is, it's, it's lots of different chunks. Now, this is where we're going to start to get into words that, that might have different meanings for different people. Because then, then you start to get other, other things in there. Because, because in the case of a composable something, that, where is composable? A lot of times what's inferred on this is you have multiple different parts. But in terms of the, the, the data store of record, the main common data store that is going to be used by whatever application, whatever service that you're serving here, generally speaking, it's assumed that it's going to be relatively common.
You're going to have some storage at some place that your composable architecture is going to use.
Or it could be, you could have multiple different services that possibly have their own independent storage, a separate content management system to your asset management system, to your order placement system or something like that. Like if you're, you know, a restaurant or something like that, you might have those different things, that's fine. But I think that still fits into composable rather than the, the other side of things, which is when you start talking this term of microservices, how would you differentiate that?
[00:09:22] Speaker B: Yeah, I kind of see the shape. And it's funny because this diagram has the top, I kind of see composable as a, is almost like an hourglass shape. And what you're seeing is like one side of the hourglass here, but you can have multiple front ends that all point to this one single middleware, as you kind of mentioned, like this one to the front end. It's one single storage area. But then actually in some composable systems where I've seen is it can actually help enable multiple back end systems as well that do a similar task for very complex organizations. Like, so for instance, one of the clients that we had worked on at my previous company, they had multiple cmss at their enterprise. Because I mean, these enterprises get so large that different user groups are different business groups within the same organization. They have their own budgets or even different brands. Business units is the word I was looking for, but they all have their own budgets. They buy their own technology over time. And you find that, hey, we've got three different headless cmS's, and then we also have a headful cms, and we want to try to use all these things behind one system. Or, hey, we got three different commerce engines. And so by funneling them all through a single common middleware layer, then the different front ends don't need to necessarily care about that mess behind the scenes, and then vice versa, you could have one back end and maybe you want to have a mobile front end and a website front end and then maybe a microsite front end all pointing to the same content. And so you can kind of like said, funnel it back out to the.
[00:10:54] Speaker A: Front end as well, right? And in terms of examples of what, what a what, like a what a microservice architecture. Because with a microservice, what you're, what you're basically saying is that instead of a single application controlling all these different calls and they're all stored in the same place and an outage, or if you bring that main monolithic service down, it's powering down everything, because that, like, nothing can really exist without that, without that big central bit going, right? Whereas a microservice, you might have something like, if you've got a cart, let's say you've got an order service or cart service or something like that, it's got its own persistent storage, that is storing carts that are moving on their way through, you can scale up and down the cart service based on how many orders are being placed and so forth. This is one of these things that gets kind of brought up as, as a reason to go to a microservice architecture because you have all these different pieces that may have different loads connected to it or may have different SLA's connected to them and so forth. And so you have like, you've got whatever, the service that goes and handles bringing in your product data, the service that handles going and getting content updates, the service that handles whatever it is. So each one of these different development.
[00:12:09] Speaker B: Teams on them, different deployment cycles and separate deployments for all of them. So yeah, kind of all goals are that territory.
[00:12:17] Speaker A: That's right. So, um, and then, and one other thing that I kind of want to define before we move forward, because we're going to end up saying the words like a million times, uh, as we keep talking is headful versus headless. I know a lot of folks know what that means. I just wanted this kind of just get, give an idea of what, what that would be. I don't know if the other document is any better. No, it's not really. All right, so uh, but in terms of head, headful versus headless and what, what does that mean for, for, with respect to like a CMS? Sure.
[00:12:44] Speaker B: So I mean, headful means, you know, hey, your CMS is not only storing the content, but then it's also presenting the content. So it's responsible for everything. Everything is rendered server side. Every, all the HTML is created from the content on the server. So before it even gets back to the end user, it's kind of all done. And so that's your head full experience. Whereas in the headless experience you've got your generation of HTML and the presentation to the end client is separate from the actual CMS, the backend that's giving the content. So maybe you serve the content up in a JSON format, so it's a more generic format. And then let's say a web browser website is going to take that JSON and render it into HTML. But then your mobile app could actually do a native mobile experience by taking that JSON and converting it into the presentation layer of the mobile device. And I think it's important to understand that headless is often associated with composable. But the two terms are not the same thing. And there is, exactly. Just because the system is headless does not mean it is composable. There's plenty of headless monoliths out there where that head list, that front end is extremely tightly tied to the presentation backend and the assumptions of that back end. And it's actually kind of a spectrum, again, we like to talk black and white all the time. Like, oh, monolithic, terrible. Like, well, there's a spectrum of how monolithic is it versus how composable is it. And do you really want to dial the nut, the dial it all the way one direction or the other, you know? And the answer is, it depends on your use case.
[00:14:21] Speaker A: Totally. And I think that can probably kind of dive right into one of these first kind of misconceptions about, about the, these, these perceived opposites that aren't really, or perceived complete differences where that aren't really. Whereas you take some, you take the headless versus headful, and you take, you take, like, if you take, I've had people ask me, and I've had to even try to weigh in on, like, what's, what's better? What's better? A Adobe experience manager or contentful, you get like, widget, which are two products in the CMS space. And one of them, contentful, is a very lightweight, headless only content management system that is designed to be very fast to deploy and 100% headless, meaning it doesn't have any state where it's running. The front end, too. You can't just make a contentful site and it's done with nothing, rendering the front end. It has no styling. It's got none of that built into it. Right. Or an Adobe experience manager, which does have plenty of cases where it makes the default site that comes out of it. The demo site has always been a fully formed site. It's all done, but it's the thing on your web browser that looks like a website.
You go, okay, well, those are two different things. Whereas the reality is that Adobe experience manager has been headless forever. It's been headless almost since day one. Like, it's like there's, there's ways of getting the content out of it with no front end. Um, and, and it's been, and it's got a headless use case that you can use just like contentful. So you're kind of like, it's, it. They're not, they're not totally apples and oranges. I mean, fine, there's still totally different flavors of fruit with totally different feature sets, but it's not just one's. One's better. You wouldn't say, well, you know, I was, I was on the old Krusty one, and now I'm going to go new, new and shiny and use contentful, which is. That isn't necessarily a distinction in that case.
[00:16:23] Speaker B: Right? No, I think it makes a lot of sense. Like you have, you have a platform that can support both, and yet people are choosing one or the other. It already kind of shows you that either case is somewhat monolithic. You know, if you're going to use the headless aspect of AEM, you're going to adhere to the patterns of am. You're still going to adhere to some of how it does its dynamic, render, dynamic renditions of assets, which when you start depending on that, again, you're kind of tightly coupled AEM. But to get those full benefits, you want that.
And you could choose, though, do you want to do it? The headless approach, you want to do it head full. And people are choosing a lot of times head full still with Adobe experience manager, because in their cases, it just makes better sense than the alternative that's also available to them on that same platform that they've already paid for.
[00:17:11] Speaker A: Totally. And one of the other things, too, is that. So we were participating in a shootout one time where the company was looking into, like, what should we go with? And here are some CMS alternatives and so forth. And they go, well, I'm told we should go all headless because it's super flexible. And the more we dug into use cases, it's like, well, do you even have, like, do you have like a mobile app? No. Well, do you. But do you plan to have a mobile app? No. No, we don't. Okay, cool. Do you plan, like, how, what's the percentage of your visitors that are even on mobile? It's like a very, it was like super low. Like they're very desktop heavy. Like much more so than the average. Right. They're like, you know, 75% desktop or something like that. Yeah. Okay, good.
What, so what, what would you think you would get out of going? Totally have like, like what, what benefit besides being like, cool and you can hang with the kids, know, with the, you know, hello, fellow kids, you know, kind of a thing. Like, is that like, what benefit? So it's kind of like if the right, if all of your experiences essentially are going to be rendered headful, you know, with a fully formed experience that you want to control centrally, all your caching and all your styling, all that kind of stuff is one experience, then is there a point to trying to go and break it apart into lots of constituent parts?
[00:18:29] Speaker B: Yeah, you know, it reminds me because, like, I've been to conferences for, I don't know, 15 years talking, you know, going back to my drupal days, talking about, like, omnichannel content. That's another big one that's out there is like, hey, we got to have this system. Gotta have this type of a CMS or whatever, because it specializes in omni channel content. Well, well, number one, you can make omnichannel content in any CMS you want. Any CMS gonna have the ability serve that content out. But number two, omnichannel is, generally speaking, not a technology problem, right? Being able to serve content to multiple systems, that's like child's play for technologists. It's actually more a actual content problem than anything. It's like, well, okay, you want to reuse your content well, but do you want to actually reuse your website content in your mobile app, or are you going to show something different? Do you want to use that same exact content in your emails that you maybe want a little bit more concise or to be a little bit more CTA focused? No, you don't a lot of times. And so I think a lot of people really kind of get lured in by this idea of, well, if I go this direction, the world is my oyster. I'm going to have all these future options to go to. It's like, yeah, but there's a cost to having all those options. And if you're never going to actually exercise those options. For instance, one of the things going back, even before I was in CMS land, I mean, we used to when we were building these Java applications, and one of the way to make them more composable was to get something, a middleware, an ORM object relational model that whatever the heck that technology is that maps your Java code to your backend database to get your database objects into Java objects. And instead of doing a writing a dirty query straight to your database according to the query language, that was considered dirty. No, you got to have this middle piece of software that would do that for you so that if you ever wanted to switch your database, you could.
How often are people switching their enterprise database? I'm not saying never happens, but come on. Like, and there was a huge cost to that added middle layer, whereas it would have been just easier, it'd been quicker for us to develop, go straight to the database, and more performant for us to go straight to the database. Now, again, I'm not saying there isn't any downside to it. And if we ever did want to switch database, yes, it would be more work. But are we going to need that error?
[00:20:56] Speaker A: Right.
[00:20:57] Speaker B: Your situation may vary.
[00:20:59] Speaker A: Right, right. And to me, it's kind of like the maybe talk to, like, I hope I'm not. I hope I'm not stepping on any toes here because of your vehicle choice. But then you take us, talk to somebody who's got like a, like a, like they've got an f 250 jacked up. F 250. You know what I mean? You know, 800 foot pound of torque, whatever, eight liter diesel or something like that. And it's. And, and they, and they live in suburbia. And you're like, what? Why did, why did you purchase that vehicle? What's what? You know? And they're like, well, what if I need to tow a boat off road? And you're like, how. How often do you do that? Like, like, so. So you're going to drive this thing, which you, you know, literally you could stack 30 children in front of the car before you could even see the top of the first one. You know what I mean? Like, you're going to. It's the most unsafe thing to do. Your, your, your black smoke everywhere. So that maybe once during the lifetime of that truck, you could drive it off load, off road while towing a boat, and you paid 100,000 for it. You know what I mean? It's like, it's kind of.
[00:22:05] Speaker B: By the way, maybe you have a friend that could tow it that one time.
[00:22:09] Speaker A: Right, right, exactly. So, yeah, so it's kind of, to me, it's analogous that there's like. But, but I guess that comes to that. That. That, um, that other kind of common myth that. That, uh, of like, you don't want to be locked into a tech stack and, um. And like, oh, we're not going to do this anymore because we don't like vendor lock it. You know what I mean? You know, it's like, like as if the entire Internet is like the adobe flash days or something like that, you know, kind of a thing. Like, well, but are you planning on changing? Like, well, we don't want to be locked in over this. Okay, good. Well, all your email stuff is all. It's all coming out of HubSpot right now. So are you planning on taking it out? Like, no, we're not. Okay, so.
[00:22:56] Speaker B: And then I think that the dirty secret that nobody wants to say is, I'm sorry you're locked into your tech stack, whatever you choose, or you have made things so sure. Incomposible. You could say, hey, my front end is never going to depend on the. The details of the back end, the, the specifics of the back end. Yep. You can do that. Absolutely. And there are cases where that makes sense. Like I said, that the case where I mentioned the big, big organization had multiple CMS is multiple commerce systems. I get it. But in, let's say you're not that system, let's say you just have your one commerce system. You probably bought that commerce system because it has features that are applicable to your business that other commerce platforms don't have. Because if they had them, you'd bought them.
[00:23:48] Speaker A: Right.
[00:23:49] Speaker B: So if they have specific features that you're going after, I don't care how you attach yourself to those features, if you say, hey, I'm going to now switch to another commerce system. Well, what if they don't have that feature? Well, now you got to rebuild your middleware. What if they have that feature but it's implemented in three different calls? Again, you got to redo your middleware, maybe even have to redo some of the things on the front end. So, like, I think there's this idea that it'll be easy to switch my technology if I'm composable. No, that it won't. And depending on how good your people are, if they're really good at making that middleware, so that abstracts out all the things. It might be less effort, but it's never going to be no effort. And I mean, again. And the more you want to leverage the tools that you're buying, buying, which is why you're buying them, the more you're still going to be beholden to some of the assumptions of these platforms no matter what. If all these platforms could easily be put behind a ubiquitous middleware layer with no downsides whatsoever, I question why they're even in the market to begin with. What makes them better than each other if they can all be effectively hidden behind a middleware and you don't care which one you're talking to.
[00:25:05] Speaker A: That's right. Yeah. And it's, and the thing is, though, is that so luckily for us, the composable slash, you know, microservice, I mean, I don't totally want to call it a fad because it has a lot of cases where it is the right tool for the job. Like if you just look at it, just, just take a piece of this in a piece of a technology stack that we use all the time. You take the way that AEM assets worked on an on premise situation and the way that it works in the cloud service, specifically when it comes to handling asset ingest and asset workflows.
So if you take, take a monolith where a monolith is just one big frickin Java app, you're going to say good, upload 20 gigs of mixed jpegs and mp4 s to this Java application. This is just a computer. This is running, and it's usually not even bigger than my laptop.
You're going to throw a full sd card worth of media to this thing.
It's going to have a hard. And that thing is still responsible for serving up the whole authoring experience for your entire enterprise. Right. The thing's kind of, it's really not going to have a great day. And then you take the way that Adobe refactored that into the cloud service, said, you know what, microservice is the best way to do this so that when somebody goes and starts uploading and they, and they've got, you know, whatever, 60 gig worth of assets in this one run good, let's spin up a bunch of containers, process all these things on the way up, and then spin them down.
[00:26:52] Speaker B: Absolutely. It's a great example of like, where monoliths can be a problem. Right? Like, because in that case, just like you mentioned. Yeah, you grind, not only do you grind the asset processing to a halt, but in the monolith situation, you grind age authoring to a halt page serving to a halt like that. That's a problem. So, so, yeah, absolutely. There are cases where monolith can be a problem as well. And to Adobe's credit, in that case, they busted that chunk of the monolith away and did make that more composable so that they could spin up a bunch of different instances, spin them back down when it's not busy. And so, yeah, these systems end up becoming monoliths of monoliths. Monoliths with composable pieces built into the composability of monoliths. I mean, even a composable system, within that composable system, you've got little mini monoliths.
[00:27:39] Speaker A: Yeah, it's true. It's true.
[00:27:41] Speaker B: Yeah.
[00:27:41] Speaker A: It's funny. Not to spend too much into story time, but I'll never forget this instance where there's one company, big companies working with, and they were they right after am, our Adobe first released the Adobe desktop app, like whatever, 6.1 late in the six one, almost, almost in the 62 days when they released the desktop and they were like, oh, we can use this desktop. They'll be like Google Drive, right? You just go, just take assets and just throw them into this thing and they'll just upload it, right? Oh, my gosh. They basically completely ddos their author. It was just down because a bunch of people were like, yes. And they just started using this desktop app as though it was like onedrive kind of a thing. And it was toast because all these calls are just going back to this hapless little computer, this hapless little model from this case that was struggling to try to, there's 500 meg psds that drew a billboard and stuff like that, just all trying to get processed by this poor author.
In that case, with a microservice type architecture, then you're able to solve that problem to where it's performing to the expectations of the user. So it's the right tool for the job. In that case.
Another one of these ones, though, I guess, to that extent, is that in that case, a performance problem was solved by spinning something off into microservices. You end up then with a myth that flies around that monoliths are slow and monoliths have performance problems. And, and how would, how would you, how would you respond to that? And somebody comes up and say, what? Why would you use that? Because it's modeled slow. You know it's slow, right?
[00:29:27] Speaker B: I know.
I mean, I think because there this, we all like to take examples of the worst cases that we elevate them to the truth about all things. And it's funny because, like, I had a buddy, we talked even politics. Like, when you talk politics of people, you all like, look at, let's talk about like a super, a topic that people really said on one side or the other, like, take food stamps. And the people that are against food stamps are going to point at the person that's at the store buying cigarettes and then using food stamps to get food with, like, hey, they should use their money that everybody's abusing the system. And then, and then the people on the other side, right? If you'd be pointing at the, the mom that was abandoned by the husband that has six kids and never had a job and can't afford to support. And we both pick these extremes and then we use that as our view. And it's ridiculous because when we say, hey, monoliths are slow, like, well, then what are they slow at? You know, I mean, if there's, you know, in the case of the AEm thing. Yeah. That, that asset processing on the server, that was a bad thing. Great. We solved that problem. Right? And because it is a monolithic system, when they deploy that update, everybody gets that. And now you have that feature, right? But some people are like, hey, you know what? CMS is modern CMS is the monolithic CMS is super slow.
I don't know if it is. And even if it is, like when you're working most sites that are, again, let's take your use case. What are you using it for? If you're doing a whole bunch of site searches? Yeah, you probably don't want to do those directly into your CMS, but are you doing a bunch of commerce calls through your CMS? Okay, I probably don't want to necessarily push commerce calls through your CMS. Are you just serving a bunch of pages marketing content from your CMS?
Great.
It's going to get cashed in a CDN. Your performance, the slowness of your CMS doesn't even matter. It's not even a topic. And I would argue that it's not super slow, but I mean, even if it was, it wouldn't even matter. It's not even relevant. So again, you got to look at your situation.
Just because you serve up content super fast and let's say a headless CMS doesn't mean that your front end is going to be fast. What if your front end is making 20 different calls to your back end? Then it's going to be slow and piecing all that together.
You know, like in the end, the same amount of things still need to happen. Now, if your CMS is getting overloaded, offloading all that rendering to the browsers in an endless situation, maybe that does help your performance. But again, is that your situation where you're getting so much server traffic that you can't solve it through horizontal scaling and you can't sell or it'd be too costly to do so and you need to upload the HTML rendering. Okay, maybe that's going to be a better case for composable or headless system.
But I've been the vast majority of situations, a monolithic CMS is going to perform just fine.
[00:32:20] Speaker A: Right? Right. Yeah, yeah. And, and I guess that brings like, to me see, so in talking about performance and also talking about backend calls and if you've got. So, because the one thing that I think that any monolith kind of has going for it is that it's a single object that has a known set of properties, has a known set of troubleshooting that you do, has a known set of parts of it that you should monitor for its health and so forth that you can have a look at. It's using this amount of memory, its response time is like this. It's using this much, it's burning this much cpu, it's got this much disutalization or whatever its properties are. Even if it's a hosted monolith or something like that. You've got pieces of it that you can look at whenever you start saying, well, you know, there's this other company that does all of our, that does the menu system and the doordash and all that kind of stuff. We just paste all these things into this thing and then it's going to work. To work. Awesome. And they say that they've got three nines of availability or whatever, whatever they say. Five nines or whatever the heck. They say you don't control that anymore. And so suddenly you're. Suddenly you've got an experience that you. That doesn't have a known set of qualities to it and doesn't have a known set of things that are always going to act this way. Or what happens when the thick. When the cartoon service, the cart microservice dies and the other things haven't died? Like do people start getting free food? Like does CMS? Like what happens? Right? Like, so, so there's all these different unexpected ways that, that, that the experience can break when you've cobbled together all these different pieces that you then need to think with. And this is, this is, this is overhead and this is, this is, this is part of the overall cost of maintaining the service that you don't necessarily need to think with when it's all internal to the monolith. Doesn't mean that one's bad and one's good. It's just that if you don't think with that and you think, well, now I'm buying the service. And they say it's always available. They say it's highly available until you, until your service gets a bunch of orders. And they think that you're ddosing the system because you got a bunch of orders. They turn you off and then your API key is broken, then your whole thing is busted. Like, like it's, it's it. They both have cost. Like, like you were just saying that the same number of things have to get done. The same number.
[00:34:51] Speaker B: Yeah.
In technology, we are notorious for trading problems for problems. Right. I'm gonna trade these problems for these other problems. But a lot of times when we do that, we know our problems. We think that there isn't problems over there. It's the classic grass is greener, right? So it's like, hey, and I look people always say this, well, if I go plausible, I can get all best in class individual pieces. That's true. Right? And guess what? You can get best in class experts in all those individual pieces. That's true. But what you can't get in a composable situation is who is the person that is the expert in your flavor composable? If you in composable land, if you've got ten different databases, ten different commerce systems, and ten different front ends, that is a thousand combinations. Ten times ten times ten. A thousand combinations of what your system is. And guess what? You care about your business stakeholders. They don't care about the individual system. They care about the system and they need to support the system. And so when you, you know, when you reduce down to the, to the monolith and you say, well, okay, but by going with monolith, I'm making some trade offs. I might not get the best in class commerce experience, might not get the best in class database and all those things. Yeah, but what you can get is you can get experts that have built their career around that monolith, that actually know the whole system. So which problems do you want to have? Do you want to have ten different guys that you need to call anytime the system goes down to figure out whose fault it is and that different vendors all pointing their finger? Actually, it's not our system, it's their system.
But maybe the systems are better and have better features for exactly what you need. Or do you want the other system where you have people, you have experts that actually get their hands around the whole thing and can debug it no matter what part of the system is broken?
[00:36:45] Speaker A: That's right. That's right. That's where I'm sure you've run across it a million times, too, when somebody comes to you like, good. So you've done assets implementations, right? And we're like, yeah, yeah, yeah, I've done that. Okay, good. So you've done am implementers, right? Yeah, done that. Very good. So good. So we're doing assets at am. Oh, good, good. Except for assets is orange logic. You're like, I haven't plugged those two together. I've not done it. I went to a sales praise on it once, so I know about it, but I don't, I've never, I have no idea how they act together. Oh, good. Well, how easy is it is it to integrate and how problem free is it?
I don't know. I don't know.
How often are you going to find experts like, you just said that have done all of those things. Have you used this version of hybris or something like that?
Have you used like it? So we're using an on prem version of this, but plus we're using the hosted version of this and we're using this other thing for assets. And so you've done that, right?
No, instead. I don't know. I don't really have no idea what's going to end. So how do you, and then all through then estimating projects like that, you know what I mean?
Like when somebody says good, well, about how much do you think that's going to run? And you're like, anything could happen. Like it could fly away for all I know. Like it's. We have no idea what behavior this thing is going to have when you hook these things together.
[00:38:09] Speaker B: Right.
You brought up a very good example of what really I would advise of all the things that you could pick between going monolith and going composable.
Please do not pick composable of expensive monoliths.
And because take that example you mentioned, you know, like, hey, I want to use am sites, but I want to use a orange logic dam or a widened dam or whatever, you know.
[00:38:35] Speaker A: Right, right.
[00:38:37] Speaker B: Can it be done? Of course it could be done. We can do anything with technology. However, when you use Am sites with Am assets, you have paid for a feature in Am sites that knows, because it's a monolith, the dirty monolith word. But those am sites, how it renders images, it knows intricately how to talk to that Am asset server and it knows intricately how to get it a rendition of exactly what it needs on your webpage so that you get high performance pages that rank well for SEO, that are exactly sized to not only the device, but the actual use case. So that if it's like four wide on a page, it's going to give you one that's a quarter of the size of the page, not going to give you a full width just because your device can handle full width. Like that's really cool stuff that you paid for in this monolith that you bought. And could you make that work with a different non AEM down? Course you could make it work, but you're going to have to code for that now because am sites has no idea how to talk that thing. Your developers not going to write that code. And I think that's the big thing with composable is when you go composable, you are now taking control of the features yourself. That's a good thing or a bad thing, depending on your situation.
But if you pay for all the features and then you're signing up to create all the features as well.
I asked the question, why did you pay for the feature?
[00:40:01] Speaker A: Right, right. That's right. And the thing is too, is that you've got, you've got the short term and the long term costs that most folks aren't thinking with because they've got a budget right now and they're thinking with how to implement something using a budget they've got right now. But if you've got something like for example, take your asset example where you've got a CMS and an asset repository that are built to work with each other. And so if an upgrade gets done on one of those two things, you can bet and you can bank on it being tested with the version of the CMS that you're using, it would be one of the things that they would have or should have tested for. And if they haven't tested for it, you can put the screws to them of like it's broken, go fix it and it's not going to be on you to fix it. Whereas if you've got two disparate systems that aren't tested with one another, an upgrade can totally break the other one and it's on you to fix that. It's totally on you and your team to fix that. So you basically end up having to, it's kind of like, it's almost like buying the car that's out of warranty, you know what I mean? Like, you know, it's cheaper, but you know that, that and you, you probably aren't, but you know that you should be putting, you know, two $300 a month into your deferred maintenance, you know, account in the bank so that when the muffler falls off the back of it, that you already have the money for that because you know, you're at a warranty, you know what I mean? And nobody's thinking about that. Nobody's thinking about there's a deferred maintenance budget that we really should have on this that is like, okay, when, when, you know, this, this API with the, like take the AEM and orange logic example. We got it to work and then they upgraded one thing on the orange logic side and it totally doesn't work. And now it's like, now it's an emergency. Now you got to come up with the money to go and develop your way out of that situation and it could happen again.
[00:41:56] Speaker B: Right. And composable the premise behind composable is. Yeah, but that doesn't happen because you build a middleware layer that takes care of those differences in the API chain and make sure that everything is backward compatible, and you have a contract with your front end, and you never break that contract. And absolutely phenomenal development principles. It is not a guarantee. Like, I don't know how many times I've seen backward compatible changes still somehow broke the front end. It's like, okay, great. You know what? We have a contract. We're going to send you back these six fields. Well, shoot. We didn't expect that that field all of a sudden would return this new character, this unicode character that blew up your front end and really, like, nobody put in the contract, and it will only return ascii characters between a and z, you know, and it'll only be 14 characters long, because if I send you a 30 character long thing, it's gonna blow you up. It's hilarious. I have this, like, device once that blew up because it couldn't connect because my SSId of my network was the combination of the SSID and the password together was too many characters. It blew it up. And I got credit. They actually added in their documentation that if it was, if you exceeded 40 characters, then it would, this. This device would not be able to connect. And it's just like, no contracts were broken. Like, it was a normal SSID and normal password with combination of two somehow broke things. Like, nobody would have ever guessed that happening. So I think you know this idea that, well, if I have a composable system, then when I change something, well, I'll have all unit tests that make sure the contract didn't break so I don't have to test all the different use cases.
[00:43:36] Speaker A: That's not true.
[00:43:37] Speaker B: It's just not. And so, like, even in a composable system, many times when you're making sweeping back end changes, you still got to have the different teams that are in all the different. The mobile team and the web team, the email team. Whoever's using all these systems as a backend still do need to run through their regression tests and hopefully get suites for those. But it's not really a whole lot different than monolith world.
[00:43:58] Speaker A: Oh, totally. I guess that kind of comes back to, there's another point that I read. I was reading an article, and by the way, those little diagrams that we used to start out with is this wonderful dev two article on composable architecture. But one of the points in this particular article that I read that the author was saying is that one of the downsides of composable is that some organizations just aren't ready. They're not ready yet for, for composable. So, so there's not, they're not up to, and up to dealing with this. They're, they're still, you know, old and backwards in their ways and, you know, and, and they're, you know, they still probably, you know, have analog amplifiers in their house and whatever, you know, they, they're just not ready for this where as, whereas it's, it's not, it, it's not old, it's not old versus new. It's not, it's not, you know, one versus the other. And these are, these are, these are still tools for the job. And I think that there are some cases too, and I don't want to also come across that either of us are anticomposable because there are so many use cases where they're thoroughly the right tool for the job. There are in some cases you got a website, maybe you got a brand new property that you're spinning up because so many corporate sites have so many dependencies that are really tied together nicely by a thick application server. If you've got something that is just like you got, oh yeah, I'm already behind the firewall. I've got this thing posted on premise. I don't want to make a front end connection to this weird old back end system that I need to pull this value from or need to push poke this thing to. When the guy submits a helpful or whatever it is.
I can't expose that to the Internet. So good.
My old model of web application server is the right tool for the job to talk to this ye olde server that is probably still going to be living when I'm a grandpa and that's the right thing. Whereas in some cases you got a brand new site. It's like, no, we can go light, we can go agile, we can have this, do this for the front end. You take something new like edge delivery. Right. Edge delivery is something where it's the right tool for a bunch of different workloads.
There are some workloads where edge delivery is so fast and not fast just from like a web delivery standpoint. It's just fast to fast to work with. And let's say you have a team where you've got a single AEM dev and that's the person who's supposed to be maintaining and upgrading and working on working on a big site on a traditional AM site. If that's the person who's got it. They're never going to go on vacation. They're going to be tied to that chair from now until the end of time. If that is really the only person who's working on that one website. They're going to be doing production support. They're going to be being the DevOps guy. They're going to be doing all this stuff, you know what I mean? And I've seen this too, where they just get burnt out because it's impossible to support. Whereas with something lightweight like edge delivery, you could just, you could just have a couple of junior devs and somebody who's anchoring it and it'll work out. Okay. Um, and for that type of workload. So, so there are, there are things where it's like, dude, that is 100% the right tool for the job.
[00:47:16] Speaker B: Yep. Yep. And I think, you know, just, it really comes on to the right tool for the job and, and, you know, like composable. I urge people, don't, don't try to think of composable and monolithic as one is superior technologically because then you can run down all these different things that we talked about today. You really got to look at is it superior for my business use case? And it can be a case I mentioned earlier where we had the multiple different backends from different business units that all had their different pieces of technology. That was a business case that led to composable being applicable in that situation. Another case where I've heard where composable could be a very useful thing is, let's say I'm building a new website for a company that is planning on being purchased, acquired within the next two years. And they don't want to have to invest a whole, you know, six months into building a new shiny website to only have to throw it all away because they're going to get put on the parent company's technology. Well, hey, maybe make it composable so that the front end won't have to be redone when you go to, when they're acquired. They just have to reattach to a new back end. The front end is it so that, that's just another business case where polls will, can make sense, I think, you know, edge delivery, same thing. Like, hey, if you just got a quick marketing website that's serving a bunch of marketing material and not really doing anything on the back end, it's a great solution if you want to start synchronizing in content from other platforms and use that content multiple ways in your web pages, okay. It's not really built to support that. So now you're going to have to either introduce yet another system, you have to get lambdas, you know, put them, put them out into, you know, a different third party tool, you know, can you use some Adobe IO and app builder stuff, but then you're going to be learning a new tool there. And so then now you got to really analyze. Okay, well I didn't have to teach them how to do the AEM front end stuff, but now I'm at to teach them this new back and stuff. And eventually when you get to the end of the day, most enterprise systems, by the time you piece it all back together, you either learned all the things in the one monolithic or you learn all the things and all the individual things. I think one of the big things like, well I can't find talent for this particular platform and it's just hard, like, yeah, but again, once you have a platform, even in composable that supports all the same features that the monolith supported, it's going to require just as much internal knowledge of again that platform, your flavor of it, it's not really going to be any different. And so I always, I feel like a lot of times when I hear people say compose, we're dumbing down the systems, we're making it all simple, our simple front end with just JavaScript, a simple backend that just has JSON communication. Yeah, but you still have to have this all talking together for full on features. And really what we need to do is we need to enable people, and once they're enabled with the appropriate systems, they can work in all these things. I've seen people work super fast in, in monoliths when they understand them. And just like composable when you understand the whole system, it's not a matter of the technology bits, it's who's worked in this platform and understands how they all talk together.
[00:50:21] Speaker A: Yeah, I think, I think it puts such a greater emphasis on then your internal documentation and so forth. I mean, I remember onboarding to one of these, it was a big composable system and I was like, it wasn't something I was used to and it took me, so they did, there was a bunch of video walkthroughs they did, and I went through, it was about 4 hours of video walkthroughs and I finished all 4 hours and I'm like, I still am not really sure what does what in this thing like because it had all these different, this was the message broker for that? And this talks to this. So that's where the, this is. No, it's not. It's, it's over here. Like there was it. So, so I think it does end up putting a massive burden on your internal ability to articulate that to new developers. Otherwise, new talent is not going to be useful.
[00:51:12] Speaker B: Yeah, I mean, I think we probably get away with more than we should. Not documenting as well in the monolith because people more easily stumble upon things that they, you know, how do these things talk together? Well, because it's in the same code base, I think, you know, when you start talking composable and maybe this is a positive thing. It's like the onus is like, it's obvious. You need to document this thing like crazy. Like we.
[00:51:33] Speaker A: Right.
[00:51:33] Speaker B: Should do, even though we're all right. We all load doing it in the technology industry because you've got, you really got a document so somebody can figure out how these dots all connect because it's not immediately obvious. In fact, it's purposely, by definition, not obvious.
[00:51:47] Speaker A: Right. Yeah, exactly. Now, one thing I want to talk about before we're coming up, coming up on our hour, but, but one of the things I wanted to, because we got, got through all these positives and negatives and, or more than positive negatives, but just considerations, things to think about. Right. And for me, I know that you've done a ton of this over the years, but for me, one of the things that I find the most fun is going into an organization and evaluating all this and actually trying to just be, I mean, I love just being beholden to nobody's sales guy and really just like, what are they trying to do and what's going to be the best thing in this case? So, like, for you going into something, what are some of the kind of, I guess, key questions? Because, because, because for us as architects, like, the answer is always a, well, defense.
But for you, what are some of the key things that some of those depends hinge on? What are the kind of questions that you would want to ask or have somebody consider when trying to think of, like if they're in a position, you got a company that's like, well, got this old thing that we've been using for 15 years and we've heard there's lots of new things. So we're trying to consider, management wants me to consider, should I go to the new thing? So what, and then, so what, where, where do you, where would you take that? Where do you, where do you usually go to first.
[00:53:16] Speaker B: I mean, the first thing is like, what are your actual problems? Because I mean, that the, the awesome thing about working at a big agency like I used to is that we moved just as many people from Drupal to am as we move from am to Drupal. Like it's like, well, so it's not the system, is it? Right, like it's not like one isn't fundamentally super better than the other. Now obviously I'm Adobe fanboy that these days, so of course, you know, my default would probably go that direction. But like, honestly, Drupal's a great CMS and like, it really is, like, what is the actual problem? Really starting to dig in and understand when was this thing built? How was it maintained over the years, how you've been trying to build it? You know, and honestly, a lot of times even just having an ability to look under the hood and see what the problems that they're experiencing are, you have to really kind of hit all the different stakeholders because the it stakeholders are going to have some pain points. Like, we can't support this system and therefore we want to take on more control. Well, that's a very understandable desire on their perspective, but they don't necessarily care that, that they're going to take away control from the authors and their ability to create pages. Like, well, they can still create content. Okay, well, but creating content is one thing, but maybe they want to actually control the experience.
If we, if we take a system and go a certain direction where, hey, that's all now in the developer's hands now. Hey, maybe they don't have to wait as long for developing a new component, but they have to wait for developers, for them to change the experience on a page. So you really have to dig in and understand like what are their use cases? What are they trying to accomplish? You know, what are the motivations? Right. Like, is it literally, hey, my boss loves, you know, he came from a place or she came from a place where they, they were all Aquia. And therefore she's pushing me towards, it's like, okay, right. You know, like that, that's fine. You know, let's talk through your case to make sure there's no huge problem with going that direction. But, but beyond that, like, you know, it really is understanding those business cases. And sometimes those business cases are actually even personal cases, right? Um, yeah. Because in the end, most of these technologies can solve all different things. I think when you're deciding to be monolith and composable, though, you really have to have a good reason to be composable. That has solid use case. Going back to what you said earlier, Tyler, it's like, well, but it's going to give me the options. Options? Do what? You know, options. Well, I do it well. For what reasons? What reasons? You know, like, well, if that's where you're stuck, I'm not sure you need it, because it's in. It's actually more work than building a tightly coupled front end and back in that know how to talk to each other.
[00:55:56] Speaker A: That's right. That's right. It's like. Yeah. Or is this just. I don't like. I don't like not having options is because I just hated when my mom was always telling me what to do.
Okay.
[00:56:05] Speaker B: All right, all right.
[00:56:06] Speaker A: I'm glad we had this talk, but. Yeah, yeah, yeah. It's. It's, uh.
Having that all pulled apart from the business case, because the other thing, too. Is that. Is that the number? Man, I don't know about you, but the number of migrations that I got pulled in to do, um, that, like, why. Why are we going this way? Like, what's. What's. Like, what's the deal? Like, why. Why this whole big CMS move? What's the deal? Well, it's because my VP said we had to go to the cloud. Well, while you ditch in your data center. Is that. Is that it? Oh, no, no, we're keeping it.
Okay. So, like, it's one of these, like. Like you said, sometimes it's personal. Sometimes it's just, you know, you know, the VP heard it at a conference. They heard this name at a conference. They heard it's supposed to be composable. They heard it's supposed to be this, they're supposed to be that. And it's funny, too, because now, being on the far side of when a lot of those really hype driven moves were happening to the cloud, right?
And now you've got this whole era. Like, just about anybody in it these days has heard this term of cloud repatriation, which is where this whole backswing of going back swings, going back the other direction. Because everybody assumed if you go back to 2018 or something like that, it was assumed that 0% of workloads that weren't in a company that. Where your product is hosting data center stuff, 0% of those would continue to have their own gear. And it was like, it's all going to the cloud. Until you realize that people like Amazon, those guys at Microsoft who are doing Azure, those are a bunch of engineers, they got to be paid, and cloud is just somebody else's computer, and you're just paying those guys salary. Essentially, if you've got static workloads, it's like, good. What? What are you getting out of this cloud move? You could have actually kept them all on premise to be faster and cheaper. You know what I mean? So you got these big companies like base camp.
[00:58:04] Speaker B: Yeah. I mean, just, like, understand in technology, whenever you go to a technology conference that's talking about a new movement, of course they're talking about the benefits, and of course, they're leaving out the downsides. Like, that's just. Peep. That's just him. How every topic is discussed in this world. When you go to any sort of conference, the conference is trying to sell you something more. Yeah. It's either selling your product, selling you an ideal, and it's going to talk about the good sides of it. But understand, like, all the people that came before this technology weren't just dumb and didn't know how to do things, just, oh, you know what? They built it that way because they were just stone age developers that just didn't have the new way of doing things like we do today. And the new way is just ubiquitously all better. All positives. Like, no, there were solid reasons why things were built, brent, in a monolithic way. There's solid reasons why you'll build things in the composable way, and the pendulum will swing back and forth as people like, hey, I hear all this great stuff about puzzle, and everybody will rush over there, and then they'll be like, hey, I heard all this. These great features get remodeled, so that's going to swing back, and then we're just. We're going to have the same podcast 20 years from now to ask.
[00:59:13] Speaker A: Yeah, yeah, yeah. Unfortunately. Unfortunately, we are. I think. I think, yeah. When you and I come back and we've got long, gray beards, and we can just sit there and go, yep. Like we were saying.
[00:59:23] Speaker B: Yeah, we set it back.
The good old days.
[00:59:29] Speaker A: Yep, yep. Well, we will be. We'll be recording the podcast, you know, from the backseat of our, you know, hover car or what. Or whatever it is, like. Yeah, I was not. I was telling you back then. Yeah, yeah.
[00:59:41] Speaker B: All right.
[00:59:42] Speaker A: Well, I think that about wraps us up here. But, goodness, I almost feel like we've just scratched the surface of this. In fact, you and I have notes here, and we've gotten through, like, precisely one quarter of them. So I feel like an entire meetup series could be done of just, like, a support group for people who have been made to go composable when they. When their. Their better judgment said, you know, we could have been better going this other direction. But, yeah.
[01:00:14] Speaker B: Hey, we covered. We covered. We covered what we covered. Hopefully it was helpful for folks. If you ever want to do another v two, I'm more than happy to do so. I apologize. Sometimes I just talk too much myself.
[01:00:27] Speaker A: Oh, man. Well, this is. This is a hot. So it almost feels cathartic getting a chance to just like. Just like. Like he could. I, too, have been made to do, you know, a composable against my better judgment, but yeah. Yeah.
All right, good. Well, thanks for coming on, Brett, and we'll. We'll talk again soon.
Cool. Thanks, Dad.
