Considerations

[00:00:01]
>> Erik Reinert: So let's factor in when you should use back-end architecture designs, right? So the first factor of an architecture design should really be the project requirements, right? The functionality, performance, security, and scalability needs of the project. You should be able to answer these questions really before you even start making a design.

[00:00:22]
This is part of the technical design approach, which is thinking about the problem you're trying to solve. And I do talk about this in the DevOps for developers course as well, which we call it hippo, the 3 W's, who, what and why, really first is who, who am I solving this problem for, right?

[00:00:41]
If you're not solving the problem for a specific part of the company, then who really benefits from it, right? What is the problem you're trying to solve, right? If you don't know the problem you're trying to solve, and you don't know who you're solving it for, maybe it's not as valuable as you think it is.

[00:00:58]
And then why you're trying to solve that problem is really important. So these project requirements can help you before you even start designing things on how you can get to where you want to. This is another big one, team expertise, we talked about this earlier where maybe you're a complete go shop, right?

[00:01:19]
But some reason you saw somebody who uses Rust, so now you're really interested into Rust, right? Selling that, even though you might need to, can be very difficult, right? And so you need to consider the factors of the experience and the skill set of the development team that you're working with, right?

[00:01:39]
I'm sure each of us at our companies have that one weird system that some person made and then left and now you have no idea how to manage it. This is a prime example of that, where the team doesn't understand it but the person who did do it does and now it's this black box that nobody can maintain, right?

[00:01:56]
Team expertise is crucial, don't do that team to your teammates, [LAUGH] like just don't, eventually you might have the opportunity to do the thing that you want, right? But again, if it's something that's so out of left field that nobody can relate to it, nobody can understand it, it might not be a good thing to incorporate into your design.

[00:02:17]
Budget, so we were just talking about open source and vendor lock-in and things like that, right? Considering your budget, whether it be engineering hours, right? How many developers are gonna be on the project? How much time are they gonna be working on the project, right? That's really important, those are resources as well.

[00:02:37]
Guys, developers are resources, okay, [LAUGH] I don't know how many times I have to say that, but they are, nothing is free. Nothing is free. You might think that open source software is free. No, it's not, you have to maintain it. You have to be able to support it, right, that costs.

[00:02:58]
And sometimes as crazy as it sounds, it might be easier to lock into a vendor because they have good pricing. Now they have an on demand pricing that's easy to use, and they also take care of the management of the system for you, right? So budget is a huge part of it and just another side story at Hippo where I work, we've had situations in the past where people have come to me and been like, yeah, I've only got like a $500 budget.

[00:03:26]
And I'm like, so you're gonna do like one thing then because [LAUGH] that's not a lot. But it is then going and saying, okay, you don't have a lot of a budget. Where can you allocate those resources so that you're using the most of your time, right? Or using the most of your budget or whatever towards valuable time.

[00:03:47]
So again, it's not just cloud costs and things like that. It's also making sure that you're considering how much effort you're gonna be putting into it. Time constraints Is a big one, right? As I said earlier with regards to exploration and things like that, if you've only got a week to build a project, don't spend five out of those seven days exploring.

[00:04:09]
[LAUGH] That's probably not a good idea. I've definitely done that before, but I've seen a lot of developers fail at time constraints, constraining yourself to again, time boxes so that you're not overly complicating the system or you're not making it so that it takes too long to implement.

[00:04:29]
Having good time constraints and having good structure around that can help you build things faster, help you iterate quicker, and help you even come back and maybe do it again a different way the next time. Project size and complexity, right? A good example of that, again is like the the blog and Kubernetes.

[00:04:50]
You don't need a massive system to run a very simple problem that you're trying to solve, right? The larger the project and more complex may benefit from certain systems, but smaller projects may benefit from not even using a system. And again, we're gonna be talking about this later on in the course with the different systems or architectures that we'll be discussing, and why it may just be simple to avoid all of it.

[00:05:21]
Seriously, it's okay to avoid all of that complexity if it means that you're getting to market sooner, that you have an opportunity to get it into the users hands. And I'll be real with you. Kubernetes is great but if you've only got one user, it doesn't matter. [LAUGH] Like it really doesn't so project size and complexity is really Important.

[00:05:41]
Maintenance, again, we've talked about this a lot, right? How long is it gonna take you to maintain this thing that you're building, right? If you're creating something and then you gotta be like, okay, now we've gotta set up pager duty for alerts on off hours and stuff like that, nobody's gonna look forward to that.

[00:05:59]
I don't look forward to that. I am on a pager duty, and I hate it [LAUGH] but I maintain those systems and we built them in a way where if the front end goes down because we decided to not be serverless or things like that. Then I'm in charge of that I have to consider that, right?

[00:06:17]
And that's a part of it is how easy is it for you to maintain the system that you're creating? Another good example of that is, before I started working at Hippo, we have one service called POD. It's a very monolithic application. It basically predates when the actual company was created and I found out through research that we actually spent more time and literal CPU resources on tests in PRS than we did on our production cluster.

[00:06:59]
So literally we're spending more time managing our like we were basically a CI company. I literally walked into a meeting one day and I said you guys realize that we're basically just a CI company with a front end and they were like what? And I was like yeah like we have thousands of cores being provisioned daily just to do tests and our cluster doesn't even scale this much.

[00:07:19]
Why are we spending so much time on testing? And now we're at a point to where it's like fractions of what it used to be. And that's really important is having that maintenance control and understanding how easy it is to maintain it. Considering technological choices as well, right?

[00:07:40]
Keeping track of the latest technological trends can influence the choice of the system design. Be weary with these trends, right? I'm not saying here that you should follow all the latest trends and just adapt to them. What I'm saying is you should be aware of them, right? It's a good thing to know the potential things that you can do in the future, things like serverless, things like microservices, events buses, things like that.

[00:08:04]
But it's also good to understand when you shouldn't use those things, right? Event bus might sound cool, but if you don't understand how event systems work, you could really be shooting yourself in the foot pretty quickly. And then going back to maintenance, how do you maintain that event system, right?

[00:08:24]
If you don't have good understanding of those technological choices, they can hurt you as well as help you. This one's huge, and I never see a lot of people doing this, which is user feedback, right? Actually talking to your users and asking their experience. You might not think that the architecture somehow relates to them, but it does, right?

[00:08:49]
Because what users might be dealing with might be because of your architecture, right? It might be because you designed something in a specific way. And so because of that they're seeing lagged responses or they're seeing more challenges in the user experience. And things like that because you didn't consider a lot of times I've seen people just be like, just throw a loader on it, it's fine.

[00:09:13]
[LAUGH] That's not always a good solution. Your users don't like to wait, especially in the year of 2024. User's like the attention span of a user now is like seven seconds. If you can't get a response within like five to seven seconds, they're out, they're done. They're like this feels slow because we've become accustom to that user experience.

[00:09:36]
I'm sure if you guys are scrolling on apps or things like that and a video doesn't load, you just skip. You don't care what that, that could have been a really cool thing, but because it didn't load in time and because you didn't think about that, that could be an impact and a consideration.

[00:09:53]
As a matter of fact, I actually do think, one company that does a really, really, really good job of this is Netflix, because Netflix constantly considers like the user experience? Has anyone noticed that, like nowadays, when you log into Netflix, sometimes you don't even need to use your password?

[00:10:12]
That's because I actually to go back to the interview part. I was actually interviewing at Netflix, and I was going to work on that system that was going to make it so that they could figure out and authenticate you without actually having to authenticate you. They could look at things like your IP address, where you're coming from, your network, things like that.

[00:10:33]
And that was enough to have a score of being like, okay, this is the person we expect them to be, let's get them into the platform quicker. So, I do think Netflix does a really good job of user feedback. Market trends, this is kind of circumstantial, but if you work in finance, for example, considerations of how financial structures change.

[00:10:58]
For example I work in an insurance company, right? Every year we have to redefine our plans, our rates for specific states. There's different rates that we can provide and things like that. And we have to follow market trends for that. Understanding when things are going to change and you having to follow that flow is really important.

[00:11:22]
Because if you're not considering that, that might go back to how easy it is to maintain that system even from a developer standpoint. And to give you an example of this, I don't know why, but a long time ago, we decided that everything should be in JSON files.

[00:11:40]
All of our rate plans should be in JSON files. And now we have thousands [LAUGH] of JSON files that we have to maintain. And I'm actually working on a project right now at my job to figure out how to make that easier for developers because our rate changes go years back.

[00:11:59]
We need like we have to keep that data. We can't change it, it's immutable, right? But because the market changes, because there might be more storms in Texas versus California. We have to change those and these become thousands and thousands of snapshots that unfortunately, we didn't really consider where we are today, how much of a challenge that would be.

[00:12:23]
And the last one is legal and regulatory requirements. So, we don't really deal with this a ton in America just because we love selling personal data. But again, if you work in Europe, right, or other parts of the world, you might have other personal data requirements on how to store that data, how to share that data, right?

[00:12:45]
The whole do not sell my information. That little button alone can be an entire system of, okay, how do we make sure that this information doesn't get leaked, or get exposed, or get resold or things like that. So compliance with laws and regulations may dictate the kind of system that you create and how you create it.