Benefits and Factors to Consider with MACH Architecture

Sam Brace: [00:00:00] Welcome to MX Matters. This is where we discuss the changes, the trends that are happening in technology, specifically the visual economy. I am Sam Brace.

I am the Director of Customer Education for Cloudinary and in this episode is our friend Gary, who of course, if you’ve been listening to other MX Matters episodes, you know him as a frequent guest co-host for this program, but also for those of you that are joining us for the first time, he is our Vice President of Technology Partnerships at Cloudinary.

So Gary, great to have you back again.

Gary Ballabio: Thanks for letting me be here, Sam.

Sam Brace: Of course, of course. And for this episode, we are gonna be talking about something called the MACH architecture, which sounds very fancy, very fast if you know anything about mach speeds, but we have someone that is very tied to what this architecture is, why people that are based in all sorts of the spaces that we’ve talked about in the program, as we said, the visual economy, so people that are managing [00:01:00] websites, web presence, when it comes to large spaces of imagery, videography, but also even marketers, creative professionals that have to play in this field with SaaS-based companies, what they might need to know about this new or rebranded type of architecture that is taking place.

Joined with us for this to be able to add some light to this topic is our friend, Tim Benniks, who you’ve probably seen Tim Benniks in another Cloudinary capacity, if you’ve been paying attention to our marketing, our outreach programs, because he is someone that definitely understands how we work as a company, but also an amazing public speaker and has quite the online presence as well.

But his current role is a Principal Developer Advocate at Uniform, which also happens to be a member of the MACH Alliance like Cloudinary is. So we’ll talk about all those details. So without further ado, Tim, welcome to the program.

Tim Benniks: Hello. Thank you so much for that [00:02:00] lovely intro. That was super fancy.

Sam Brace: I, I try. Thank you, Tim. So Tim, let’s break this down. So I’ve said MACH architecture, but for people that are listening to this, they might be saying, okay, well, that’s gonna be like a new form of like the LAMP stack, right? Or maybe the Jamstack. Like, is that the same thing or is it slightly different?

Tim Benniks: Oh, wow. We are starting with the best questions that are hard to answer. Like architectures can go so many different ways and MACH is just one of those iterations. And you just mentioned in your intro that it’s maybe a little rebranded and that’s actually a really interesting part about it. So the acronym stands for microservices based, API first, cloud native SaaS, and headless, and all these things on their own without going into them right now in this answer have existed for a while.

Right. And now they’re just put together as this magical combination [00:03:00] of awesome as I like to call it. And it’s mainly there because you have multiple streams going on in, building architecture for big brands in the enterprise. And you can range that from monolithical applications to maybe MACH based applications and those have some significant differences that we should probably talk about today. And it’s an exciting and effort changing world.

Sam Brace: Let’s break down that term because as you said, microservices based, API first, cloud native SaaS, and headless. Talk to me about what microservices mean, because I think all three of us might have a slightly different definition of what microservices are. So tell me about the way that maybe the MACH Alliance, the people that are talking on MACH architecture, how are they defining what microservices are, as that M in the overall acronym?

Tim Benniks: All right. So I, I think within this acronym, the microservices is the one that might [00:04:00] be ranging across multiple things the most. And so microservices can be as simple as literally a service that only does one thing. That’s why it’s called micro, right? So it’s a singular endpoint for something that provides you a service.

And how I personally like to see those is they’re stateless and they’re not super smart in that sense. So you have an input, it does some stuff, and then there’s an output. And that can go as small as a serverless function or a Lambda function. For example, in AWS. Towards more, this is an API endpoint with a bunch of different things that it does, but it’s only scoped to one thing.

And so that’s slightly bigger. And so generally microservices are used to connect things up, or maybe you can use them as a small API endpoint to get the stock of a product or the size of an image, or maybe to do a compute, right? Potentially [00:05:00] you want to remove some background from an image or you want to get some metadata from something, you don’t wanna have all that logic in your front end app.

So you just put it in a little microservice, you query, it comes back, you use it. And the beauty of this is that these microservices they’re kind of standalone. So you can code them in any sort of coding language that you want without affecting how the rest of your app is built. So they’re a very interesting approach and I might have offended some people with this answer because for some, this might be much bigger than for others. And so I just gave you my context here. So, Gary, what do you think when I say these things?

Gary Ballabio: I dunno if you wanna. Um, there we go. What, so honestly, like what I’m thinking of, whenever I hear the term, you know, microservice, I’m always thinking about, well, usually that does come with cloud and that does come with API.

Why do we have to call it out separately? There must be reasons why we’re calling it out or, you know, it is called out separately. That’s my big question. Actually, I don’t really have a good answer for that myself. I was actually gonna ask you that question, Tim.[00:06:00]

Tim Benniks: Maybe let’s say you’re building this whole application and architecture and stuff, and there is something that you need that you cannot get from one single vendor or that one single vendor gives you too much or in a different way.

A microservice is something that you built specifically for a task that would then maybe split an order and come back with some information or something that another SaaS cloud system doesn’t do, you can make your own microservice for it. And you can even think about, okay, maybe I need to connect to a legacy surface that is pretty slow, that doesn’t have any caching. I mean, I put a microservice in front of it that then handles that caching for you. That is, for example, in my opinion, how it could be used.

Gary Ballabio: Got it. So it could be a set of APIs even from different vendors and bringing it together as, you know, solving a problem.

Tim Benniks: Exactly. And what I tend to like about this, and this goes a little bit deeper into why this MACH stuff is so cool. These microservices, or at least when you use, let’s say [00:07:00] Amazon Lambda functions or Azure functions, or there’s different names for them, right? They are turned off and you don’t use them.

Hence you don’t pay for them if you don’t use them. It is very interesting. So when you start using them, they wake up, they do their stuff and they go back to sleep. So it’s a usage based payment system there. And that is a very interesting thing because on the other side, on the monolithic side, your server is always on with all bells and whistles, even if you don’t use them.

So if you think about environmentally friendly energy usage, consumption, stuff like that, it’s, it’s a very interesting concept.

Gary Ballabio: Since you brought up the monolith term, first of all, it might be good to define that for some of our audience. But in addition to that, maybe you can go through your thoughts on how the industry you think is going to evolve as more businesses adopt headless architectures, or MACH architecture, what will happen to the monoliths? It’s like, do you see it being combined, where there’ll be some architectures [00:08:00] utilizing them as well as headless capabilities or like, where do you see from your perspective? Where do you see things, the way things are trending?

Tim Benniks: Before we dive in, let’s define like what you asked, this monolith thing. Monolith on its own means something that’s all together as one. And so there’s a whole bunch of software that has existed for a good while that was great, this is actually handling all your potential business problems you could have on the web. They would do that with one vendor. So it’s a monolith and we call this a suite. So there’s a whole bunch of services, ranging from servers to front end, to application management, to databases. It’s all one vendor.

And this comes with some benefits because you install the thing. You run. Everybody’s happy. You have accelerated time to market in that sense. And if something is broken, you point a finger to one person. This is my contract, this is my SLA, fix it. So there’s some real benefits there. On the other hand, it’s not super flexible because if you wanna break out and do your own thing, you’re breaking out of how [00:09:00] that vendor has interconnected all these services together.

And then when you need to do an update, it’s no longer possible, or it is. Everything is possible. It just costs you a lot of money and time. And so what we’re seeing now is that these vendors were really great. In like a digital experience platform, you have stakeholders that are practitioners, content editors, marketing managers, end users, of course, and you have all the tech.

And so for the longest time in these monoliths, these suites, the practitioner came first because the marketer needed to be able to go into all these systems, drag and drop things around, have a preview, hit “Publish”, and run, but it gave technical issues for the front end developers.

And if you wanted to scale only one thing, you cannot just lift something out of that monolith and then change only that one and not the rest. Right? So there was this huge change into more IT-first stuff. Developers needed freedom. They were running with headless CMSs because they could make their own front end, completely [00:10:00] separated from that system.

And so now to come back to that question of how will it evolve? I think there is a place for all of this, right? The more MACH-first you go, the more composed you go. You choose the best pieces and you put them together through microservices, for example, or APIs, it also becomes a little bit more complex.

You kind of have to know where everything lives and how it all works. And that’s a valid argument for some companies to not do it, because if you’re fully driven through this “what you see is what you get” kind of approach, and you have trained your people for 10 years in this, doing a big bang release where this is no longer possible or partly possible, it’s, it’s pretty challenging. And, um, there will be a mix because lots of companies still have a bit of legacy and they want to go to this composable stuff because in the end you have so much more freedom because everything is separated. You want a better wishlist system, you just rip the old one out, lock the new one in, and it’s better, [00:11:00] right?

Only that part. So it’s great. But still, now it’s still very IT driven, right? So we have to get these practitioners back in, to also be happy. And this is the area, for example, where Uniform is playing, and this is not a Uniform marketing talk. So I won’t be talking too much about it, but this is where we are playing a little bit.

And because companies like Uniform are there to help you with orchestration of all this stuff together, there will always be a mix. And what I’m personally thinking, and this is my personal opinions or not the MACH Alliance opinion. Let’s be clear on this. I’m thinking that all these monoliths, these suites, they still have a great place because if you think about Shopify, it’s one of these, right?

It’s a website out of the box kind of thing. It’s great. All of that will go mid-market. It will all go slightly down. And all the top market, the big players, the enterprise players that need to have all the specificity, they’ll be doing MACH architectures.

Gary Ballabio: Yeah, it makes sense. I mean, it is [00:12:00] interesting to hear that. So you think it it’s much more of an enterprise play. So I won’t put words in your mouth, but this is my interpretation of what you said.

The trade off there, there’s definitely trade offs on the business side, because I mean, I could hear, you know, procurement people saying I’d rather just buy from one or just deal with, or even finance, deal with one invoice, deal with one vendor, and not have all of these agreements and all these negotiations and everything. So there’s clearly a pretty major tradeoff there.

Tim Benniks: There are some challenges, let’s be honest. And so what we will probably see in the future, if there are going to be consultancy companies that might take parts of these contracts for you and deal with it for you.

And we’ve already seen some deals going on, for example, between… I won’t name any names now, because it probably will change over time and then this does not fit anymore, but you have like headless eCommerce vendors that have a deal with the front end. The deal is one deal as in the front end will just earn 25% off the contract for the eCommerce vendor, and then they only [00:13:00] pay the e-commerce vendor.

So you have these kind of things going on now, and that we’re trying to find our way of what is the best approach here. But generally, if you can solve your business problems better with MACH approaches, which is generally the case, that outweighs the negativity of having to deal with multiple SLAs and stuff like that.

And so I think we are in a paradigm shift at the moment where we are going towards MACH Alliance type architectures, and we all want it. There’s kind of a fear of missing out thing going on almost. It’s a very interesting one. But our minds are still in the place where we think one solution will give us a full chain fix for everything.

While the paradigm shift doesn’t actually tell you that our minds are still a little bit there. We are kind of struggling as a whole in the tech industry at the moment because that paradigm shift like change takes time, [00:14:00] right? And if you go fully MACH architecture, not one of the vendors that you choose will be full chain.

So you have to do more yourself. As a technical stakeholder, you will have to take more responsibility of the tools that you choose. And so there’s many more SI system integrators that are gonna be amazing at helping you choose, and they will bear a bunch of that weight on them of doing that. And it’s, it’s a really cool thing to witness.

But there’s also one drawback. And I kind of coin this term myself that I call the MACH monolith, which is kind of a fun, strange way of talking. But what you see now due to this paradigm shift, everything is headless now, right? You mentioned Cloudinary. You have full coverage of your API completely headless. CMSs do the same.

Ecommerce is doing the same. But in our minds, we still want this full suite approach where I can see the preview of what I’ve been doing. And so what is [00:15:00] now happening? So in between the paradigm, starting to shift and ending to shift, we are now actually seeing headless systems implementing monolith like features to keep everybody happy. There’s a product category coming up where Uniform is playing that helps you with all this, but it doesn’t exist yet other than Uniform and some other players.

And so, you’re starting to interconnect all these MACH-like tools to be able to actually get somewhere. But what happens in a year when everything is interconnected and you wanna change one thing, you can no longer point a finger to anyone. And so suddenly there’s an extra complexity in here because our mindset is not fully composable just yet.

And what I’m hoping and what we’re working on very hard with the MACH Alliance is to actually educate everybody about this stuff, to make sure that people are enabled to actually choose the right tools and how to connect them and what these microservices would do. And what is real cloud native and [00:16:00] what is managed hosting and what is real headless and what is hybrid headless. There’s so many words here.

Sam Brace: You’ve just touched on a lot of interesting points that people need to be thinking about as they’re making these architecture decisions. You raised a really big one that I think I’ve experienced with people that we interacted on a daily basis from like the community standpoint, user standpoint, where there is a fear of missing out or FOMO that’s attached to these things where headless as a term, MACH as a term, those are things that people are saying like, oh, I wanna be a part of that.

Cause it’s buzzy, it’s exciting. There’s movement happening with this. And of course, when they say themselves, okay, this is gonna take more time than maybe they anticipated because it does take time to develop the vendor list for that best of breed and the APIs you wanna bring in to build your architecture. It takes work. It’s not where it’s as turnkey as you’re saying, going with a one stop solution, something that’s more of that monolith type of category. So I think that’s something that people do need to keep in [00:17:00] mind is that all of these terms have conditions that are tied to them and that’s not bad.

It just means, you know, you doing the research, hopefully like listening to podcast like this, it’s gonna keep making people more enlightened to what this could possibly look like if they decide to go down the path of building something with a MACH architecture, 6, 12, 18 months after they decide to make that initial decision.

Have you also experienced something similar with your conversations, maybe in the Uniform space, but also just being a developer advocate?

Tim Benniks: All the time. And the interesting thing here is like, my answers might have complicated a little bit what this whole amazing adventure of ours is about, but it’s actually, once you are through and you have your composable architecture, you never have to replatform again.

You can scale easily. And the benefits start. It’s like raining benefits, but the hump, the initial hump is a bit high and due to this FOMO, people tend to choose quickly because they have used a certain CMS before and [00:18:00] they quickly choose it and then this has an integration filter to the other thing.

So let’s just run. So we have this composable stuff. And so if you go quite fast and make these decisions early without actually thinking about how are my concerns separated, right? Do I maybe need two headless CMSs for global content and local content? And do I maybe need to integrate a DAM solution into one of them or also into the other one?

Or do I separate that out completely? And do I make my compositions in a completely different space? Because a CMS should just be a bucket for data. It shouldn’t actually compose a whole page, potentially if it’s headless, because you might wanna do that somewhere else in your front end, potentially, or in a tool like Uniform that helps you to kind of plug stuff in and replace it in an easy way without upsetting the front end.

And so we’re gonna slowly grow towards that. But what I wanted to say is don’t choose too early and [00:19:00] don’t interconnect too much because you get an indivisible thing and you might in the end want to remove that one CMS and plug in another one. Right? And if that’s no longer possible, you have created your own monolith.

And so, yes, the FOMO is real, but it’s relatively easy to solve if you are learning about how does content modeling actually work. Right? I would suggest make an account at Headless Creator and look how Marcello is talking about how you do composable and how you do content modeling and how do you separate your design from your data and where do you compose everything together?

It’s really interesting.

Sam Brace: And it seems like one thing that you’re saying that I’m very clearly hearing that I hope others, and tell me if you agree with me because I may misinterpret it vastly, but what I am hearing is that if you are inside of a technology office, if you are involved with overall architecture of the company, I think a big thing that you should be doing before you go down this path is getting a good list of requirements from the teams that will [00:20:00] be touching these parts, like talk with your marketing team, talk with your content teams, make sure that you are fulfilling all of their various needs, understanding the pain points, because what I have potentially seen other companies do is they go down the path saying we’re gonna be headless because they like the term, but they don’t realize that the marketing team really loved their CMS.

And so, and they don’t say like, okay, how do we give a lot of the same functionality, but get the outcome that we want from moving to a headless environment? So I think making sure that you’re bringing a lot of people into the MACH conversations will ensure a great outcome as you’re talking about, something that’s highly scalable, making sure that it’s future proof, all those wonderful aspects. But requirements are important right now.

Tim Benniks: At this moment, I’ve made this literally my job. How can we help educate all our lovely community from our technical partners to developers in the field to marketers or decision makers? Everybody kind of needs to find their own vibe [00:21:00] in it and then just run and try stuff. Initially, I might have let shine through that it’s only for enterprise. It’s not really true. Cuz if you have a small website and you just have a headless CMS and you have Cloudinary as a DAM and a Jamstack front end, you have a MACH architecture. My website is a MACH architecture, to be honest, right? It, it can be quite small cuz I use a little serverless function to update my Algolia index.

Oh now suddenly I have a microservice. Right? So the interpretation ranges quite wide. And so it’s relatively easy also to get started.

Gary Ballabio: Just maybe elaborate a little bit more about how Jamstack fits in with this type of architecture number one, and then number two, I’m also curious your, your thoughts on… there’s a lot of great vendors in the Jamstack space, but we don’t see them showing up necessarily in the MACH Alliance or in MACH based conversations. Why is that? And do you think that will change over time?

Tim Benniks: That’s actually a great question because the Jamstack started very [00:22:00] simple and then it became everything. And now we don’t really know anymore. Like literally today I asked in a tweet, can I use this in this framework to build a Jamstack site? And the creator of the framework asked me, what do you mean by Jamstack?

That’s where we are right now. And so Jamstack is actually at its core just a way to build a website. And it has a whole bunch of benefits, but other ways also have a whole bunch of benefits. And so what you generally see with Jamstack sites, as it’s super simple, it’s JavaScript, APIs and markup. Jam, right?

And generally the combination of these three will render you a static site. So you do all the fancy stuff with your new technology, with your front end tools, everything that you want, and then you hit compile. And then in this compile step that happens in your CI/CD server somewhere, rather than just creating you a website that is dynamic, it actually creates you a bunch of files because [00:23:00] the dynamic stuff happens on this CI/CD stack.

And then it just literally uploads almost like an artifact of a ZIP file of your website, like we had in the two thousands. Right. And so that’s the essence and the great thing about that is if you wanna scale a website like that, you just put that file on multiple places and suddenly it’s better. It’s faster.

And also because it’s not super dynamic, it’s literally a static HTML file. The CDN edge that is closest to you will serve that file in like 20 milliseconds. Right? It’s really fast. And because of that as well, it’s really hard to hack cuz there’s nothing dynamic going on. The surface of levels of attack is very low.

And so this is the base and then it started to diverge a little bit because what you can do, you can build a whole bunch of static HTML and then add JavaScript on top. That does something that we call hydration and that hydration [00:24:00] is I’m gonna use React or Vue or Svelte, one of these really fancy JavaScript libraries, to then attach itself to that HTML that was rendered.

And then suddenly dynamic things can start happening. And so the first click that you do on that website is actually just HTML that served JavaScript attaches itself, but then you click on another link and then it becomes a single page application that is only JavaScript based. And it just does AJAX calls or whatever it needs to do.

And so it’s a complete hybrid. So Google, when it indexes the site, it finds static files, but the moment you start interacting with the website, there’s no page refreshes anymore. And then suddenly the magic starts to happen because in that hydration time of adding the JavaScript, you can do personalization, you can do A/B tests, you can do AJAX calls to get stock of a product.

And so Jamstack is just a way of how you can build a website that in my opinion is one of the best approaches to it. It’s not [00:25:00] super easy, but it works really well. And so you don’t see it in the MACH architecture because it’s not a microservice. It’s not an API. It’s nothing headless, it’s literally just, I build my website. A or B.

You can also do it in runtime with PHP or with React Native or whatever you want. So it’s just one of the ways you build your site.

Sam Brace: And so if I’m sitting here as a, let’s say, a software engineer, marketer, creative professional, anybody that’s gonna be touching web in some way for my company, my organization, if I was to say like, okay, I love the idea of microservices. I’m able to get the best of breed. I’m able to bring them in API first, which means they’re easy to move in and out of the code as I need to do so.

How do I even figure out who the best of breed is? Potentially looking just through the MACH Alliance list, I could potentially do that and say, okay, these are companies that are affiliated. They understand this type of architecture, but is [00:26:00] that the best way to do it? Just to comb through and be like, alright, I see this vendor here.

I’m gonna do research. Or is there a better way for me to start doing this exploratory stage?

Tim Benniks: As far as I know it, there’s no official list of what a best of breed tool is because it keeps changing. Even if you look at Cloudinary, where you guys work, right? First, it was one big product with all APIs and probably within a while, you’re gonna maybe split it up because not everybody wants everything.

And then suddenly your best of retool is multiple small ones or a portfolio of features, or, and that has changed. Right? And we see that in different places. The question at the MACH Alliance that we get a lot is what is the best blueprint to actually get something to market fast with the best stuff, because we are so used to that sweet approach where everything is handed to you.

And we don’t really reply to that because it’s up to you, what is your business case? What do you need? And then you [00:27:00] find that, and that is really challenging. And so at the MACH Alliance, they’re not gonna say, use this one and not that one, that’s not gonna happen. That’s where the agencies and the consultancies are gonna help a lot.

You can see that a bunch of global agencies or systems integrators are now finding that if we use this combination, we are generally good to go without becoming a one trick pony that always does the same. So they have a golden five CMSs and they have certain DAMs and they have certain PIM systems. And then they look at the problematic that the customer has and they choose the right things.

And then they run. And I can probably guarantee you that in a year or two, there’s much more technology internalized at brands and at customers that I see as a customer, right, but as a brand? And people will have learned much more what they like. And they will like the tech is maturing. The technical stakeholders at brands are also maturing.

And so opinion is gonna come in a bit. Some [00:28:00] researchers come to come in and then hopefully you can maybe get a consultant to help you. And at one point, you know it yourself and then you run cuz you know your business the best. If you are a product owner, you have a certain business problem and for now, it’s just research or ask your friends. But there will not be blueprints that tell you, this is the way because business is different for every brand.

Gary Ballabio: You wanna make sure you’re pulling services together that work together and work well together. There is this underlying assumption because it’s API based, we can get it to work together, but you know, somebody who’s worked in the WordPress world has seen plugins collide with each other all the time on WordPress, right? So…

Tim Benniks: Oh yes. I’ve been there.

Gary Ballabio: So then coming with a mindset, maybe that is, you know, creating some sort of like uncertainty, right? And so if you can ask somebody, what are the best ones to work together? Then you might get into this point where you get to this MACH monolith, you know, like where you’re actually on the same one over and over again.

Tim Benniks: Yeah. And what is really interesting here is that there [00:29:00] is a new product category emerging to be able to deal with that problem, cuz there’s a certain maturity level between how you integrate these things. The first one, the lowest maturity is in my front end, I connect to two APIs. I do two AJAX calls and I build my front end.

So the developer completely decides what do I query? How and when? And then the next level up that’s one higher is more the integration side of things where a headless CMS has an integration field where commerce flows in. So now it’s on CMS level. So the content editor in the first one where the developer connects everything, the content editor has no idea where it comes from.

The second one, the content editor actually knows, oh, this is my commerce system. This is my DAM system. So they know they’re connecting to other bits. And then in the front end they query the stuff, they render it. And then you have the third one, and that’s where all these new companies are gonna come up.

Where [00:30:00] Uniform is playing is the orchestration game, where you have a unified interface that is no code where the content editor actually doesn’t know which system they’re connecting to because it all looks unified and awesome. And so they just know I’m now querying a product or five products or some images and the interface thus reflect where it comes from, but it all looks the same.

And they are kind of plugged in, in a way where the concerns are completely separated because your composition happens in that tool. So you will not have composition or contextual data to a component in your CMS anymore, but that will be in that orchestration tool where you make your composition for a page.

Let’s not dive in too deep here because we can go really deep. Let’s not do that now, but that means to make sure that you don’t create your new monolith, but connect it all to kind of like a middleware layer where you have all the freedom to compose in [00:31:00] no code or where the developers get an SDK that is super open, where we query everything the same way. Suddenly that what works together well is no longer a real question is just what do you like most and what is cheapest for your business? Right? Because it just flows into that Uniform- like orchestration system. And so you don’t have to make an integration. It’s integrated in that orchestration system.

Sam Brace: When we’re talking about MACH, I mean, it’s been a case where we, I think we’ve done a really good job of explaining what everything is in the acronym and some of the things that people should be thinking about before they go into this process. But I think one area that I’d love to get your insight on, Tim, when it comes to the types of microservices that you commonly are gonna see in MACH architecture. I know we talked about content management systems or CMSs. In other conversations that we’ve had, you hear people talking about like e-commerce systems. Like if we think about something that’s very API based like a Stripe as an example, that would be [00:32:00] getting brought into this, but like what types of services do you commonly see being brought into MACH? Like other than those two?

Tim Benniks: What is actually really interesting would be a use case that I’ve worked on a while back, where for example, you work somewhere and they will lease you a car for you. That’s a perk of the job. Imagine this, right? So you go to a website and you get to choose your car, but I also want fancy rims.

I want leather seats and I want a fancy stereo. Your boss is not gonna pay for that. Right? So you have now an eCommerce system, you have a CMS and you get everything on the page. You go to the checkout and how do I now make sure that the car part of what I want to lease is approved by a third party because the job where you work will have to approve your choice because of pricing, stuff like that.

Right? So, but these rims and all that other stuff, you have to pay that for yourself. So what you effectively need is a different route [00:33:00] for getting approval for that car and getting that for free, but then paying the rest themselves, but then still get one car with everything connected. So what you see is you plug in a microservice or a serverless function or whatever that grabs the basket or the order, splits it and then talk to the eCommerce system, talks to the approval system, talk to the payment system, and then effectively creates two orders, puts it back and gives that back to the front end. So you can show, hey, this order you pay for, this is what you got for free. And it has been approved. Now go to the payment system. Microservices are the perfect way to make that happen because this is such a crazy use case. And an eCommerce system is never gonna build that in. These makes sense in this kind of complex use cases.

Sam Brace: And I think that’s where looking at something like the MACH Alliance, but also as you mentioned, an SI, is that with your example, it actually helps you to understand like what the differences between fancy rims and the [00:34:00] differences between the wheels or the, the back like steering wheel, like what are the essentials? The things that I can’t not have, and I don’t wanna miss in that way, you can see the list. Okay. These are the types of things that I have. These are the types of areas that I shouldn’t be thinking about or should be thinking about.

And I think that’s where having the consultant, have a system integrator coming along, they can point out to you. Like these are the things that are essential as part of your architecture. Yeah. And also these are the things that are nice to have.

Tim Benniks: Exactly. And the words, MVP, minimum viable product starts to have more meaning here.

Right? And so you, you find what is minimum great for your business and you find the tools to put together and make it happen. And then you can iterate. And the beauty is of a MACH architecture or something composed like this is that you can choose, okay, this month we’re going to iterate only on that surface that approves my rims or approves my car.

Right. Because you can then only work on one part, make it performing better or add some [00:35:00] features. And then next month you work on another part. Imagine if you had a monolith, you would have to work on one part, but always deploy the whole thing and then do try to test the whole thing and all the regressions that you could have because you’re working on a monolith and you cannot separate things out.

And so it’s really interesting to make a good architecture where everything is composed in such a way that it’s much easier to work on and iterate on and scale even. We’ve seen projects where during Christmas, the wishlist is used much more than actual checkout. That happens later. Right?

So what happens if you suddenly have a million people using your wishlist? You’re gonna have to scale that service up, right? You and I add a bunch of more microservices or whatever, make sure that that works. If you had a monolith eCommerce, you would have to scale up your whole system, including all your databases and how can you scale databases?

That’s really hard because then you have session management. Otherwise you can check [00:36:00] out with somebody else’s basket, cuz you have multiple databases now. And there’s many stories around how hard it is to scale something up. And with MACH architecture, you can just scale one thing and pay more for that one, but not the rest.

And then suddenly is where all this enterprise stuff is gonna make a lot of sense.

Sam Brace: That’s actually a really good point that you’re making there. Cause it is something that we even see from the Cloudinary standpoint where when you have a situation, let’s say that you go through a peak business period, like you mentioned the holidays, or we’ve seen where customers get featured on like Shark Tank. So like, boom, everybody’s paying attention to you. So then your image bandwidth, your video bandwidth, it just skyrockets, but it also very clearly is gonna go down at a certain period of time. So knowing how to scale up that microservice in that case, Cloudinary makes perfect sense. And yes, there are other things that are tied to image bandwidth and video bandwidth, but it’s not where I suddenly have to scale up everything that’s part of the stack.

So I think you’re making a huge connection there and hopefully people are starting to see like [00:37:00] how that can be, where it iteratively grows as your business has those ebbs and flows in traffic, in attention.

Tim Benniks: And isn’t it nice that all these best of breed tools are all cloud based and therefore have their own CDNs and DDoS attack prevention and SLAs?

So when you know images are gonna be hit hard, as an architect, you’re not that worried because you know that this best of breed tool will just deal with it. And if not, you call them up and then you deal with it. And so you’re not like, of course you’re responsible for your whole architecture.

But in that sense, you’re quite safe because it’s not, um, how can you say this? Like, it’s not a pile of rocks that you put on top of each other, where if one is out, everything falls down, it’s actually a bunch of stuff that is just laying in a circle. If one goes down, the rest still works and then you just plug the one back in and the circle is complete again, it’s a very different approach. And so at scale, that’s gonna help you a lot.

Gary Ballabio: It’s really interesting when [00:38:00] you said about, they may all have different ways to deal with, you know, vulnerabilities or attack scenarios. That could be good. I mean, could be bad too. There’s just a lot of like internal people inside of the company who may have…

Tim Benniks: Oh yes. Well, let’s be honest. If multiple things fail, you’re gonna have different processes to escalate. Yeah. It’s it’s, you know what they call it web development for a reason. The word development is in it. It’s really hard. Let’s be honest.

Gary Ballabio: Speaking of which, for anybody who may be working with a monolith right now, or just like right now considering going down the path of this type of architecture, well, what is your recommendation for how they go about doing that? What’s the best practice or the first step that they can take, assuming they’re running in production today?

Tim Benniks: I think there are two ways, and I’m now speaking from experience of working at an SI for a long, long time. And so one way is we’re just gonna do a greenfield big bang. So we let the old system work.

And then in a year, we built the whole new system and then just [00:39:00] replace it. And some companies love that. Others not so much because your stakeholders also want to see progress every quarter, let’s say, or every month, for example. So one way is the big bang thing where you train people separately on the new way of working with it and you just switch and everybody’s happy, but it takes some time and it’s expensive.

And then we have the other approach, which is probably more realistic for a bunch of brands out there is find a way to start your new system, but then integrate the old system a little bit in that. And then, so like I’ve had a project for example, where we had to separate the front end from the back end because a release flow was 48 hours.

And it was crazy. Even for a CSS change, like a styling, it took that long. So we had to separate it. So what we did is we made a new design. That new design was applied to the old website. So all the stakeholders saw, hey, there’s cool, new design, new things are happening. And [00:40:00] at the same time we were building the new system and that new system would then every month or every sprint overtake a page of the old one.

So it’s just a DNS change basically. And so after six, seven months, the old system was no longer used and the new system had taken over these pages and the designs that changed were just maintained in both. So what that means is you’re giving a sort of a safe path towards going to that new thing over time.

And the interesting thing here is if you have an orchestration platform where you can plug in multiple things, you could actually make a new website, all fancy front end, and then plug in the old CMS. Even if it’s legacy in Uniform’s case, we can also handle legacy CMSs. Plug it into the system.

So you can still work in your legacy CMS as you are used to, but the front end just queries it differently. And then over time, certain components just come out of a new [00:41:00] system and certain come out of the old system. So as a brand, you have a safe path toward modernizing things. And also that means on the governance level, you can start teaching people how to edit or marketing things or do data management in the new system, but you don’t have to do it in a big bang where everybody suddenly has to change.

You get your own timeline, shall we say? And that’s generally the safest approach, but you can imagine there’s lots of organization going on if you have to do this.

Sam Brace: I’m gonna take Gary’s question and apply it to the vendor, to the SI.

Let’s say that I’m a vendor listening to this conversation. I’m an SI listening to this conversation. I say, yeah, I actually feel like I align a lot of my values, a lot of the ways that I work with clients, work internally. Maybe I am a microservice. How do I get involved with the MACH Alliance? What benefits do I even have for getting my foot in the door with that overall team?

Tim Benniks: A great [00:42:00] benefit of the MACH Alliance is the fact that there is an alliance of smaller players. Like for example, Cloudinary is not a small player because you’ve been doing it for so long, even bootstrapped. But there’s other players like Uniform that just started and there will be many more smaller players playing against the giants in the field.

Wouldn’t it be great if we had an alliance of where we have validated that all these smaller tools work really well, cuz they had a rigorous process to get in and then we can actually say to brands that want to use it, it’s actually not that scary to go with a smaller or newer company because they’re in the MACH lines, they have been validated.

They have the stamp of approval and that’s a great power to have as a vendor, as a microservice or as a SaaS system if you have been approved and you’re in, you can say, hey, but we also play in that MACH space because we are approved and suddenly you get the foot in the door and pitches are [00:43:00] much easier. And of course there’s a pretty big community around the MACH Alliance.

And especially now that’s ramping up, there’s lots of conferences going on. There’s people that write insights, articles. And so this is one of those things in that community that will hopefully help people. So it’s also just a place to be as a SaaS project or company, for example. To be able to actually get in it, that’s very interesting. There is a technical council, which I am a part actually, that evaluate people or companies, SIs, or a whole bunch of different ones that actually want to come in to this alliance. And so there’s different criteria. Like you can be a vendor like Cloudinary. You can also be an SI for example, like a Valtech or an Epam, like an agency, but we also have a new category called Enablers, which is something like Netlify. They help you to enable to[00:44:00] run your website. And so they’re not actually a MACH vendor, but they help you to make that architecture will happen. Like Amazon could work, for example. And then we have one last one, which is the Ambassadors. And so Ambassadors are individuals that are really excited about the MACH Alliance, but their company is not part of the MACH Alliance or not yet.

And so they’re basically making sure that where they work and in their community, people start to hear about this composable stuff, about MACH Alliance, about architectures. And we have a whole bunch of these ambassadors and they are amazing cuz they have so much knowledge of how to do projects in multiple ways. If they can be an ambassador for the MACH Alliance, they can try to sell it in, but they can also change their company in such a way that they can actually apply to become a vendor or an SI.

Sam Brace: Tim, it sounds like we have a lot of information that we provided to people about what MACH is and with all the things that they need to know about it. In terms [00:45:00] of you obviously being a developer advocate for an up and coming company like Uniform, if people wanted, just to see the latest and greatest of what you’re thinking about, especially around these types of topics, where can they go?

Tim Benniks: Oh, there’s multiple places because nowadays my job is to create content around this stuff. A year ago, I didn’t even think I would do that, but here we are. You can go to my personal YouTube channel. Look for my name, Tim Benniks and you’ll find it. But in the name of Uniform, we’re doing a lot of content to educate around this as well.

So you can go to uniform.dev. You can find this on YouTube also, or on the Uniform website. Because I dropped that name here and there, because it’s such a new, interesting way of working in these architectures and there’s no other options or some maybe, but not wide enough to have spoken about these here.

So I do apologize for saying that name here and there, but it is actually a very interesting thing to have a look [00:46:00] at it, how you can compose with these headless sources.

Sam Brace: I think you have a great website as well. So timbenniks.dev, if you’re trying to get the latest and greatest for what you do, it’s, it’s a well built website.

So you’re trying to see how things are done, as you pointed out, it’s built with MACH.

Tim Benniks: So this website has Cloudinary, obviously. It has Algolia, it has Contentful. It has Prismic. It’s running on Vercel and it’s in Jamstack with Nuxt. So lots of things combined.

I have to talk about this stuff, so I have to work with it as well.

So why not go all over, you know, go for it. And so there you go. And it’s working pretty well.

Sam Brace: Well, Tim. Thank you again. Hopefully we can have you some time back to talk more things MACH, maybe things that are just tied to overall development in this space, but it’s been a pleasure having you on the program.

Gary, any final words for us to be thinking about in terms of MACH from your side of the house?

Gary Ballabio: Not at all. I just wanna thank Tim for the time. Loved hearing you talk and learned a lot from you today, so thank you for that.

Tim Benniks: [00:47:00] Awesome. Thank you very much guys. Absolutely.

Sam Brace: And make sure to come back for our next episodes of MX Matters, we’ll be talking with people just like Tim, the visionaries, the people that are overseeing the changes with visual economy and the trends that are taking part of that. So make sure to Like, and Subscribe, so, you know, when the latest and greatest episodes are coming out, just like this one. From all of us at Cloudinary and the MX Matters team, thank you, and we’ll see you next time.