Backend Architecture Designs Overview

[00:00:00]
>> Erik: So we're gonna get into our first subject here, which is what are Backend Architecture Designs. And I love this GIF, because I feel like this is what happens a lot of times when people look at architecture or their design is what am I looking at, right? It's a huge flowchart and it's incredibly confusing.

[00:00:17]
I wanna be able to help you guys again, feel more comfortable being able to design these things, more comfortable having input on these things. And again, be able to if this is something new for you, inject yourself into, whether it be the conversations at your work or have an opportunity to explore and try new things.

[00:00:39]
So I did this last course and I wanted to do it again just because I thought it was very interesting to see how well AI had evolved from the last course. And so each section has a quote from AI that I asked. I basically gave it a very simple a very simple prompt on trying to describe the course in a very wise way.

[00:00:59]
And so this quote was success begins with understanding. Before we lay a single brick, it is crucial that we fully grasp the blueprint for a thorough comprehension of the foundation leads to a structure that stands the test of time. And I feel it actually did a pretty good job with this, especially with the, before we lay a single brick, I've seen a lot of people just go direct to implementation.

[00:01:27]
And then two months later, they turn around and they're like, I have no idea what I just built. And so I strongly urge if you're somebody out there who wants to get a job in whether be architecture or design. You have to you have to be comfortable with building these things out on paper first, right?

[00:01:52]
You wouldn't build a house without a blueprint. I mean, you could try, but probably wouldn't stand the test of time, for sure, and so that's a lot of what this first section is about.
>> Erik: So let's talk about the definition of what backend architecture designs are. So the definition that we have is the process of defining the modularity, interfaces and data flow for a system to satisfy specified requirements.

[00:02:19]
So Let's talk about the three things that it mentions here. First, modularity, right? Modularity can mean a lot of things. It doesn't necessarily have to mean that you have a highly extensible, highly distributed system. It just means that you have to break down these components in the way that works best for the problem that you're trying to solve, and sometimes it means that it's just one module, sometimes it means that it's many modules.

[00:02:47]
The modularity is up to you, it doesn't mean that you have to be heavily distributed. And as we'll talk about later on in the course, decisions even around modularity can impact developer productivity as well as understanding and complexity and things like that. Interfaces, so interfaces is really the in and out of the system or of the architecture, right?

[00:03:12]
How do these systems or back ends communicate with each other? Are you gonna standardize the interface that they're using, right? These are really good to consider because you don't wanna build one system that maybe uses GRPC, but then another system that uses rest unless you have a reason for that, right?

[00:03:31]
It's very common, especially in backend design or backend systems where there will be a similar interface across all of these system so that you can handle things like air handling properly or things like that. And then the last one is data flow, which modularity and interfaces impact your data flow, right?

[00:03:52]
Understanding how information routes through your system, how many jumps does it have to take is the interfaces between the two performant, right? Things like that will impact the data flow of that system and basically how it resolves through it. So let's talk about the importance of architecture design.

[00:04:10]
Because, as I said, it's one thing I wanna be able to empower you guys, and I talk about this in the introduction for developer or DevOps for developers, course. You should feel comfortable walking into a room full of engineers and say, wait, before we implement anything, we need to think this through, right?

[00:04:30]
And so it's very important to have a structured approach to solving complex problems. And that's what these architecture designs do. Again, going back to the house example, a house is a very complicated building or a very complicated structure to create when you really break it down and think about it.

[00:04:50]
Right, you've got the foundation that has to be laid. You've got the actual travel paths through the home. You've got electrical.
>> Speaker 1: You've got plumbing, right?
>> Erik: You've got roofing. There's a lot of layers to that. And we have, again, added these complexities to make our lives better, right?

[00:05:11]
And so having an architecture design around that helps making a better structure that lasts the test of time. Architecture designs facilitate communication among team members by providing a common language and reference. So you're not just making these for building. These architecture designs are also there to help facilitate the conversation between the teams at your company.

[00:05:42]
If you want to be able to sell an idea or a specific design that you want to implement, it's really important to be able to show that and facilitate that conversation easily between teams. And so architecture designs can help with the confidence between teams that may not fully understand the problem or may also need help understanding the problem.

[00:06:08]
It can also provide a common language in the sense of not like a programming language, but saying this is how we build this type of system, right? This is how we do this, so that in the future, if a developer need something, they have that off-the-shelf solution. And I talk about this in Intro to DevOps, as well as in the ECI or Enterprise Cloud Infrastructure course, which is when you have systems and designs already in place, you can move faster.

[00:06:38]
If you already have solved for the problem of how you process asynchronous messages, right, with maybe events, buses, or workers and queues, right? Then you don't have to think about that again. That's a system that has already solved a problem very well, and that makes it easier for teams to move quicker, especially going back to DevOps.

[00:07:00]
It'll help Have you build those systems as well as automate those systems? Yep?
>> Speaker 1: Assuming you're gonna get into this later, but do you have any tools for drawing up designs that you'd like?
>> Erik: Yeah, so I'll be showing a few of the designs I really use lucid charts.

[00:07:17]
Lucid is probably my favorite. I've been using Excel to draw more and more, but lucid has. Okay, so [LAUGH] the thing to note about designs is I've had principal engineers come into meetings with scribbles on a piece of paper, and then just screenshot that and put it in a conference document.

[00:07:38]
[LAUGH] And those are terrible.. I'm sorry but I have to say it, I understand that back in the 90s we just had whiteboards but we don't really need to do that anymore. And I do think that it it helps to have your design in a good layout format, easy to read and help identify each different component.

[00:08:04]
Lucid does a really great job at that. You can pick if you're using a container, you can pick if you're using a service or a subnet. There's a lot of really great ways of kind of architecting the design to your specifications while being able to present it in a nice visual format.

[00:08:20]
So I would normally lean towards the tools that help with that. It might take a little bit more, but as you'll see in some of the slides later, it still allows anyone to pick this up and eventually understand what you're trying to accomplish. And the last real importance here is they can improve efficiency and productivity by reducing redundancy and facilitating code reuse.

[00:08:46]
The point here really is is after you've designed something you've put it to paper, right? You might look back at it and say, well, this this service does the same thing as this service and they share some code. Maybe we could refactor this and so that all the code exists in one place, right?

[00:09:03]
And then every service sends their request to this specific service, which then makes the decoupling easier, the management of that specific component easier. And again, going back to the house example, it's really, really hard to have a whole Architecture in your head at all times. I know that there are some people who say that they can do it, but then when across multiple architectures across multiple systems, I can guarantee you that companies like Amazon, Netflix, Google, they've got tons and tons of charts, tons and tons of documentation.

[00:09:41]
Because it's a lot of extra energy to just keep that in your head, keep trying to reiterate it to people, right? That's also kind of tribal knowledge, which becomes very challenging when you wanna iterate on those things in the future. And so having these designs available, just being able to say go look at it can also help again look at things for improvements, as well as removing redundancy and things like that.

[00:10:06]
>> Speaker 2: Do you have any opinions on how to keep things like this up to date? I mean.
>> Erik: Yeah.
>> Speaker 2: I think a lot of places have designed documents that are like, I don't know if this is remotely trustworthy and even still.
>> Erik: Yeah, that's a super fair question.

[00:10:23]
And what's funny is they do talk about that a bit in the DevOps courses, because that was really my job for a while as well.
>> Erik: Listen, right now I work at a very large company. We have over 100 developers, we've got probably 15 different teams. It's got to be your culture.

[00:10:44]
It's really got to be your culture, the engineering managers need to be able to appreciate and understand why these things need to be updated. They need to be able to promote that time, right? I'm pretty sure all of us here, I'm not even gonna ask you to raise your hands.

[00:11:01]
Because I'm sure all of us here have experienced, we don't need to have time for docs. Let's just build, right? That's a terrible, terrible culture. Pretty much almost every company I've worked at, I've dealt with that. And I am a very much a proponent of fixing that. And so I think part of that is being vocal, bringing it to your managers and being like, hey, I have no confidence in this, and what am I to do when I don't have any confidence in the documentation that I have, right?

[00:11:34]
And actually, I will say, how many of you at your companies you're at today have confidence in the documentation that you guys have? Just by a raise of hands
>> Erik: cool so a little bit yeah, okay, yeah. So I know you guys on stream can't see but basically it was like one and a half people.

[00:11:52]
And that's really common. It's really common. And that should really kind of show how often companies deal with this and how little they actually prioritize it. So I do think that even the culture of the developer, while you're implementing the design or going through it, make sure you spend time going back, looking for any other documentation, outdating it, marking it, deleting it.

[00:12:17]
And you might even find other situations where the code or the sorry, not the code, the documentation and how you're doing it is not good. You might need to find newer ways of how to share these things, whether it be switching to something like, I don't like Confluence, I hate Confluence.

[00:12:35]
It's one of the worst platforms on the face of the planet, and every company I've ever worked at uses it, and I hate it. I really do not like Confluence at all and I actually had a conversation the other day with my engineering manager about this. Where I was like listen dude, we have the exact same problem we don't have a lot of confidence in our documentation but we have thousands of pages of documentation.

[00:13:00]
And so yeah, that it's really important to have up to date documents, up to date specs and design so that you can build that confidence and more people want to use it. Otherwise, you'll get to a point where nobody ends up updating anything, and you don't wanna get there.

[00:13:18]
We have one more important. They also play a key role in ensuring the final product, right? So really, the big reason why you make a design is to be able to say, okay, I've solved the problem that we're trying to solve, right? And you can show that through the design.

[00:13:36]
And even this stage of the design can mean and show whether or not it's overly complex if it's too simple, right? Once you are able to look at it at a high level and kind of share it with other people and other teams, you might find out that this is the design system that you're approaching may not even work or may not be what the company needs just because of different business objectives and things like that.

[00:14:04]
So it definitely plays a key role in before even spending developer money, which is really what this is, guys, you can save your developer money and time a lot at a company by just writing it down first. And spending a couple of hours documenting that, building out that design, and thinking it through before you actually start saying, okay, now team, go work on it.

[00:14:29]
You do not wanna build something that you don't have confidence in, otherwise you are wasting company dollars. So sgain, be aware of that. You really wanna make sure that you're meeting the user needs and business objectives.