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.
This talk has been presented at JSNation Live 2021, check out the latest edition of this JavaScript Conference.
The architecture chosen for the team and the infrastructure it operates on can make or break the productivity of the team.
The primary goal of a company is to ship value to customers quickly, producing something people want and delivering it fast to stay competitive.
Frustrating, fragile, and slow systems are often complex, involve many hoops and gatekeepers, and require lengthy deployment processes, causing delays and inefficiencies.
Complexity slows down developers, creates knowledge silos, and makes it difficult for team members to be autonomous. It also leads to frustration and increased pager duty.
Decoupling the front-end reduces complexity, allowing front-end developers to focus solely on front-end tasks without dealing with back-end processes, resulting in faster deployments.
Pre-compiled front-ends reduce fragility by having fewer moving parts and servers in production. This minimizes the risk of failures and allows for quick rollbacks if issues arise.
Serverless functions reduce boilerplate code and allow front-end developers to make privileged API calls quickly without dealing with complex back-end setups, enhancing productivity.
A frustrating, fragile, and slow architecture leads to developer frustration, increased chances of things breaking, and slower shipping speeds.
The Jamstack architecture allows teams to deploy multiple times a day, improving deployment velocity and enabling continuous and rapid shipping of updates.
Creating an architecture that supports a culture of shipping ensures that developers can ship quickly and efficiently, leading to higher productivity and satisfaction.
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.
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, app.nellify.com. It's not a marketing site.
Comments