Technical debt, environmental drift, and other issues face devops teams as complexity of projects grow. We strive to understand the implications of these issues.
- [Instructor] Let's discuss some of the issues that arise as the complexity of environments grow. As we increase our footprint, there's an overhead that we need to contend with. Often during our software development life cycle, the team may choose short-term gain over a more robust solution. This is known as technical debt. A client team I was working with was trying to release a product on a tight schedule. We made the decision to complete the release with the current shortcut the team was using, rather than replacing it with a more robust, open-source package. They did this because it would take them time to learn the nuances. The team decided to take on technical debt and rework it in the future. There can be many reasons for taking on technical debt. For instance, businesses are often under extreme time constraints or pressure. The business may need to release a feature or product within a certain time limit, and not doing so would impact the bottom line. There may also be a lack of resources, documentation, or just leadership, or the team may be doing a poor job of refactoring. For instance, having development in parallel branches that needs to be combined. Taking on debt is in inevitable as teams grow. Martin Fowler's Quadrant on Technical Debt is a helpful tool here. It's divided into four quadrants. In the upper-left, we have reckless and deliberate. The team decides to make a less-optimal choice and sticks with it. In the upper-right quadrant, our team decides on short-term gain but plans to address it in the future. This is the quadrant we want to be in. In the lower-right quadrant, we have teams that may not have the knowledge when developing and are now aware, so they choose to address the issues. Finally, we have teams which are reckless and inadvertent. You don't want to be in this quadrant because the debt will have to be paid back in the future, and you have no plan to deal with it. Another area that adds complexity as solutions grow is configuration drift, which is where the environment being impacted by software or hardware changes from the reference state that we have defined. We see this in Cloud environments where updating the hardware can be done through the selection of a few menu. You can choose to change the RAM or CPU configuration with relative ease, which may be different from our production environment, causing issues. Software changes refer to items such as cumulative updates and patches, amongst others. Many of us have experienced this issue. Think of the number of times a developer has finished working on a sprint, and they're able to demo the new feature on their environment. If you ask them to put it into staging, you'll likely hear, "Well, I need to make a few changes to the environment "before it can be deployed," and this creates drift. State drift becomes a real concern once we move to a DevOps paradigm as we need to be able to continuously deploy and test changes.
- Developing an infrastructure strategy
- Managing technical debt
- Managing Amazon Kubernetes Service (AKS)
- Deploying applications on AKS
- Scaling your Kubernetes clusters
- Implementing infrastructure as code
- Deploying Azure resources via Terraform
- Implementing security and compliance