Listen

Description

John Williams

The rise of omnichannel content strategy and the emergence of new technical capabilities like cloud computing, API-delivered microservices, and headless software platforms have created entire new content ecosystems.

John Williams explores these new systems and modern content and experience architectures on his "Going Headless with John" YouTube channel and in his work as CTO at Amplience, a headless-CMS company.

We talked about:

his YouTube channel, Going Headless with John, and his role at Amplience, a headless CMS company
the rationale behind the MACH alliance and the elements of the acronym

Microservices
API first
Cloud native
Headless

the ability to scale and to implement version control that a multi-tenant architecture permits
how decoupled architectures let companies choose "best of breed" software solutions
his take on the differences between the concepts of "headless," "MACH architecture," and "composability"
how to help content authors work in (non-WYSIWYG) decoupled systems
the importance of understanding the "why" in decoupled content authoring environments
the benefits of adopting an iterative approach to implementing composable architectures

John's bio
John Williams is a highly experienced and innovative CTO with over 25 years of experience in the tech industry. He is passionate about leveraging technology to drive growth and innovation. His expertise lies in creating and executing technology strategies that deliver transformative results for businesses, and he has a proven track record of building high-performing teams that thrive in fast-paced and rapidly changing environments.

Connect with John online

LinkedIn
Going Headless with John YouTube channel

Video
Here’s the video version of our conversation:

https://youtu.be/IFoI1fh8420
Podcast intro transcript
This is the Content Strategy Insights podcast, episode number 187. The rise of omnichannel content strategy and composable commerce - along with the emergence of new tech practices like microservices and headless software platforms - has given rise to new content systems architectures. It's also inspired many new conversations around concepts like composability and decoupled-ness. John Williams explores these topics on his "Going Headless with John" YouTube channel and in his work as the CTO at a headless CMS company.
Interview transcript
Larry:
Hi everyone. Welcome to episode number 187 of the Content Strategy Insights podcast. I'm really happy today to welcome to the show, John Williams. John is the CTO at Amplience, a commerce-oriented, headless CMS. He's also the host of Going Headless with John, a YouTube channel that I really enjoy. So welcome John. Tell the folks a little bit more about what you're up to these days.

John:
Yeah. Well, we're actually working on... In Amplience we're working on a whole bunch of things around headless. We're doing a whole new release around our content form. We are doing a hell of a lot around AI and how we incorporate that into the MACH world, which is what we're talking about today, and how we keep consistent with our technology practices around MACH and headless, as well as incorporating new technology.

John:
So we're all pretty busy at the minute. We've got a really big release coming up, out in June at Shoptalk. For anyone who's going there, coming over and see me have a chat at the booth, we'll show you some really cool things.

Larry:
Cool. Yeah, and you've just hit on the... We're all infinitely busy these days trying to keep up with, not with just AI. But there's also the fundamental architectural stuff that we're dealing with in this new composable, MACH-ey, headless world.

Larry:
I guess one of the things I like to do in this podcast, it's all about democratizing practice and principles and what's going on out in the world. And one of the things I like about your YouTube channel is you're really good at explaining the benefits and the concepts that surround headless, but that's happening in the context. Headless is the H in MACH and maybe the... I'm not sure I would say a MACH or MACH. But anyhow, I know that Amplience is one of the founding members of the Alliance. Maybe you could talk a little bit about that? And for folks who don't know, that it's an acronym for microservices, API-first, cloud-native, and headless architectures. So maybe you could talk a little bit about that world?

John:
Yeah, sure. So the actual concept evolved. So we were found a member of the MACH Alliance, which we can chat about later. But the actual principles just evolved in terms of an ethos of how we build software. And it's not like we just turned up one day and said, "oh, let's just do this thing called MACH," because it didn't exist.

John:
It was just the approach using lots of modern approaches together. So microservices, that's more about doing very small self-contained pieces of code that ultimately have a service that deliver a service, but keep it really tight and focus on those services for a specific business problem or a specific business domain. And keep it really self-contained, including things like the database so that individual teams can actually work on these microservices. And it allows you to build things a lot more quickly, because you can iterate on those smaller areas. And you can also deploy them separately so your teams can be more independent of each other. Because they're all working to a contract and they're all on these different microservices.

John:
So it's a really good way of pulling a system apart, which is always what you do in software engineering terms, abstract, and then pull the system apart and then allow you to focus on those individual areas. So microservices is the thinking about services in actual... Think of business demands, think of them as fixing a specific problem, those kinds of things.

John:
Then there's the API-first, and this was the one that always gets people a bit confused, I would say, between the microservices and headless. The API-first is really about thinking about the things you're building in terms of their APIs before you start thinking about how you're going to actually build it. So if you are going to work on a particular business demand, start thinking about the APIs that are necessarily around that, and by doing that, it allows you to actually make that system more flexible in many ways because you start thinking about how the system is going to be used from the outside.

John:
One of the big things around API-first is the coverage. So if you go down an API-first route and you're down a headless API-first route, the whole system should really be accessible through an API. There shouldn't be some special thing somewhere that you have to go and log onto something and that you can only get access it through an SDK. Or it's only ever accessible, even if there is an API, through a very specific SDK, because it's got lots of other special routing in there.

John:
So having that sort of API-first approach allows you to basically turn your system more like a toolbox. So you've got all of these different APIs you can connect with and do lots of interesting things around. The reason that it's... I would say I'm going to miss the C for now, but the reason I'd say it's different from headless, is you could have a system that's headless, but it's still not API-first because all of your admin system, all of your backend could still be, I don't know, running on a server somewhere that you have to connect into, but your content or your features could all be delivered headless.

John:
So it's quite a subtle distinction. But a headless and API-first are not necessarily the same thing. And also when you think about... I'm quite passionate about this, when you think about headless, it's actually not just the API, and I'm going to use CMS because that's the world that I live in. If you just have an API that allows you to access your content, you may still have dependencies on the presentation layer. It may not be completely separate, it may not be completely headless, because your underlying database, your structures and how you think about the world may be more monolithic because it's come from a monolithic aspect.

John:
Which means that there's still parts of the technology that are considering the presentation layer. You still have to understand the nuances of how it's going to be deployed, whereas in pure headless, you've abstracted it all away. So that you don't care whether it's in a presentation layer or not actually.

John:
And that's been at the fundamental level. That's why you see many headless CMSs that use things like, allow you to define the schemas or completely schemeless for delivering their content. And obviously the C in MACH is cloud, being cloud-native. That's been done to death now, I think in the industry for many years, but it's all... Your system should be completely deployable in the cloud, it's running in the cloud.

John:
When we're in the MACH Alliance, what we look for are things like being multi-tenanted, so not just being a managed service in the cloud, but be a more multi-tenanted version of that in the cloud. So you can take the full power of scale that you get from working on Amazon AWS or as your... Does that help?

Larry:
Yeah. No, that helps a lot. In fact, a couple of concepts there you've mentioned. I want to revisit the need to abstract things and separate concerns out. But I wanted to talk just real quickly about multi-tenancy. One of the reasons I wanted to have you on is because you're very technical. And probably over the course of the 186 prior episode, there's probably been 80% less technical. So I really want to go...

Larry:
One of the things I think you can maybe help my folks understand, is that notion of multi-tenancy. And I think you distinguished it from...