LEVERAGING THE MICROSOFT PLATFORM FOR DEVOPS

 
 
WHAT IS DEVOPS?


DevOps is the collaboration of one or more individuals on a project to optimize:

1. ENVIRONMENT PROVISIONING
2. ENVIRONMENT CONFIGURATION
3. APPLICATION BUILD(S)
4. APPLICATION DEPLOYMENT(S)

DevOps is about improving how software is built, delivered, and operated by enabling IT departments to reduce cycle times, optimize the use of IT resources, and improve quality and availability. It is about increasing the scope of agility, and it should be viewed as a team undertaking. It requires teams to look at their full life cycle investments.

At its core, DevOps enables better software development and accelerates the last mile of delivery by focusing on:

1. Shortening of cycle times


DevOps practices enable organizations to shorten cycle times and increase the traceability and auditability of each release by improving transparency and collaboration between development and operations teams, and by eliminating waste in current manual processes through automation.

2. Optimization of resources


DevOps practices enable organizations to efficiently manage environments in a way that supports self-service of environment provisioning/de-provisioning, controls costs, and uses the provisioned resources effectively while minimizing security risks.

3. Improving quality and availability


DevOps practices help to identify defects early in the development cycle, identify the root cause of issues, and quickly test and deploy fixes. DevOps also helps organizations capture rich telemetry on app performance and usage so teams can learn from the behavior of users to drive future priorities and investments.

 

Leveraging the Microsoft Platform for DevOps / 3

WHY DEVOPS?


Successful organizations understand that competitive advantage is fleeting, and to continuously innovate in an era of digitized operations, they are required to write their own software.

It is important to view the development of custom applications not as a craft that happens independent of the business, but as a strategic process that generates value. This leads organizations to see development from the perspective of a value chain where value does not materialize when outputs are delivered through requirements implementation, but when outcomes are realized through the right requirements being implemented, tested, and deployed into production. More value delivered faster is, of course, better – hence the focus on throughput/flow.

Focusing on organizational aspects such as people, processes, and tools will help improve the flow of value and eliminate waste. Ultimately, successful organizations achieve the following processes and goals with DevOps:

1. ADAPT AND LEARN


Requirements are refined through a quick succession of feedback loops. More conservative organizations do this through process patterns, such as specification by example, where the business, developers, and testers collaborate closely on refining the specification and continuously verifying (testing) that the implementation is loyal to it. These specifications by example include behavior-driven development, acceptance testing development, or simply agile testing. This is all relevant in the context of improving quality. More mature organizations will perform these checks directly in production, by observing user reaction to features. Adapt and learn is also known as hypothesis-driven development or build-measure-learn. 2. SHORTEN TOTAL CYCLE TIME Successfully adapting and learning leads to a shortened total cycle time. Knowledge – no matter how formal the requirements and specification definition process – is mostly tacit. For learning to take place in a meaningful way, feedback loops are better when shorter. Shorter cycle time is also directly related to quality. Shorter cycles impose smaller batches of work, which in turn (as researched and documented by queuing theory) also has a positive, non-linear effect on quality. Quality in this context is defined as structural and functional – valuable software is more likely to manifest when executed in short cycles rather than in long phases.

3. ELIMINATE WASTE Short cycle times demand the removal of wasteful activities. Spending days promoting code to the acceptance testing environment is not conducive to rapid feedback loops and shortened lead time to value. Optimized use of resources (e.g., environment provisioning) is a common attribute in successful and high-performing organizations.

4. COLLABORATE Successful organizations work better together by building camaraderie and stronger working relationships. Collaboration is created through adapt and learn, and it contributes to shortening the time cycle and eliminating waste.

5. REDUCE RISK For shortened cycle times to be sustainable, safety is necessary. Availability and resilience (or better, anti-fragility) need to be key attributes of the product and the process. Monitoring and diagnostic tools are typically involved with this. More mature organizations will purposely inject faults into their production environment to practice detection, diagnosis, and remediation processes. Practice makes perfect.




 

LEVELS OF DEVOPS MATURITY




PATH TO MATURITY


As mentioned, DevOps is the collaboration of one or more individuals on a project to optimize:

1. Environment provisioning
2. Environment configuration
3. Application build(s)
4. Application deployment(s)

Most teams that evolve DevOps over time do so in a very predictable manner. Each of the four steps listed above is likely to be repeated many times over, but at different rates. For example, building an application happens much more frequently than the other actions, so therefore it’s logical to automate it first. The typical order in which things are automated is as follows:

1. Application build(s)
2. Application deployment(s)
3. Environment configuration
4. Environment provisioning

LEVEL 0 - ARCHAIC


The most basic level, and therefore the least mature, is for these steps to be performed manually. The following is an example of the most basic level of DevOps.

A team has built an application and it needs to be deployed to a new environment. A server administrator manually provisions the servers needed for the new environment. Once that has been completed, he will configure the servers. A developer will build the application (and possibly package it up). The developer will then deploy the application, including databases, services, and whatever else is needed. Once all of this is done, one or more people will verify the application has been deployed correctly.

If this was going to be a one-time process, there would be nothing wrong with this approach. But when was the last time a single environment was set up for an application that was deployed only once and never deployed again?

LEVEL 1 - TRADITIONAL


To fully realize a Level 1 maturity, the automated build system should have the following characteristics:

1. Run on a non-developer machine (preferably a server)
2. Build on a trigger (i.e., check in), schedule, or both
3. Execute unit tests
4. Fail builds for multiple reasons (not just a compiler error)
5. Notify team of failed builds
6. Ability to block check-ins under certain conditions
7. Package the application to simplify the deployment process

Leveraging the above ensures if source code is checked in that does not compile, the team is notified sooner rather than later so that the issue can be resolved (preferably by the person who checked in the breaking change). It also ensures that even if the code does compile, that the team is notified if the updated source code causes a unit test to fail. When automated builds are configured to run on a trigger or a frequent schedule, it is often referred to as continuous integration (CI) or continuous build (CB).4 / Leveraging the Microsoft Platform for DevOps

 

LEVEL 2 - MAINSTREAM


Manual deployments are rife with human error. Files could be copied to the wrong directory, or even worse, to the directory of a different environment. Database scripts may not be executed in the correct order. Services may be shut down for deployments and not restarted when the deployment is done. The list goes on and on.

Automating deployments is usually the next area where a DevOps team matures. The team has seen the benefits of automated builds and realizes that there will be many benefits to automated deployments, including:

1. All steps are performed, and in the correct order, every time
2. Long-term time savings (which translates into cost savings)
3. Once configured, no special knowledge of the system is needed in order to perform the deployment

Not only are manual deployments fraught with human error, but they are also very time consuming. Depending on the complexity of the system, automating a deployment can be an investment, but it is an investment that will be paid back many times over the course of the project.

Configuring automated deployments to run on a trigger or a frequent schedule is often referred to as continuous deployment (CD). There are at least two major benefits of CD:

1. Developers can test functionality on a remote environment (there are many reasons why code may work locally, but not in other environments).
2. Non-developers can get a look at recent changes without having to look over the developer’s shoulder.

In addition, this phase is usually where teams introduce Infrastructure-as-Code.

LEVEL 3 - MODERN


This level of maturity introduces the concept of immutable continuous delivery. This means you can blow away any environment, at any time. Your automated deployments will use containers, Infrastructure-as-Code, or some combination of both to ensure the proper provisioning and configuration of the environment.

Depending on the needs of the project, many teams will not mature past Level 2. There may not be a need for it. If there are a small, finite, number of environments, there may not be an advantage to going any further. But, if there will be N number of environments, then automating the build-up and tear-down of environments becomes appealing. Common reasons for this are:

1. The application is installed on premises for each production installation
2. The development team may have a need for a new environment for each feature branch
3. The testing team may have a need to bring up and tear down their own environments

Whatever the reason, if there will be several environments then automating the configuration of the environment will be a major time saver. Activities that may need to be automated include:

1. Installing/configuring software/services needed by the application
2. These are typically items that only need to be done once every per environment (e.g. installing IIS)
3. Initial creation of application assets, like databases
4. Network configurations, like DNS entries

Leveraging the Microsoft Platform for DevOps / 5

LEVEL 4 - BLEEDING EDGE


The final level in automation is using microservices to further increase the deployment capabilities of your immutable environments. The line between Level 3 and Level 4 are easily blurred. However, Level 4 generally refers to teams doing hundreds or even thousands of deployments to production per day.

Very few companies will achieve this level of automation. In fact, this level of automation is not necessary for most. These features require a considerable amount of effort to set up, process, and implement. Only applications that require hyper-deployment to production should be considered as candidates. This is often only the case with very large commercial, customer-facing applications.

  

 

BEST PRACTICES

The set of DevOps best practices continues to evolve and grow. Here are some of the best practices we have established over many client engagements.

1. Automate your build process
2. Automate your deployment process
3. Execute builds via trigger or a frequent schedule (at least once per hour)
4. Execute unit tests during builds and fail if any of the tests fail
5. Support multiple environments
– Number of environments depends on the needs of the application
– Development
– Test/QA
– Stage
– Production
6. Only deploy a build if it has already been deployed to a lower environment (for example, a build should not be deployed to test without being deployed to development first)
7. Builds beyond the initial development environment should be packaged, and that same package should be used to deploy to the higher environments
– Do not rebuild the package for each environment
– Per-environment configurations are expected to bemade as the packages are deployed
8. Ensure your team is both autonomous and aligns with your enterprise
9. Implement usage monitoring, telemetry collection, and gain feedback from stakeholders to integrate and refine back into your product backlog
10. Manage your technical debt
11. Conduct code reviews
12. Document your code
13. Use enterprise package management
14. Have a production-first mindset
15. Develop infrastructure-as-code practices
16. Use the cloud to your benefit (testing in production, cloud test, automatic scaling, enterprise dev/test labs, containers, microservices)

 

ENVIRONMENT GUIDELINES

A common question asked is, "How do I set up my environments, and how many do I need?" The old paradigm was Dev > Int > Test/QA > Stage > Prod. There were often five separate environments. Over the years, Dev has gradually fallen to local machines and away from full server farms.

Four server farms are still common: Dev/Int > Test/QA > Stage > Prod. Some organizations have a hard time letting go of old principles. When frameworks were different, there were often complex integrations that needed to be tested in a dev capacity working together before they could move to the Test/QA environment. With today’s frameworks, that’s not the case.

Read the diagram below starting at the bottom left. When developing web applications for the cloud, it’s easy to have a local dev machine or virtual machine (VM) on your computer. Azure Enterprise Dev/Test Labs offer attractive features for those multiple-server dev instance requirements. Create templates and use quotas for automatic shutdowns.

When the developer commits changes to the source system, the automation begins across the gray arrow. The Build Agent in Visual Studio Team Services executes the build script tasks and runs the automated unit tests. Upon successful completion of the tests, the package is deployed to the Test/QA system.

At this point, the Test/QA environment is the first real environment needed. You will have a single Azure App Service instance and any storage, DB, or other services. You can then do human testing, quality assurance, and UAT in this environment. We recommend using Azure Resource Groups to segment Test/QA from Prod. This separation provides security and role-based access permissions.

When testing is complete, you want to deploy to Stage. In the Azure cloud, this is called a Deployment Slot. Azure App Service provides up to five deployment slots per deployed web app. You can deploy any number of different versions of code to these slots. The slots are swappable at any time. They stay "warm" and can literally be changed over in seconds.

But the real power is with a feature called Testing In Production. This feature enables you to set a percentage of traffic to direct to Stage. You could direct, for instance, 5% of your traffic to the Stage slot, run your final verifications, then once you’re completely satisfied, swap the entire Stage slot to Production (and reduce the TIP percentage back to zero). Of course, if there is a problem at any point in this process, you have your live production slot that you can you can revert back to.

CLOUD SOLUTIONS Leveraging the Microsoft Platform for DevOps / 7

These features are extremely powerful and enable you to:

1. Reduce the number of environments – only two are needed in this model
2. Automate build, integration, and testing tasks
3. Implement more robust testing processes
4. Better control versioning releases and package management

The flow of the on-premises solutions is very much the same as the cloud. The main differences are:

1. On-premises Dev environments cannot use Azure Dev/Test Labs. This may require an additional server environment for developers.
2. Deployment slots are not available. This means a separate Stage environment is required.

As you can see, that’s three environments minimum, and in some cases four, for an on-premises solution, which will also result in a cost difference. We highly recommend a cloud solution.

Please note that these are only recommendations. They do not represent every situation for every organization. There will always be exceptions.

INFRASTRUCTURE-AS-CODE Azure Resource Manager (ARM) Templates provide capabilities called Infrastructure-as-Code. This means using code files to deploy resources to Azure. This can be almost any type of Azure Resource: Virtual Machine, Azure SQL instance, Storage Account, Search Service, Redis Cache, Traffic Manager, etc.


ARM Templates, which are JSON, are an extremely valuable component of the DevOps journey. They allow you to build and configure your cloud infrastructure in a repeatable fashion. You can build the Dev environment, then copy/paste to start the QA environment, then to the production environment, and so on. This allows us to have different ARM Template versions to test unique environment configurations. They also enable rapid environment deployment for disaster recovery or system restore scenarios.

ARM Templates reduce the burden of provisioning and configuration of Azure resources on IT staff. Developers can now manage their own environment configurations completely within their own world – in code. Governance can (and should) be applied using ARM Templates. Be sure to include them as part of your managed code projects in TFS/VSTS.

Creating ARM Templates is simple. Microsoft provides a gallery of sample templates. Often, it is easiest to start from a sample and customize from there. Another option is to build out an environment in Azure manually and have Azure generate the ARM template to use as a starting point. Starting from a blank template is also an option. Visual Studio provides a robust JSON editor to work with the template. Once finished, deployment is easy with Azure PowerShell or the CLI.

SOURCE CONTROL

The first step in automating a release pipeline is effective source control management. We use both TFSVC and Git. Your source code is always the first input into the pipeline (see diagrams above). The build agents then compile that code into artifacts that are used by the rest of the process.

ON-PREMISES SOLUTIONS8 / Leveraging the Microsoft Platform for DevOps

 

Most developers have built some application at some point in their career without source control. You store the files locally on your hard drive. When you build your code, it creates the appropriate files in the file system on your computer. You then copy and paste those files onto a web server. Remember how much time it took to manage that process? Source control is the first fundamental step in automating your DevOps pipeline.

Using VSTS for source control is very easy. Microsoft is now the largest contributor to Git and have more published Git repositories than anyone else. We have been using Git for more than two years. Here’s a sample of the flow we recommend:

CONTINUOUS BUILD/INTEGRATION

Continuous build (CB), or synonymously, continuous integration (CI), is a core DevOps practice that we recommend. It can be defined as the process by which code is compiled every time it is checked-in or committed. Rather than a developer initiating manual builds, the system does it automatically. The goal is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible.

CI solves issues that many teams wrestle with on a daily basis, such as: delivery delays, non-working/low quality code, incomplete solutions, and rework. Each of these issues introduces cost, both in terms of resources to fix the issue and in time. Time-to-market is often a key business driver that enables highly effective teams. CI also helps increase quality. You know the latest build will work, which helps reduce stress and uncertainty in your teams.

Visual Studio Team Services (VSTS/TFS) has a rich feature set for implementing CI. It provides hosted build agents to start building your projects immediately, as well as a flexible build system that allows you to install your own agents. There are agents for Windows, OS X, and Linux. The out-of-the-box options cover your most commonly used tasks: Android, iOS, Maven, Jenkins, Gulp, Grunt, Gradle, and more.

The first step in a CI implementation is creating the build definition(s). Each application will likely only need one or two build definitions. It is common to have a non-optimized build. This can include compiled code, with debug information to help aid in troubleshooting, as well as un-minified resources (e.g. JavaScript and CSS files). This build typically results in a direct deployment to the development environment.

The second build definition is commonly used to produce a deployment package optimized for production. This can include compiled code (with optimizations), as well as JavaScript and CSS resources that have been bundled and minified to provide the end-user with a better browsing experience. This build does not result in a deployment being performed, but rather the creation of a package which includes all of the assets of the build needed for a deployment and makes those assets available to be deployed by another process.Leveraging the Microsoft Platform for DevOps / 9




PERFICIENT


The next step is to add your various build steps and configure each one. This could be a NuGet restore, Azure PowerShell script, MSBuild, or a Visual Studio Test (see below). Once all the tasks are configured and ordered, you will configure the rest of the build options for repositories, variables, triggers, and retention.

Once your definitions are built, you can manage access to your builds by defining groups and granting permissions for viewing, editing, creating, and queuing builds. You can also manage and share build resources across projects. In addition, you can control access to build resources (pools and queues) and audit changes to your builds.

Finally, the VSTS CI tools provide diagnostics, automated alerts, historical changes, and output logs to troubleshoot issues and audit the changes of your build definitions over time. This enterprise-ready toolset is essential to any DevOps solution.

CONTINUOUS TEST

Continuous test is exactly as it sounds: each time code is compiled, the system will run automated unit tests. This is an important step in the DevOps process. It enables you to find problems in code earlier and review the results immediately to begin resolving any errors. Microsoft supports a number of testing platforms and frameworks: NUnit, XUnit, Selenium, Java, Maven, Node.JS, Gradle, and MSTest. These tools work for applications hosted both in the cloud and on-premises.

Continuous test is quite easy to get started and set up. First, check-in your solution – including your test projects – to Visual Studio Team Services. Next, create a build definition that includes a task for Visual Studio Test. Once configured, tests will execute every time a build is initiated. You can go to the Tests tab to see the results summary. Test results between the current build and the last one can also be compared. Here you’ll find changes in new, failed, and passed tests, how long these tests took to run, how long these tests have been failing, and more. You can organize the test results and open bugs directly for failed tests.

Microsoft provides a number of testing tools and services that include performance testing, exploratory testing, load testing, acceptance testing, and automation testing. You might not enable all of these continuously in a DevOps scenario. In fact, you are usually only going to automate unit tests. However, it is important to know that each of these exists as part of the testing capabilities in the Visual Studio platform.

CONTINUOUS DEPLOYMENT

Continuous deployment (CD) happens after a continuous integration (CI) has successfully executed (i.e., no build errors and no failed tests). CI and CD typically happen within the same process. CD is not right for everyone or every project.

CD relies heavily on automation of all tasks and steps in a delivery pipeline. The initial tasks of setting up the automation can be daunting, but it will save a lot of headaches and effort going forward. It is highly recommended that developers not consider their task(s) to be complete until they have verified the functionality in another environment (i.e., not their local environment). There are any number of reasons why the source code will execute as expected locally, but fail to execute as expected in another environment. Requiring the team to validate in another environment ensures that all resources needed are persisted in source control and that nothing has been hard-coded to a local machine.10 / Leveraging the Microsoft Platform for DevOps

 

The environment used for CD should be considered unstable. It is not recommended that anyone outside of the development team use this environment. There are two primary reasons for this. First, a build can be triggered at any time, and the behavior of the environment can be unpredictable at that time. Second, even if a build successfully compiles and passes all tests, there still exists a possibility that it has a major issue and the site could be unusable until a fix is committed to source control.

PACKAGING AND RELEASE MANAGEMENT

Many software projects today rely on package managers (i.e. NuGet, npm) to successfully build. Others rely on packages as an output of the build or release process to share components across teams or make available as an open source component. Visual Studio Team Services provides a great set of features for effectively managing these packages.

1. Privately hosted packages – NuGet is the first supported package type, but the service is built to support any programming language or platform, and can contain artifacts from your own build server, NuGet.org, npmjs.com, GitHub, and more
2. Consistent access to components needed by your build
3. Enterprise authentication to manage permissions on who is allowed access to those components
4. Seamless integration with build and release management tools
5. A friction-free way to bring in an open source component to your enterprise
6. Discovery and search of packages across the enterprise

Leveraging the Microsoft Platform for DevOps / 11




Release management helps you automate the deployment and testing of your software in multiple environments. You can either fully automate the delivery of your software all the way to production, or set up semi-automated processes with approvals and on-demand deployments.

Release management runs the following steps as part of every deployment:

1. Pre-deployment approval: When a new deployment request is triggered, release management checks whether a pre-deployment approval is required before deploying a release to an environment. If it is required, it sends out email notifications to the appropriate approvers.
2. Queue deployment job: Release management schedules the deployment job on an available automation agent. An agent is a piece of software that is capable of running tasks in the deployment.
3. Agent selection: An automation agent picks up the job. The agents for release management are exactly the same as those that run your builds in Team Services and Team Foundation Server. A release definition can contain settings to select an appropriate agent at runtime.
4. Download artifacts: The agent downloads all the artifacts specified in that release, provided you have not opted to skip the download. The agent currently understands two types of artifacts: Team Build artifacts and Jenkins artifacts.
5. Run the deployment tasks: The agent then runs all the tasks in the deployment job to deploy the app to the target servers for an environment.
6. Generate progress logs: The agent creates detailed logs for each step while running the deployment, and pushes these logs back to Team Services or Team Foundation Server.
7. Post-deployment approval: When deployment to an environment is complete, release management checks to see if there is a post-deployment approval required for that environment. If no approval is required, or upon completion of a required approval, release management proceeds to trigger deployment to the next environment.

12 / Leveraging the Microsoft Platform for DevOps





   



 

azure IT Operators

 Summary
  The purpose of this document is to provide information that will help quickly get started using Azure services. The target audience is those in an IT operator role.
© 2016 Microsoft. All rights reserved. This document is for informational purposes only. Microsoft makes no warranties, express or implied, with respect to the information presented here.
Contents
 Introduction to cloud computing and Microsoft Azure ............................................................................. 3

Cloud computing overview .................................................................................................................. 3

Types of cloud computing .................................................................................................................... 4

SaaS: Software as a service .............................................................................................................. 4

PaaS: Platform as a service............................................................................................................... 4

IaaS: Infrastructure as a service........................................................................................................ 4

Azure services...................................................................................................................................... 5

Compute services ............................................................................................................................ 5

Data services ................................................................................................................................... 5

Application services ......................................................................................................................... 5

Network services ............................................................................................................................. 5

Azure key concepts.................................................................................................................................. 6

Datacenters and regions ...................................................................................................................... 6

Azure portal......................................................................................................................................... 6

Resources ............................................................................................................................................ 6

Resource groups .................................................................................................................................. 6

Resource Manager templates .............................................................................................................. 6

Automation ......................................................................................................................................... 7

Azure PowerShell ............................................................................................................................. 7

Azure command-line interface ......................................................................................................... 7

REST APIs ......................................................................................................................................... 7

Getting started with Azure subscriptions ................................................................................................. 8

Select and enable an Azure subscription .............................................................................................. 8

Grant administrative access to an Azure subscription .......................................................................... 9

View billing information in the Azure portal ......................................................................................... 9

Get billing information from billing APIs............................................................................................... 9

Forecast cost with the pricing calculator .............................................................................................. 9

Set up billing alerts .............................................................................................................................. 9

Azure Resource Manager....................................................................................................................... 10

Tips for creating resource groups....................................................................................................... 10

Building Resource Manager templates ............................................................................................... 11

Security of Azure resources (RBAC) .................................................................................................... 12

Azure Virtual Machines.......................................................................................................................... 13

Use cases ........................................................................................................................................... 13

Deployment of virtual machines ........................................................................................................ 13

Portal ............................................................................................................................................. 13

PowerShell..................................................................................................................................... 14

Command-line interface ................................................................................................................ 14

Access and security for virtual machines ............................................................................................ 14

Azure Storage ........................................................................................................................................ 15

Use cases ........................................................................................................................................... 16

Blob storage .................................................................................................................................. 16

File storage .................................................................................................................................... 16

Table storage ................................................................................................................................. 17

Queue storage ............................................................................................................................... 17

Deploying a storage account .............................................................................................................. 17

Portal ............................................................................................................................................. 17

PowerShell..................................................................................................................................... 17

Command-line interface ................................................................................................................ 18

Access and security for Azure Storage................................................................................................ 19

Virtual machine disks ..................................................................................................................... 19

Storage tools ................................................................................................................................. 19

Storage API .................................................................................................................................... 19

Storage access keys........................................................................................................................ 19

Shared access signatures ............................................................................................................... 19

Azure Virtual Network ........................................................................................................................... 20

Use cases ........................................................................................................................................... 20

Cloud-only virtual networks ........................................................................................................... 20

Cross-premises virtual networks .................................................................................................... 20

Deploying a virtual network ............................................................................................................... 20

Portal ............................................................................................................................................. 20

PowerShell..................................................................................................................................... 20

Command-line interface ................................................................................................................ 21

Access and security for virtual networks ............................................................................................ 21

This guide introduces core concepts related to the deployment and management of a Microsoft Azure infrastructure. If you are new to cloud computing, or Azure itself, this guide will help get you quickly started with concepts, deployment, and management details. Many sections of this guide discuss an operation such as deploying a virtual machine, and then provide a link for in-depth technical detail.
 Introduction to cloud computing and Microsoft Azure
 Cloud computing overview
 Cloud computing provides a modern alternative to the traditional on-premises datacenter. Public cloud vendors provide and manage all computing infrastructure and the underlying management software. These vendors provide a wide variety of cloud services. A cloud service in this case might be a virtual machine, a web server, or cloud-hosted database engine. As a cloud provider customer, you lease these cloud services on an as-needed basis. In doing so, you convert the capital expense of hardware maintenance into an operational expense. A cloud service also provides these benefits:
  Rapid deployment of large compute environments

 Rapid deallocation of systems that are no longer required

 Easy deployment of traditionally complex systems like load balancers


 Ability to provide flexible compute capacity or scale when needed
 More cost-effective computing environments

 Access from anywhere with a web-based portal or programmatic automation

 Cloud-based services to meet most compute and application needs



With on-premises infrastructure, you have complete control over the hardware and software that is deployed. Historically, this has led to hardware procurement decisions that focus on scaling up. An example is purchasing a server with more cores to satisfy peak performance needs. Unfortunately, this infrastructure might be underutilized outside a demand window. With Azure, you can deploy only the infrastructure that you need, and adjust this up or down at any time. This leads to a focus on scaling out through the deployment of additional compute nodes to satisfy a performance need. Although this has consequences for the design of an appropriate software architecture, there is now ample proof that scaling out the commodity of cloud services is more cost-effective than scaling up through expensive hardware.

Microsoft has deployed many Azure datacenters around the globe, with more planned. Additionally, Microsoft is increasing sovereign clouds in regions like China and Germany. Only the largest global enterprises can deploy datacenters in this manner, so using Azure makes it easy for enterprises of any size to deploy their services close to their customers.

For small businesses, Azure allows for a low-cost entry point, with the ability to scale rapidly as demand for compute increases. This prevents a large up-front capital investment in infrastructure, and it provides the flexibility to architect and re-architect systems as needed. The use of cloud computing fits well with the scale-fast and fail-fast model of startup growth.

For more information on the available Azure regions, see Azure regions.
 Types of cloud computing
 Cloud computing is usually classified into three categories: SaaS, PaaS, and IaaS.
 SaaS: Software as a service
 SaaS is software that is centrally hosted and managed. It’s usually based on a multitenant architecture—a single version of the application is used for all customers. It can be scaled out to multiple instances to ensure the best performance in all locations. SaaS software typically is licensed through a monthly or annual subscription.

Microsoft Office 365 is a prototypical model of a SaaS offering. Subscribers pay a monthly or annual subscription fee, and they get Microsoft Exchange as a service (online and/or desktop Microsoft Outlook), storage as a service (Microsoft OneDrive), and the rest of the Microsoft Office suite (online, the desktop version, or both). Subscribers always get the most recent version. So you can have an Exchange server without having to purchase a server and install and support Exchange—the Exchange server is managed for you. Compared to installing and upgrading Office every year, this is much less expensive and requires much less effort to keep updated.
 PaaS: Platform as a service
 With PaaS, you deploy your application into an application-hosting environment that the cloud service vendor provides. The developer provides the application, and the PaaS vendor provides the ability to deploy and run it. This frees developers from infrastructure management so they can focus on development.

Azure provides several PaaS compute offerings, including the Web Apps feature of Azure App Service and Azure Cloud Services (web and worker roles). In either case, developers have multiple ways to deploy their application without knowing anything about the nuts and bolts that support it. Developers don’t have to create virtual machines (VMs), use Remote Desktop Protocol (RDP) to sign in to each one, or install the application. They just hit a button (or close to it), and the tools provided by Microsoft provision the VMs and then deploy and install the application on them.
 IaaS: Infrastructure as a service
 An IaaS cloud vendor runs and manages all physical compute resources and the required software to enable computer virtualization. A customer of this service deploys virtual machines in these hosted datacenters. Although the virtual machines are located in an offsite datacenter, the IaaS consumer has control over the configuration and management of them.

Azure includes several IaaS solutions, including Azure Virtual Machines, virtual machine scale sets, and related networking infrastructure. Azure Virtual Machines is a popular choice for initially migrating services to Azure because it enables a "lift and shift" migration model. You can configure a VM like the infrastructure currently running your services in your datacenter, and then migrate your software to the new VM. You might need to make configuration updates, such as URLs to other services or storage, but you can migrate many applications in this way.

Virtual machine scale sets are built on top of Azure Virtual Machines and provide an easy way to deploy clusters of identical VMs. Virtual machine scale sets also support autoscaling so that new VMs can be deployed automatically when required. This makes virtual machine scale sets an ideal platform to host higher-level microservice compute clusters, such as Azure Service Fabric and Azure Container Service.
 Azure services
 Azure offers many services in its cloud computing platform. These services include the following.
 Compute services
 Services for hosting and running application workload:

 Azure Virtual Machines—both Linux and Windows
  App Services (Web Apps, Mobile Apps, Logic Apps, API Apps, and Function Apps)

 Azure Batch (for large-scale parallel and batch compute jobs)

 Azure RemoteApp

 Azure Service Fabric


 Azure Container Service
Data services
 Services for storing and managing data:

 Azure Storage (comprises the Azure Blob, Queue, Table, and File services)
  Azure SQL Database
 Azure DocumentDB

 Microsoft Azure StorSimple

 Azure Redis Cache



Application services
 Services for building and operating applications:
  Azure Active Directory (Azure AD)
 Azure Service Bus for connecting distributed systems

 Azure HDInsight for processing big data


 Azure Scheduler

 Azure Media Services
Network services
 Services for networking both within Azure and between Azure and on-premises datacenters:
  Azure Virtual Network

 Azure ExpressRoute

 Azure-provided DNS


 Azure Traffic Manager

 Azure Content Delivery Network
For detailed documentation on each of these services, as well as other Azure services, see Azure service documentation.
 Azure key concepts
 Datacenters and regions
 Azure is a global cloud platform that is generally available in many regions around the world. When you provision a service, application, or VM in Azure, you are asked to select a region. The selected region represents a specific datacenter where your application runs. For more information, see Azure regions.

One of the benefits of using Azure is that you can deploy your applications into a variety of datacenters around the globe. The region you choose can affect the performance of your application. It’s optimal to choose a region that is closer to most your customers, to reduce latency in network requests. You might also select a region to meet the legal requirements for distributing your app in certain countries.
 Azure portal
 The Azure portal is a web-based application that can be used to create, manage, and remove Azure resources and services. The Azure portal is located at https://portal.azure.com. It includes a customizable dashboard and tooling for managing Azure resources. It also provides billing and subscription information. For more information, see Microsoft Azure portal overview.



Resources
 Azure resources are individual compute, networking, data, or app hosting services that have been deployed into an Azure subscription. Some common resources are a virtual machines, storage accounts, or SQL databases. Azure services often consist of several related Azure resources. For instance, an Azure virtual machine might include a VM, storage account, network adapter, and public IP address. All of these are individual resources. Each resource can be created, managed, and deleted individually or as a group. Azure resources are covered in more detail later in this guide.
 Resource groups
 An Azure resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only resources that you want to manage as a group. Azure resource groups are covered in more detail later in this guide.
 Resource Manager templates
 An Azure Resource Manager template is a JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group. It also defines the dependencies between deployed resources. Resource Manager templates are covered in more detail later in this guide.
 Automation
 In addition to creating, managing, and deleting resources by using the Azure portal, you can automate these activities by using PowerShell or the Azure command-line interface (CLI).
 Azure PowerShell
 Azure PowerShell is a set of modules that provide cmdlets to manage Azure. You can use the cmdlets to create, manage, and remove Azure services. In most cases, you can use the cmdlets for the same tasks that you perform in the Azure portal. The cmdlets can help you can achieve consistent, repeatable, and hands-off deployments. For more information, see How to install and configure Azure PowerShell.
 Azure command-line interface
 The Azure command-line interface is a tool that you can use to create, manage, and remove Azure resources from the command line. The Azure CLI is available for Linux, Mac OS X, and Windows. For more information and technical details, see Install the Azure CLI.
 REST APIs Azure is built on a set of REST APIs that support the Azure portal UI. Most of these REST APIs are also supported to let you programmatically provision and manage your Azure resources and apps from any Internet-enabled device. For more information, see the Azure REST SDK Reference.



Getting started with Azure subscriptions
 A subscription is a logical grouping of Azure services that is linked to an Azure account. A singe Azure account can contain multiple subscriptions. Billing for Azure services is done on a per-subscription basis. Azure subscriptions have an account administrator, who has full control over the subscription, and a service administrator, who has control over all services in the subscription. In addition to administrators, individual accounts can be granted detailed control of Azure resources through RBAC.
 Select and enable an Azure subscription
 Before you can work with Azure services, you need a subscription. Several subscription types are available.
 Free accounts: The link to sign up for a free account is on the Azure website. This gives you a $200 credit over the course of 30 days to try any combination of resources in Azure. If you exceed your credit amount, your account will be suspended. At the end of the trial, your services will be decommissioned and will no longer work. You can upgrade this to a pay-as-you-go subscription at any time.

MSDN subscriptions: If you have an MSDN subscription, you get a specific amount in Azure credit each month. For example, if you have a Microsoft Visual Studio Enterprise with MSDN subscription, you get $150 per month in Azure credit.



If you exceed the credit amount, your service will be disabled until the next month starts. You can turn off the spending limit and add a credit card to be used for the additional costs. Some of these costs are discounted for MSDN accounts. For example, you pay the Linux price for VMs running Windows Server, and there is no additional charge for Microsoft servers such as Microsoft SQL Server. This makes MSDN accounts ideal for development and test scenarios.
 BizSpark accounts: The Microsoft BizSpark program provides a lot of benefits to startups. One of those benefits is access to all the Microsoft software for development and test environments for up to five MSDN accounts. You get $150 in Azure credit for each of those five MSDN accounts, and you pay reduced rates for several of the Azure services, such as Virtual Machines.

Pay-as-you-go: With this subscription, you pay for what you use by attaching a credit card or debit card to the account. If you are an organization, you can also be approved for invoicing.

Enterprise agreements: With an enterprise agreement, you commit to using a certain amount of services in Azure over the next year, and you pay that amount ahead of time. The commitment that you make is consumed throughout the year. If you exceed the commitment amount, you can pay the overage in arrears. Depending on the amount of the commitment, you get a discount on the services in Azure.



For more information and to create an Azure subscription, see How to sign up, purchase, upgrade, or activate Azure.
 Grant administrative access to an Azure subscription
 Multiple account administrator roles are available and can be changed at any time. Two key roles are:
  Service administrator: This role is authorized to manage Azure services. By default, it’s granted access to the same account as the account administrator.

 Co-administrator: This role has the same access as the service administrator. However, this role cannot change the association of a subscription to Azure directories.



For more information, see How to add or change Azure administrator roles.
 View billing information in the Azure portal
 An important component of using Azure is the ability to view billing information. The Azure portal provides detailed insight into Azure billing information.

For more information, see How to download your Azure billing invoice and daily usage data.
 Get billing information from billing APIs
 In addition to viewing the billing in the portal, you can access the billing information by using a script or program through the Azure Billing REST APIs:
  You can use the Azure Usage API to retrieve your usage data. You can fine-tune the billing usage information by tagging related Azure resources. For example, you can tag each of the resources in a resource group with a department name or project name, and then track the costs specifically for that one tag.

 You can use the Azure Rate Card API to list all the available resources, along with the metadata and pricing information about each of those resources.



For more information, see Gain insights into your Microsoft Azure resource consumption.
 Forecast cost with the pricing calculator
 The pricing for each service in Azure is different. Many Azure services provide Basic, Standard, and Premium tiers. Usually, each tier has several price and performance levels. By using the online pricing calculator, you can create pricing estimates. The calculator includes flexibility to estimate cost on a single resource or a group of resources.
 Set up billing alerts
 After you have deployed your application or solution on Azure, you can create alerts that send you email when you approach spending limits defined in the alert. For more information, see Set up billing alerts for your Microsoft Azure subscriptions.
 Azure Resource Manager
 Azure Resource Manager is a deployment, management, and organization mechanism for Azure resources. By using Resource Manager, you can put many individual resources together in a resource group.

Resource Manager also includes deployment capabilities that allow for customizable deployment and configuration of related resources. For instance, by using Resource Manager, you can deploy an application that consists of multiple virtual machines, a load balancer, and a SQL database as a single unit. You develop these deployments by using a Resource Manager template.

Resource Manager provides several benefits:

 You can deploy, manage, and monitor all the resources for your solution as a group, rather than handling these resources individually.
  You can repeatedly deploy your solution throughout the development lifecycle and have confidence that your resources are deployed in a consistent state.


 You can manage your infrastructure through declarative templates rather than scripts.
 You can define the dependencies between resources so they are deployed in the correct order.

 You can apply access control to all services in your resource group because RBAC is natively integrated into the management platform.

 You can apply tags on resources to logically organize all the resources in your subscription.

 You can clarify your organization’s billing by viewing costs for a group of resources that share the same tag.



Tips for creating resource groups
 When you’re making decisions about your resource groups, consider these tips:
  All the resources in a resource group should have the same lifecycle.

 You can assign a resource to only one group at a time.

 You can add or remove a resource from a resource group at any time. Every resource must belong to a resource group. So if you remove a resource from one group, you must add it to another.

 You can move most types of resources to a different resource group at any time.


 The resources in a resource group can be in different regions.
 You can use a resource group to control access for the resources in it.



Building Resource Manager templates
 Resource Manager templates declaratively define the resources and resource configurations that will be deployed into a single resource group. You can use Resource Manager templates to orchestrate complex deployments without the need for excess scripting or manual configuration. After you develop a template, you can deploy it multiple times—each time with an identical outcome.

A Resource Manager template consists of four sections:
  Parameters: These are inputs to the deployment. Parameter values can be provided by a human or an automated process. An example parameter might be an admin user name and password for a Windows VM. The parameter values will be used throughout the deployment when they’re specified.

 Variables: These are used to hold values that are used throughout the deployment. Unlike parameters, a variable value is not provided at deployment time. Instead, it’s hard coded or dynamically generated.

 Resources: This section of the template defines the resources to be deployed, such as virtual machines, storage accounts, and virtual networks.

 Output: After a deployment has finished, Resource Manager can return data such as dynamically generated connection strings.



The following mechanisms are available for deployment automation:
  Functions: You can use several functions in Resource Manager templates. These include operations such as converting a string to lowercase, deploying multiple instances of a defined resource, and dynamically returning the target resource group. Resource Manager functions help build dynamic deployments.

 Resource dependencies: When you’re deploying multiple resources, some resources will have a dependency on others. To facilitate deployment, you can use a dependency declaration so that dependent resources are deployed before the others.

 Template linking: From within one Resource Manager template, you can link to another template. This allows deployment decomposition into a set of targeted, purpose-specific templates.



You can build Resource Manager templates in any text editor. However, the Azure SDK for Visual Studio includes tooling to assist in the creation process. By using Visual Studio, you can add resources to the template through a wizard. You can then deploy and debug the template directly from the Visual Studio IDE. For more information, see Authoring Azure Resource Manager templates.
 Finally, you can convert existing resource groups into a reusable template from the Azure portal. This can be helpful if you want to create a deployable template of an existing resource group, or you just want to examine the underlying JSON. To export a resource group, select the Automation Script button from the resource group’s settings.



Security of Azure resources (RBAC)
 You can grant operational access to user accounts at a specified scope: subscription, resource group, or individual resource. This means you can deploy a set of resources into a resource group, such as a virtual machine and all related resources, and grant permissions to a specific user or group. This approach limits access to only the resources that belong to the target resource group. You can also grant access to a single resource, such as a virtual machine or a virtual network.

To grant access, you assign a role to the user or user group. There are many predefined roles. You can also define your own custom roles.

Here are a few example roles built into Azure:
  Owner: A user with this role can manage everything, including access.

 Reader: A user with this role can read resources of all types (except secrets) but can’t make changes.

 Virtual machine contributor: A user with this role can manage virtual machines but can’t manage the virtual network to which they are connected or the storage account where the VHD file resides.

 SQL DB contributor: A user with this role can manage SQL databases but not their security-related policies.

 SQL security manager: A user with this role can manage the security-related policies of SQL servers and databases.

 Storage account contributor: A user with this role can manage storage accounts but cannot manage access to the storage accounts.



For more information, see Use role assignments to manage access to your Azure subscription resources.
 Azure Virtual Machines
 Azure Virtual Machines is one of the central IaaS services in Azure. Azure Virtual Machines supports the deployment of Windows or Linux virtual machines in a Microsoft Azure datacenter. With Azure Virtual Machines, you have total control over the VM configuration and are responsible for all software installation, configuration, and maintenance.

When you’re deploying an Azure VM, you can select an image from the Azure Marketplace, or you can provide you own generalized image. This image will be used to apply the operating system and initial configuration. During the deployment, Resource Manager will handle some configuration settings, such as assigning the computer name, administrative credentials, and network configuration. You can use Azure virtual machine extensions to further automate configurations such as software installation, antivirus configuration, and monitoring solutions.
 You can create virtual machines in many different sizes. The size of virtual machine dictates resource allocation such as processing, memory, and storage capacity. In some cases, specific features such as RDMA-enabled network adapters and SSD disks are available only with certain VM sizes. For a complete list of VM sizes and capabilities, see "Sizes for virtual machines in Azure" for Windows and Linux.



Use cases
 Because Azure virtual machines offer complete control over configuration, they are ideal for a wide range of server workloads that do not fit into a PaaS model. Server workloads such as database servers (SQL Server, Oracle, or MongoDB), Windows Server Active Directory, Microsoft SharePoint, and many more become possible to run on the Microsoft Azure platform. If desired, you can move such workloads from an on-premises datacenter to one or more Azure regions, without a large amount of reconfiguration.
 Deployment of virtual machines
 You can deploy Azure virtual machines by using the Azure portal, by using automation with the Azure PowerShell module, or by using automation with the cross-platform CLI.
 Portal
 Deploying a virtual machine by using the Azure portal requires only an active Azure subscription and access to a web browser. You can select many different operating system images with varying configurations. All storage and networking requirements are configured during the deployment. For more information, see "Create your first Windows virtual machine in the Azure portal" for Windows and Linux.

In addition to deploying a virtual machine from the Azure portal, you can deploy an Azure Resource Manager template from the portal. This will deploy and configure all resources as defined in the template. For more information, see Deploy resources with Resource Manager templates and Azure portal.
 PowerShell
 Deploying an Azure virtual machine by using PowerShell allows for complete deployment automation of all related virtual machine resources, including storage and networking. For more information, see Create a Windows VM using Resource Manager and PowerShell.

In addition to deploying Azure compute resources individually, you can use the Azure PowerShell module to deploy an Azure Resource Manager template. This provides automation to start the deployment action while retaining all benefits of modeling a deployment by using Resource Manager templates. For more information, see Deploy resources with Resource Manager templates and Azure PowerShell.
 Command-line interface
 As with the PowerShell module, the Azure command-line interface provides deployment automation and can be used on Windows, OS X, or Linux systems. When you’re using the Azure CLI vm quick-create command, all related virtual machine resources (including storage and networking) and the virtual machine itself are deployed. For more information, see Create a Linux VM in Azure by using the CLI.



Likewise, you can use the Azure CLI to deploy an Azure Resource Manager template. This provides automation to start the deployment action while retaining all benefits of modeling a deployment by using Resource Manager templates. For more information, see Deploy resources with Resource Manager templates and Azure CLI.
 Access and security for virtual machines
 Accessing a virtual machine from the Internet requires the associated network interface, or load balancer if applicable, to be configured with a public IP address. The public IP address includes a DNS name that will resolve to the virtual machine or load balancer. For more information, see IP addresses in Azure.

You manage access to the virtual machine over the public IP address by using a network security group (NSG) resource. An NSG acts like a firewall and allows or denies traffic across the network interface or subnet on a set of defined ports. For instance, to create a Remote Desktop session with an Azure VM, you need to configure the NSG to allow inbound traffic on port 3389. For more information, see Opening ports to a VM in Azure using the Azure portal.

Finally, as with the management of any computer system, you should provide security for an Azure virtual machine at the operating system by using security credentials and software firewalls.
 Azure Storage
 Azure Storage is a Microsoft-managed service that provides durable, scalable, and redundant storage. You can add an Azure storage account as a resource to any resource group by using any resource deployment method. Azure includes four storage types: Blob storage, File Storage, Table storage, and Queue storage. When deploying a storage account, two account types are available, General-purpose and Blob storage. A General purpose storage account gives you access to all four storage types. Blob storage accounts are similar to general-purpose accounts, but contain specialized blobs that include hot and cold access tiers. For more information on Blob storage, see Azure Blob storage.

Azure storage accounts can be configured with different levels of redundancy:
  Locally redundant storage provides high availability by ensuring that three copies of all data are made synchronously before a write is deemed successful. These copies are stored in a single facility in a single region. The replicas reside in separate fault domains and upgrade domains. This means the data is available even if a storage node that’s holding your data fails or is taken offline to be updated.

 Geo-redundant storage makes three synchronous copies of the data in the primary region for high availability, and then asynchronously makes three replicas in a paired region for disaster recovery.

 Read-access geo-redundant storage is geo-redundant storage plus the ability to read the data in the secondary region. This ability makes it suitable for partial disaster recovery. If there’s a problem with the primary region, you can change your application to have read-only access to the paired region.



Use cases
 Each storage type has a different use case.
 Blob storage The word blob is an acronym for binary large object. Blobs are unstructured files like those that you store on your computer. Blob storage can store any type of text or binary data, such as a document, media file, or application installer. Blob storage is also referred to as object storage. Azure Blob storage also holds Azure Virtual Machines data disks.



Azure Storage supports three kinds of blobs:
  Block blobs are used to hold ordinary files up to 195 GB in size (4 MB × 50,000 blocks). The primary use case for block blobs is the storage of files that are read from beginning to end, such as media files or image files for websites. They are named block blobs because files larger than 64 MB must be uploaded as small blocks. These blocks are then consolidated (or committed) into the final blob.

 Page blobs are used to hold random-access files up to 1 TB in size. Page blobs are used primarily as the backing storage for the VHDs that provide durable disks for Azure Virtual Machines, the IaaS compute service in Azure. They are named page blobs because they provide random read/write access to 512-byte pages.

 Append blobs consist of blocks like block blobs, but they are optimized for append operations. These are frequently used for logging information from one or more sources to the same blob. For example, you might write all of your trace logging to the same append blob for an application that’s running on multiple VMs. A single append blob can be up to 195 GB.



For more information, see Get started with Azure Blob storage.
 File storage
 Azure File storage is a service that offers file shares in the cloud by using the standard Server Message Block (SMB) protocol. The service supports both SMB 2.1 and SMB 3.0. With Azure File storage, you can migrate applications that rely on file shares to Azure quickly and without costly rewrites. Applications running on Azure virtual machines, in cloud services, or from on-premises clients can mount a file share in the cloud. This is similar to how a desktop application mounts a typical SMB share. Any number of application components can then mount and access the File storage share simultaneously.

Because a File storage share is a standard SMB file share, applications running in Azure can access data in the share via file system I/O APIs. Developers can therefore use their existing code and skills to migrate existing applications. IT pros can use PowerShell cmdlets to create, mount, and manage File storage shares as part of the administration of Azure applications.

For more information, see Get started with Azure File storage.
 Table storage
 Azure Table storage is a service that stores structured NoSQL data in the cloud. Table storage is a key/attribute store with a schema-less design. Because Table storage is schema-less, it's easy to adapt your data as the needs of your application evolve. Access to data is fast and cost-effective for all kinds of applications. Table storage is typically significantly lower in cost than traditional SQL for similar volumes of data.

You can use Table storage to store flexible datasets, such as user data for web applications, address books, device information, and any other type of metadata that your service requires. You can store any number of entities in a table. A storage account can contain any number of tables, up to the capacity limit of the storage account.

For more information, see Get started with Azure Table storage.
 Queue storage
 Azure Queue storage provides cloud messaging between application components. In designing applications for scale, application components are often decoupled so that they can scale independently. Queue storage delivers asynchronous messaging for communication between application components, whether they are running in the cloud, on the desktop, on an on-premises server, or on a mobile device. Queue storage also supports managing asynchronous tasks and building process workflows.

For more information, see Get started with Azure Queue storage.
 Deploying a storage account
 Portal
 Deploying a storage account by using the Azure portal requires only an active Azure subscription and access to a web browser. You can deploy a new storage account into a new or existing resource group. After you’ve created the storage account, you can create a blob container or file share by using the portal. You can create Table and Queue storage entities programmatically.

In addition to deploying a storage account from the Azure portal, you can deploy an Azure Resource Manager template from the portal. This will deploy and configure all resources as defined in the template, including any storage accounts. For more information, see Deploy resources with Resource Manager templates and Azure portal.
 PowerShell
 Deploying an Azure storage account by using PowerShell allows for complete deployment automation of the storage account. For more information, see Using Azure PowerShell with Azure Storage.

In addition to deploying Azure resources individually, you can use the Azure PowerShell module to deploy an Azure Resource Manager template. This provides automation to start the deployment action while retaining all benefits of modeling a deployment by using Resource Manager templates. For more information, see Deploy resources with Resource Manager templates and Azure PowerShell.
 Command-line interface
 As with the PowerShell module, the Azure command-line Interface provides deployment automation and can be used on Windows, OS X, or Linux systems. You can use the Azure CLI storage account create command to create a storage account. For more information, see Using the Azure CLI with Azure Storage.



Likewise, you can use the Azure CLI to deploy an Azure Resource Manager template. This provides automation to start the deployment action while retaining all benefits of modeling a deployment by using Resource Manager templates. For more information, see Deploy resources with Resource Manager templates and Azure CLI.
 Access and security for Azure Storage
 Azure Storage is accessed in a variety of ways, including though the Azure portal, during VM creation and operation, and from Storage client libraries. This section will detail a few of these.
 Virtual machine disks
 When you’re deploying a virtual machine, you also need to create a storage account to hold the virtual machine operating system disk and any additional data disks. You can select an existing storage account or create a new one. Because the maximum size of a blob is 1,024 GB, a single VM disk has a maximum size of 1,023 GB. To configure a larger data disk, you can present multiple data disks to the virtual machine and pool them together as a single logical disk. For more information, see "Storage infrastructure guidelines" for Windows and Linux.



Storage tools
 Azure storage accounts can be accessed through many different storage explorers, such as Visual Studio Cloud Explorer. These tools provide the ability to browse through storage accounts and data. For more information and a list of available storage explorers, see Azure Storage client tools.
 Storage API
 Storage resources can be accessed by any language that can make HTTP/HTTPS requests. Additionally, Azure Storage offers programming libraries for several popular languages. These libraries simplify many aspects of working with Azure Storage by handling details such as synchronous and asynchronous invocation, batching of operations, exception management, automatic retries, and operational behavior. For more information, see Azure Storage service REST API reference.
 Storage access keys
 Each storage account has two authentication keys, a primary and a secondary. Either of these can be used for storage access operations. These storage keys are used to help secure a storage account and are required for programmatically accessing data. There are two keys to allow occasional rollover of the keys to enhance security. It is critical to keep these secure because their possession, along with the account name, allows unlimited access to any data in the storage account.
 Shared access signatures
 If you need to allow users to have controlled access to your storage resources, you can create a shared access signature. A shared access signature is a token that can be appended to a URL that enables delegated access to a storage resource. Anyone who possesses the token can access the resource that it points to with the permissions that it specifies, for the period of time that it’s valid. For more information, see Using shared access signatures.
 Azure Virtual Network
 Virtual networks are necessary to support communications between virtual machines. You can define subnets, custom IP address, DNS settings, security filtering, and load balancing. By using a VPN gateway or an ExpressRoute circuit, you can connect Azure virtual networks to your on-premises networks.
 Use cases
 Cloud-only virtual networks
 An Azure virtual network, by default, is accessible only to resources stored in Azure. Resources connected to the same virtual network can communicate with each other. You can associate virtual machine network interfaces and load balancers with a public IP address to make the virtual machine accessible over the Internet. You can help secure access to the publicly exposed resources by using a network security group.
 Cross-premises virtual networks
 You can connect an on-premises network to an Azure virtual network by using ExpressRoute or a site-to-site VPN connection. In this configuration, the Azure virtual network is essentially a cloud-based extension of your on-premises network.

Because the Azure virtual network is connected to your on-premises network, cross-premises virtual networks must use a unique portion of the address space that your organization uses. In the same way that different corporate locations are assigned a specific IP subnet, Azure becomes another location as you extend your network.
 Deploying a virtual network
 Portal
 Deploying an Azure virtual network by using the Azure portal requires only an active Azure subscription and access to a web browser. You can deploy a new virtual network into a new or existing resource group. When you’re creating a new virtual machine from the portal, you can select an existing virtual network or a create a new one. For more information, see Create a virtual network using the Azure portal.

In addition to deploying an Azure virtual network from the Azure portal, you can deploy an Azure Resource Manager template from the portal. This will deploy and configure all resources as defined in the template, including any virtual network resources. For more information, see Deploy resources with Resource Manager templates and Azure portal.
 PowerShell
 Deploying an Azure virtual network by using PowerShell allows for complete deployment automation of the storage account. For more information, see Create a virtual network by using PowerShell.

In addition to deploying Azure resources individually, you can use the Azure PowerShell module to deploy an Azure Resource Manager template. This provides automation to start the deployment action while retaining all benefits of modeling a deployment by using Resource Manager templates. For more information, see Deploy resources with Resource Manager templates and Azure PowerShell.
 Command-line interface
 As with the PowerShell module, the Azure command-line interface provides deployment automation and can be used on Windows, OS X, or Linux systems. You can use the Azure CLI network vnet create command to create a virtual network. For more information, see Create a virtual network by using the Azure CLI.



Likewise, you can use the Azure CLI to deploy an Azure Resource Manager template. This provides automation to start the deployment action while retaining all benefits of modeling a deployment by using Resource Manager templates. For more information, see Deploy resources with Resource Manager templates and Azure CLI.
 Access and security for virtual networks
 You can help secure Azure virtual networks by using a network security group. NSGs contain a list of access control list (ACL) rules that allow or deny network traffic to your VM instances in a virtual network. You can associate NSGs with either subnets or individual VM instances within that subnet. When you associate an NSG with a subnet, the ACL rules apply to all the VM instances in that subnet. In addition, you can further restrict traffic to an individual VM by associating an NSG directly with that VM. For more information, see What is a Network Security Group?.