Embracing Composable Software Architectures – Netlify, Matt Biilmann

This is techstrong tv. Hey guys, thanks for the throw. We're here with Matt Biilmann, who's c e o for Net Liffey, and we're talking about how to move from monoliths to more composable IT environments and web applications in particular.

Matt, welcome the show. Thanks, happy to be here. We've been having this chat about how to move away from monoliths for quite some time now with mixed success.

So from your perspective, I know you guys have recently launched something called Nety Connect that kind of helps folks get down that path. But let's just get started with what's the fundamental challenge from your perspective. I mean, we, we always built netlify around this idea of decoupling the web experience layer from all the underlying backend business logic that had sent, transitioned the, like, traditionally been, been like built together in monolithic systems.

Uh, often for, for for large scale marketing infrastructure would be things like Adobe Experience Manager Site Core, or Salesforce Commerce Cloud. At lower end, you would see stuff like in installs or, uh, in the application space, like large monolithic GAVA application rails applications and so on, where both the actual user interface, the underlying business logic and the underlying data access would be part of one monolithic application, right? Like, and we build netlify around the idea that we would shift away from that world to a world where you would start like building decoupled, um, self-standing web device that would talk to all these different headless APIs and services, right?

Um, and we sort of in the, in the front end world, coined the term GT stack and, and help that part of the space really developed the tooling to move really fast when you can build the web UI independently, right? Like, and we've seen sort of a whole industry emerge around that with Hitless CMSs and Hitless commerce platforms and, um, hitless search systems and hitless personalization systems and all of this, right? Like, and I think now in sort of the whole early adopter space that that approach to building has just totally been proven out, right?

Like, I can't think of in the last eight years since we started, I can't think of a single new content management solution, commercial content management solution hitting the market that's not hitless, right? Like, I can't think of simple single, new like major commerce platform that's not hitless, right? Like, so the, the whole theory there has been proven out, and the tool set is very advanced now, but now we are hitting sort of the next set of challenges when larger companies with a lot of existing systems start thinking, okay, how do we get there?

Right? Like, because obviously if you're a a, an enterprise scale company and you have a big existing web architecture based on these MODELLY systems, there's no world where you just turn that off and replace it with some new architecture, right? Like, it's not gonna happen.

It's not realistic. There's not resources for that kind of switch, and it's not gonna go well, right? So the next big question become like, how do we enable architects to think through that transition as a gradual transition where you can start like maybe decoupling part of the web UI and build like self-standing websites, web applications that access the existing systems as if they were hitless first, and how do you then add modern headless system to that mix?

And that's why we launched Netlify Connect, um, earlier this week as a, as a layer that allows companies to build a set of connectors that sort of ingests all of their ingested, syncs all of the content from their existing legacy sources and from the new modern hitless sources, and then gives their web teams one GraphQL a p i that they can build on top of where, where they can access this, the data regardless of where it's coming from, right? Like, and we are seeing this as a huge enabler in startup, in, in, in, in the approach to decomposing your monolith. Mm-hmm.

To that end, it almost sounds like we're trying to wean people off the monolith one, you know, component at as at a time as it were. And the way to think about that might be that I'm breaking it up into a series of, uh, microservices that I'm wrapping around it a little bit to invoke these headless services, or how should I be thinking about that? I think that's, there's, there's some to be said for that as long as you have the right definition of what you need for service, right?

Like, I think there's also at some point in moments to, to make the services to micro, right? Like where you start feeling that everything needs to be a, a, a, a microservice, and that's not necessarily the right approach, but I think one of the things we've seen is that in the end, like almost like a lot of the stuff you build is servicing customers that needs to interface it, interface with that through some form of ui, right? Like, and if you, if that UI layer is a part of your monolith, then, then you're just inherently constrained in how fast you can move in your customer experience by how fast you can move on shipping and delivering that whole monolith.

So we are very much arguing like that. A first step should, should be to try to decouple, right? Like, how do you get the actual user experience layer out of the monolith and into something your team can iterate on really fast and in isolation?

And then what's the best way of starting to introduce tools that are really built around that decoupled way of working without trying to do it in one big, like rea architecture or something, right? Because that's, to me is also how you get the big bang for your buck, right? Like when, when you look at, like, typically when I ask a lot of like our, like prospects that we are talking to in the enterprise world, how, how often do you ship changes to, to production for your like actual ui?

There, there's a broad set of answers, but often the answer is like, within, we have like a release every two weeks or maybe like a big monthly release we roll things into, right? Like, and if you look at enterprise customers and edify platform, I had one of our data scientists just run like the numbers on that, right? Like, and they ship an average of 150 times a week to production, right?

Like that's the kind of unlock this kind of de decoupling can bring, right? Like, and then I believe as you start transitioning individual parts of that monolith into individual services, those services can also get closer to the, that pace of shipping, right? Like, because the scope of what you ship is just more contained and more isolated.

Mm-hmm. So by decoupling that, does that make it easier for organizations to kind of start embracing best DevOps practices as you kind of alluded to? I mean, I think that there's also a piece where to decouple it, well, you have to start embracing some of these DevOps, uh, practices, right?

Like you have to make it easy to be able to spin up, um, and, and new campaign, a new project, a new app, and, and, and know, and know that you have the whole backing of release pipelines and release management and change management and rollback and so on, right? Like, I think the more you decouple, the more you depend on just having that kind of process nailed down, right? Like, because otherwise, companies, like with a big model is probably spent a long time trying to set up the kind of release processes and, and DevOps processes they have around that one.

If they have to spend all of that time and all of that DevOps work on every new service and every new self-standing app, that's gonna be untenable, right? Like, so you have to rely on, on tooling that allows you to spin up these kind of services faster. And honestly, also, it it, it gives teams the ability to buy external services, right?

Like that's also where we've seen this whole headless industry move up with tools like content full or content stack or the, like in the, in the headless content space or tools like commerce tools or commercially, as in, in, in actually doing e-commerce transactions or managed the database ventures like Planet Scale or Neon, making it very easy to to, to set up a, a, a robust data workflow for, for that part of your application and so on, right? Like, I think as we start seeing that decoupling, we also start seeing more of, of an ability to buy versus built when it comes to a lot of the actual developer workflows and DevOps workflows. Mm-hmm.

What is the future of the user interface? We see a lot of conversations these days about natural language interfaces and ai, so Yeah. Yeah.

Where are we going with that? Look, I think even, even as I think through Netlify Connect as a product, right? Like in this ability of, of taking all the externals and internal systems of a company, making them available to a set of web developers that can then iterate on, on what kind of experience to build on top of those, I think that layer is gonna be really important in this whole transition that we'll, we'll go through where I believe that five years from now, generative AI will have changed the way we interface with computers, right?

Like it's, it's pretty easy to imagine just from looking at tools like chatt, bt, and sansia and, uh, voice generation models and language generation models and so on that like five years from now, we'll be able to have this kind of interaction that the two of us is having right now with a computer, right? Like there's no, there's no real reason if we just bring down latency in each of these elements that, that, that that won't be the case, right? So we should expect that to, to have an profound effect of, of, of every part of how we think about user interfaces, right?

Um, they, they will most likely really not be the same kind of interfaces we are building today, but they'll still depend on the same kind of layer of being able to access different kind of content and data sources, different sets of transactions, expose those to URLs that the language models can, can, can interact with, and that you can spin up different ad hoc type interfaces on, on, on top of to, to, to do operations and so on, right? Um, so I think the most important thing you can do as a company is again, to not lock you into some monolithic system that has a very specific view of how the UI world is, is gonna look like and try to set yourself up or are faced like for, for, for a world of very face fast pace change in that area, and where you can tailor the, the different kinds of outputs to the different emerging interactive par paradigms that that, that we'll see As you look into the future, then are we gonna be able to rip and replace headless services more easily as we go along? And that'll make it easier to add new functionality and upgrade applications, but it also will reduce the cost of switching, right?

Yeah. Yeah. That, that, that's of course also a, a, a promise of the tools like Netlify Connect, right?

Like that, as soon as you have an abstraction layer in place, it does allow you to, to, to switch out the, the underlying services and, and, and constantly aim for, for best in class and in, in each area. It'll, it'll never be like a zero switching cost and you just switch in and out, right? Like each service also comes with like ways of inputting data that you've trained people in and the workflows that you've built tooling around, right?

But the more you have clear decoupling and, and clear like responsibilities for each service, the more freedom you have as, as, as an architect to take choices in an individual area without having to think through your whole core platform. And we have talked to, like, as, as part of developing Connect, we've also really talked to a lot of, like the companies that have in-house built several similar abstraction layers, um, for this purpose, right? Like, and, and we have really heard how it's allowed them to go through, like one of them told me they, they'd been able to go through maybe a little extreme, but like five replatforming in, in, in, in three years.

But because they had that poor like, uh, middleware layer in place, that allowed them to both switch out the different components on the on, on the, on the backend side and the different, uh, experience, uh, frameworks for, for the experience size very independently and very, like relatively easily In a lot of ways. And you kind of talked about this earlier, but aren't we just really practicing good computer science here? I mean, we've been talking about separating the presentation layer from the backend for decades.

So what's taken so long for everybody to wrap their heads around this? Probably the fact that it's really hard to get out of a monolith when, when, once you're really deep in it, right? Like, and I think that that's, that's been a large part of what we've done since the beginning with Netlify, right?

Like even, even just starting to allow people to easily spin their different UIs into individual applications that, that, that, that talks to API and that each has their own release management pipeline, they each roll back cycle their, and, and that in themselves have some ability to, um, architect the gradual transition where you might spin out a new hitless front end, but you still proxy anything that you haven't like re-platformed yet, back to your monolith, right? Like tools like that. We, we, we, we started out by building, and that's really helped accelerate this motion, right?

Like, and now I think the next, the next frontier in that is this middleware layer between the front end and the back end that gives you the architectural freedom to, to, to start decoupling your monolith a bit faster. All right? And then what's next for JAMstack?

Where are we going from here? I mean, I've been talking about just this concept of going from jamming to composing, right? Like, um, back, back when we started Netlify and came up with the term JAMstack, it, it was really because there wasn't even a, a, a name for this architectural approach to, to building where it really fundamentally like decoupled the, the web experience from the end, right?

Like, and today we are kind of in a point where like, I, I was, I was on a podcast with, with, with a coach school the other day, and I was explaining the JAMstack and so on, and the interviewer kind of said like, look, honestly, all the stuff you talked about as, as coming before the JAMstack, probably none of our students have experienced that because like, this is just the way we teach them to build stuff now, right? Like, so there's this sense that in, in, in the early adopter space and in the space of new projects, new tools and so on, right? Like the JAMstack has essentially just become the way we built for the modern width, right?

And now I think you hear the, the phrase composable architectures a lot in the enterprise space because I think that's kind of the next frontier, right? Like when you're not just thinking about the architecture of a single web project, you're not just thinking about how do we build this campaign, or how do we build this new greenfield app? When you're starting to think about, okay, as a large company, how does our web architecture look like that that's where you kind of go from just like the, the front and centric idea of Gamst stack to the more holistic idea of a composable architecture and, and, and how you sort of both decouple that whole web experience layer, but also do it in a way that set you up to, to gradually go from where you are now to a, to a set of cleanly composed, uh, services.

All right, folks, while you're heard it here, software architecture's cool. Again, it matters and it makes a difference. Hey, Matt, thanks for being on the show.

Thanks so much for having me. All right, and back to you guys in the studio.