On this episode Ryan and Stack Overflow Director of Brand Design David Longworth chat with Matt Biilmann, CEO and co-founder of Netlify, about composable architecture, how making it easier to code will create more developers, and the future of the front end is portability.
At Netlify Compose 2023, Biilmann announced their new composable web platform.
This isn’t Netlify’s first rodeo—we talked to them for episodes 588 and 456.
You can find Matt Biilmann on X or LinkedIn (and perhaps elsewhere).
Today’s shoutout goes to Dick Lucas who asked a topical question, How to prevent Netlify from treating warnings as errors because process.env.CI = true?, viewed by over 84,000 people.
[intro music plays]
Ben Popper Well, this is interesting. 70% of the Fortune 500s use Pluralsight to upskill their workforce, and you can too. Start a free trial and see if Pluralsight is right for you. Visit pluralsight.com/stackoverflow to learn more.
Ryan Donovan Hello everybody, and welcome to the Stack Overflow Podcast, a place to talk about all things software and technology. I'm joined today by our Director of Design, David Longworth.
David Longworth Hello, Ryan.
RD How are you doing today, Dave?
DL I'm good, thank you. It's a nice Friday in London. I went to the design museum today and saw a little exhibition on MailChimp and the history of email, which is kind of cool.
RD An exhibition on MailChimp, all right.
DL Highly recommend it.
RD What a world we live in.
DL They've clearly got a lot of money to be spending on those things.
RD That's right. The future of content marketing is museum pieces.
DL QR codes, yep, all that.
RD Well, our guest today is Matt Biilmann, CEO and co-founder of Netlify, and he is here to talk about all things composable architecture, next step beyond Jamstack, and what the future of the front end holds for all you web developers. So welcome to the program, Matt.
Matt Biilmann Thank you. Thanks for having me, great to be here.
RD So we like to start these programs off by getting to know our guest. How did you get started in software and technology and how did you get to the position you are in now?
MB Oh man, that can easily be a really long story, but to make a longer story short, I got a Commodore-64 back when I was 10 years old and just loved that you could write stuff that made things happen. It was like magic. So I was always just programming, but back when I got a Commodore-64, no one really thought much about it as a career path or anything like that. So I actually have a Bachelor’s in musicology and comparative literature and then started on a major in cultural studies while working as a musical journalist for the Danish Radio, always on the side just building and procrastinating around programming and everything. And then I met a girl, moved to Spain, very quickly figured out that in Madrid and Spain the market for writing about music in Danish was not great for some reason. But the market for writing code was a lot better, so I started just doing that professionally. I got first hired by some startup working remotely and then a Madrid-based startup and somehow within a couple of years went from being an engineer there to being CTO of the company, fairly much like product engineering work and then started that company in Spain with one of the founders of that company. I came to the Bay Area in San Francisco with that and started seeing this change in where I believed the future of the web would be going, where at the time before we launched Netlify, pretty much every website or web store or web application was one big monolithic application where the user experience and the business logic and data access and plugin system and everything was just part of this monolith. And I started just believing that we would move from that architecture into an architecture where we would really decouple the front end experience layer into its own application and work on that alone, and where the back end would split into all these different APIs and services that we could call out to and use and reuse across companies and so on. So I started really looking at all the teams at the time that were already building like that and understanding what they were doing and what they were successful with, and it was just obvious that it was a great architecture. It was much better for the web developers to be able to really take the UI as not some secondary effect of what back end you chose, but as a real layer on its own that you can deploy and maintain and release, but at the same time, it was very hard for any team to really adopt that way of building because you had to figure out CDN management, object storage, cache invalidation, CI/CD build pipelines, and you had to figure out how to trigger your build pipelines when content changed or products changed and tie all of that together and now figure out for us all of that, how do we do staging environments, how do we do rollbacks and so on. So the architecture was the right thing but there wasn't really a coherent platform for building with it. And that became the idea for Netlify– what do we actually need to make that architecture a viable choice for everyone? And back in the day, there wasn't even a name for that architecture so we came up with this name Jamstack to give a way of talking about it as this is really decoupling the UI from the back end and built a whole community around that and launched Netlify.
RD Yeah, you've got to have a good name for the architecture to compete with the MEANs and the MERNs.
DL That's branding, Ryan.
MB I even remember early on talking to Tom Preston-Werner from GitHub about that. He was one of our early investors and we were talking about that naming because we were agonizing a bit about if it should be this name or that name. And he also just said, “Look, it's not so much the name. Think about Ajax. It's actually not a very good name in itself, but just the fact that someone went out there and gave that technique a name suddenly enabled people to adopt it because there was a shared vocabulary around it.” So it was very much the same with Jamstack where we were like, “Okay, we mainly just really need to make sure there's a shared vocabulary and agreeing that this is an architectural change that goes beyond a specific tool.” And I think it really unlocked a lot of that shift in modern web development that's then happened since, because when we started, we literally had to get people to change how they architected for the web in order for them to be able to use the platform we're building. And now, seven years later, every modern front end framework just works on Netlify because it's kind of become the default way of building now. You just assume that you have that kind of front end cloud layer. And obviously on our end, we've onboarded more than 4 million developers to the platform and we are reaching more than a billion unique visitors to the sites, stores, and apps that run on our network every single month, so we've also seen that groundswell happening.
RD Well, I think so many of the big popular frameworks were so heavy and everything is moving to sort of smaller pieces, and Jamstack was the first movement towards that. I've heard of things like micro front ends, and obviously the thing we're talking about today is the composable architecture, which is another shift towards it.
MB And we've seen the whole world of modern front end frameworks like Next.js or Gatsby or Remix or SvelteKit or Astro or Nuxt. Any of those are built with this idea where the destination you think about putting them on is typically our front end cloud product running that whole framework. So I think we’ve just seen that that's become the de facto way of doing things on the modern web. And then speaking to what's next there, we've sort of been in the process we were at you could say when we launched Netlify itself, and said, “To make Jamstack happen, what kind of platform needs to exist to make it simple enough to build in a repeatable manner with this architecture?” And now we've been talking to a lot of the large companies, typically companies with more than 2,000 employees. Often at that scale, you typically have lots of different brands and different types of web properties across sites and stores and apps. Typically a lot of them have bought some big monolithic systems that are at the core of that web architecture, and then they've also gone and acquired companies and inherited their stacks and so on. So they have really complex stacks set up that are pretty heterogeneous and where a lot of them are getting pretty outdated by now. When you look at this, if you want to start a new project and build for the modern web, this is probably how you’re going to do it. So that whole market segment is kind of also in that process of figuring out, “Okay, how do we modernize our core web architectures and how do we go from a place where we are struggling to perform fast enough, to iterate fast, to build great user experiences and to differentiate online, to a place where we can be constantly shipping and iterating and allowing teams to build great digital experiences.” And in that segment, there's now a lot of talk around composable architectures for that reason, because no one in the segment thinks we can go from where we are to where we need to be just by making some massive cross company replatforming initiatives to adopt a new platform. It has to be an architectural strategy that allows them to compose together different systems at different layers of the stack and evolve each of them independently. So we've been looking a lot at the companies that are trying to do that and the one that succeeds and the one that fails in doing that and saying, “Okay, what's the platform we need to deliver to help all those companies be able to modernize their web architecture and get much faster time to market, faster ability to iterate, while keeping the governance and security and so on that's required for that level of scale, and while keeping all the stakeholders happy?” Because at that scale, we also go from “all you need is to keep the web team happy and make them ship the UI fast” to “what about all the content editors and the marketeers and the publishers that are invested in the current systems and that need tooling that goes beyond opening a ticket with a developer and getting, ‘Hey, maybe we'll look at it next sprint as an answer.’”
DL Well, you touched on an interesting point, which is about organizational issues, which seems to me that that's a human side of this that has led to all these inefficiencies and monolithic outdated systems. And so how is this set up different in terms of not being just the tech debt of tomorrow? If there's more complexities, more smaller systems, maybe a person who sets that up leaves, someone forgets about it. How do you think we're going to get around that going forward?
MB I think that's why we're really launching our composable platform that apart from our core front end cloud offering includes two new offerings, which is Netlify Connect aimed at the architect-type persona that really needs to think through how we get all these different content sources and product sources and so on exposed to the front end cloud layer in a way that's predictable and consistent and allows us to over time evolve each of these pieces independently without constantly rearchitecting and shifting things around, and then Netlify Create, which is really our visual editing layer for the non-developer stakeholder where it's really a question of can we trace through the system where the different pieces of content come from, and can we then empower developers to define the right rules for the business stakeholders and what they should be able to do without developers? And it's important that it's still in the control of the developers.
DL Give them the guardrails, yep.
MB You really want to have the guardrails. You want to be able to work with your component libraries and your systems and so on, but you want to be able to empower the nontechnical user to go directly to the website, to click at it, to see what they can change, to work with the components you have and so on, in a way that doesn't require them to be a developer and understand where all of this comes from, but also in a way that still talks back to your different content sources on the backend. So that's why we think there's such a big opportunity at each of those layers, just that you can say that in the front end cloud, we really focused on the orchestration and the workflows. We connected to GitHub, we connected to the sources that need to trigger new builds, we pushed code through the system and we gave you the release management processes for developers to work with to deploy, produce, and so on. We want to take that to the whole broader system where it's not just the developers, but where it's also how the architect-level personas make sure that the right access to content and so on can happen for those developers in a way that scales and lets them connect whatever they have on the backend, and how do we then use that knowledge of where the content actually comes from to allow to build that tooling on top for the business stakeholders, and do it in a way where all the glue code is on us in a way and not take that you have to maintain and operate.
RD It's interesting that there seems to be two schools of thought. One is going kind of closer to bare metal everything, and then there's one that's almost going to abstracting things away, going to a low-code approach. And I think Jean Yang of Akita, when I was talking to her, she said an interesting thing that APIs are basically low-code tools. Do you think moving to a more composable web where the content creators can kind of plug things in and see what they're doing without being developers, is that moving to a more kind of low-code approach?
MB So I have this maybe slightly different view on it. At Netlify we're developers, and we think the future is more developers. We think that's only going to accelerate, but companies need developers to be able to build the things that differentiate their companies instead of all of the things that are totally the same across all different companies. And I think part of this movement towards composable you can think about as the old conflict between buy versus build where for a while a lot of these companies in many ways actually leaned into that low-code vision and bought big monolithic tools that ought to enable the marketeers to do everything on their own. And they mainly learned that the marketeers still couldn't do their job on their own, but now the developers also couldn't do their job because you work within the constraints of some massive GXP system and you get some weird template language to work with, and as a developer, what can I actually do? So we think the move to composable is more of a move back towards build, but it's a question of how you focus your developers on only building your things and not all the common components. You don't want your developers to build the content management API. You don't want your developers to build checkout systems for different payment providers. You don't want your developers to spend their time reinventing how you do a product catalog. All of those things are things you should be able to just buy and plug in.
RD Right, solve new problems.
MB You want your developers to be able to build differentiated user experiences for your customers. And then where you want that no-code flow or that low-touch flow is still on all the repeatable processes that the marketeers and so on need to be able to do. They do absolutely need tooling to be able to go launch new campaigns based on your current design system and so on on their own without a dev cycle behind it. They need tooling to go in and update copy or run experiments without constantly involving developers and so on. But a big part of our viewpoint is that what really makes things work is when we can make the workflow include both developers and business stakeholders and give both of them the tools they need.
DL Right. Do you think this is a philosophical change, outside of obviously the systems you guys are launching? Because I always think an example, especially with something like Jamstack, is that it's like a bank. A lot of what we've talked about is very front end focused and they're sort of the last people standing with crazy old systems like tapes and these things that feed into each other. I remember my friend worked at a bank and he said they had two terminals for two different systems and they were the link, so you'd look at one terminal, take that output, put it in another one. So is this something that a big company like a bank could learn from this philosophy without buying another tool or whatever?
MB I mean, we're starting to see financial institutions being one of our big growth areas and customer bases, and it makes sense because they essentially really need this. As you said, none of them have all modern, new, headless systems in place and there's no way for them to say, “Tomorrow we turn off all the legacy stuff and turn on something new.” They have to be able to evolve. But then at the other end of things, when was the last time you walked into a bank to do something? It's probably a really long time ago. Essentially all interactions you have with your bank now are probably online and probably digital interactions. So all of them need touch points with their customers and all of their customer experience is essentially an online experience today. And if they're still stuck in doing one release every quarter or something like that, that's going to be really hard to stand out in that landscape and to be the bank that gets associated with good experience. So that's exactly why you need this kind of tooling where they can decouple the front end layer, where they can find the right way to connect to the existing legacy systems while introducing modern systems, and start getting to that piece of iteration and freedom in tool choice that enables them to actually build great experiences.
DL Do you think that we'll get a service-orientated architecture on the back end as well, like everything's composable on the back end?
MB I think that's a big part of the motion as well, to break down these very big monoliths. And I think there's always some pull away, I think sometimes people go too aggressively on microservices and make them too micro, but I absolutely think that the service oriented architecture of breaking different components into individual services that have a clear purpose and either a team around it or a company around it is typically the right way to go. And I think everybody is kind of aiming to move in that direction, it gives you more reusable building blocks. And I think there's something very true to that sense that, in a certain way, the API is a piece of the no code of it, where those are the pieces you don't want to build. You do want to integrate them into your code and build on top of them and so on, but you do want to have this more clear contract of, “Okay, I need this component. Let's make it a service.” Then I think some of the patterns are how broad should that service area be versus how micro should it be?
DL Is that what Connect is going to do? Basically you would plug APIs into that and it will give you one interface to deal with on the front end”
MB So Connect, as it is right now, is really a unifying layer for all of your data sources that will sync them into each accelerated GraphQL data layer that you can build on top of during build time or run time or anything. But that also gives you the certainty that because it's synced in there, you don't actually touch the underlying API in real time during run time or anything like that. Then over time, we're probably also going to add connectors that allow you to go through real time, but the first one is really for the content and everything that you use to actually build that user experience from how you get it synced into one version data layer that you can build against and talk to and where you know that you don't have to reason about the performance of the individual systems behind them and the uptime characteristics of the individual systems behind them. You can just use that kind of content lake and build and ship with confidence.
DL I'm just wondering– one of the charms of the initial Netlify approach is, “I've got my GitHub repo, I just connect it. That handles all the stuff as a front ender, and specifically, I don't want to handle.” I just wonder, to the stuff you talk to, it seems like the portability of this stuff is going down. We've talked to Vercel on the podcast as well and they're doing similar things where it makes sense from a business point of view, but I just wonder where the future of the web is going in terms of portability and not binding ourselves to a platform or even a front end system.
MB I think that's a really good point. Actually just over the last couple of weeks, we've done a lot of launches around what we think about its core platform primitives. I think there's a risk in that framework-derived infrastructure approach where everything gets very tightly coupled to one big front end framework that kind of becomes your new monolith and that can end up really dragging down portability, but also the ability to over time evolve in that layer. So we're really thinking about what are the core platform primitives that we have to make really clear contracts around a primitive like standards-based caching that's tightly integrated to the platform, but also really based around modern caching standards. So we also just launched Netlify Functions 2.0 which is really a major revamp of the DX of Netlify Functions, but again, really leaning into core web standards, just same as we've done for Netlify Edge Functions where it's really just the modern web API that's starting to really emerge around requests, response, response streams, everything like that to really make it feel like a strong contract around that this is a more contained part of some really big complex system, but it has a clear standards-based contract. And today we just launched cache tags with instant cache purges as another primitive that we feel should standardize quite well. And you'll never get a hundred percent portability as you start having these front end cloud platforms, but I think we can do better in terms of building simpler, clearer core platform primitives that are easy to reason about instead of the risk of going too far in building very tangled proprietary systems where it feels like portability is gone.
DL Great. And I've seen the front end frameworks getting in on that, like Svelte and Nuxt, things compile down into Netlify functions and stuff which I think is a smart way to handle those adapters in SvelteKit and stuff like that.
MB Yeah, I like that move in frameworks to think about what's this portable adapter layer. After we acquired Gatsby, we actually introduced an adapter layer for Gatsby with the same thing in mind of how we make it portable and simple. And I think, especially when you think about these architectural concerns and not just about how do we get a thing done now, but if you're a bank and you've gotten burned by getting stuck in legacy infrastructure once, how do you think about architecting for the next 10 years in a way where each piece can evolve? I think that framework landscape is also important to think about the strategy of how do you not get too tied into some kind of monolithic proprietary set up that you just can't untangle in the future.
DL Yeah, let's not repeat the mistakes of the past.
MB Precisely.
RD Matt, is there anything else you wanted to touch on that we haven't touched on?
MB We're just really excited to launch our full composable platform at Netlify Compose next week. We’re excited to try to do what we essentially did for Jamstack by building the front end cloud platform to do that for the whole composable architecture space by building our composable platform. And I’m excited to get it out into the world and start helping large companies overcome some of these problems on modernizing their web architecture and help them ship faster and still ship securely and with governance, but with high speed and great user experiences. And we just want to see the web being the best place to deliver great user experiences and help more of them exist.
[music plays]
RD Okay, that is the end of the show. As we do often at the end of these, I'm going to shout out a question. We don't have any new Lifeboat Badges, so I'm going to shout out a Netlify question: “How to prevent Netlify from treating warnings as errors because of process.env.CI = true.” It was asked three years ago, so it may not be true anymore, they may have already fixed this. Asked by Dick Lucas. So if you were still running into warnings as errors, we may have a solution for you. As always, I am Ryan Donovan. I edit the blog here at Stack Overflow, you can find it at stackoverflow.blog. And you can find me on Twitter @RThorDonovan.
DL I'm David Longworth, the Head of Brand Design at Stack Overflow, and you can find me on the internet somewhere @aboveDave.
MB And I'm Matt Biilmann, CEO and co-founder of Netlify. You can find Netlify on netlify.com, and you can find me on Twitter or Threads or LinkedIn or whatever your preferred media is, and I'm always happy to connect with any users or customers of our product.
RD Well thank you very much for listening, and we'll talk to you next time.
[outro music plays]