Avoiding Common Mistakes in Cloud Native Development
Technical debt in software makes you work harder to change or update an application or service. Often, the debt exists because the team responsible for the design and construction of the software took shortcuts to reach a deadline. In many cases the shortcuts are defensible. A product that reaches the market too late is just as much of a failure as a product that never reaches the market at all.
The cloud helps development teams move fast, but sometimes too fast. In this article, I want to give you actionable advice to help you avoid technical debt and shortcuts in your cloud-native applications and services. We’ll look at problems I’ve seen occur across different teams and organizations, and I’ll also give you some advice specific to Azure on how to mitigate the problems. We’ll start with the topic of governance.
Have a Governance Policy
When starting a project, development teams will typically take the default settings for a cloud service. Fortunately, the settings in Azure usually default to error on the side of safety. For example, App Services come with the HTTP/2 protocol disabled by default. The default allows services to reach a broader range of HTTP 1.1 clients, but might not be the best setting for performance. Likewise, up until last year, the default TLS protocol for an App Service was TLS 1.0. The default provided the widest range of compatibility, but is not the best setting for security (the default is now TLS 1.2).
Keeping track of the settings your organization requires, like enforcing transparent data encryption and requiring the latest TLS version, is tedious. However, you can use Azure Policy to enforce the rules in an automated fashion. By implementing policies you can also restrict the types and sizes of resources the team creates, as well as the locations they use to deploy the resources. See the official documentation for an overview of the Azure Policy service.
Coordinate Logging and Instrumentation
Azure makes it easy to develop in independent silos. For example, team A creates an environment for service A, including a dedicated instance of App Insights. Team B then creates an environment for application B, with its own App Insights. By the time you’ve rolled into production, you realize how difficult it is to track down errors, performance problems, and other anomalies.
Ideally, you’ll have a single resource you can use to monitor the health of a system, even if the team built the system as independent pieces. App Insights can do the job, but you need to let the separate teams know how to coordinate so they all send instrumentation in the single App Insights resource. See What is Application Insights for more info.
Monitor Resources for Efficient Usage
Another disadvantage to developing in silos is the possibility of underutilizing resources. If team A and team B both deploy to their own App Service plans, you might be using more of Azure’s virtual hardware than you need, which costs you more money than you need to spend. Ideally, your operations people will work across teams to ensure the system is using an optimum amount of resources. In addition to App Services, the team needs to look at big picture opportunities to save costs, by using SQL Elastic Pools instead of individual SQL Azure databases, for example.
Azure Monitor can provide the metrics you need to gauge resource utilization. Azure Monitor collects data from a wide variety of sources. You can aggregate the data and feed the data into alerts, dashboards, and reports, or export the data to use as you see fit. You can read more in the Azure Monitor overview.
Monitor Resources for Effective Usage
Sometimes the development teams will place resources into locations that don’t make the best use of those resources. For example, I’ve seen apps deployed into East US using databases deployed in the Central US. This happens for no specific reason other than the person setting up the resource is more focused on the overall deployment and misses small details like the resource location.
Azure Policy can help in this scenario, too, by making sure all the resources in a resource group are in the same location as the group (this is a built-in policy named “Audit resource location matches resource group location”). You can also create your own custom policies, and there is a GitHub repository dedicated to housing additional policy samples. Some audits you want to perform might exist outside the capabilities of Policy, in which case you can schedule your own PowerShell scripts to perform the audit.
It is easy to get caught up in the technology and speed of cloud-native development, so you need to help your teams use the cloud effectively, efficiently, and safely. Azure provides many tools to help, but you need to put them into play early enough to make a difference.