After some thoughtful deliberations, you've joined the Azure community, and now you want to get started building applications. What do you need?
Not much really. The most important thing to have is just a connection to Azure to deploy your app. You can use the tools, applications, and frameworks of your choice.
Whatever you use to create or edit your applications in your on-premises environment, you can use with Azure. Choose anything: from Notepad to Visual Studio Code, to Sublime Text, to Visual Studio, to the code editors in the Azure portal. It's your call!
Plug-ins are available for all the popular IDEs, giving you the ability to do things like publish directly to Azure. And even if you prefer using a bare-bones tool like Notepad, you can still automate your deployments to Azure using Continuous Integration (CI)/Continuous Delivery (CD) practices.
Azure provides a powerful command-line interface (CLI) with which you can do basically everything in Azure. You can use the Azure CLI to start and stop virtual machines (VMs), to deploy your application to an app in Azure Web App, to create new resources, and everything else. It's also very useful for automating tasks and running them in your CI/CD pipelines.
You can use the Azure CLI available on the Azure portal in the Azure Cloud Shell, or locally, on your machine, through the Azure CLI tooling. Another advantage is that you can apply your existing Bash or Windows PowerShell expertise in the Azure CLI.
Azure is great for web applications and APIs. It's also great as a host for desktop and mobile applications. You could, for instance, use it to authenticate users in your desktop application or send push notifications to your mobile app. No matter what scenario you have in mind, Azure can add value to it.
Clearly, it's important to know what things cost in Azure. To assist you in that, Microsoft offers the Azure Pricing Calculator. With this handy tool, you select the services that you are going to use and specify how much you anticipate using them, and the calculator will let you know what your monthly and yearly bill will be. This, together with how much data you'll use, determines your costs.
Note The Azure Pricing Calculator estimates costs for pay-as-you-go subscriptions. There are other payment options for enterprises, partners, and MSDN subscribers, which can affect the costs of services.
You can also keep an eye on your costs using the Azure Billing APIs and Pricing alerts. You can take advantage of these to gain insights into costs and spending trends so that you can control your costs.
Azure provides a lot of services to help you build and run your applications. There are so many services, in fact, that it can sometimes be a bit confusing to choose just the right services for your scenario. Which ones should you pick as a developer? Let's explore some of your options.
The first choice you'll need to make right out of the gate is where to host your application. Azure offers several hosting options.
One of the ways to host your application is in a VM in Azure Virtual Machine. This provides you with a lot of control over how you host your application, but you are responsible for maintaining the environment, such as patching the operating system (OS) and keeping antivirus programs up to date.
You can, for instance, use an VM to test the latest preview version of Visual Studio, without getting your machine "dirty."
Containers are much more lightweight than VMs and you can start and stop them in a few seconds. Containers also offer tremendous portability, which makes them ideal for developing an app locally, on your machine, and then hosting it in the cloud, in test, and later in production. You can even run containers on-premises or in other clouds—the environment that you use on your development machine travels with your container, so your app always runs in the same ecosystem.
Just like VMs, containers provide you with a lot of control over your environment. You can install what you need to run your applications. But, again, you are responsible for patching and maintaining the OS that runs in the container and for ancillaries like antivirus programs.
You can host your container using Azure Container Instances. Using this service, you can quickly spin up a container, without the need for a container orchestrator, like Kubernetes, and without having to manage the resources that host the container.
The Container Instances service is billed per second, per virtual CPU, per gigabyte, or memory.
Another way to host containers is by using Azure Container Service. With this service, you can scale and manage your containers using orchestrators like Mesosphere DC/OS, Docker Swarm, or Kubernetes. This service is a great way to begin moving your containers to the cloud.
With Azure Functions, you can write just the code you need for a solution without worrying about building a full application or the infrastructure to run it. A function is a unit of code logic that is triggered by an HTTP request, an event in another Azure service, or based on a schedule. Input and output bindings connect your function code to other services, like Azure Blob Storage, Azure Cosmos DB, and Azure Service Bus, with minimal code. Using Functions, you can build small pieces of functionality quickly and host them in an elastic environment that automatically manages scaling.
Another thing that makes Azure Functions special is that you can choose to pay only for functions that run, without having to keep compute instances running all month. This is also called serverless because it requires only that you to create your application and not deal with any servers or even scaling of servers.
You can write Azure Functions in C#, F#, Node.js, Java, PHP, and a growing list of languages.
An example of an application that uses Functions is one that activates a function every time a new image file is uploaded to Azure Blob Storage. The function would then resize the image and write it to another Blob Storage account. The function signature for this example would look like this (in C# script):
public static void Run(Stream myBlob, string name, TraceWriter log, BlockBlob outputBlob) { }
Data from the Blob that triggered the function is passed into the function as the myBlob parameter, which includes the Blob URL. You can use outputBlob output binding parameter to specify the Blob to which to write the result. There's no need to write the plumbing for connecting to Blob Storage, you just configure it.
You can orchestrate business logic with Logic Apps, automating a business process or integrating with software as a service (SaaS) applications. Just like in Azure Functions, Logic Apps can be activated by an outside source; for instance, a new message on an Azure Storage Queue. You weave together API calls to connectors to create a (possibly complex) workflow that can involve resources in the cloud and on-premises. Logic Apps has many available connectors to APIs, such as one for connecting to Azure SQL Databases, to SalesForce, to SAP, and so on. You can also expose your own APIs or Azure Functions as connectors to use in a Logic App, making it possible for you to easily perform actions against external systems in your workflow or have your Logic App be activated by one of them.
Just like Azure Functions, Logic Apps are serverless, are scaled automatically, and you pay for them only when it runs.
Here's an example of a workflow in Logic Apps:
Alternatively, you can host your applications in one of the core service offerings in Azure: Azure App Service. Azure App Service is a collection of hosting and orchestrating services that share features and capabilities. For instance, all App Services have the capability to secure an application using Azure Active Directory and can use custom domains.
Azure App Service comprises the following:
You can write your Mobile App backend in .NET or Node.js.
Azure App Service is one of the key services in Azure that you can use to host your applications. Each of these services bring unique capabilities to the table, but they all share some common features:
Azure App Service runs on App Service Plans, which are abstractions from VMs. One or more VMs run your Azure App Service, but you don't need to know which ones because Azure takes care of them. You can, however, scale the resources that run your Azure App Service. You can either choose a higher pricing tier (ranging from free to premium) or increase the number of application instances that are running. You can even have Azure App Service automatically scale the number of instances for you, based on a schedule or metrics like CPU, memory, or HTTP queue length.
This is a very useful feature of Azure App Service. You can deploy a new version of your application to a deployment slot, where you can then test whether it works as expected, and then move it into your production slot. You can even use Azure's Testing in Production feature to route a percentage of traffic from your production app to a deployment slot. For instance, you could shunt 10 percent of your users to the new version of your app in the deployment slot to see whether the new features are functioning as expected and whether users are actually using them.
After you are satisfied with how the new version of your app is performing in the deployment slot, you can carry out a swap, which exchanges the app in the deployment slot with that in your production slot. You can also swap from a development slot to a staging slot, and then to the production slot, as illustrated in Figure 2-1. Before doing this, the swap operation verifies that the new version of your website is warmed up and ready to go. When this has been confirmed, the swap operation switches the slots, and your users now see the new version of the app, with no downtime. If you want, you can also swap back, reverting the deployment of the new version.
Figure 2-1: Swapping a deployment slot
You use deployment slots within an environment like Development, Test, or Production. You don't use deployment slots as environments, because they all reside in the same App Service Plan, and you want those to be separated for security, scaling, billing, and performance.
You can swap deployment slots manually, through the Azure command-line interface (CLI) and through the Azure Management API. This allows tools like Visual Studio Team Services to perform swap operations during a release.
A deployment slot is another element of Azure App Service (like a Web App) that runs in the same Azure App Service Plan, next to your original Azure App Service. Because deployments slots run in the same Azure App Service Plan as your original Azure App Service, they don't cost anything extra to use.
To publish your application to App Services, you can use external services such as Visual Studio Team Services, Jenkins, or Octopus Deploy. You also can use the Continuous Delivery (CD) feature in App Services. This makes it possible for you to create a build-test-release pipeline right in the App Service. The process does the following:
You can connect external resources such as data stores to your App Services. These resources do not need to be located in Azure; they can be anywhere, such as on-premises, in your own datacenter. You can connect to services on-premises through many mechanisms, depending on your requirements. You can use Azure Hybrid Connections, Azure Virtual Networks, and Azure ExpressRoute to connect to on-premises resources.
When you spin up an app in Azure App Service, it exposes a URL—for example, https://myazurewebsite.azurewebsites.net. Most likely, you will want to use your own custom domain, which you can do by mapping that domain name to App Services. Here's how to do that.
Additionally, you can ensure that your application is served over HTTPS by using a Secure Sockets Layer (SSL) certificate. You can bring your own certificate or buy one directly from the Azure portal. When you buy an SSL certificate from the Azure portal, you buy an Azure App Service certificate, which you can configure to be used by your custom domain bindings.
In a multitier web application, you often have a database or services that are used by your app in Web App. Ideally, you want these services to be exposed only to the app and not to the internet. Of course, the app itself is often internet-facing given that it provides the entry point for your users.
To isolate these support services from the internet, you can use an Azure Virtual Network. This service wraps your support services and connects them to your app in Web App in such as a way that the support services are exposed only to the app, not to the internet. This article describes this service in more detail and shows you how to use it.
Sometimes, you might want even more control. Maybe you want your app to be wrapped in a Virtual
Network so that you can control access to it. Perhaps you want it to be called by another app in
Web App and have it be a part of your backend. For this scenario, you can use an Azure App Service Environment. This affords you a very high scale and gives you control over isolation and network access. Note, though, that App Service Environment is available for App Services in the premium pricing tiers only.
What to use when?
Even though App Service, Functions, and Logic Apps often works hand in hand, each is designed with specific application needs in mind.
Table 2-1 briefly outlines the purpose for the category of needs that you might have. Table 2-1: Which App Service should you use when
Category | Purpose | Azure App Service type |
Host applications | Host web applications and APIs | Web App and/or Web App for Containers from App Service |
Host backend for mobile apps | Mobile App from App Service | |
Orchestrate processes | Orchestrate a step in a process | Functions |
Orchestrate an entire process | Logic Apps |
After your application is up and running in Azure, you want it to be as performant as it can be. Azure provides a range of services that can help you with that.
One of the Azure services that can help you to make your application faster is Azure Content Delivery Network. You upload your static files—videos, images, JavaScript, CSS, and even static HTML files— to a data store such as Azure Blob Storage and then couple Azure Content Delivery Network to that. Content Delivery Network will then take those static files and replicate them to hundreds of Points-ofPresence (PoP) all over the world. All you need to do in your app is to change the reference to the static files to a different URL. For example, where that reference previously might have been ~/images/image.png, it would now be https://example.azureedge.com/image.png. This is very easy to do and improves the performance of your application in the following ways:
You can benefit from Content Delivery Network in web applications but also in mobile and desktop applications.
An example of using Content Delivery Network is to serve videos for a mobile app. The videos can be large, and you don't want to store them on the mobile device (nor do your users!). Using Content Delivery Network, they are served from the PoP, which also improves performance, because it is close to the user.
Every modern application works with data. When you retrieve data from a data store like a database, this typically involves scanning multiple tables or documents in some distant server, weaving the results together, and then sending the result to the requesting device. This, of course, takes time and can frustrate and annoy your users.
To eliminate some of these "roundtrips," you can cache data that doesn't change often. This way, instead of querying the database every time, you could retrieve some of the data from a cache, like Azure Redis Cache. The benefit of the cache is that it stores data in a simple format such as key–value. You don't need to run a complex query to get this data, you just need to know the key to retrieve the value. This can improve the performance of your application dramatically. Here's how this workflow operates:
Azure provides Cache-as-a-Service with Redis Cache. This is based on the open-source Redis project, and is now backed by Microsoft engineers and SLAs. It is highly performant and has advanced options like clustering and geo-replication.
Many modern applications have users all over the world. Providing a performant experience for everyone is challenging to say the least. The most obvious problem you need to deal with is latency. Latency is the time it takes for a signal or a request to travel to a user. The further away users are from your application, the more latency they experience.
Azure Traffic Manager scales across regions which helps to reduce latency and to provide users a performant experience, regardless of where they are. Traffic Manager is an intelligent routing mechanism that you put in front of, for instance, your Web App applications, all over the world. Web App acts as endpoints, which Azure Traffic Manager monitors for health and performance. As Figure 2-2 demonstrates, when a user accesses your application, Traffic Manager routes her to the Web App application that is most performant in her proximity.
Including Traffic Manager in your architecture is a great way to improve the performance of your application.
Figure 2-2: Azure Traffic Manager directs traffic to the most geographic performant endpoint
Data is a very important aspect of any modern application, and it comes in all shapes and sizes. Azure provides many types of data stores that can help you to maintain and retrieve data in any scenario. Table 2-2 presents the storage options available in Azure.
Table 2-2: Storage options in Azure
SQL Databases | MySQL | PostgreSQL | Cosmos DB | Blob | Table | Queue | File | Disk | Data Lake Store | SQL Data Warehouse | |
Relational data | X | X |
|
|
|
|
|
|
|
|
|
Object-relational data |
|
| X |
|
|
|
|
|
|
|
|
Unstructured data |
|
|
| X | X |
|
|
|
|
|
|
Semi-structured data |
|
|
|
|
| X |
|
|
|
|
|
Queue messages |
|
|
|
|
|
| X |
|
|
|
|
Files on disk |
|
|
|
|
|
|
| X |
|
|
|
High-performance files on disk |
|
|
|
|
|
|
|
| X |
|
|
Store large data |
|
|
|
| X |
|
| X | X | X | X |
Store small data | X | X | X | X |
| X | X | X | X |
|
|
Geographic data replication | X |
|
| X |
|
|
|
|
|
|
|
Let's take a closer look at each storage option.
If you want to use tables with columns and rows to store data, Azure SQL Database is a great choice.
It is a relational database system that is similar to on-premises Microsoft SQL Server. Because SQL Database runs in the cloud, it is fully managed, performant, scalable, automatically backed up, and has many advanced featured.
You can use SQL Database with your favorite tools, including SQL Server Management Studio and the Entity Framework.
Here are some of its more advanced features:
Databases in SQL Database are extremely reliable and robust and offer an Service-Level Agreement (SLA) that guarantees 99.99 percent uptime.
MySQL is an open-source relational database system that is used by millions of applications, like
WordPress, Joomla, and Drupal. Now, MySQL is available as a managed database service in the Azure Database for MySQL service. This means that you can get up and running quickly, without the need to set up or maintain servers. Azure does it all for you. You get security and scalability right out of the box. Also, the Database for MySQL service enjoys the same reliability as that of SQL Database, providing an industry leading 99.99 percent uptime SLA.
Just as with SQL Database and Azure Database for PostgreSQL, incremental backups are made every five minutes, and full backups are performed every hour, which you can use to recover your data to an earlier state as far back as 35 days.
Based on the popular PostgreSQL database technology, Azure Database for PostgreSQL provides an object-relational database service. This is slightly different to relational database services in that object-relational databases can store more complex data types, such as nested data types, and are therefore more closely aligned to the object-oriented programming languages that we use in our applications.
Database for PostgreSQL is a managed service that has the same characteristics as Database for MySQL. You can scale it up and down, it is highly available (99.99 percent SLA), and it is automatically backed up.
Azure Cosmos DB is the new version and rebranding of DocumentDB—and more. Cosmos DB is a new kind of database that is truly made for the cloud. Here are some of its key features:
In addition to all of these features, Cosmos DB offers different APIs with which you can store and retrieve data, including SQL, JavaScript, Gremlin, MongoDB, and Azure Table Storage. Different APIs handle data in different ways. You can use documents as data as well as unstructured tables, graphs, blobs, and so on. You use the API that fits your needs, and Cosmos DB takes care of the rest. You benefit from cloud-grade performance, scalability, and reliability, and still use the programming model to which you're accustomed.
Another option you have for storing data is Azure Storage. This is one of the oldest and most reliable, performant services in Azure. Azure Storage offers five types of storage that all benefit from the following shared features:
The four Azure Storage types are Blob, Queue, File, and Disk (Figure 2-3).
Figure 2-3: Azure Storage services overview
You can use Azure Blob Storage to store large unstructured data—literally, blobs of data. This can be video, image, audio, or text, or even virtual hard drive (VHD) files for VMs.
There are two types of Blobs: Page and Block Blobs. Page Blobs are optimized for random read and write operations. These are perfect for storing a VHD. Block Blobs are optimized for efficiently uploading large amounts of data. These are perfect for storing large video files that don't change often.
Azure Queue Storage is an unusual type of storage in that it is used to store small messages of data, but its main purpose is to serve as a queue. You put messages on the queue and other processes pick it up. This pattern decouples the message sender from the message processor and results in performance and reliability benefits. Azure Queue Storage is based on the Microsoft Message Queueing that you can find in previous versions of Windows.
You can use Azure File Storage as a drive from which to share files. Its uses the Server Message Block (SMB) protocol, which means that you can use it with Windows and Linux, and you can access it from the cloud or from on-premises systems. Like the other Azure Storage types, File Storage is scalable and inexpensive.
Azure Disk Storage is similar to File Storage, but is specifically meant for high I/O performance. It is perfect for use as a drive in a VM that needs high performance, like a VM that runs SQL Server. Note, though, that Disk Storage is available only in the premium pricing tier of Azure Storage.
The previous data stores were meant for regular application use or for use with VMs. Azure Data Lake Store is as storage for big data applications. You use it to store large amounts of data in its native format—structured, unstructured, or anything in between. The point of the Data Lake Store is to hold your raw data so that you can analyze it or transform and move it. Following are the main characteristics of Azure Data Lake:
This is a very different approach from the traditional data warehouse, in which you define data schemas upfront.
For instance, you could use a Data Lake Store to store all of the data that you get from your Internet of Things (IoT) devices that are collecting temperature data. You can leave the data in the store and then filter through it and create a view of the data per hour, or per week. Storing the data in Data Lake Store is quite inexpensive, so you can keep years of data there at a very low cost.
You use Azure SQL Data Warehouse when you need a traditional data warehousing solution that is completely managed, scalable in size, and performant and secure. You store data in predefined schemas and query it by using the familiar SQL Server SQL dialect.
Because SQL Data Warehouse runs in Azure, you can use advanced features like automatic threat detection that uses machine learning to understand the patterns of your workload and serve as an alarm system to alert you of a potential breach.
An example of using SQL Data Warehouse is when you know which reports you want to show to users and know what the data schema for these reports is. You can then create schemas in SQL Data Warehouse and populate it with data so that users can navigate through the data.