Develop your skills for autoscaling on Azure with this course from Cloud Academy. Learn how to improve your teams and development skills and understand how they relate to scalable solutions. What's more, in this course you can analyze and execute how to deal with transient faults.
This Course is made up of 19 lectures that will guide you through the process from beginning to end.
To discover more Azure Courses visit our content training library.
- Learn how to develop applications for autoscale
- Prepare for the Azure AZ-303 certification
- Design and Implement code that addresses singleton application instances
This course is recommended for:
- IT Professionals preparing for Azure certification
- IT Professionals that need to develop applications that can autoscale
There are no prior requirements necessary in order to do this training course, although an understanding of MS Azure will prove helpful
When developing for autoscale, it's important to fully test your retry strategy implementation. This is especially true when both the application and target resources are under heavy load. To check the behavior of your strategy during testing, you should purposefully inject transient faults and non-transient faults into your service. An example of this would be to send invalid requests or to add code that detects test requests and then responds with different types of errors. You can also create a test resource or test service that returns a range of typical errors that a real service might return. Be sure to cover all types of errors that your proposed retry strategy is designed to address. Another way to fully test your retry strategy is to force transient errors by temporarily disabling the service or overloading the service that you've deployed. It's important to perform high load factor tests and concurrent tests to ensure that your chosen retry mechanism and overall retry strategy works as expected under such conditions and it doesn't have an adverse affect on the overall operation of the client.
A retry policy is actually a combination of all pieces of your overall retry strategy. The policy defines the fault detection process that's used to determine if a fall is likely to be transient as well as the type of interval to use. The retry policy also defines the actual interval values as well as the number of times to retry. When implementing retries they must be implemented in multiple places even when developing the simplest application. In more complex applications retries musts be implemented in every layer of the application. However, instead of hard coating elements of each policy at several locations you should consider storing all policies at a central point. For example, you could store values like the interval and retry counts in an applications configuration files. You could then read them from there at run time, programmatically building retry policies. Storing policies in the central point makes it easier to manage those settings. It also becomes easier to modify and tune those values when you need to respond to changing requirements. Even better, you should design the system so that it stores the values instead of rereading a configuration file every time those values are needed. Just make sure that suitable defaults are used if the required values can't be obtained from the configuration. When developing an Azure Cloud Services application you should consider storing any values that are used to build retry policies at run time in the service configuration file. By doing so, you can ensure that they can be changed without the need to restart the application when the time comes.
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.