The Multisite Conundrum

Transcript

Note: The following is the transcription of the video produced by an automated transcription system.

Akshay Sura: All right, today we talk about what we face every single day, which is the multi-site conundrum, deploying multiple sites for your customer, using the same code base, different codebases, multiple agencies working so Kamruz, I know you've had strong beliefs on this one. This is what led us to start on this. What made you think of educating people about the multi-site conundrum?

Kamruz Jaman: So I think we've like the traditional CMS as we've been working with. One of the benefits has been being able to deploy multiple sites into a single instance and the reuse, do you get from that right? And that's been working great. You build one site, you build a set of components and then each of the other sites can just build on top of that and reuse those. But. And that works really well. When you're at a small scale, you have just a handful of sites to manage or you're at a small team scale. But as it grows, it becomes a bit of a problem. And I'll kind of explain this with some of these slides or make it just a bit more easy to easy to understand. So when traditionally when we've been working, you'd have a single code base and you'd have a single team working and deploying into your one CMS platform, right? So you have one set of content management servers. You have a set of content delivery servers, but all of your code gets bundled up together and pushed to this one platform right and off it goes and you deploy out to multiple sites. With any luck, you know, most of the sites are kind of the same, and you can just use the features of CMS to change things like the header image and the home page image and the images and things like that. And then you can just switch out a CSS file and that you have the exact same code base, the CSS. You can do a lot with it, and it looks like a completely different brand new site.

Kamruz Jaman: And then you get to go right. It's a CMS. It's all the content is editable anyway. Now, as the sites grow and each of the sites then start to require slightly different functionality, right? So you know, you have to grow your code base out, and if you're in a cycle world, you're probably following something like the Helix Architecture Principles now. You have your multiple layers and then you split it out by features and you split it up by project. And but you still bundle all of this thing in together and you'll deploy out to this single server base again. And you'll probably have some component reuse in there, but you're probably starting to split out into different sites needing slightly different functionality. So each one has a little quirk. And that's not so bad, right? If it's still a smaller handful of sites, it's still very manageable, probably a single team managing all of it. So they kind of know what's going on throughout the code base and the interactivity between the different pieces of the code base. And then this is where things start to. Get into that conundrum and start to get a bit scary, and I know you worked for some large enterprises as well. So I know you've been in this position and you end up with multiple teams, multiple agencies working on the code base and all of them deploying into still the single platform still delivering out to the separate sites. And this.

Kamruz Jaman: This is tough, right, because these teams are working on different because the functionality in in silos, essentially and. You try to set up a platform for them to use, but. They might not necessarily know the platform well, because you're not managing the team members on those teams, right? So the training, the knowledge they have, their experience, that's all out of your control, you're handing off to these different agencies, different departments handing out to different agencies, different business units are handing up to different agencies. And then. Your business grows and then you have more sites, you acquire more companies there on different platforms, you want to bring those onto the same platform. Yet more agencies are coming on and everybody's just developing, developing, developing and these silos and then use deploying, deploying, deploying. And. The governance around this is immense, I found, right. So being able to coordinate these agencies, being able to figure out who is developing what and when you're deploying into the same code base, there's so much risk of one agency doing something which has this unforeseen knock on it, knock on effect for everybody else. You have yeah, it's a little bit crazy. I've been working on this project at the moment where. We have 100 sites on the one platform. And it's like 20 different agencies working on this. Everyone has these very slightly different code bases as we have. There is some foundational and some common platform. But after that, you know, everybody still has their unique thing that they're doing, right, so they might have a pipeline processor that they wanted to do something on.

Kamruz Jaman: Now think about it. One project has a potential effect on one hundred websites on one pipeline processor. How do you know? How that is going to affect the other sites down the road? And how do those other sites track back to figure out who was the one that introduced that change to have that knock on effect? And how do you how did you just get back to figuring out how much time do you spend, right? Just figuring out who made that change and why is it doing this for me? So this is this is where I think the Jamstack approach really does help. The headless CMS is its own platform. Its sole purpose is to provide content. I know we've been using it for some of the presentational and layout aspects as well, but its job is not to. It cannot, right by its very nature of it being a SaaS and a and a cloud based CMS, it cannot hold any custom code. So it's one job is to provide output in REST APIs right now. What each of the agencies can then go and do is. Built on a common platform, and that's what we have, right, we have a common platform that all of our projects are using, and we use that as a basis for all of the all of our customers, for example, and even all of the projects within a same customer. What we have tried to do for the most part, is to have the same code base and just make tweaks via CSS and things like that.

Kamruz Jaman: But if you need to, you can have separate code bases for every site. If they're that much different, you can have a separate code base for each one. Or if they require some different pieces of functionality. And then the deployments are separate, right, so I kick off a build in the Vercel that will go and deploy out for site one. I kick off another build for site in Vercel, and that will it's a separate project in the Vercel that will go and kick off a separate build, a separate deploy to a separate space in a Vercel, right? These are atomic deployments. I do it, I do a change in sight one, and I break something while one it won't deploy because it's a broken build anyway, even if it did deploy. It's not going to go ahead and effect site two three four five six seven eight, whatever. We can still have common functionality. Obviously, being Jamstack would use a lot of serverless. We love using the Azure functions, so site one can have its own set of Azure functions, and we can have a common set of Azure functions at all or some of the other sites can still continue to use. So you get a bit of a best of all worlds, right, where you can have separate code bases if you need or same code base. But the deployments themselves are atomic, but you can still reuse a lot of the functionality through the serverless functions and whatever else you need.

Akshay Sura: Yeah, and just to get the point on, it's not like you can't do this with the monolith approach, you can. It's just the cost of hosting licensing to maintain different like each site in its own instance is just going

Kamruz Jaman: To be too much for a regular org to handle, and it's still a nightmare. But if you do that, you don't get any of the benefits of a multi side, right? So at least in the business space, we we're not. The code base is obviously separate, and you potentially could if you were to treat the monolith as. Headless, right, and just use it for data and modelling, then you could do this right. But if you're using what you've bought the platform for, which is for presentation and having the code base and serving out everything as traditionally you would, you can't do that unless, as you say, you have like if I have 100 sites, am I going to or even if I have four sites? Am I going to have? Four separate CMS instances, am I going to host four separate teams administered separately and pay for the licensing separately? Oh yeah. And then so I've seen some workarounds to this before where? What they would do is a CMS would be a common platform, but then what they would try to do is separate out the content delivery notes because that's what the that's from a business perspective. That's the most important thing that doesn't go down, that's serving actual clients. So what they would do is then they cluster their CD nodes. So it's like we have these sites of what we'll do is. Well, split out these set of sites onto CD cluster node one. And these other sites include cluster node two, and then they go through all these hoops and round about to deploy partial code bases to that cluster and part of code basis to that cluster.

Kamruz Jaman: But then all of the code base is CM. So you're not getting this true deployment where you get some site. Some nodes are getting some code but hasn't fully been tested, and it becomes a bit of a nightmare to kind of manage as well, right? Like in terms of. Just oversight on that code base, the deployment approaches are testing approaches. There's a lot of effort that goes into trying to manage that. But, you know, with this approach, you know, each agency can just work if need be, just work on their singular code base, knowing that they're not going to have a knock on effect to the other agency and they don't need all of that domain. Additional domain knowledge us as architects, we don't need to then be managing lots of separate teams and thinking about all of the different ways that this thing could be affecting the application in this, this approach and these side effects and so on and so forth, right? It adds a lot of cognitive load, right? And again, if you have that singular code base, you just this project I was just working on had. Over two hundred and thirty two hundred and forty projects across the Helix Stack, right? Yeah. Nobody was really looking at this. The cognitive load to try and figure out what was going on was immense. And if nobody's looking at it, then guess what's going to happen? You're going to have you're going to have these issues where you have these clashes and knock on effects. Yeah, no, I agree with you. Yeah.

Akshay Sura: Well, thank you so much, Mr. Ruz, for the multi side conundrum. Hopefully, we'll come back with more on this and Jamstack.

Kamruz Jaman: All right. Thanks.

If you have any questions, please get in touch with me. @akshaysura13 on Twitter or on Slack.