The audience for this chapter includes business executives and technology decision-makers who want a quick overview of developer topics. This chapter connects the Azure developer services that span across the geographic regions of Azure datacenters. It overviews application development services in Microsoft Azure, making decisions for creating cloud applications, and how Azure supports code using popular programming languages.
This chapter is foundational and offers high-level explanations with later chapters providing deeper dives, configurations, and coding exercises. The support for developers or Application development (AppDev) includes application development with C#, .NET, Python, and others.
.NET
Python
JavaScript
Java
PHP
Go Language
The use of open source or non-Microsoft languages on a Microsoft platform may be surprising to some engineers; however, it is a key investment from Microsoft to support developers’ languages of choice. Development language support is one leg of the development triangle.
Application development has evolved from longer, software development life cycles to embrace Agile deployment methods. Agile connects the second leg of the deployment triangle: people with processes. Azure DevOps (see Chapter 21) guides the Agile method of software creation and connectivity. In this chapter, you simply need to comprehend that code development using Agile deployment methods is achieved in an incremental process and requires team members, managers, and executives to support the method.
The third leg of the application development triangle is the technologies, Azure development services. Traditional development services depended on the hardware architecture to create a highly available service. Traditionally, budgets invested in servers, multiple processors, memory, and multiple networks with fiber to storage area networks (SAN). The cost of purpose-built datacenters goes further with the need to create highly available datacenter, including dual power feeds for buildings, dual power to the server racks, power backup systems, cooling, and humidity control. Developers need to understand which Azure services best support their application requirements for high availability (HA).
Learn more about business continuity and the high availability of the Azure global network at https://azure.microsoft.com/en-us/features/resiliency/.
Azure Development and GitHub
GitHub is a web-based management platform used as a collaboration and source control service to manage software development projects and files; it uses a distributed version control system called Git. Microsoft acquired GitHub in October 2018, and the announcement said that GitHub would operate independently. Although viewed skeptically by some people in the industry because of Microsoft’s history with open source, the often-used “New Microsoft” moniker and the general change in the culture within Microsoft is still one that points to a 180-degree shift in support for open source.
GitHub adds unique features beyond the standard implementation of Git. The GitHub platform is designed to support developers’ life cycle management of their applications from inception to delivery and beyond (e.g., maintenance, feature and fix releases, etc.). Updates, or versioning, include things like new coding features, vulnerabilities being patched, and different team members contributing. Git was created to support tracking changes to the Linux kernel in support of Linus Torvalds and other global contributing developers.
The information in GitHub is stored in a data structure called a repository, and data is changed using push-and-pull Git functions. You can download a copy of the repository, which is known as a working copy. As the development project files, or objects, change (called commit objects), the changes are tracked using a mandatory posting data attribute that includes who, what, why, and when. Role-based access identifies who made the change, and Git logs show what changed and when. Git commits are typically required to provide a tagging process for why a change was submitted. The life cycle of the development project supports the revisioning of software because the Git log shows the master branch, current branch (working on before commit back to the master), and committed code to create a new “merged” version.
GitHub offers developers and their teams many subscription access models, including free, professional, team, and enterprise. Many open source projects are hosted using the free plan, whereas businesses use professional and enterprise subscription models to have private repositories. Features for the plans vary, including unlimited repositories, limited collaborators, and storage size.
Learn more about GitHub’s plans for developers at https://github.com/pricing.
Microsoft Azure continues to integrate directly with GitHub web services using Azure’s current DevOps platform. GitHub’s integration with Azure supports cloud security, like SAML (Secure Access Markup Language), visual and digital metrics for tracking and critical-issue support programs.
When the term Azure DevOps is used, clarification is often required because there are two distinctly different versions, and neither is a repository on GitHub. Azure DevOps Server has an on-premises version (a server running on a VM) and an online service (no VM). Both versions (server or service) implement the Git service through the formerly branded Microsoft Team Foundation Server.
Azure DevOps Services is Software as a Service (SaaS), offering that is directly supported using Microsoft Visual Studio. Visual Studio is an integrated development environment (IDE) running on Azure. Azure DevOps Services do not use GitHub as the back end for code repository. GitHub is a different hosting platform for repository management. Azure DevOps offers native cloud-based team collaboration for writing, editing, and sharing code. Azure DevOps services support connection into your GitHub account. GitHub can be used to update Azure app service directly or integrated with accounts to Azure DevOps “Boards” feature to link team text commits and DevOps pull requests (PR).
Chapter 21 provides configuration guidance and hands-on exercises. Azure App Service supports continuous deployment from GitHub, Bitbucket, and Azure repositories (part of Azure DevOps Services).
Azure Infrastructure as Code
Standardizing on supported cloud infrastructure blueprints is good for engineers, Agile teams, and businesses. Standards prevent organizational shortcomings of ad hoc scaffolding that has not been validated to support business needs. Businesses standardize development languages for custom applications, operating systems, remote access, network security, endpoint protection, and public clouds to support their business. Infrastructure as code (IaC) supports methods to standardize production-ready cloud networks, services, and security infrastructure deployment.
Azure Resource Manager (ARM) templates
HashiCorp Terraform
Create standard secure virtual networks
Test new VM deployments
Update an infrastructure library for business-ready workloads
Use automation and repeatable deployment models
Azure supports ARM templates natively through a JavaScript Object Notation (JSON) definition file so that it can be customized for your Azure subscription use. The JSON files support Azure resources, location sequencing, variables, and many deployment methods. ARM templates can be deployed using the portal, PowerShell, Azure CLI, and the REST API.
HashiCorp Terraform supports building and versioning IaC template libraries so that you can manage Azure services as well as AWS or GCP. Like ARM, HashiCorp’s Terraform uses configuration files to generate plans for the “desired state” when it executes. It can create Azure VNets and VMs, enable DNS and Bastion Hosts, and create users and groups in Azure Active Directory—all by using code from a GitHub repository.
Azure Resource Manager templates complete work through the Azure API model, and Terraform uses providers to allow secure interaction with your Azure subscription. Refer to Chapter 11, where both ARM and Terraform are enabled to generate code that can be deployed in Azure.
ARM and HashiCorp Terraform are technology leaders. Using both deployment models solves a problem that you may not know your business encountered. Both deployment processes offer 24×7 support and world-class training to ramp up your team and can provide a deep pool of subject-matter experts to hire. Some businesses deploy Azure infrastructure using PowerShell or CLI scripts from an IaC library. Others use only ARM templates to deploy and manage Azure resources, and separate tools to manage on-premises and non-Azure workloads, like VMware, AWS, and Google Cloud Platform. Terraform allows your Azure team to develop a process to deploy IaC and use the same method to deploy to other clouds and on-premise.
Learn more about HashiCorp providers for Azure, AWS, GCP, and Alibaba cloud—and many other technology services—at www.terraform.io/docs/providers/index.html.
Azure App Service
Azure App Service enables many services under one umbrella, such as hosting web apps, and mobile back ends, and REST APIs, without the need to manage the infrastructure. The back-end services support high availability (HA) and scaling of services, but you must select the correct pricing tier.
Azure App Service on Linux
Azure App Service (default)
Azure App Service on Linux was added after the Windows-based series. Hosting websites or web applications on Linux supports a different stack of services. For example, deploying programming language environment support in a Linux distro is slightly different than deploying a Windows-based app service. The following exercise offers greater insight into these differences.
- 1.
Log in to your Azure subscription portal (Free or Test subscription is fine). Use a role that supports starting the Azure CMD shell.
- 2.
Start the Azure cloud shell in the upper right of the Azure portal, and select the Bash terminal, as seen in Figure 4-2.
- 3.
Type the following command:
az webapp list-runtimes --linux - 4.Note that the list is long and includes the supported language versions available in your Azure App Service on Linux. (The following is a partial listing.)"RUBY|2.3.8","RUBY|2.4.5","RUBY|2.5.5","RUBY|2.6.2","NODE|lts","NODE|12-lts","NODE|10.12","NODE|10.14",... < BREAK > ..."PHP|5.6","PHP|7.0","PHP|7.2","PHP|7.3","DOTNETCORE|1.0","DOTNETCORE|1.1",... < BREAK >..."TOMCAT|9.0-jre8","JAVA|8-jre8","WILDFLY|14-jre8","TOMCAT|8.5-java11","TOMCAT|9.0-java11","JAVA|11-java11","PYTHON|3.8","PYTHON|3.7","PYTHON|3.6","PYTHON|2.7"
- 5.
Run the command once more without the - - linux extension. Type the following command:
Az webapp list-runtimes - 6.
Note that the list is different and starts with : aspnet | v4.7, …
In addition to the language support differences, there is a difference in deployment methods. Azure App Service on Linux supports FTP, a local install version of Git, GitHub, and Bitbucket.
There are many different App Service plans, and we’ll review the highlights here; however, you should understand what is needed to support the architecture. An Azure App Service is a web service (Windows stack or Linux stack) running on a virtual machine (VM). You need to review current information on service plans, including Azure regions, VM instances, VM size, and pricing tiers.
The guidance provided on this topic is a snapshot from the time of writing. Services and tiers will change because demand drives cloud services.
Shared compute tier: Free and Shared
Dedicated compute tier: Basic, Standard, Premium, PremiumV2
Isolated tier: Dedicated VMs on dedicated virtual networks
Each App Service tier supports either the Linux web stack and applications running on Linux VMs or the Windows web stack and applications running on Windows VMs. Each tier provides a subset of App Service features, and choosing the correct tier is critical to achieving application development requirements. The higher Azure Web Apps tiers offer more features. Go to https://github.com/harris-soh-copeland-puca/azure-docs/blob/master/articles/app-service/overview-hosting-plans.md for more information about the different Azure App Service plans.
If your application requires SSL certificates, custom domain names, or integration with Azure Traffic Manager (see Chapter 12), then review the App Service tier to find out which features are supported in which tier. The good news is that all the App Service tiers support scaling up and out.
Scaling up refers to more CPU, memory, and disk space for each VM in the tier. Scaling out refers to increasing the VM number with limits based on the pricing tier you selected. No change in code or redeployment of code is required to scale, and the updates take less than a minute.
More information on scaling app services or enabling features to support multicore CPUs with additional RAM is at https://azure.microsoft.com/en-us/pricing/details/app-service/plans/.
Summary
In this chapter, you learned about Azure development support for services and languages. This chapter is especially helpful for business executives and technology decision-makers to learn which Azure services support GitHub and Git. We overviewed two well-positioned deployment methods—ARM and HashiCorp Terraform. You gained insight into the Azure App Service and the need to understand features for scaling up and scaling out before you select a pricing tier.