You Are Scaling Your App Wrong
ฝัง
- เผยแพร่เมื่อ 11 ต.ค. 2024
- How do I create a web application that will scale? How do I architect my app to be scalable? Do I need to use microservices in order to properly scale up my application? These are the questions we will answer in today's episode of Dev Questions.
Website: www.iamtimcore...
Patreon: / iamtimcorey
Ask Your Question: suggestions.ia...
Sign Up to Get More Great Developer Content in Your Inbox: signup.iamtimc...
I went through this about a year ago. The project I was on was integrating with another web app. All the higher ups were concerned about scaling when this all rolled out to production. I kept saying it's not going to be an issue. They kept pressuring me to scale everything. The APIs were running under an S1 Azure App Service where utilization was averaging
The good news is that if you set things up well in Azure, you can always reduce the resources your app is reserving, which should save the organization money.
but higher ups know everything about scaling and development lol. they read somewhere scaling must happen no matter what
This may be one of your best videos yet. I know your audience is mostly entry level developers, but there are plenty of senior developers who grossly underestimate the operational component of scaling, premature optimization, etc. Writing code is easy, the people part is much more challenging.
Making the next step from Senior to Staff+ requires thinking about all of the key points in this video. Thanks again for the content!
You are welcome.
10:50 this is so important. All of us enterprise devs really need to take a look at Mike Acton and Casey Muratori's stuff on Data Oriented Design or Performance Aware Programming. the problem with a bunch of disconnected services is that there is almost no way to optimize the code across the whole process, there's no way to tell at a high level system wide perspective what part of the whole rube goldberg machine is causing the most perf problems. if the whole process would be almost instantaneous if you were in a single threaded modular monolith, and you make that into a distributed ball of mud, you're never going to be able to optimize. premature abstraction is the root of so many perf issues, not premature optimization.
1. Make Good Documentation
2. Simple Code
3. Writing Performant Code
4. Step by Step Scale Out
Hey Tim, would love to see a video about how to use a db/query profiler and/or how to implement some form of DI diagnostics for a simple application
This video just made a miserable Dev day a million times better. Thank you!
You are welcome.
Great video as always, I totally agree, the problem I faced was try to pass idea to the manager 😅
You are welcome.
How to find bottlenecks? Do you also have any video on that?
Load and/or stress testing. You can do it per component, but also end-to-end. You can roll your own test scenarios & "drivers" or there are third-party solutions for mid to large-scale testing (eg. simulating large #'s of web users clicking on various things).
Hi Tim.
What is you take on HA/DR? In my experience it is for the most part waste of time and money.
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
The quick version is that HA/DR is like insurance. You need to figure out how important it is and how much you should carry. For instance, DR is pretty important if your company depends on your app and your app goes down. If your company loses $10,000/hour that it cannot function and your app takes 8 hours to restore, that's a problem. If you cannot restore at all, the company can even go out of business. On the other hand, if your app is of secondary importance and going down for hours isn't the end of the world, spending very much on good DR instead of "ok DR" probably isn't worth it.
For HA, again, you need to evaluate the risk/rewards. If your data center goes down, are you ok? Can you spool up somewhere else in a reasonable timeframe? How much does that cost?
Masterclass video
Thanks!
First time to be first. :D
👍
ragebait titles like this are so annoying. You don't know anything about our apps
That's the thing - it isn't a rage-bait title. It is based upon real-world observation. I'm not just some talking head. I've spent almost 30 years in the industry with a large portion of that as a consultant. I've worked with hundreds of companies and thousands of apps. I almost never saw an app that truly needed to scale in the traditional sense. Rather, I saw apps that were either poorly written and trying to throw resources at the problem instead of fixing the true problem or they were prematurely scaled out in a way that made the app less performant and more brittle when they did not need to be. If Stack Overflow can operate as a monolith while serving 1.3 billion page views per month, most apps can probably survive without the typical scaling techniques.
The trap people fall into is seeing their application slow because the load goes up and thinking that the answer must be that their app needs to scale out or be architected with microservices. That is a simplistic view that represents a poor architectural knowledge of software development.