Podcasts

We interview Arron Moss of Zero-1 and MDOQ this week on helping developers automate their Magento CI pipeline and how this saves big money for merchants

MDOQ automation and SaaS

Brent: All right. So you haven’t seen last week’s episode, but last week I did start with some music, and it went, dih dih dih dih did do. Oh, you saw the preview. Yeah. So 

Aaron: [00:00:18] Deryck, yeah. Deryck, was it? That was it. 

Brent: [00:00:21] Yeah. So it hasn’t been published, but we do some music now. And, and so if you wanted to do the intro music, that would be great.

So go ahead. 

Aaron: [00:00:28] What’s it? To tap a tune? 

Brent: [00:00:30] Yeah. We’re just looking for some really good intro music. So if you could do maybe a 15-second song as an intro, that’d be fantastic. 

Aaron: [00:00:42] God, on the spot. Did do do do style?

Brent: [00:00:45] Any style you want, this is open mic. This part…we’ll edit this. So don’t worry. I’m not going to put anything embarrassing. 

Aaron: [00:00:54] It Probably got to be about five or six seconds. Did something that Springs to mind actually [00:01:00] did it du, du, du, du, du, du, du, du, du, du OU, which is from a well-known that UK TV program?

Brent: [00:01:07] I used to have UK TV anywhere before it got shut off by the BBC.

Okay. 

Aaron: [00:01:14] Yeah. 

Brent: [00:01:18] All right. That’s good. Do, do, do, do, do. Perfect. All right, Aaron, why don’t you introduce yourself? Introduce your business and tell us what you’re, what you’re doing nowadays. 

Aaron: [00:01:33] Okay. Yeah. So my name’s Aaron Moss.  I’m a CEO and founder of a little-known company in the Central UK in a spot town called Boxton. The agency’s called Zero One. We’ve been an Ecommerce agency formed in 1999, and we’ve been a devoted Magento-only SI since around 2009. I believe we first looked at Magento at 1.3. And, as a business predominantly working with open source and probably OScommerce at the time, gradually as many others did, got bitten by the book, of making the platform work well for, then smaller businesses and startups. And we’ve really grown with the platform over that time now. And probably right in saying that maybe we are still one of a somewhat diminishing proportion that is still solely working with Magento. I certainly know many agencies are perhaps looking at more than one platform at a time.

I don’t know if that’s a strategy that I’ve [00:03:00] consciously and made the decision over. It’s just pure British stubbornness, to be fair. But I think the devotion to a single platform in my mind will certainly pay dividends to us, I hope. And the way that we’ve I think, capitalized on that, that focus.

And that’s it. And we stand here today, really like that business, but in two forms, I. I an SI in a more traditional sense. And like the holders of a product that is about to extract itself from our traditional business.

So we sit here twofold in a sense. 

Brent: [00:03:54] Yeah, that’s great. And I think you know, just to get down to the nuts and bolts, what I wanted to talk about is, [00:04:00] is the product you’re doing MDOQ, right? Where you’re helping developers and essentially then merchants streamline the CI process.

Would that be an excellent way to look at it or a development process inside of Magento? And I don’t want to get into it. 

Aaron: [00:04:20] That’s a great start. And actually, not getting into the technicalities of it is an amazing help for me as we take the product forward because this is the most challenging aspect of bringing the product to market.

We could describe it in many ways, in simplistic terms. It’s a tool belt. For the Magento application in one sense. Yes. It includes key components such as pipeline, deployment pipeline. But there are a whole host of other [00:05:00] areas of the application. All founded around automation.

And I’m going to steal. I’m going to steal an analogy that I tripped across courtesy of Mr. Marks last week. MDOC is the glue in between this freedom of open source and the constraints of SaaS, which, as he perfectly put it, the guard rails, these, the doors are locked. The guardrails are up, and open source, as with Magento, has been both its greatest strength and greatest weakness over the years of that sheer openness to the platform. There’s protection in the middle, as, using the metaphor of guard rails, we believe MDOC is giving that unique kind of central [00:06:00] position to the benefits of both. You can protect the platform with automation and shielding, or most so, you can have the power of open source without necessarily locking the door and closing and throwing away the key. That’s a work in progress analogy. So we’ll see, we’ll see how that one gets received. And I might work on that. 

Brent: [00:06:29] I think just to educate any merchants, the idea of how you would traditionally run a website is that you or your developer would log on with FTP or SFTP or something and modify the code directly on the server.

And hopefully, it works. And sometimes it doesn’t. Sometimes you break things, and then you scramble to figure out what you want to do. Along came version control. And then we [00:07:00] we would publish things to version control and then publish things maybe to FTP.

But again we’re talking directly to the server. Certainly, this was a habit of many developers. And then along came, and you can help me here, but along came compilation that would add a little bit more complexity to the build or let’s just call it the complexity of the actual running website.

The compilation has nothing new to say .net or some of these other technologies. But Magento2 would then compile itself. And allow for a faster runtime on production, but it also meant that logging in with FTP and just modifying a file which again was never good practice, ended up being even worse practice in this case.

[00:08:00] So the traditional route for some developer now, or has been for a long time, would be to work on your local machine. Publish that to a development server, or sorry, publish it to your repository, which then would get deployed or published to a development server, staging server, production server, or wherever you’d like to publish it to.

So. I think this is where you’re going to come in. What we’ve seen is the complexity around those builds on your local machine, especially with some of the new technologies that have been introduced into Magento, are making that even more difficult. And I think MDOC now comes in and helps us, helps any developer get onto a project quickly.

And I know we spoke before that the time for a local setup has [00:09:00] grown and agencies have to start looking at how much time each of their developers is taking to make that local setup work, just to get started or get their development going because they have to get that running on their local machine.

Aaron: [00:09:18] Yeah. I mean, you’ve explained, I think, the key challenges of us as a business. And I think one of the pieces of background from our SI agency really, a key factor is, as you’ve just explained, tying this to, effectively, preparation time to become a billable asset as it were in the agency world.

I recall the first insight we had into this was from Gary Specter. It was on a partner call with Magento probably [00:10:00] five years ago, very early days of the Enterprise Cloud launch. And they were pitching Enterprise Cloud Edition as the early stages of the business as it was comin,g to market and said they’d surveyed all the Magento SI’s, and the aggregate estimation for preparing as a developer to carry out some work on the Magento installation was 1.5 days. And I thought, wow, you know for us, we’re a small agency, and we love working with the application for smaller businesses.

And quite frankly, for the majority of small businesses, and we do focus on open-source, many of those businesses would struggle to bear the cost of the person-hours for 1.5 days for a lot of the small iterative pieces of work that we do anyway. [00:11:00] On a typical day where we’re rolling out two to four-hour developments in a very iterative kind of CICD way, you know, so deployments are happening all the time and to effectively like potentially top and tail with prep and two-way and the rest of the acceptance process at the end, a two-hour piece of work, you see this massive inflation and what we can assume might culminate in this heightened TCO. That is the kind of hot topic at the moment. So the platform costs for us would just be unrealistic for smaller businesses. So we took the learnings from some of these really large clients that we’ve had the fortune of working with. And we developed the process. Everything that we did was about [00:12:00] 

It was about replication, and it was about taking a process into becoming automation. And then it eventually manifested into a product that’s becoming quite rounded. So one-click replication, you know, so. You click a couple of buttons, and you have, what is as near as we can get a, certainly a development environment, but to feel as local as it can very, very quickly.

And quickly, generally between five and 20 minutes to have a fully functional instance ready to work with from a development or a QA or support or exploration or a sandbox basis. And we realized that when we had the early [00:13:00] seed of this that we felt, for us, we had something that we could take forward.

And we’ve just continued. We’ve continued, albeit on the time-saving aspects of what it began to deliver a few years ago. And actually, we’ve been able to put more and more of our internal resources to make it better and better and better. Yeah, so we’re delighted with where it is today.

It’s used quite extensively by a number of businesses. And we’ve got some exciting prospects. And as you mentioned before, the other complex application stack, precisely as we move now towards headless and PWA, gets ever more complicated for an individual, say, software engineer, to get a [00:14:00] local working environment. So we believe remote, you know, RDE’s with automation around infrastructure replication, but we hope that that’s where the industry will go, you know, and it seems to be the case. We’re getting really strong evidence. Now we’ve got a couple of larger clients who were doing Magento PWA projects and were using Vue storefront. Spin up working view store from dev instances within minutes with no, no localized or DevOps or local infrastructure requirements and to be working and delivering code, usable code to that wider application that they don’t need to become involved with is very excited and some of [00:15:00] the customers that are using it getting excited about the speed that they can deliver kind of project iterations. So, yeah. I don’t know if 

Brent: [00:15:12] I think I want to key in on that five to 20 minutes and that may be a lot of merchants don’t understand the amount of time a developer could take in creating their local environment and especially a new person who’s just been introduced to the project.

I would even say that a developer then who is primarily front end, who would, maybe he or she isn’t that familiar with some of the intricacies of some of the parts of Magento, they might spend a little bit more time or they need some help from a senior dev to get some of these things running the solution that you’re offering really for five to 20 minutes. If we’re taking an average of four hours or three hours or whatever that timeframe is, depending on the level of the developer to get it up and running. Certainly, [00:16:00] if it’s a longer-term project and you have a developer working on it in the long term than four hours or three hours or two, whatever that timeframe is, is negligible over a two or three month period–but having an agile group and having the ability to bring in front end developers to offer and supplement work with the realization that.

Hey, we’re going to get in here. We’re going to get up and running in five to 10 minutes. Wow. That’s fantastic. And I think it’s very difficult for a merchant to understand that and the need for that and the complexity and how much time that will save. You also spoke a bit of the whole process, the QA process, and just bringing somebody in for, let’s just say the merchant has something they’d like to do. It’s sort of last minute, and their regular developer’s on vacation, and as an [00:17:00] agency, you want to be able to help them. Having the ability to easily spin up an environment and do that quickly is imperative. So I think, you know, if you could just speak a little bit to the fact, I mean, to how a merchant should be sort of looking at the time frame from code to get to live and how can they, how can an agency improve that timeframe? I think that would help everybody understand the importance of what you’re doing and how that will really help developers over time.

And then I think at scale too, the more developers you have, the more complex it is to keep everybody on the same page. 

Aaron: [00:17:49] I think the key, the key for me is, and this could be why, whether we’ve got this right or wrong, [00:18:00] this has been my kind of firmer opinion of the last couple of weeks, a couple of years in particular.

With respect to let’s say that the DevOps culture and the practicality of, let’s say, deployment pipelines. Now there are commercial pieces of software that you can work with that can help manage that process. But if you look back over the last ten years at other peripheral sectors of e-commerce, then let’s take email marketing.

Now that is very much ten years ago, the whole mechanics of email marketing and how that evolved into becoming intelligent with not necessarily even AI, but the level of benefit and progression of how static emails to global marketing email [00:19:00] marketing lists slowly progressed through the innovative thinking of the agencies and the merchants on how they could be more successful.

And then slowly over the years that became, it became the intellect, which then eventually became the product. And obviously, now we have a very flourished market with businesses that have very rounded, powerful software solutions that encompass things like AI. So you’ve got Dotdigital, and then obviously you’ve got this whole visual merchandising sector as well, and there’s undoubtedly a convergence between these. Now in DevOps, there hasn’t been this breakthrough. These systems are all very much backend and seem to be always retained as being within the intellectual property typically of the agency if the merchant is small. Or if it’s a [00:20:00] prominent merchant, there’s usually some hazardous assets, probably the best way to explain. With DevOps engineers, that again, it’s not an open policy and it’s not an open kind of culture. It’s usually key people within the agency, within the merchant, who actually hold the keys to that kind of process and the progression of DevOps within a business.

And what we would like to think is that like any other sector that evolves alongside e-commerce, it needs to, as it can break into commercially competitive products that can bring, introduce automation to all these processes to effectively, as I said earlier, is to get the protection and to fight back with protecting open [00:21:00] source with software automation that kind of brings this utopian best of both rarely between open source and SaaS. And that’s what we’re trying to break through and try and convince the industry that that opportunity is, we feel, the single most, let’s say fruitful, way to reduce total cost of ownership, certainly for a platform like Magento, because the colorful array and stark difference in costs from our size and merchants and all people delivering on the Magento2 platform for us is worryingly disruptive because of that. There doesn’t seem to be any leveling of costs.

And that for us, one way of controlling that by introducing that kind of layer of application and automation that we hope will bring a bit of stability to ownership costs for the platform. 

Brent: [00:22:19] Yeah. So let me just speak right to this whole SaaS versus the on-prem or self-hosted platforms.

And look at it from the merchant’s point of view traditionally you know, when we did go, when we were just doing things with FTP, the process to update your website was fairly similar, you know, I guess in the SaaS world, you would go log in and make some modifications to your theme. The more complex your theme is, the more skill you’ll need in doing those modifications.

And I guess I am assuming because I’m not a hundred percent sure. Still, I’m assuming there’s some version control and the [00:23:00] theming inside Shopify or something that somebody, somebody will correct me if, if there isn’t version control or if there isn’t wow, that’s going to be horrible. But I’m assuming there is. In the traditional FTP world, there was no version control unless you had it on the server itself, which, you know, a lot of agencies would do.

Then, you know, from a SaaS platform, you probably have a staging environment that you could publish. Those changes to a live environment. You want to do some kind of testing. I think what you’re saying is your solution is very similar to that process where even a merchant who had some light development knowledge or just had to change a color and a CSS or something like that could log into a staging server.

And if they had the same sort of skill sets, they could, you know, I’m just very theoretical here. They could modify that code on the server and then publish that [00:24:00] to live. 

Aaron: [00:24:03] Yeah, I think that’s sort of an excellent attempt to bring me back to the simplification that I need to be able to communicate as we take the product forward because I’m often really dragged into much deeper conversations now.

Yeah. And another way to put it is let’s take a couple of current real-world scenarios. So if you are, you’re on M2. And you want to look at a PWA or, let’s say, somewhere in the middle. You want to look at the Hyva implementation. Now you may be a merchant who just wants to bring an expert in who’s got a year’s worth of experience in Tailwind CSS, doesn’t care about the Magento infrastructure application, the staff, or anything he’s just [00:25:00] brought in because he isn’t, he’s a Tailwind guru. Now, this fully facilitates the fact that you can spin up a replication from production. It manages the source control branch off, and it gives you, effectively, root access to a server that is in total isolation.

So you can go and do what you want. You can allow, with just the provision of an SSH public key, that individual to do anything to run havoc if they wish to because you can destroy that infrastructure, or you can click a button. It will analyze the file structure, and it will report back a suggestion of what’s going to go into source control.

So you can accept that work back in. And this is for me. This was the missing link. And the failure and demise of the, [00:26:00] what was with Magento 1, the connect system and the admin system. And in the Magento 2, it was, I forgot what it was called, but it died in 2.3.5. They removed it.

So, kind of the extension connector interfaces without the marriage of changes on the Magento application to source control. You’re left with the only risk, you know? So we couple those things together, you know, so that we can install a module and the system knows exactly what’s been done.

So you’d give a Hyva expert access to a server and tell him to go and do what he needs to do. And he finishes at the end of the day, and you click a button, and it will say. Here are the changes. Now we can accept those into source control, and you can click another button, and we’ll go running regression tests all night and deploy automatically if you [00:27:00] want.

If you’ve got outstanding regression tasks, automation is just, it is the future, and it sits. It sits nowhere in, in the accessible commercial domain, as a, let’s say, as the productized agency, which is why we get such disparity and confusion with the marketplace and TCO that is at the mercy of the agency.

So yeah, I think we take that culture outside the agency and put it independently. And it means then that the merchants have better platform control. They feel like they have more control over the application because they do, and the agencies and the experts can work more independently because the kind of [00:28:00] operational culture of the website in terms of its progression doesn’t need to live externally to the merchant. It can belong. So it’s agencies can deliver code to source control, and that’s their responsibility for doing application infrastructure. That’s what, that’s what platform as a service is. So that just basically takes control and makes it more independent.

Brent: [00:28:23] Yeah. And I think from the merchant, so again, looking at this through the lens of the merchant, if they sign up for a SaaS-based solution, like BigCommerce or Shopify, they don’t care about the infrastructure. They don’t care how the code gets to the server, but they just want it to work.

And you know, I think the reality is that merchants on Magento would also like it to work, but they would also like to do everything they want to do inside of Magento or inside of their application, which they can do anything. Yeah. So we you know, we talked about some simple things that can get easily published [00:29:00] to production.

The reality is that there are some very complex things that are not even possible in a lot of the SaaS solutions that as a developer and as an agency, this helps you to get those things into production, much quicker and much more efficiently. And I’m just gonna, I’m just going to go out on a limb much more, with a lot more safety in terms of visibility on code, visibility on how well that code works in a near-production environment, and then getting that code live and even let’s just say that it is you, that there was something missed in QA or something missed in UAT or there is some third party that’s on the production that nobody tested and it didn’t work. Going backward is also easier, like some regression or some return, a one-step back.

Do you agree with that?

Aaron: [00:29:57] Yes, absolutely. [00:30:00] Yeah. And I think this is whereas a business, I suppose, beginning with its passion and eye on the smaller business that, you know, to be fair, the majority we talk to. Probably glaze over if we start talking about deployment pipelines and, you know, in some cases, regression testing. I think that visibility and exposure of authors as an agency to those enterprise-level businesses where that level of operation is is an absolute necessity to de-risk.

You know, they, a hundred percent is almost. I mean they call it now configuration as code. This is where Magento is going. It’s to have to jump into a Magento admin system and frantically configure things. Cause code is just gone live at the same time. [00:31:00] That’s where we lived in Magento 2.2, and certainly Magento won.

And as that has progressed and we now have this evolution and this concept of CAC and configuration as code now, thankfully, I thank the Lord. We can take the exact configuration of the Magento application alongside a new code and deploy  live instantly at the same time. So the configuration all happens in unison with a deployment that just de-risks so much, and it’s been such an eye-opener for us to be able to take that methodology down to our smaller clients because with many of those, it doesn’t take much in terms of, you know, disruption. And we understand we want to be deploying 50 times a day. You know, if we have to have operatives and people who are skilled to go into Magento admins [00:32:00] for smaller businesses and go jumping around, changing.

Configuration and tuning, and configuring the new module that’s just gone live. It’s not there. It’s not the scalable progression of the application. And I think as those features have been introduced to Magento, rightly so it points the progression further in the sense that there is almost an inbuilt deterrent from maybe working in Magento admin too much to configure the application, you know, with this new ability to lock the configuration down to give people less of a reason to be interacting so much with the application, but we’ve seen it.

We’ve seen it so much where you can go into Magento admin one or two. [00:33:00] And change a setting and cause a problem, you know, and I think to take even that aspect. There are small merchants that probably wouldn’t like this, but when you show them the benefits of everything going through a process of automation and therefore baked into source control, then changing and setting in system config here away from production, never in production, away from production that even itself as a configuration change, go through a regression process.

Then we start to understand that. We are, without locking that door, we are moving towards SaaS without becoming SaaS and, and gaining both benefits and flexibility, you know, and that’s for us in smaller businesses that are showing a remarkable opportunity in again, [00:34:00] cost reduction because we’re not mopping up. We can click buttons and deploy and know that we don’t have to have three or four resources ready to pick up the pieces after because we just, all we need to do is increase the regression testing and the processes in pre-production and production starts to take care of itself, you know? 

Brent: [00:34:26] Yeah, I want to key in on two pieces there. The first piece is the ability for the merchant to really screw up their store. I’ll just be very blunt, really screw up their store by just logging into admin. It can happen in anything. You can screw up your eCommerce or Shopify, or Magento. And I think that you’ve brought up a great point that they should be screwing up their store in some non-production environment. And getting into that habit. So the first part is, you know, just doing the habit [00:35:00] of playing with some of these things, and your typical merchant would never log into staging just to see what happens when they click something.

They would most likely log in, click it in production, and if it breaks, they would go back and unclick it. The unfortunate things that happen in real life are that they’ve clicked it. And now, suddenly, they’re locked out of admin. So, the ability in a set now they have to call some, you know, some call center in some far off land.

It could be Newcastle. Who knows. And try to restore that but getting into the habit of doing things in an appropriate way and educating the merchant on how this should happen is, I feel, the first step in just best practice around e-commerce in general, not Magento, not BigCommerce, not Shopify, not any of those other platforms, Shopware.

Helping them to understand that, yes, [00:36:00] the code should go through this process, but even the configurations should go through this process that will help them to be better, I think, a better merchant, but also just a better store owner and understanding that some of the things that the store owner does will impact their production environment and what they could be doing or, you know, a lot of people are going to have a staff. What their staff is doing is impacting their live site and how that live site impact will reduce their sales at some point if it stops their site from working for an extended period of time. 

Aaron: [00:36:40] Yeah, absolutely. I think in, taking well, similar kinds of analogies from other areas of both Magento and other industries.

I mean, you have the concept of, take the enterprise staging, for instance. I mean, that is a feature that allows. [00:37:00] content to be staged before it’s made live or from a marketing perspective, planning and visibility of a marketing event in the future. No, again, that’s for us.

It still doesn’t really encompass everything the whole, the whole application, you know, they’re always, they’re always individuals within a business and the more that can be involved, the better, the more innovative the companies, the more accessibility of any kind of staff members involved to get access to, call it a sandbox environment, an environment that they can do anything with.

The more they can, the more value they can deliver to the business and potentially drive that business forward. And that is not isolated singularly at marketing events. It’s the whole Magento application. It’s how I can maybe use this new feature to [00:38:00] understand how, whether this configuration is better or this method is, you know, this extension could be used in this way.

And to sandbox that somewhere away from production, as you say, is absolutely what it de-risks, what’s happening in real life now on production. And it gives you the safety net of doing it away from production, and the fact that it is an infinitely replicable system that you can clone 20 instances of production means that there are not individuals tripping over each other.

So you’ve just done this. I should just knock this out that, you know, you can have individual instances, or you can work on a team environment for a particular activity again like, content staging, but it starts and stops at contact staging for planning marketing events. And it, of course, that’s only a commerce feature, so it’s, again, it’s one of those things that doesn’t serve the community and the open-source customer base. So we had this thought two years ago, and we quite simply built it into the infrastructure. It was a system time change. You can spin an instance up, set the system clock on the container that runs, and just say select this future date to next week.

And then all the facilities of open source that can schedule campaigns and design changes and rules were effectively there in commerce because you were setting the system date on there, on the installation to two weeks in the future. So that one could work, but just turning it into the enterprise schedule because we’re setting the date to two weeks ahead.

That’s just another, another byproduct, really just an excellent brainstorming session. Still, there are so many other ways of really drawing much more out of the Magento open-source application than really getting credit for it at the moment. I think that’s the main reason. The open-source and the community are relatively quiet, and that is both scary and, in a sense, disappointed.

 I think there needs now to be a resurgence to really not bite back, but push out this content and show the world really how amazing Magento Open source, in its foundation, really is. 

Brent: [00:40:42] Yeah. So three points, and then I think we’re going to run out of time.

The first point is just the education around the sandbox idea, and the reality is the merchant should already be used to sandboxes if they’re running PayPal or any payment gateway. They want to make sure their payment gateway works before they [00:41:00] go live. They all give you the ability to do a sandbox.

Yes. Sandbox should never be something the merchant doesn’t understand. And if they don’t do that as an agency or developer, you should be educating the merchant about this concept of a sandbox. And I think that you brought the idea of a sandbox right upfront. And a big differentiator, I think, between what you’re doing and what a SaaS version is doing, or even the traditional way of running a Magento store, is the ability to have ten different environments and how many people have a merchant that has so many great ideas. They want to test every idea every day. But that idea is stepping on this idea because.

Developer A is working on this, or Developer B and the merchant is saying, we’ll just add more people to it. Okay. Your solution does add the ability to theoretically add more production people. [00:42:00] Because we can segment that development process into thin little parallel silos that then can be merged in later.

So I think those are the, you know, the sandbox thing and the ability to have all these different environments. Indeed, the different environments are something that is a big differentiator from the traditional SaaS model. But you know, I think that would help merchants see the value in what you’re doing and help them to understand that that value will get their code live faster, even then in something, you know, like a SaaS environment.

Aaron: [00:42:42] Yeah. I think that this conversation we have quite often with businesses of all sizes. And I think it boils back to this [00:43:00] concurrency, I think is the one key thing that you honed in on. We have some larger clients that we invite to exploit the application because it could be QA’d. It could be exploratory. It could be training. It could be bugs. It could be a small feature, a subset of a much larger delivery. We’ve got some clients that have up to 50 concurrent instances. And what that does is creates independence. Then it creates an opportunity for brand new ideas to go straight through to production, obviously critical issues to be independently fixed and go straight through.

And, and as we know. The business has changed and adapted almost daily. So what could be a priority to the business last week that might change next week? So a concurrency level to allow the [00:44:00] streams of work and ideas to change pace means that it buckles this tradition. At the same time, the rest of the business can only really get visibility of that feature in three weeks because UAT, which is usually the only kind of accessible point that the business receives visibility, is there and not behind another two work packages or there’s a bottleneck because it’s a single stream. All these instances are globally visible at any point. So for us, things that stop, start decisions, people go on holiday, and all these are the normal business activities that can slow and speed up individual streams are facilitated.

Brent: [00:44:48] So I have my last point that I wanted to talk about, and then let’s just recap what you just said. And I liked that concept, the concurrent concept. Still, the reality now is that headless will necessitate merchants to look at some hosted solution, like a PWA, and that they have to continue to think about how that code gets into production.

So I think Magento’s is an excellent example of how you can run anything headless on top of it. But BigCommerce now allows for any PWA, and Vue storefront has a solution that runs on top of BigCommerce. So you know, making sure that your developers understand that process, even in a SaaS environment.

And how that can help the merchant, the agency, the developer to streamline the process of getting that code live no matter what backend solution they’re using. It could, you [00:46:00] know, at some point, it could be Commerce Tools, or it could be Shopware. There’s an infinite amount of solutions that the MDOC solution can provide that would help the entire workflow happen faster and more efficiently. And I think the key is that it happened safer. 

Aaron: [00:46:23] Hmm. Yeah. I mean, with PWA, we looked at PWA. We looked at the customers that we had at the time. And at the time, we made the firm decision to focus firstly on the storefront.

And we now have a facility and support within the MDOC Application for Vue storefront as a stack. And to answer a couple of points there. It’s [00:47:00] broken into almost a three-layer application stack independently and managed with MDOC in that you have your Magento backend and the headless stance, you have your caching layer, which is the view storefront API, and you have a facsimile view storefront instances. And those three components not only can be independent but that now we’re for some significant benefits with the right kind of infrastructure and the orchestration in place. So that. Let’s say we can have a development backend. Now maybe you need to carry out some work on exposing, let’s say, a point system, you know, developed a point system on open source and now needs to be in the backend to exchange the relevant data. That needs to be exposed to a new development at the API layer [00:48:00] and involves the storefront API work, and that it could be that you can spin off five or six instances all referencing that particular API layer, which is still in non-production, that’s still an active development. Still, you know, the people developing, you know, the JavaScript guys here, you know, someone developing a user interface for points and redemption and checkout are all entirely independent. So I’ve got something ringing here, but I’m not quite sure what it is. 

Brent: [00:48:38] Yeah, and that’s a great point. Having the ability to segment out those different processes allows for the future ability for new features to be introduced, and [00:49:00] there are no restrictions on this that would preclude someone working in a traditional Magento environment.

If they’re working in a headless environment that could be doing the same thing, just decouple the backend, moving a new backend, your two frontends, and in that scenario, your two friends and items are still going to be the same. 

Aaron: [00:49:25] Yeah, absolutely. Yeah, I think that level, that the slicing up, particularly with your storefront, would have been three key components.

It affords that progression almost marries, thankfully with the direction that we’re going in is we’ve got to introduce this automation because you know a heavy Magento backend requiring all these application components with elastic search Redis in the middle of gotta be populated.

And we’ve got clients that take [00:50:00] 16 hours to populate and then index from nothing, to have to orchestrate that locally just to do a bit of CSS on the front-end is not feasible. It won’t be possible, and it won’t allow Magento to retain the competitive edge as it attempts to continue the kind of support for innovation and openness if the application stack cannot be automated from an orchestration perspective.

So it’s very exciting to see these other strands introduced and PWA converge more. You can swap out the backend and the front-end that you’ve developed on the storefront. It could be connected to a different backend next year. I mean, that in itself is exciting.

Brent: [00:50:56] Yeah, exactly. We’re almost [00:51:00] out of time here. I did want to cover some important points on how to pronounce the Hyva theme. It almost sounded like you were saying “Hoover,” Which just sucks up the theme.

Yeah, I think it must be where you live. Jisse had some points, and Vinai had some points, and Wilhelm had some points on how to pronounce it. And the other thing is, it is Redis. And I think that you mispronounced it. There are many more English speakers in the US now than in England, so I would just stress that a lot of us in America do pronounce things the correct way, but manywe don’t have to dive down into that. Great. This has [00:52:00] been very informative. I hope that you know, I hope the merchants didn’t.

I hope we didn’t get too complicated for the merchants. I think it’s important that the merchant, the developer, and the agency all understand how important that is. And I think one, one good way that we could end it with is if you could, in one sentence, say how this will help the developer, how this will help a merchant, how this will help the agency would give us a good, you know kind of, closing off point on why what you’re doing is so important for our community.

Aaron: [00:52:39] Yeah. I’ll certainly try it. I think to encapsulate all the potential benefits that are shared across those particular disciplines for us. It is the transition of repetitive activities in your professional capacity in your role in a business as a merchant, as a [00:53:00] developer, is introducing automation where it needs to introduce a cost-saving many we benefit into the working developments of Magento as an application for the benefit of all, not only risk reduction.

But as I say, it a significant cost-saving, and it is not unlike any other industry that’s introduced the same methods to bring safety and cost reduction. Likewise, it’s progress in technology. So that’s what we hope to do. And hopefully, there’ll be other platforms that emerge too, as I say, further stabilize and reduce costs for Magento as a whole. 

Brent: [00:53:58] Yeah, that’s great. I really [00:54:00] appreciate it. Aaron, so no relation to Moss from the IT crowd.

Aaron: [00:54:12] No! Less hair as well. 

Brent: [00:54:14] Great. Hey, this has been fun,willidea should try to do this again. And as things progress and as you know, maybe even some demos we could do in the future or something like that, I don’t know. Let’s keep it open. I love what you’re doing and how you’re helping the Magento community, and keep it up.

Keep up all the good work. 

Aaron: [00:54:37] Thank you. Thanks for inviting me. Take care. 

Brent: [00:54:39] Yep.