Don’t make these 5 Azure developer mistakes
By Alex Bennett, Firebrand Training
Alex works for Firebrand Training, a Microsoft Gold Learning Partner. He has worked in the IT training and certification industry for the past 4 years. He writes regularly about Windows Server, Microsoft Azure and IT security.
‘The cloud is very unforgiving. It will remind you of every mistake you make,’ states Mark Russinovich, Microsoft Technical Lead.
Mistakes are inevitable when developing for the cloud because it’s a ‘world where you test in production.’
Nobody is immune, not even Microsoft. At Build 2014, they discussed learning from mistakes when developing with Azure - like accidentally flooding the entire audit logging system with one extra comma.
To help minimise - and learn - from mistakes, developers who use Azure should make full use of the platform’s features and best practices.
1. Not setting up your apps for Autoscaling
You can’t always predict how often, or for how long, your applications will be used. To keep them running smoothly during high-load situations, Azure developers must set up Autoscaling.
Autoscaling dynamically allocates resources required by an application to match performance requirements and minimise runtime costs. This feature makes use of the elasticity of cloud-hosted environments, without the need for an operator to continually monitor performance.
Developers can use Azure Autoscale, a custom solution, or a third-party service to meet their needs. It’s recommended to use the built-in Autoscaling features if they meet your requirements. Complex scaling features can take time to implement and could potentially be unnecessary if the built-in feature fulfils your needs.
However, this isn’t an instant solution. There are a number of app design considerations when implementing Autoscaling.
For example, developers must design their solutions to be horizontally scalable. If you want to make full use of Autoscaling, do not design solutions that require your code to always be running in a specific instance.
If you do need the capacity to process all requests with highly fluctuating volume, and cost isn’t an issue, setup an aggressive Autoscaling policy that starts additional instances quickly.
Alternatively, when anticipating a high load, use a scheduled policy that starts a sufficient number of instances to meet the maximum load before it’s expected.
For more information on how to setup and make the most of Autoscaling, take a look at the documentation.
Autoscale conceptual diagram
2. Leaving security to someone else
‘On average there are now 777 cloud apps in-use in European organisations, but 94.4% of these apps are not enterprise-ready from a security standpoint,’ says Eduard Meelhuysen, VP at cloud security firm Netskope.
A consistent cause of software vulnerabilities are software defects and bugs written into program logic. These flaws can be accidentally built into any application hosted on Microsoft Azure.
Azure developers are expected to create apps and websites for public use, but the lack of thought often given to security in these applications is a weakness that can be exploited by cyber criminals.
Microsoft takes every possible step to keep the platform secure. However, it’s an individual’s or enterprise’s responsibility to ensure security at an Azure component level.
Finding security issues and fixing them during production can be hugely costly and time-consuming, so it’s well worth employing security best practices for your application early in your development cycle. These include:
- Ensuring web applications enforce HTTPS
- Conducting regular logging and traffic monitoring
- Disabling remote debugging immediately after troubleshooting
- Staging regular penetration tests on your apps
In addition, Azure was enhanced with a Security Center last year, designed to show the overall security of your Azure estate at a glance.
3. Neglecting Azure Key Vault
Data breaches are now more widespread than ever and result in an average revenue loss of 20%, according to research from Cisco.
Secure key management is essential to protecting data in the cloud, and encryption is by far the best way to do this.
Azure Key Vault can be used to create a hardened container in Azure to store and manage cryptographic keys and secrets, used by your cloud applications and services.
Use Key Vault and you’ll be able to encrypt keys and secrets, like authentication keys, storage account keys, data encryption keys, .PFX files, and passwords. These are protected by hardware security modules (HSMs).
Key Vault streamlines the key management process and allows you to maintain control of keys that access and encrypt your data.
Developers can also create keys for development and testing quickly and then seamlessly migrate them to production keys.
To get started with Azure Key Vault, developers should take a look at this 20 minute tutorial from Microsoft.
4. Not following the high availability checklist
One of the greatest benefits of Azure is the ability to dynamically control the availability and scalability of your cloud applications.
A highly available application reacts to changes in availability, load, and temporary failures in services and hardware. With high availability properly configured, your application will continue to operate at an acceptable level, as defined by requirements - like the application service-level agreement.
Azure has many built-in platform features that support highly available applications, but some developers aren’t taking full advantage of them. Here are some ‘quick-fixes’ that developers can implement right now.
Use Traffic Manager to increase your application’s resiliency by distributing traffic to multiple Azure regions.
If you’re not using this service in front of your application, you’re limited to a single region for resources. This obviously limits your scale and can increase latency to users that are outside of your chosen region. You’ll also lower your protection in the case of a region-wide service disruption.
Using Active Geo-Replication with your SQL databases enables you to use up to four secondary databases across multiple regions. Secondary databases can be used in the event of a service disruption, or any inability to connect to your primary database.
Without geo-replication, if planned maintenance knocks your database offline, you’re application will be unavailable until you can bring it back online. With geo-replication, your users should not even notice that your primary database has fallen over.
Using a Content Delivery Network (CDN) takes load off your servers by caching content in CDN locations around the world. This will help decrease latency and increase availability, and can also form part of your protection from denial of service (DoS) attacks.
For more quick fixes to improve the availability of your cloud apps, take a look at Microsoft’s High Availability checklist.
5. Not using logging or diagnostics
‘We run into the same issues again and again with logging," says Mark Russinovich. ‘Log as if nobody was looking…you never know when that extra piece of info you put in there can shave hours off a debugging session.’
Luckily, Azure Web Apps has built-in diagnostics to help you with debugging your App Service web app. App Service web apps provide the ability to log information from both the web server and web application. These are separated into:
- Web server diagnostics provides detailed error logging, failed request tracing and web server logging
- Application diagnostics allows you to capture information produced by a web application.
Diagnostics can be enabled in the Azure portal, by navigating to Settings > Diagnostic Logs.
Diagnostic settings in the Azure Portal
Find out how to use diagnostic logging for Windows Azure websites here.
With more updates coming for Azure, including enhancements to Security Center, there’s tonnes for developers to learn this year. For an early preview of Azure updates, join the Azure Advisors community and Azure Security Center Advisors group.