The need for a strategy

- [Instructor] We've discussed technical debt. Now, let's look the need for a strategy to address these issues. If you buy a car on credit, you owe the dealership money in the future, that you could've spent elsewhere. The same is true for technical debt. The term debt implies we have to pay something back. Whether that's money, time, or energy. At some point we're going to have to resolve the debt that we created. And just like financial debt, as time goes on, the debt increases. So it becomes more difficult to manage. And often because of the time lapsed, the optimal solution has changed, as the product has expanded. So what happens if we ignore the debt? Well, it might slow down release cycles due to longer development times. Increase costs, as we need more resources to support the solution, or even impact product quality, as we may not be able to roll out certain features because of previous decisions. It's always best to have a strategy to mitigate risk, as we know that technical debt is inevitable during our software development lifecycle. Let's say you have an IaaS deployment in the cloud. This means that your team needs to maintain the infrastructure and is responsible for patching the system. Given that you have test, QA, and production deployments, it's important for them to be aware of any differences between those environments. In a PaaS scenario you might have serverless functions with an Azure SQL database as your managed backend. So you might be thinking, "I don't need to worry about this now," but even though Microsoft manages the instances, we still need to be conscious of drift. For instance, which regions are your databases in? What about your failover policies? Are they similar for your environments? Are your network security groups configured the same for public endpoint access? These are some of the important questions that come up, even when you don't have to maintain the physical infrastructure, as you would with IaaS. In all cases, we need to compare resources against our reference date, and update as necessary. The issues with drift could cause challenges in deploying between environments, errors in product functionality, and difficulty in finding bugs. Oftentimes when I'm working with clients that have just started out in the cloud, they're deploying items manually. Now this might work initially, but you have to consider when scaling to hundreds or several thousand services. The overhead and cost of managing drift can become significant. A strategy will help us maintain our environments, and peace of mind.