Chapter 7: Application Performance and Cloud Cost

After dealing with the most common cost-saving techniques in the infrastructural part of this book, in this chapter, we will discuss how a well-designed and high-performing modern application can play an important role in optimizing your cloud spending.

We will also look at why any investment in performance optimization strategies, such as database tuning and refactoring, can easily and quickly be repaid by the monthly savings, and how a strong motivator for modernization can be financial, on top of the usual technical reasons such as architecture, software updates, and so on. An application that is not fit for the cloud may bring unnecessary costs, and we will learn what the main optimization focus items are by looking at practical examples about how this approach can bring consistent down-sizing to the starting infrastructure.

In this chapter, we will cover the following topics:

• Optimizing your database for costs
...

Technical requirements

For this chapter, you'll need the following:

• A computer with internet connectivity
• Access to the Azure portal
• Privileges to access Cost Management information (see https://docs.microsoft.com/en-us/azure/cost-management-billing/costs/assign-access-acm-data)

Optimizing your database for costs

We often see that customers migrate to cloud applications that rely on old databases. Sometimes, even cloud-native applications are developed using old patterns for data handling, mostly because companies have a history that needs to be retained and cannot be wiped out by a new database or application.

But an old and stratified database has its drawbacks: queries are slow and resource-intensive, so typically, the reaction is to add more resources and scale vertically, which is not what this section is about. You need to consider optimizing your database so that your application is leaner and faster, but mostly so that you will save money by downgrading the infrastructure. Database performance is commonly correlated to the following infrastructural parameters:

• Read/write input/output operations per second (IOPS)
• Disk throughput
• Disk latency
• CPU and RAM
• Queue depth

This is true not only when you are dealing with IaaS...

Application performance optimization

Having fully optimized your databases against your infrastructure is, unfortunately, sometimes not enough. If your application is running in Azure, it probably came from one of the most common migration patterns:

• Lift and shift: You took the application and moved it to cloud resources without changing anything. This is typically the most expensive pattern infrastructure-wise as matching on-premises resources within the cloud is a time-consuming and often useless activity in terms of modernization, since you will often just move your legacy app somewhere else.
• Refactor: You made small changes in the code and probably took advantage of a few PaaS products and now have a mix of old and new cloud objects, as well as a roadmap to something more modern.
• Rearchitect: Chances are you cannibalized the original application toward a microservices solution, which is much better than the preceding two patterns, but even if this dramatically reduces...

Practical examples

So far, we have analyzed the most common saving techniques, such as cleanup, right-sizing, and reservations, and have also considered and maybe already planned an application optimization continuous process. In this section, we'll bring everything together with some real-life examples that will show you how everything will come together in a beautiful dance once you've trained each dancer individually.

Storage throughput versus network bandwidth

Previously, we learned that every VM family has different capabilities and performance, so we have VMs with wider storage bandwidth and VMs with wider network bandwidth, with different costs. In addition, please always keep in mind that the network traffic inside a VNet is not billed.

Let's consider your first application: it's a one-database architecture, where it is unlikely that you can save costs by reducing nodes as they are already at a minimum. Decoupling the database storage to another...

Summary

In this chapter, once we had covered every possible cost-saving implementation in terms of the infrastructure, we started analyzing our application catalog to understand how and why optimizing at the application level is sometimes the only way of bringing extra cost saving to your process.

We started with database tuning and optimization by providing an optimization plan template. Then, we looked at what technical debt is and how to understand, analyze, represent, and reduce it so that your application set is continuously enhanced and improved by keeping costs down. We discussed the importance of an APM tool, such as Azure Application Insights, not only to manage your application at a technical level but also to spot issues that may incur unexpected costs.

We then worked on a few practical examples, starting with an application where we moved the database to NAS (first IaaS, then PaaS), then migrated the database to PaaS, to increase efficiency and cost-effectiveness...

Questions

1. What are the limitations of infrastructure-only optimization, and why do you need to work with the app and dev team for any application optimization?
2. Why can database tuning be important for cost-saving?
3. What is technical debt?
4. Why is Application Insights a key element of application optimization?

Further reading

• Azure Application Insights: https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview
• Azure application architecture fundamentals: https://docs.microsoft.com/en-us/azure/architecture/guide/
• Benefits of using Azure NetApp Files with Oracle Database: https://docs.microsoft.com/en-us/azure/azure-netapp-files/solutions-benefits-azure-netapp-files-oracle-database
• Strangler Fig Pattern: https://martinfowler.com/bliki/StranglerFigApplication.html