How Your Architecture and Infrastructure Can Make (or Break) Your Team’s Productivity


Developers want to ship and create value for our users. Why, then, do so many teams struggle with getting things to production quickly? In this talk, Jason Lengstorf will look at the impact our frontend architecture and infrastructure has on our teams’ ability to build, iterate, and deploy software — and how it affects the quality and risks of deployment.

8 min
09 Jun, 2021


Sign in or register to post your comment.

AI Generated Video Summary

Today's Talk discusses how architecture and infrastructure choices impact team productivity. Complex systems can lead to frustration, fragility, and slowness, hindering efficiency and creating knowledge silos. Decoupled front-ends, pre-compiled front-ends, and serverless functions can improve productivity and enable faster deployment. Supportive architectures are crucial for building a shipping culture and avoiding frustrating, fragile, and slow systems.

1. Being Productive by Default

Short description:

Today, I will discuss how the architecture and infrastructure choices can impact team productivity. Complex systems can lead to frustration, fragility, and slowness. They can slow down developers and create knowledge silos within teams. Complexity also hinders company efficiency and can lead to bureaucracy.

JASON LENTON All right. Hello, everyone. And I am super excited to talk to you today about being productive by default. And what I mean by that is I want to talk about how the architecture you choose for your team and the infrastructure you put it on can make or break the productivity of your teams.

I've got a lot of ground to cover in seven minutes. So let's get right into it. First of all, our primary goal as a company is to ship value to customers quickly. The way that we succeed as a company is to produce something people want and get it to them fast so that we stay competitive and so the people want to continue paying us for our services. And teams want to ship. By default, teams want to get things out the door. It's very fun for us to see things go live.

So what stops a team from shipping? There are a few things that we're not going to talk about today like building a foundation of trust and making sure you're taking care of your people. I'm going to assume that you are doing that work because if you don't do that work, none of the advice I'm going to give you today is going to mean anything. But assuming you've got that in place, let's talk about your infrastructure. If your infrastructure and processes are frustrating, if they are fragile, if they are slow, if you have to go through a whole bunch of hoops and gatekeepers and checks and different teams and you're only able to deploy once every few days or maybe even every few weeks, that is very frustrating, fragile, and slow. You may have actually seen them talking about this but there's a good chance they've been using the acronym FFS, frustrating, fragile, and slow. Complexity is a lot of what leads to these frustrating, fragile, and slow systems. We are trying to do very complex things with our code and our apps but if we're not careful, that complexity starts to turn into sprawl and bureaucracy and that fragility. Let's talk a little bit about how complexity can affect the team. So first of all, complex system is going to slow down a developer. If a developer has to ask for permission to do part of their job, if there are things in the front end that require them to move into the middle tier or the back end and they have to ask for permission from a back end developer or wait on a DevOps engineer or start looking for other teams to take care of pieces of the work. It's going to slow them down. If you've got teams that are working in complex systems, you start to develop knowledge silos. You've got this problem where a team is going to be working on something and they're the only ones who know how it works. And worse if that team has someone who's the only one who knows how it works, that means that the entire team can get stuck if one person is out. That's no fun. It creates a lot of pager duty. It makes it hard for people to go on vacation and it's hard to create autonomy. Complex systems also slow down companies. A key cause of bureaucracy is complexity.

2. Improving Productivity with Infrastructure Choices

Short description:

Fragile systems lead to slower deployment velocity and increased fragility. Decoupled front-ends reduce complexity and allow for faster deployment with low risk. Pre-compiled front-ends reduce fragility and enable quick rollbacks. Serverless functions reduce boilerplate and empower front-end teams to make privileged API calls. By choosing an infrastructure that focuses on the front-end, teams can be more productive and deploy multiple times a day.

If your systems are fragile, you start to put processes in place to control that. And if you put those processes in place, it can lead to your entire company becoming much slower. As things get slower, people are going to start slowing down on their deployment velocity because they don't want to go through that process. They'll put more and more changes into each deployment. That means each deployment gets bigger, and therefore more fragile, which means more things break.

Decoupled front-ends reduce complexity. Now your front-end developers get to be front-end developers. If you are decoupled and deploying to the cloud, you suddenly don't have a whole bunch of DevOps steps and managing node servers and figuring out how Docker and Kubernetes work for front-end deployment. You get to build a front-end, deploy it to Git, and CI-CD takes it live because it can be deployed with low risk to a CDN. Pre-compiled front-ends are going to reduce fragility. There are fewer moving parts. There are fewer servers being used in production. There are less things to break, which means that you can control that risk. It also allows you to do things like create immutable deploys, where each compiled version of the front-end is its own folder. So you can quickly roll back if something goes wrong with one click. That's a huge benefit.

Teams can just go live once they get a PR review instead of having to wait days or weeks for other teams to go through the process. And serverless functions reduce boilerplate. If you need to do something, like make a privileged API call, a lot of times this would fall into this middle tier, where it's hard to assign that to the back-end team, because it's an API that's only used for the front-end, and it touches data from multiple back-end teams. So it's not clear who owns that, and a lot of times it will fall to the front-end team. If you use serverless functions, now your front-end team is not dealing with Node and setting up proxies and setting up Docker and Kubernetes. They're just able to write some JavaScript and deploy that and get that privileged API call that they need to make really quickly. The big benefit of all this is that you don't have to think about servers, you don't have to think about DevOps, you don't have to think about rollbacks, you don't have to think about scaling, you don't have to think about caching, any of that. All your front-end teams need to think about is shipping. And that's why this model, by choosing an infrastructure that is giving your teams the ability to focus on just the front-end, that is letting them focus on just the bit that they're actually experts in, and letting them remove all of those extra dependencies, and that extra complexity that sneaks in when your front-ends become too complex. That is what makes teams really, really productive. And what that means for us at Nellify, for example, is that you can deploy to production not just daily, but multiple times a day. This is the Nellify app, It's not a marketing site.

3. The Importance of a Supportive Architecture

Short description:

Our front-end team can deploy four times within five to six hours after merging a PR. Adopting the Jamstack can lead to similar success. To build a shipping culture, it's crucial to have a supportive architecture. Frustrating, fragile, and slow architectures hinder developers and slow down shipping.

It's not a marketing site. It's not a one-off property. This is the absolute core of our business. And our front-end team is able to deploy as soon as a PR is merged, four deploys within the span of about five hours, six hours. That is an incredible velocity for a production team.

And that's not irregular. We see this happen to teams that adopt the Jamstack all the time. And I think that it's something that will be just as successful if you bring it into your team. If you want to build a culture of shipping, you need to create the architecture that supports it. And that's really, really important.

Because if you put an architecture in that is frustrating, fragile, and slow, your developers are going to be frustrated. They're going to see things break and they're going to be slowed down. They can't ship as fast as they want.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.
In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Day Berlin 2022React Day Berlin 2022
25 min
Building High-Performing Cross-Cultural Teams
Everything we do, from the way in which we write our emails, to the method in which we provide negative feedback and evaluate performance, governs the performance of our teams. And understanding how culture impacts our efficacy as a team can drastically improve our day-to-day collaboration. In this session you'll learn: How different cultures communicate, How different cultures evaluate performance and give constructive criticism, How different cultures make decisions, How different cultures trust, How different cultures perceive time.
React Summit 2023React Summit 2023
26 min
Principles for Scaling Frontend Application Development
After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.

Workshops on related topic

React Summit 2022React Summit 2022
50 min
High-performance Next.js
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.