Latest / DevQuestions with Tim Corey / 227. You Are Scaling Your App Wrong

Transcript

227. You Are Scaling Your App Wrong · DevQuestions with Tim Corey

• 0:00
  SPEAKER_01: You are scaling your application wrong.
• 0:03
  SPEAKER_01: Everyone wants to have an application that's scalable, that can grow as they grow.
• 0:07
  SPEAKER_01: However, almost everyone does it the wrong way.
• 0:11
  SPEAKER_01: So let's talk about the mistakes people make when trying to build a resilient application in today's episode of Dev Questions.
• 0:26
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:30
  SPEAKER_01: Software development is more than just writing code.
• 0:33
  SPEAKER_01: So let's talk about the rest of it.
• 0:35
  SPEAKER_01: Specifically, let's talk about how to properly set your application up for long-term success with scalability.
• 0:42
  SPEAKER_01: Now let's start off right away by setting a good foundation to work on.
• 0:47
  SPEAKER_01: Let's start by defining the term scalability.
• 0:50
  SPEAKER_01: The idea is that your application might support a few users now, but in the future, you might have hundreds or thousands or even hundreds of thousands of users that use your application every day or every hour or every minute.
• 1:05
  SPEAKER_01: How do you design your application to be able to meet the growing demands, is what we mean by scalability.
• 1:12
  SPEAKER_01: Now, the vast majority of apps do not need to scale the way that you think they do.
• 1:18
  SPEAKER_01: In fact, I would go so far as to say that 99% of all web applications can easily run on one web server.
• 1:27
  SPEAKER_01: And I know that when I say that, there are people out there that are thinking, well, yes, that's for everybody else, not for me.
• 1:35
  SPEAKER_01: My app is the exception.
• 1:37
  SPEAKER_01: No, it's not.
• 1:38
  SPEAKER_01: Your app isn't exempt from this.
• 1:40
  SPEAKER_01: But that doesn't mean you can't avoid thinking about scalability.
• 1:44
  SPEAKER_01: So let's talk about the five key factors for application scalability as I see it.
• 1:50
  SPEAKER_01: Now, these five factors apply to any application of any size.
• 1:55
  SPEAKER_01: It doesn't matter if you're building a small application to support a few users or trying to build the next Google.
• 2:02
  SPEAKER_01: So let's talk about those five key factors.
• 2:05
  SPEAKER_01: Factor number one, and this is gonna surprise you, good documentation.
• 2:10
  SPEAKER_01: And you may say, Tim, that has nothing to do with scaling my app.
• 2:13
  SPEAKER_01: It has everything to do with scaling your app.
• 2:16
  SPEAKER_01: Let's think for a minute.
• 2:18
  SPEAKER_01: As your app grows, the what's the biggest difficulty you'll experience?
• 2:23
  SPEAKER_01: It's not gonna be, oh, how do we get more people to be able to be on the site at one time?
• 2:29
  SPEAKER_01: That's not the first thing that happens.
• 2:31
  SPEAKER_01: The first thing that happens is you have more users.
• 2:35
  SPEAKER_01: Well, so what does that matter?
• 2:37
  SPEAKER_01: Well, because with more users comes more bug reports, more issues, and more feature requests.
• 2:44
  SPEAKER_01: How do you handle that?
• 2:46
  SPEAKER_01: As your app grows, you have more and more people that are using your application, more and more people that want to use your application.
• 2:54
  SPEAKER_01: And you bump into more and more problems.
• 2:57
  SPEAKER_01: So how do you grow?
• 2:59
  SPEAKER_01: Well, you grow your team.
• 3:01
  SPEAKER_01: You grow the number of people that are working on your application so you can put out new features, new bug fixes faster.
• 3:09
  SPEAKER_01: Well, how do you grow your team?
• 3:12
  SPEAKER_01: You hire new people, but when you hire new people, the most common thing that happens is that it slows your team down.
• 3:21
  SPEAKER_01: Because they have to onboard that person, they have to train that person, they have to bring that person up to speed.
• 3:27
  SPEAKER_01: And that can take months to get right.
• 3:30
  SPEAKER_01: Well, if you're gonna be slowing your team down, guess what you're not doing?
• 3:36
  SPEAKER_01: Supporting that larger customer base.
• 3:39
  SPEAKER_01: So your application may lose users because you were not equipped to handle the moment.
• 3:46
  SPEAKER_01: So good documentation allows you to more easily onboard people, get them up to speed, get them going in the same direction the rest of the team is, and get them fixing those bugs and adding those new features.
• 3:59
  SPEAKER_01: This allows you to grow your application by growing your user base, by supporting your growing user base.
• 4:06
  SPEAKER_01: So, good documentation is actually one of the most important and one of the first things that you need to work on in order to scale your application.
• 4:16
  SPEAKER_01: You have to remember that scaling your application isn't just about cool features or microservices or working with the cloud and all that.
• 4:25
  SPEAKER_01: That's not what scalability is because you can have the most scaled-out application ever that no one uses.
• 4:33
  SPEAKER_01: Scalability is the entire process, it's the entire ecosystem of your application.
• 4:40
  SPEAKER_01: If you've got a massive application and one part-time worker working on maintaining it or fixing the bugs, it's not going to go well.
• 4:48
  SPEAKER_01: Even if you have that application running, well, your customers aren't going to be happy.
• 4:54
  SPEAKER_01: You need to be able to support that application.
• 4:57
  SPEAKER_01: So you need to have the team around it to support it.
• 5:00
  SPEAKER_01: You need to have the willingness of your team to work on this application.
• 5:06
  SPEAKER_01: You need to have the backing of management to work on bug fixes, to improve the application, and to know which items to add or which features to add in order to keep this application moving forward, in order to keep your customers happy and bring in new customers.
• 5:23
  SPEAKER_01: So it's not just about the code itself, it's about the entire ecosystem.
• 5:28
  SPEAKER_01: And so the number one thing you can do is have good documentation.
• 5:32
  SPEAKER_01: It allows you to onboard new developers.
• 5:35
  SPEAKER_01: And if you have front-end requirements, maybe it's a good idea to have good documentation there too for things like onboarding new support staff, new help desk people, new sales representatives, whatever the case may be, having good documentation will allow you to bring people up to speed much more quickly, which will allow you to grow faster.
• 5:57
  SPEAKER_01: So that's number one.
• 5:58
  SPEAKER_01: Number two, let's talk about the code.
• 6:01
  SPEAKER_01: Simple code.
• 6:03
  SPEAKER_01: This is the thing that trips a lot of people up, especially if you haven't built a lot of applications or a lot of scalable applications before.
• 6:11
  SPEAKER_01: The temptation is to say, okay, I need to have all these design patterns.
• 6:17
  SPEAKER_01: I need to have this complicated system of all these different interlocking things for testing and for scaling out and for communicating between services and all this other stuff.
• 6:32
  SPEAKER_01: Well, guess what?
• 6:33
  SPEAKER_01: The more complex your code is, the harder it is to fix bugs and add new features.
• 6:39
  SPEAKER_01: And again, it comes back to if you need to fix more bugs faster and you to add more features faster, well, what's a great way of doing that?
• 6:49
  SPEAKER_01: Writing simple code that's easy to work on, that's easy to fix bugs, that's easy to roll out new features.
• 6:57
  SPEAKER_01: If you have to open 18 different files to track down one simple request through your system, that's probably too many.
• 7:05
  SPEAKER_01: You're probably making this thing too complicated.
• 7:08
  SPEAKER_01: And by doing that, what you're doing is actually making it harder to scale your application.
• 7:14
  SPEAKER_01: Remember, scaling your application is not just about how many users per second can hit your site.
• 7:21
  SPEAKER_01: It's about being able to support your application.
• 7:25
  SPEAKER_01: It's about being able to have that whole ecosystem.
• 7:27
  SPEAKER_01: And so a complex application, complex code is going to burn you in the long run.
• 7:34
  SPEAKER_01: So the simpler your code, more simple your code is, the better.
• 7:39
  SPEAKER_01: Now, when I say simple, I don't mean that it doesn't do much.
• 7:43
  SPEAKER_01: There's a difference between simple code and code that does simple things.
• 7:50
  SPEAKER_01: So my analogy, the kind of the broad categories I think about the three different levels of developer.
• 7:58
  SPEAKER_01: If you want to put them in three general categories, you could say beginner, mid-level developer, and a senior developer.
• 8:05
  SPEAKER_01: So junior, mid-level, and senior.
• 8:07
  SPEAKER_01: Well, a junior developer writes simple code that solves simple problems.
• 8:12
  SPEAKER_01: And a mid-level developer writes complex code to solve complex problems.
• 8:17
  SPEAKER_01: And a senior developer writes simple code to solve complex problems.
• 8:22
  SPEAKER_01: So that's how I see it as the three categories, and of course, those are rough categories, but that's what you want to get to is the idea of writing simple code to solve complex problems.
• 8:32
  SPEAKER_01: You don't want to have a super complicated infrastructure that takes a long time to even describe to someone in order to support your service.
• 8:43
  SPEAKER_01: Because when you do that, go back to point number one, it's hard to document that because it's so complicated, so much to do.
• 8:50
  SPEAKER_01: And two, then it's hard to support that because you have a lot of work to track down any one issue.
• 8:57
  SPEAKER_01: And if you have hundreds of issues you're working on, that makes life so much harder.
• 9:02
  SPEAKER_01: So simple code.
• 9:04
  SPEAKER_01: Code that is working on hard problems, but in a simple way.
• 9:09
  SPEAKER_01: So don't just add design patterns, don't just add systems, don't just add frameworks because the hot new thing, or because you know your the TikTok guy said to do that, or that YouTube guy said to do that.
• 9:26
  SPEAKER_01: Don't just add that because someone told you to.
• 10:02
  SPEAKER_01: Okay, so think through how to make your code simpler.
• 10:05
  SPEAKER_01: All right.
• 10:06
  SPEAKER_01: Number three, writing performant code.
• 10:11
  SPEAKER_01: And this is another area where people just get burnt.
• 10:15
  SPEAKER_01: I've seen company after company.
• 10:17
  SPEAKER_01: I've worked with lots of companies that they add new servers or they add more RAM or they buy a beefier server because that's the solution to making their application run better.
• 10:31
  SPEAKER_01: They say, oh, we need a scale so we're gonna add more RAM, or we need a scale so we're gonna add three more servers.
• 10:38
  SPEAKER_01: Well, is that the right solution?
• 10:42
  SPEAKER_01: Oftentimes I'd say no.
• 10:44
  SPEAKER_01: Because oftentimes what happens is they've written poor code.
• 10:48
  SPEAKER_01: It's not very performant.
• 10:50
  SPEAKER_01: And so instead of addressing the code, they just throw more resources at it, thinking that they're somehow scaling their application.
• 10:59
  SPEAKER_01: Instead, what you want to do is think about how to optimize your code.
• 11:05
  SPEAKER_01: Understand where the bottlenecks are.
• 11:08
  SPEAKER_01: If you can't tell me where the bottlenecks are in your application, how can you tell me you need to be able to add more servers or more resources?
• 11:18
  SPEAKER_01: If it might be as simple as rewrite that that um that little bit right here in a different way.
• 11:26
  SPEAKER_01: It might be to write some SQL code that's better, more optimized than what you've got right now.
• 11:33
  SPEAKER_01: It may be thinking, rethinking how you do display of data.
• 11:39
  SPEAKER_01: For example, one of the ones that I see a lot, and people really want to hold on to this tight.
• 11:44
  SPEAKER_01: You have a web page or web application, and you want to show users a grid.
• 11:51
  SPEAKER_01: Everyone loves a grid on the web page for whatever reason, and so they say, okay, we need to have a grid.
• 11:56
  SPEAKER_01: Cool.
• 11:56
  SPEAKER_01: It's gonna show us all of our users.
• 11:59
  SPEAKER_01: Great.
• 12:01
  SPEAKER_01: It's gonna have a hundred thousand users on it.
• 12:05
  SPEAKER_01: No.
• 12:06
  SPEAKER_01: Just no.
• 12:08
  SPEAKER_01: Do not load all those records onto the webpage.
• 12:12
  SPEAKER_01: Just don't.
• 12:14
  SPEAKER_01: Worse yet, do not load all the details about those records onto that webpage.
• 12:19
  SPEAKER_01: For instance, maybe you're showing first name, last name, and email address and their ID in that grid.
• 12:26
  SPEAKER_01: That's the only four pieces of data you should have in the back end.
• 12:30
  SPEAKER_01: You should not be loading the complete model for those users with all of their addresses, their phone numbers, their contact information, their relationship.
• 12:40
  SPEAKER_01: No, you should be loading just those four pieces of data.
• 12:44
  SPEAKER_01: Whatever you're showing to the user, maybe an extra ID if you're not showing the ID.
• 12:48
  SPEAKER_01: That should be it.
• 12:49
  SPEAKER_01: And you should not be loading all the records.
• 12:52
  SPEAKER_01: You might say, well, Tim, but I have to do sorting and filtering, and you have to do a lot of that in the server.
• 12:57
  SPEAKER_01: You just do.
• 12:59
  SPEAKER_01: Do not put that into a web application, even a desktop application, don't do that.
• 13:03
  SPEAKER_01: Because what you're doing is you're taking up a ton of memory, you're taking up a lot of resources for what the user isn't going to see.
• 13:12
  SPEAKER_01: And that's that's the thing.
• 13:14
  SPEAKER_01: If you have a hundred thousand records, if you have a thousand records on a web application, how many records does a user see?
• 13:24
  SPEAKER_01: Well, even if you said you have 30 records on a page, the average user is not going to go through more than two to three pages.
• 13:34
  SPEAKER_01: They're at most going to see 90 records out of a thousand.
• 13:40
  SPEAKER_01: And quite frankly, a thousand is a low number compared to what I've seen.
• 13:44
  SPEAKER_01: So why are you loading the other 900 records?
• 13:50
  SPEAKER_01: And you might say, well, Tim, I have to know that because I have to know how to display the pages.
• 13:54
  SPEAKER_01: No, you don't.
• 13:55
  SPEAKER_01: You need to learn how to optimize your data access code.
• 13:59
  SPEAKER_01: You can ask SQL or whatever your database engine is of choice to say how many records are there, and then give me the first 30, or the first 60 if you want to have that next page available without a call.
• 14:12
  SPEAKER_01: Okay, so you have 60 records, so two pages.
• 14:16
  SPEAKER_01: And you know that there is, let's just pick an easy number for me to do math on, 600 records total.
• 14:24
  SPEAKER_01: Well, you know there's 10 pages.
• 14:26
  SPEAKER_01: 60 or 600 divided by 60 is 10.
• 14:30
  SPEAKER_01: 10 pages.
• 14:31
  SPEAKER_01: So you can put those little numbers one through 10 at the bottom if you want.
• 14:35
  SPEAKER_01: And if the user starts hitting through, hits next, they load page two, which is already loaded because you loaded two pages.
• 14:41
  SPEAKER_01: And then when they load that page two, you can go ask the server for page three.
• 14:45
  SPEAKER_01: And you might say, well, but Tim, why don't they go to page eight right away?
• 14:48
  SPEAKER_01: Okay, so you ask the server for page eight.
• 14:52
  SPEAKER_01: And maybe if you really, really, really want to have this quote unquote great experience, maybe you ask for page seven, page nine as well.
• 15:00
  SPEAKER_01: Okay, so now you're loading the page as well as the page on both sides.
• 15:05
  SPEAKER_01: Okay, you could do that, but that's the most you should be doing.
• 15:09
  SPEAKER_01: And you should be thinking about even do I need to do this?
• 15:12
  SPEAKER_01: And you might say, well, what about sorting?
• 15:14
  SPEAKER_01: You go to the server and sort and bring back the first page.
• 15:19
  SPEAKER_01: There are a lot of things you can do to be more performant.
• 15:22
  SPEAKER_01: And you might say, well, Tim, that's gonna take lots of network calls.
• 15:26
  SPEAKER_01: Have you ever actually done any kind of performance metrics on it?
• 15:30
  SPEAKER_01: Have you evaluated what the best way to do this is?
• 15:33
  SPEAKER_01: Have you looked at caching records in something like Redis, where it's it's still cache, it's not going to the database server, but it's not on the client side or it's not in the client's browser?
• 15:44
  SPEAKER_01: Like there are ways to do this where you can have add performance if there is a bottleneck.
• 15:51
  SPEAKER_01: But you need to think about your performance code first by knowing where the bottlenecks are.
• 15:57
  SPEAKER_01: If you don't know where the bottlenecks are, you cannot make performance improvements.
• 16:02
  SPEAKER_01: Because what you'll be doing instead is making performance guesses.
• 16:06
  SPEAKER_01: And performance guesses can lead to as many problems as they solve.
• 16:11
  SPEAKER_01: Don't try and prematurely optimize your code.
• 16:14
  SPEAKER_01: Don't try to do things that you're guessing this should make things more performant.
• 16:20
  SPEAKER_01: Don't do that.
• 16:22
  SPEAKER_01: Now, yes, you can learn from your history, learn from what you've done in the past and know that there's certain things you should and shouldn't do.
• 16:30
  SPEAKER_01: And absolutely write good code.
• 16:34
  SPEAKER_01: But don't try to optimize and you know, tweak certain things and you know, be very, very specific about making performance improvements when you don't know if that's actually a performance problem.
• 16:44
  SPEAKER_01: Okay, so write performant code, but do that by evaluating your code, finding where the bottlenecks are and making them better.
• 16:53
  SPEAKER_01: Okay, so don't just blindly do it and do write performant code as opposed to just throwing more resources at the problem.
• 17:03
  SPEAKER_01: Number four, have a team with margin.
• 17:08
  SPEAKER_01: And again, you might say, Tim, we're talking about optimizing our application.
• 17:12
  SPEAKER_01: Absolutely we are.
• 17:13
  SPEAKER_01: And again, whole ecosystem.
• 17:15
  SPEAKER_01: So why is a team with margin?
• 17:17
  SPEAKER_01: First of all, what I mean by margin, what I mean is as a developer, if you come in on Monday morning and you have a mountain of work to do and you work all day long on Monday, all day long on Tuesday, Wednesday, Thursday, Friday, maybe even over time at some point, just to get stuff done and you're just focused on bug fixes or just fix on new features or whatever the case, that's not margin.
• 17:43
  SPEAKER_01: Margin is I have a little time that I am not required to be working on a bug fix or required to work on the next feature.
• 17:52
  SPEAKER_01: Having some time in your schedule that you can dedicate to maintenance, to other tasks that aren't going to be ever the top priority.
• 18:04
  SPEAKER_01: So a rush team that's hurrying to just get things done doesn't have time to do things like.NET version upgrades, or upgrading NuGet packages, or evaluating uh bugs in packages, or security flaws, or do any of the other important maintenance tasks.
• 18:24
  SPEAKER_01: So having a team at margin will allow you to make your application more scalable.
• 18:29
  SPEAKER_01: Now, why is that?
• 18:31
  SPEAKER_01: Well, if you're working on a.NET app, let's just say you are using an ASP.NET Core MBC application.
• 18:38
  SPEAKER_01: All right, so you have this web application that's been running great, but you've got lots of users on it and it's starting to slow down a little bit and you're starting to see some performance issue.
• 18:47
  SPEAKER_01: You're trying to find those bottlenecks and you're trying to make sure the code is simple, but it's still kind of slowing down.
• 18:55
  SPEAKER_01: Well, if you have some margin, one of the things is you upgrade the version of.NET.
• 19:00
  SPEAKER_01: Why?
• 19:01
  SPEAKER_01: Well, firstly, because you want to stay on the at least the LTS version, the latest version that's long-term support, um, or STS if you want to have the standard term or short-term support version.
• 19:15
  SPEAKER_01: But either way, one of the later versions.
• 19:17
  SPEAKER_01: But why?
• 19:18
  SPEAKER_01: Because isn't that just, you know, if you want to have the new features?
• 19:22
  SPEAKER_01: Well, no, not just the new features, every version of.NET has performance fixes.
• 19:29
  SPEAKER_01: So every version of.NET gets a little bit faster, and sometimes a lot faster.
• 19:34
  SPEAKER_01: Well, that right there can make your application better.
• 19:40
  SPEAKER_01: And then those NuGet packages that you have dependencies on, well, sometimes authors go, oh, there was a bug I fixed there, or there was a performance issue that I fixed.
• 19:52
  SPEAKER_01: Well, upgrading those packages can make your application more performant just because your dependencies get faster or the underlying framework gets faster.
• 20:02
  SPEAKER_01: So not only are those things good because they keep your application secure, they keep your application protected against issues, but they also can make your application more scalable by making it faster.
• 20:15
  SPEAKER_01: Because hopefully, as things grow and as things mature, they become more performant.
• 20:20
  SPEAKER_01: It's not always the case with all your dependencies.
• 20:23
  SPEAKER_01: But I can tell you with.NET, that is the case.
• 20:27
  SPEAKER_01: They work really hard on making things more performant.
• 20:30
  SPEAKER_01: So, number four, again, is to have a team at margin so you can do these maintenance tasks.
• 20:36
  SPEAKER_01: And it doesn't have to be just upgrades.
• 20:38
  SPEAKER_01: Maintenance tasks can be hey, this has been a problem, but it's just not been on our high prairie list, but we should take care of it.
• 20:46
  SPEAKER_01: You know, maybe it fixing this one thing will make the team faster in some way.
• 20:50
  SPEAKER_01: Maybe we're always dealing with one bug that just slows down our debugging process.
• 20:55
  SPEAKER_01: Fix that issue and keep going.
• 20:58
  SPEAKER_01: One of the ones I see a lot is logs.
• 21:01
  SPEAKER_01: If you look at your logs and you have hundreds or thousands of log entries, clean that stuff up.
• 21:08
  SPEAKER_01: Clean that up.
• 21:09
  SPEAKER_01: Figure out how to take out the irrelevant information, how to filter it down to the important ones.
• 21:14
  SPEAKER_01: And then if you have warnings or if you have errors in your logs, address them.
• 21:23
  SPEAKER_01: You want to get down to zero errors, zero warnings.
• 21:29
  SPEAKER_01: Now I know that is the pie in the sky, best possible ideal that might not feel achievable.
• 21:38
  SPEAKER_01: But having that margin will allow you to start addressing some of those.
• 21:42
  SPEAKER_01: Take the most egregious ones out of play.
• 21:45
  SPEAKER_01: That way, when you're looking for how your application is doing, you can see the real issues, the real just-in-time errors that might be caused by something, you know, a new patch or a new feature or something.
• 22:00
  SPEAKER_01: Something that happened, and you're not getting sidetracked going down rabbit holes of, oh, that's one of those bugs that just happens.
• 22:07
  SPEAKER_01: Okay.
• 22:08
  SPEAKER_01: Address those.
• 22:09
  SPEAKER_01: Fix those.
• 22:10
  SPEAKER_01: That way you make your team more efficient.
• 22:14
  SPEAKER_01: Now, number five, yes, you need a plan for scaling.
• 22:19
  SPEAKER_01: Okay?
• 22:20
  SPEAKER_01: A plan.
• 22:21
  SPEAKER_01: So this is where you have a plan for how your application is going to grow if it needs to.
• 22:27
  SPEAKER_01: Now, again, unscientific percentage.
• 22:31
  SPEAKER_01: Okay, so, but 99% of people do not need to have a web application on more than one server.
• 22:41
  SPEAKER_01: In fact, if you tell me, no, but I need it, I want to know have you optimized your code?
• 22:47
  SPEAKER_01: Do you even know where the bottlenecks are?
• 22:50
  SPEAKER_01: Have you made sure that you have written simple code?
• 22:53
  SPEAKER_01: Have you looked at what the problems are?
• 22:56
  SPEAKER_01: Have you evaluated if you're showing too much information, downloading too much information to the client?
• 23:01
  SPEAKER_01: All these things, have you performance optimized your application?
• 23:05
  SPEAKER_01: Or are you just saying, hey, I really didn't care about making my application performant?
• 23:11
  SPEAKER_01: I just gonna throw more resources at it.
• 23:13
  SPEAKER_01: Okay?
• 23:14
  SPEAKER_01: So again, 99% of people just didn't optimize their application.
• 23:20
  SPEAKER_01: Because today's modern servers are super powerful and handle thousands and thousands of connections at the same time.
• 23:28
  SPEAKER_01: And quite frankly, most people don't need that much.
• 23:32
  SPEAKER_01: Even big companies and big search engines don't often need the type of scale that people think they do.
• 23:40
  SPEAKER_01: Because even a hundred or a thousand connections a minute isn't that much.
• 23:47
  SPEAKER_01: So you can do that with one server.
• 23:51
  SPEAKER_01: All right.
• 23:52
  SPEAKER_01: But yes, you should have a plan for what do we do if we do exceed the server's resources and we can't optimize anymore?
• 24:00
  SPEAKER_01: Or maybe unfortunately you don't have time to optimize anymore, or our dependency on this third-party system means we have to scale out.
• 24:10
  SPEAKER_01: Well, have a plan for that.
• 24:12
  SPEAKER_01: Now, this does not mean that you make your whole application into microservices, thinking someday we're gonna have an ability to scale out all these different pieces.
• 24:21
  SPEAKER_01: No, don't do that.
• 24:23
  SPEAKER_01: And it doesn't mean complex design patterns with interlocking systems and inputs and outputs and all these other things to make this really complicated system that could scale someday.
• 24:35
  SPEAKER_01: No, no, no.
• 24:36
  SPEAKER_01: What it means is having an understanding of how your application could be scaled in the future.
• 24:42
  SPEAKER_01: That might just mean multiple web servers.
• 24:45
  SPEAKER_01: And you might think through well, if we have multiple web servers, what does this mean?
• 24:50
  SPEAKER_01: For instance, if you're trying to use any type of server-side caching, well, what happens if a person goes from one server to the other?
• 24:58
  SPEAKER_01: Do they lose data?
• 25:00
  SPEAKER_01: Does that cause a problem?
• 25:01
  SPEAKER_01: Maybe it shouldn't have server-side caching on the server.
• 25:04
  SPEAKER_01: Maybe it should be in a separate server, like a Red Hat server.
• 25:07
  SPEAKER_01: Think through those kind of implementation details so that you're prepared to scale your application in a way that is helpful, that is going to not cause a worse experience for the user.
• 25:21
  SPEAKER_01: So it might be multi-web servers.
• 25:24
  SPEAKER_01: It might just mean more resources for your existing server.
• 25:27
  SPEAKER_01: It might mean that you scale up an API, but you keep your web server itself the same.
• 25:34
  SPEAKER_01: Or maybe just the opposite.
• 25:35
  SPEAKER_01: Maybe you have multiple web servers and just still talk to the same API.
• 25:40
  SPEAKER_01: Because if you think through your plan, don't think about having a billion users a minute.
• 25:47
  SPEAKER_01: Okay?
• 25:48
  SPEAKER_01: What you're thinking about is okay, what if we are at 80% of our total resources?
• 25:54
  SPEAKER_01: And that's probably the number to look at.
• 25:56
  SPEAKER_01: Is if we hit 80% consistently of the number of resources we have for our server, or if we're spiking in certain times to much higher than 80%, well then how do we scale to the next level?
• 26:10
  SPEAKER_01: Not, again, not to the moon, just the next step.
• 26:14
  SPEAKER_01: Is that just having a second server and having it a round robin type, you know, send users to server A or server B?
• 26:23
  SPEAKER_01: And that might be all you need.
• 26:25
  SPEAKER_01: And that can be done quite easily, even in-house on your own physical servers.
• 26:31
  SPEAKER_01: Or maybe it's the fact that you have some things in the cloud and you just know that you can add a second server and you test that out.
• 26:38
  SPEAKER_01: So knowing what it means to take the next step, not all the steps, and you're not not sacrificing your application scale today for a theoretical scalability for tomorrow.
• 26:52
  SPEAKER_01: Meaning, again, you're not rewriting your perfectly fine web application into crazy microservices just because maybe someday I need to scale that.
• 27:03
  SPEAKER_01: Don't do that.
• 27:04
  SPEAKER_01: That's not the plan I'm talking about.
• 27:05
  SPEAKER_01: The plan I'm talking about is just knowing how do you take the next step?
• 27:10
  SPEAKER_01: How do we scale up to double or triple what we have right now?
• 27:14
  SPEAKER_01: And what would that look like?
• 27:16
  SPEAKER_01: And just understand what that plan is, and back to number one, document that.
• 27:46
  SPEAKER_01: So when you're applying to a college, you apply to a college, usually there's some set periods of time where that can cause some spikes.
• 27:54
  SPEAKER_01: Maybe for the fall semester, which starts in August, maybe there's a spike in March for applications, March and April, because students are wrapping up their high school and they're thinking about college, and so they're talking to guidance counselors and they're getting more serious about the future, or maybe they're that's back in January, whatever.
• 28:14
  SPEAKER_01: That's that can cause some spikes.
• 28:16
  SPEAKER_01: However, the big spike comes when you have your registrar say, okay, here's the classes that are available.
• 28:24
  SPEAKER_01: Sign up for your classes.
• 28:26
  SPEAKER_01: Because that's usually a smaller window.
• 28:28
  SPEAKER_01: That's usually in July or early August before classes actually start, where you can go on and say, There's the classes I want to take.
• 28:38
  SPEAKER_01: So you can have a web server that runs just fine the rest of the year, but on two days, the usage is five, six, seven, eight, ten times what it normally is, maybe even more.
• 28:53
  SPEAKER_01: Well, that can be hard.
• 28:55
  SPEAKER_01: And that's where you think about well, okay, so if we put this server in Azure, we can run on a cheap server.
• 29:03
  SPEAKER_01: And we can run just fine most of the year.
• 29:06
  SPEAKER_01: And we know for those two days, we can scale out, meaning add more servers for a period of 48 hours.
• 29:14
  SPEAKER_01: And yes, that's more expensive, but just for 48 hours.
• 29:18
  SPEAKER_01: And we scale back down.
• 29:19
  SPEAKER_01: That's the plan I'm talking about.
• 29:21
  SPEAKER_01: Having that type of plan can be super helpful.
• 29:24
  SPEAKER_01: Not just saying, oh, we're gonna create microservices and have as complex architecture so that you know, for those two days, we've got this.
• 29:32
  SPEAKER_01: Don't do that.
• 29:34
  SPEAKER_01: But have a plan, test that plan, and document that plan.
• 29:38
  SPEAKER_01: So if you think that scalability is just about adding more servers or implementing microservices, you're gonna create an absolute mess of an application.
• 29:48
  SPEAKER_01: So that's it's actually gonna cause that application to be less performant and less scalable than a simple web application.
• 29:56
  SPEAKER_01: So you need to think through where the scale really needs to come from and then how to set up for yourself the best possible scenario for success in the long run.
• 30:09
  SPEAKER_01: Okay.
• 30:10
  SPEAKER_01: So again, I keep harping on this, but if you create a complex application that's hard to manage, you got a stressed-out team with no margin, that's gonna be hard to maintain.
• 30:21
  SPEAKER_01: It's gonna be hard to grow.
• 30:23
  SPEAKER_01: It's gonna be hard to bring in more people or add more resources or grow the application out.
• 30:29
  SPEAKER_01: This is why preparing your team for scalability through good documentation and margin, and preparing your code for scalability through making it simple and performant is actually the best way to ensure that your application can properly scale.
• 30:44
  SPEAKER_01: And if you need to do that actual scale, if you need to actually scale the resources, having that plan will actually make the task much simpler and make it much more easy to actually add those extra resources when you need them and not until you need them.
• 31:02
  SPEAKER_01: The benefit of doing this this way is not only are you more prepared, calmer, and more able to handle the various situations that get thrown at you, but you also spend less money.
• 31:14
  SPEAKER_01: And you know what bosses love?
• 31:16
  SPEAKER_01: Spending less money.
• 31:18
  SPEAKER_01: Having a happy boss can make for a happy life.
• 31:22
  SPEAKER_01: Okay.
• 31:23
  SPEAKER_01: So this is the way to scale out your application.
• 31:26
  SPEAKER_01: This is the way to prepare for scalability, and this is the way to make sure that your team is set up for the best possible success.
• 31:34
  SPEAKER_01: I hope that answers your question.
• 31:35
  SPEAKER_01: Thanks for listening.
• 31:36
  SPEAKER_01: And as always, I am Tim Corey.
• 31:39
  SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
• 31:42
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.