• Development and test scenarios

    One of the common workloads in Azure is development and test (dev/test). In most cases, you can replicate all or part of your production infrastructure in Azure, whether it be on-premises or already running in Azure, and use the replica for development, staging, or testing.

    If you have an on-premises datacenter and you want to set up a dev/test environment, you have to procure hardware, install the operating system and the rest of the software, set up networking, configure the firewall, and so on. This can take a substantial amount of time. Once the testing is over, you have to either leave the hardware idle or repurpose it until you need it for other testing. With Azure, you can provision what you need (virtual machines [VMs], web apps, databases, storage, and so on) and proceed with the testing within minutes. When you are finished testing, you can tear down all of the services and stop paying for them. In fact, using Azure you can automate the deployment and teardown of your dev/test environment by using PowerShell, the command-line interface (CLI), and/or Azure Resource Manager (ARM) templates.

    Best of all, as your infrastructure grows, you can easily scale your dev/test environment to fit current needs. With an on-premises dev/test infrastructure, you have to go through the procurement and configuration process again.

    If everything you have is on-premises, you can still use Azure for dev/test. You can set up a virtual network and extend your on-premises network into Azure. For example, you might want to test your application against a new version of SQL Server; you can have a web application running in your local datacenter that accesses SQL Server hosted in Azure.

    If you have an MSDN subscription, you get a monthly credit to use for your dev/test infrastructure in Azure. In addition, several of the services are discounted. For example, Windows VMs are billed at the equivalent Linux rate (effectively removing the Windows license cost). This can significantly lower the overall cost of setting up and using a dev/test infrastructure.

    Here are some other business cases that you can cover by using Azure to quickly replicate the parts of your infrastructure.

     The flexibility of trying something small really fast Let’s say you only want to test one thing. For example, you want to change the way something is displayed in your website, but you’re not sure if it will work or how it will work. You can make the modifications to the website and then deploy it as a new website with the configuration pointing to the production backend. Then, you can check the workflow and visual layout and decide if it is worth setting up a complete dev/test environment to proceed.

     Load testing You can create an entire copy of your production environment and then do load testing on the copy. This can include different VMs, websites, storage, virtual networks, and so on. This gives you the isolation to do load testing without affecting any of the production services, and it can help you pinpoint potential bottlenecks in your workflow so you can handle them before they affect the customer.

    You can use load testing to figure out the scope of the resources you need to handle different loads, such as the size or number of VMs or App Service instances. You can then change these services to autoscale when needed. For example, you might discover that as the percentage of CPU utilization exceeds 60 percent, your website becomes unacceptably slow, so you decide to implement autoscaling to increase the instance count when the CPU utilization hits the target value. Load testing leads to a better overall experience for your customer.

     Software upgrades If you are using software from an external company, you will want to test your software with the company’s software for compatibility before upgrading your production services. For example, if you use SQL Server 2012, and SQL Server 2014 is released, you will want to test your application against the new version before upgrading. You might need to modify your software to work with the new version of SQL Server and go through the whole cycle of testing, staging, and implementation.

    In an on-premises environment, you probably can get a prerelease copy or a free short-term trial of the new version. However, you need to have infrastructure on which to run it, so as with the previous examples, you might need to procure hardware and so on. With Azure, the software might be available in a preconfigured VM, as is the case with Windows, SQL Server, Oracle, and Linux, among others. In that case, you can just provision a new VM with the new version in a dev/test scenario and run your software against it.

    If there is no preconfigured VM in the Azure Marketplace, you can provision a Windows or Linux VM, install the new version of software on it, and use that for your dev/test scenario.

     A/B testing Let’s say you want to perform A/B testing on your website without repeatedly redeploying the different versions of the website. Azure Web Apps allows multiple deployment slots. You can publish version A to one slot and version B to another and then swap them in and out of production as needed to perform the testing and metrics collection.

    Another option is to use the DNS query and routing policies available with Azure Traffic Manager. Traffic Manager gives you the ability to balance incoming traffic among multiple services using the following methods: performance, weighted, and priority. With the weighted method, you can distribute load to various endpoints based upon an assigned weight for each endpoint. This means you can divert a small percentage of traffic to a separate deployment to perform A/B testing.

    Source of Information : Microsoft Azure Essentials Fundamentals of Azure Second Edition


0 comments:

Leave a Reply