Recomposing Enterprise Frontends at Navan

Bill Watson

There are a few buttons on here, so I imagine it's the big green one, Phil. Okay, for those who don't know me, it's very bright up here. My name is Bill Watson. I am a software architect that specializes in the frontend space. I have a background in full stack, but more recently, I switched over into the frontend space because I have a passion for design, and I really think that impacting the users is where I wanted to be in my profession. I've worked in both large and small companies like Yahoo, which is one of the bigger ones, and then I've worked for a large number of TMCs. For those that don't know, it's travel management companies, just like Navan. Let me tell you that the industry is ripe for the takeover. There is way too much tech debt. Basically, the whole industry is built on a legacy machine called the GDS. I won't get into details about that, but from my perspective, I love how things work. I am obsessed with making governance an important aspect of frontend development architecture.

Alright, so today we're going to be talking about who Navan is. We're also going to talk about frontend ecosystems, where we are. We're going to go into Enterprise adoption and simplifying the migration. We also have a case study, and then we're going to head into what Navan is planning to do in the short term and the long term.

Recently, we rebranded from TripActions to Navan. This was a significant undertaking. As you know, a company of our size, which is now almost $10 billion, has a wide range of tool suites and platforms that we deliver our services on. So, if anybody's been through a redesign, they know the tech debt that's incurred during that process. Personally, I've been through about 7 rebrands, and I didn't expect to do one right when I came into this company. I was 2 months in, and they said, "Hey, we want to do a rebrand." I thought, "Please don't give me that." But anyway, it went off smoothly. But this is one of those things that large companies do. They move extremely fast and want to get things done. Most companies that are startups end up turning into enterprises but accrue tech debt during that time, and this is no different from Navan. Most of these companies focus on driving the company forward and then they focus on the backend.

Let's talk about what Navan does. Navan does a very special thing for the industry. They have been actively disrupting the industry for about 8 years. They question every status quo across the board, which is one of the things that brought me to them. If you go out to any of the partners, if you use Expensify, Concur, if you're integrating with Saber, we want to go all around that, completely break the mold, tear it all down, rebuild it from scratch, and start a new trend of making booking travel less stressful and leaving the stress for travelers.

Here is a graph showing how we've been scaling. You can see a small dip when COVID-19 took place, but basically, we've been exploding for the last 6 years. With this comes our feature development life cycle. Most of the requests, both from large and small companies, go through feature development, and they build extremely fast, accruing a lot of tech debt along the way. When requests come in, you quickly find out that supporting customers, adapting to business landscapes, breaking into new verticals – these aren't engineering needs. These are what the company focuses on so that they can continue to grow. This doesn't always align with engineering.

As we can see here, we have a couple of examples of how it looks different between engineering and product. You can talk to any person who has ever tried to make a change at an enterprise. It's always the same thing. This is the biggest problem with pushing new technology stacks into a well-established company or a late-stage startup.

From the product perspective, you can see shipping features, design parity, fast releases, engineers. From the product and the sales side, it's all about money, which is great. That's how we have jobs, that's the way we want it to be. But engineers focus on saving money. They don't want to cost more money, and it's not always seen in parity. Saving money is not the same as making money, but we have to put this forward. The majority of the changes happen in isolated teams across the organization, going in different directions in different verticals.

So, we're going to pivot into what the frontend landscape looks like right now. I gave you a moment on this slide because a lot of people, the decision-makers in companies, realize that, "Hey, you guys are creating JavaScript, HTML, and CSS. Cool, go do it." That's not what we think about on a day-to-day basis. This is a very small snapshot of what we do and what we think about regularly. When they say, "Create a new project, go ahead and spin it up," "Oh, cool, yeah, I can have React up and running in five minutes." But what about all the rest? You try to explain this to them. This is normal. But how do we decouple companies to understand this and not only understand it but give you the ability to make these shifts? And this is something that is a long-standing issue. It's not company-specific. This is across the board, and I'm going to keep reiterating that because it's important for decision-makers to know that we actually do a lot more than you actually see.

Actually, it's not the problem because the problem is a lot bigger. When you have a large company, you don't have 1 project. You have 500 projects, and they all have different repositories, different patterns, different flavors, different versions. So, how can you change this effectively within a governed ecosystem? These systems are defined. They may not be perfect, but that's what they know, and they do not want to change. So, how do you give them an out? That's the hard part. Every single salesperson here, whether you're an agency or you’re Netlify, you need to find that decision-maker who understands this problem as a whole and can give you the ability to transition a company into the new tech space with ease, with limiting the impact it has on their customers and increasing ROI.

The company first decides, "Let's refactor everything." I don't know about that. So, who else is doing this? What can we do? How can we take some heavy lifting off of what's currently been delivered? I consider this kind of like Amazon Cloud. We've heard about this from previous speakers, but do we really want to create a frontend cloud and manage it? Probably not. We're all here because we know that. The next piece is all right, let's go ahead and build it. An example about 6 months ago, I was tired of serving from ECR. I didn't like Docker containers, and I didn't like serving them from Docker containers. So, I decided to build a little bootstrap project. I spent two days on it. I got it out in S3, put it in front of CloudFront, and said, "Hey, look at it. I deployed in 6 seconds." They were like, "What? Are you kidding me?" The web is not as complex as it needs to be. But a lot of people need to learn about how you can change the habits and let them understand that these POCs can be vision, but this is something that I don't want to maintain. Did I provide Edge functions, did I do proxies, did I do environmental variables? No, I didn't want to handle all that. I just wanted to put some static files on a CDN and give them to the client. We actually went through a 6 month audit. I may be sharing a little bit too much, but look at the feature comparison. This is pretty astounding to see what you get out of the box from Netlify.

Yes, there are some pieces missing, but they're a partner and they work with us extremely well, giving us the ability to push them and give us also some feedback about what we can do better. That's what I love about the partnership with them. With the combination of CI/CD, we ended up landing on a flavor of GitHub Actions and Netlify. Coming back to what we had discussed before, you need to give the enterprise an off-ramp. This is a perfect quote to discuss that off-ramp. We signed a contract with Netlify. They've been a client of ours and a partner for a very long time, but they didn't have all of our business. We were focusing on the client website for a long time, which is our public-facing navan.com. But we have a massive amount of internal tools that needed to be enhanced. But we also suffer from the monolithic approach that we've been hearing so much about. We have large code bases, we have some older versions, and we need an ability to break those apart.

Did I want to go through setting up Docker containers, setting up the infrastructure, setting up the release pipelines for all of these individual applications that I plan to build to decouple these large monoliths? No. So, we signed the contract, and we now know how we're going to do it. These were the requirements for our migration. We wanted to make sure it was gradual. We wanted to go environment by environment. We also wanted to ensure that it was application by application. Teams could move at their own pace. We wanted to have a rollback strategy, and with Netlify, you know that that's pretty much guaranteed. We were hosting asynchronously. You deploy, and we go both directions. We choose where we want that traffic to go. Great. We wanted developer ease of use, which means if you needed to migrate, you could do it, and you could do it easily. We also wanted this to be composable because not every CI pipeline or deployment mechanism is the same. They have different flavors, they have different needs. We also wanted to create some form of base standard for the CI/CD process. We needed to go ahead and ship new fast apps, monorepo support, documentation, observability, security, compliance. Our utmost enterprise needs all of this.

The way that we did it is, if anybody's familiar with GitHub Actions, it's a very simple out-of-the-box solution, and has a very robust open marketplace. You can also have self-hosted runners, which we're currently using. You also have the ability to do shared composite actions, as well as shared workflows. You can also build your own JavaScript workflows for anything more complex. We landed kind of in the middle. Here is an example of two of our workflows. The one on the left is our development workflow. This is normally when you merge a PR against the default branch. It's going to run your typical tests, it's going to run your lint, you have an optional build command, you can do some linting, and other features like that. And then you have your release, and all that this release is doing is just saying, "Hey, let's go ahead and run the full suite, and then we'll move on, go ahead and tag that, and then Netlify will pick that up and deploy it."

From a user's perspective, they don't need to go into Jenkins anymore, they don't need to look at those massive logs and search, and their browser crashes because there's way too much text on the page. We broke this up into five different workflows. The first one being compliance, development, maintenance, security, and release. All these we can tap into at any given point, but what we're highlighting here is that once you go ahead and implement these 15 lines of code into your repository, you get everything on the right for free. Everything comes with it. How can you not go to every developer team in your organization and say, "I don't have time to put 15 lines of code in?" Like, "What? We're doing everything for you. Everything is heavy-lifted, it's done. You just have to put this in, we'll schedule the migration for you." What this allows us to do is give the developers more time to focus on what's important and give them more creativity to introduce newer patterns, newer frameworks, test out technologies. Less about everything else and more about what makes the company more productive and ships features faster. And I added a little aside at the bottom because we can tap into any one of these workflows at any point, increment a version, change, and everyone gets it. Or if they don't want it, fine, compose it the way you want.

So, let's talk about Navan Expense. This was one of our first migrations that we did with Netlify. We have been in the contract for maybe 4 months now, and we've successfully launched about 35% of our sites. We have one large monolith repo to break apart, and that will be coming soon. But this was our first big one that we did. A little bit about this application. This application is hosted in one repository, and it's based around NX framework. You have applications, libraries, end-to-end apps, and there are seven apps, ten libs, four end-to-end test suites, and all of this codebase is big. You have interdependency nightmares across the board. When we run the affected suite, we found that, "Oh my gosh, we have to rebuild every single application every single time." Okay, great. We need time to refactor that. Good. But what we were able to do very quickly was this application had been set up on Jenkins and it was not optimized to its full potential. Within a matter of about two and a half to three weeks, we had our deploy previews done in one day. We had all of our staging environments set up in about two weeks, and then we fully migrated prod in two days. We did 10% of the traffic, and then the next day we did 50% of our traffic, and then we did a full cut over. There was 0 downtime, and we saw a bump in the CDN performance around 5% to 7%. We also moved from scheduled releases of two times a week to full CI/CD. We also increased the pipeline time from around 2.5 hours down to about 30 minutes. This was extremely beneficial for the team, the cadence, the project managers, and the developers. They feel confident about merging to master, and everything goes out according to plan.

So moving forward, this can allow feature developers or ICs to focus on feature development, create new projects, optimizing the code base, etc. It takes away everything else. They have the ability to ship faster, they have the ability to focus on what's important, and they can explore. We don't want developers focusing on small things and they don't have enough tools in their toolbelt. Netlify has that and we all know that that's why we're here. We can focus on giving the innovation back to the ICs.

Some of our favorite features — build speed, Dana the caching we're going to talk about it because I love it! I want everything built over there, just take everything and we'll get there. Unlimited environments — this is a new concept to our developers and it's been great because we can talk about the Deploy Previews, we can talk about branch deploys, and we can do bug bashes at anytime we want. The Netlify Drawer — we have less splits in our shared environments because of this directly. You no longer have to push it up. Have an account manager look at it, then send it back, and then you have another PR that just fixes a typo. We can do dedicated things in a PR, and they can work on it. The CLI has so much potential but I love the fact that we can deploy locally for it. No more dedicated proxies for that environment, no more dedicated environmental variables. You can use the CLI to go ahead and run your dev builds, and you don't have that extra initial setup. Click-once rollbacks give you that guaranteed scalability to trust what you're putting out in production. Then obviously the partnership is huge because you need to be able to trust that these guys are going to follow what they believe in which is open source. That's another thing that we love about this company. They follow the standards to give you the ability to make the valuable choices that you want.

Some of the key takeaways — Netlify has enabled me to make a bigger impact at my organization. I could not have shifted or pivoted our company to move towards more modern frameworks, better CI infrastructure, and better tooling for our developers without this. The developers can move faster, they have a standard way. We feel happy with the security and compliance around it. We can tap into the CI cycle at any time we want, and we're bringing innovation back to the developers. This enables us to hire top talent much faster. If you go ahead and handcuff your developers in your current architecture, you're not going to get any talent. But by enabling them to use the latest, everyone's going to want to come work for you. Thank you very much Netlify, glad to be here!