I’ve been looking forward to the opportunity to speak with Mathias Biilmann, CEO of Netlify, ever since the WordPress vs JAMstack debate broke out. Mathias and I sat down for a virtual discussion which has been transcribed and edited for clarity.

When I was President of Joomla, I often spoke of a future with micro/hyper services, so getting to speak with one of the leaders in the “new” movement can hopefully expand awareness of what an API driven world as well as static websites can become. Netlify, formed as MakerLoop, Inc. in 2014, has received a good deal of attention with the customers, partners, and investments it has received since then. From Wikipedia we have a brief rundown of the funding.

“On August 9, 2017, the company announced that it had raised $12 million in series A funding from Andreessen Horowitz.

On October 9, 2018, the company issued a press release announcing that it had completed a series B round led by Kleiner Perkins—with participation from Andreessen Horowitz, Slack and Flickr co-founder Stewart Butterfield, Yelp CEO and co-founder Jeremy Stoppelman, among others—securing $30 million.

On March 4, 2020, Netlify secured $53 million in a series C round led by EQT Ventures, the venture capital branch of Swedish investment company EQT, with contributions by existing investors Andreessen Horowitz, Kleiner Perkins, and newcomer Preston-Werner Ventures.”

Robert: A couple of top line items I wanted to go through with two questions. You have received almost a hundred million dollars in A+B+C funding in the last four years. Are you and your investors seeing the revenue growth that you expected because of that?

Mathias: Yeah, I mean, our output is generally happy. We’ve seen strong, strong revenue growth for multiple successive years. Right. And have also kept expanding the overall user base, [it’s] crossed like more than a million developers. So now … we have around 600 million unique visitors to sidetrack applications on the Netlify network every month. Which is something like 12% of all internet visitors hitting a Netlify site every month. So we’ve seen very, very strong growth. And of course, we raised this money because we’re building a very ambitious company. We want to really build it as a platform that can help developers build a large amount of the websites and web applications powering the modern web, but yes we’ve seen strong revenue growth.

Robert: The, the other question is what is really open source about Netlify except all the other tools people are using – are you providing something specifically open source or is it just the Netlify infrastructure that you buy into and you can use other open source [tools]?

Mathias: I would say in, in that way, we we’ve been building an infrastructure and workflow platform. The special part of Netlify is very much tying together, the idea of infrastructure and workflow in a way where developers can work in the framework of their choice with their code. They don’t have to worry about all the parts of getting from code to a live URL. And of course our infrastructure is wouldn’t even really make sense as open source, right? It’s a big system, running across lots of different cloud providers and services in spanning hundreds and hundreds of surface and niche nodes all over the world. With a DevOps team maintaining it, with lots of monitoring and alerting, and deployment mechanisms and cannery servers.

We’ve tried to build out a platform which is opinionated on an architecture, which is what has come to be known as the JAMstack. Right. So are opinionated on, if, as a developer you build and deploy to Netlify, you will be using some form of this JAMstack architecture. But outside of that, we are relying on open standards, right. Like how do we build for the open web in the way that means that people can bring whatever open source, tooling, and framework they want to build with and use, and that’s what they deploy to Netlify.

Then we have some open source projects ourselves like Netlify CMS as an open source, GIT based content management solution. That’s just for managing structured data in a Git repository. And then you can use that data for whatever. We have an identity service that we offer as part of Netlify, which is also open source. It’s called GoTrue with the goal for managing sign ups, authentication, all of that in. We have, of course, all of our CLI tooling, build tooling and it’s open source as well. Apart from that, we just operate the whole workflow platform that makes developers successful. And that powers all the infrastructure you get when you deploy such an interface.

Robert: That totally covers what I was trying to understand on where you guys fit in as a company in the open source space versus just utilizing open source tools. Obviously AWS does that as well. Atlassian does that.

Mathias: Yeah. Cutoff is similar, right. Like everybody uses Git, which is open source with GitHub. Right. But their platform is such that it’s a platform. Right. And we’ve tried to be also really good at contributing back to the open source ecosystem. I personally contributed to things like Hugo, and Gatsby, and Jekyll and so on. Our team is super active in that whole space, it’s where our employees like to live in. We try to invest a lot back into the open source ecosystem around us.

Robert: Brilliant. And thank you because it doesn’t grow without that. So is Netlify more a platform as a service, like Microsoft Azure?

Mathias: So it’s a good question. We’ve been talking a lot about what to call Netlify, is it  like a serverless cloud or something like that. In a way I think there’s definitively parallels to the platform as a service. I think a lot of the platform as a service is that it is very much around the backend layer. You host your data and your backend with a platform as a service, where we just started very much from the other end with the web layer. We saw this movement of decoupling the front end web layer from the backend layer and turning it into its own thing. We tried from the beginning to really integrate both the infrastructure and the workflows around that to give developers a way of just working with the code, working in the workflow around GitHub and pull requests and so on. And then just extending that workflow into the whole runtime and infrastructure to just reduce friction and increase development productivity. So in a certain way, you could describe us as web as a service.

Robert: The way I’m understanding it is you are reinventing / re-envisioning MVC for modern web development.

Mathias: Yeah. You can say that there’s some of those parents in there. You mentioned you had a long background in sort of the monolithic world. Right. And so do I, right. Before this, I built a big monolithic multi-tenancy CMS. Before that I built several of the platform we used at a company in Spain where I was CTO to build tens of thousands of websites for clients, which was also a traditional monolithic system, but then broken into a service oriented architecture. So I spend a lot of time following the whole development of all these different tools we as developers build for the web. There was a point where I started seeing essentially three things happening around the same time. One of them was actually the emergence of GitHub that just really started like popularizing version control for frontend web developers. Where before that, I must say that most frontend developers worked with version control  which was endless folders with the names, like “version four-final-final-final-for-real.”

It was painful and most developers would just send back and forth Zip archives and stuff like that. Then suddenly you started having this whole new wave of frontend developers actually adopting GitHub for version control, but not just for version control. Suddenly it became the main collaborative workflow. You commented on each other’s code and figured out what should go live and what should be deployed. And so on and around the same period of time, the browser really started changing from being more of a document viewer to becoming more of an operating system, running JavaScript and today, even WebAssembly and having access to all these services that you can talk to and pull in straight from the browser, like Stripe for payments or Algolia for search.

So all these different services started popping up. The first thing that happened was sort of this whole, almost Cambrian explosion, around the Node.js ecosystem where suddenly frontend developers started building all these test runners, and then the single page application, web frameworks, and bundlers and so on. You had this very fast moving ecosystem, sort of reinventing the workflows and tooling for building the frontend that would go into this smart browser-based operating system that suddenly had access to this wealth of APIs and so on. That was when I saw that their was potentially a big shift in the architecture of the web happening where this frontend presentation layer would really spin off into its own thing with a very fast pace of iteration and with very high expectations also of what can be delivered to users in terms of interactivity and experience and performance and so on.

And I saw that this shift had a huge potential to really make the web competitive again. This was the time where we started seeing the first sort of real threats to the web, first with mobile applications becoming more and more of a deployment target instead of web applications. And then things like Facebook instant articles that were saying “the web is simply too slow, you need something much faster.” And then Google AMP with the same argument that, “hey, you should like run your thing in Google’s proprietary, like open standard, but controlled by Google and deployed to Google because the web is not fast enough” and so on. So there was a sense that, that the web had to be able to deliver the same level of interactivity, user experience, and performance with a reasonable development effort.

This architectural shifts seem to really be addressing all of that. If you started to adopt that architecture at that time, it was quite a hurdle. For every project you needed to think up, okay, how are we going to run our node based build environment and how are we going to deploy that. We now need to setup a CI/CD pipeline. We need to set up object storage and a CDN. We need to figure out cache and validation and the right headers and like, how do we do staging environments? Now we need to plug in some APIs for pulling content at built time. And all of these things, suddenly it felt like the architecture was very powerful and could deliver really great results, but there was just too much friction in working with it.

Robert: So you’ve completely anticipated my next question. What does Netlify do for the JAMstack architecture?

Mathias: So our goal is really to just reduce the friction. It’s not about us coming with some weird, proprietary way to build applications or something like that. It was really about us seeing, where was this architecture going and what were people doing and how could we make it viable to build in a way for as many developers as possible, by taking away all the friction of having to glue together, all these different layers of services and workflows, and just give developers a way where they could just go in and say, this is my Git repository. This is my frontend tooling. And now I’m done. Now I can just work on my code and Netlify will pick up any builds, then set up, it gives you a URL for every pull request you make, and gives you easy ways to just write directly into your repository, and edge rules you want to apply. And later on, even the serverless functions you want to run and soon to come, like even the edge handlers you want to build in. We’ve really been focused on taking the friction away from working with this architecture and allowing two developers to build fast, iterate fast, and then get guaranteed high performance, high uptime, high reliability, and so on.

Robert: Again anticipating the next question, at the beginning of the month at JAMstack conference, you announced Edge Handlers. I’ll give you my ten second understanding of them and I hope you clarify. My understanding is that Edge Handlers don’t necessarily require me to republish the entire site that they give me functionality to do bits and pieces of the site in addition to any kind of dynamic content. I know it’s in beta right now, but I’d love to hear more about this. I think this is the most interesting sort of new thing to come out recently for JAMstack.

Mathias: In a lot of ways suite, we simply take like what you could call the routing layer initially connect to when you open a JAMstack website, and we make that layer completely programmable by web developers. You can use that in, in many different ways. A simple way could be to implement authentication for your content. You could write a little edge program that anytime a request comes in, you see this, does this user have a cookie set with JSON web token in that token? What are the permission and claims? Should this user be able to see the real content? Or should we give this user login page,. That could be one simple little edge handler and you could have your whole website, pre-built statically with all the different content pages waiting.

But it’s that little piece of edge logic that decides, do I want to show a login page or the actual content. That would be like one little example. You could also imagine things like, let’s say you want to be able to at build time for any image URL, just to pin a parameter called resize to fit in 400 x 600. Right. Then ou can on the fly resize images. You could write a little Edge Handler that would pick up that query parameter, and then if it’s present, just send that request onto Cloudinary tp do their magic and send back a resized image and then have our network cache the image forever.That would be a functionality you could just write as a little Edge Handler.

You could even have frameworks that do some server side rendering at the edge as well. The runtime environment is fairly constrained because we want anything that happens there to be very fast, like shouldn’t take much longer than 50 milliseconds. Or you’re probably doing something that doesn’t quite belong at that layer, but it opens up to a lot of possibilities. We’ve talked to a lot of customers that are already doing these kinds of things with different kinds of in CDN edge platforms that allow you to do complex edge processing and so on. So again, it’s not like we’re saying you should do something completely different. It’s more like when we talk to those customers where they really run into a lot of problems is that they now start writing rules at the CDN level or at the edge level that are very tightly coupled to what their web team is building.

If you build something that requires authentication, you need to know the structure of the pages that are authenticated, then what does the login page need? And all of that, if you’re doing more complex things like fine grain personalization the more you build there, the more you’re coupling there, the web layer and the edge layer. With the traditional CDNs, it’s very often completely different. It’s typically the networking team that works with that code and that writes it. It’s typically a completely different deployment and rollout process you have for edge rules then for your web front end. What we heard from many, many clients was just that those kinds of issues made it really hard for them to be successful with this architectural pattern, because things would get lost in communication between the web team and the networking team. Things would be really hard to roll out together and test together.

So what really sets our solutions apart is mainly making it viable for developers to work with this architecture, giving them just one workflow where in the same Git repository, you can have your web frontend built. You can have your serverless function too. You can have your edge handlers. And again, every time you open a pull request, that changes any of those parts we’ll give you a URL where you can go and see everything running together. If you run Netlify locally, we’ll spin up a dev server where all of it runs together tp take away all the friction from developers to work with these patterns and with this architecture.

Robert: So then developers can focus on development and then content creators can focus on the content side and that they don’t have to talk to each other, is that what you’re saying?

Mathias: Yeah. Yeah. Yeah. Content creators are another really interesting area. We are seeing a lot of innovation in the JAMstack space for content creators. Things like Sanity Studio, for example, that has real time editing of structured content where you can immediately see what two people are working on in the same structured content document. You get an, almost Google Docs experience of like changes happening and so on. Tools like Stackbit Studio is working on giving people like marketeers, an easier on page site builder experience, but where the content might be stored in completely different places. So we might have some of the content living in a headless CMS, and some of it living in a Git repository in Stackbit. We’ll still give content editors just a view that’s tailored for them.

I think this decoupling of different parts of the tool chain and the ability for teams to focus on a core area will make them really great, that’s one of the things that over time as developers adopt this and build around it companies will emerge in different areas of the value chain. We will see a lot of innovation that can make life better for everyone from developers to content creators, to marketeers.

Robert: Two final questions. Is there a goal for Netlify to be a single source of truth with all the content that comes through? Or is that always going to be distributed?

Mathias: I think that’s something we leave up to the ecosystem of developers, right? As Netlify our goal is to reduce the friction in whatever you do. We want to make it easier for people to tie together different content management systems. We want to make it easier, whether you’re using a headless WordPress as a backend or Contentful, or whether you end up with a system where you have some data in an identity service, like Netlify Identity, or some data in a payment platform like Stripe or Shopify, and you need everything to fit together. Our goal is not really to make that choice for you. We think that’s where there’s a vibrant, deeper system that’s going to figure things out. We just want to reduce the friction and make it easier to program with and connect and understand your running system.

Robert: Last by not least, what would you tell agencies who work across multiple platforms about how JAMstack and the Netlify experience impacts initial time to release, project maintainability, and security?

Mathias: We have a very active agency program. We work with a ton of different agency across the spectrum from system integration to branding agencies and so on. Right. One is that if you can just connect to whatever API has the content of the client then you can more easily as an agency come in and just pick the front end layer that makes your execution the simplest. That allows you to build the most compelling experience for end users. This decoupled approach typically allows agencies to build it a lot faster. Often what we’ve seen is that if an agency comes in and there’s a big monolithic system that’s already determined, like the template layer and often the navigation structure and everything, it can be really hard for an agency to come in with a real creative vision and take it to market in a short time.

Whereas if you can decouple that, like you have the content, but the agency can come in from scratch and build a really compelling front end experience, then we see much faster execution. Then there’s this whole layer of complexity that goes away. For example, if you’re building on top of WordPress, you have to be really mindful even in the design phase and in the UX phase of what data are you pulling into the main homepage, right. If you’re pulling in data from too many places and so on, you might make the homepage really slow, or you might have it go down when you get a traffic spike or you might have it be really hard to cache in any way. Whereas when you separate the build step from the runtime step and have like a build step in between the fetches, the content, build the HTML and then deploy it, you know, that the site will not be impacted by suddenly doing a hundred database queries for every time the page loads because it happens at built time so you know that the end result can be an incredibly incredibly fast. You get the reliability and scalability, you would always get out of the box with a tool like like Netlify. And you know, that in terms of security maintenance, you typically have like very low requirements because it will be the only the output of the buildthat’s exposed to internet users and internet traffic, and not the actual program.

Robert: That was wonderful Mathias! Thank you very much for your time and wish you great success.

Mathias: Thank you so much. Really appreciate it. Have a great one.