Azure is a powerful platform that offers a multitude of services and capabilities for organizations of any size moving to a cloud strategy. Whether you are a start-up needing only the base infrastructure for running your company's website, or you are a multinational operating all over the world, any kind of organization today can start deploying and migrating workloads to Azure. The first step in taking advantage of the many capabilities offered by Azure is careful planning. It might be tempting to just dive in and go ahead with deploying Azure resources. However, it should be emphasized that building a cloud environment can require a similar level of planning and detail as building your own datacenter services!

This chapter is all about providing you with a clear overview of Azure's capabilities, its benefits, and how to get started in the correct way. It also touches on how to migrate existing workloads to the cloud and cover the tools that Azure provides to streamline and smoothen this process.

Next, this chapter introduces you to business-related questions where the cloud can help in innovation and digital transformation, as well as how to handle identity and security in the cloud. Last, it covers IT infrastructure-related questions on how to build your enterprise-ready networking, how to migrate file services, and what tools are available in Azure for monitoring and day-to-day operations.

Starting from the assessment phase, where you will receive guidance on what your organization's cloud readiness looks like, this chapter, and indeed the whole book, will help you understand the core strategy for app modernization with Azure.

Once you decide to start deploying and using resources in Azure, we will examine best practices around migration planning, migration tooling, and what processes Microsoft makes available for you to make this process as smooth as possible.

Aside from workload migration, you need an understanding of deploying and running Azure infrastructure services. Think of resources such as Azure networking, storage, and virtual machines, and how to manage these. Don't forget that Azure allows you to do more than just run your virtual datacenter in the cloud. More and more organizations are looking at public cloud solutions for hosting Platform as a Service-based workloads. This means you still run the business applications, but you are not deploying them on virtual machines anymore, and you are also not managing most of the infrastructure, such as networking and storage. Besides running infrastructure and platform services, you might also think of migrating your workloads to serverless and microservices solutions using containers. Having this flexibility regarding the environment you use in the public cloud, whether traditional infrastructure services, platform services, or containerized workloads, is really one of the core benefits of the cloud and a chief way in which Azure's technical innovation can support your business needs.

Furthermore, you must think about your organizational governance and compliance requirements. Even in your own datacenter, you don't just want anybody walking in and deploying new hardware, deploying new servers, expanding storage, and so on. The mindset around governance, security, and control remains, even if you start using cloud services. The good news is that Azure comes with an extensive list of governance and compliance capabilities, several even as a core part of the underlying platform. Others are offered as flexible, configurable services where you can take control.

Whereas the first few paragraphs in this introduction section mentioned the public cloud as an overall strategy for running your IT workloads, know that from here on we shift to Azure as Microsoft's public cloud solution. Before tackling more technical questions and aspects of what it takes to migrate and deploy your applications to Azure, let's talk about some scenarios where Azure can be of help in business innovation.

While cloud computing environments such as Azure have been around for 10 years now, the tipping point for cloud adoption by enterprises was seen around 2016, where for the first time an IDG survey found that over half of the IT environments of surveyed businesses were hosted in the cloud¹.

The "first generation" of cloud adoption was characterized primarily by the deployment of virtual datacenters. In this first generation, organizations deployed new or migrated existing virtual machine workloads into Azure for a variety of reasons: some migrated to the public cloud to save on datacenter-running costs, while others wanted to take advantage of the easier and faster method for the deployment of infrastructure. Other organizations looked to Azure to streamline their business processes, to use it as a test setup, or to use the cloud as an affordable disaster recovery solution. For others, the huge potential for performance and scale, as well as flexibility (especially during peak usage), were the core reasons for adopting Azure.

The "second generation" of the public cloud arrived when rather than purely seeing value in running and managing virtual machines, some organizations saw benefit and innovation in moving to platform services. This mainly removes the focus and dependency on virtual machines, networking, and storage, and switches to a new approach with the core focus being on the application itself. Since platform services don't require much infrastructure, they are easier to manage. There is also less time spent patching or maintaining servers, which typically results in the improved uptime of your applications as well.

A "third generation" is currently in its early stages, where organizations are adopting serverless and microservices, as well as using native cloud services to build cognitive solutions and artificial intelligence solutions. Azure makes it easy to deploy these kinds of back-end services, where less and less knowledge is needed to build the underlying infrastructure. For most of these services, there is not much, sometimes even nothing, to manage on the infrastructure side.

Azure, at its heart, is a public cloud platform, but there are a variety of different cloud models available in the industry today. Let's run through the main ones.

At a high level, many organizations are looking into deploying or embracing one (or more) of the following cloud models.

Public cloud

This is the typical cloud platform offered by a service provider. Such service providers include Azure, Amazon Web Services (AWS), Google Cloud Platform (GCP), Rackspace, and Digital Ocean. In simple terms, the datacenter is managed by the vendor, and you consume the hosting part as a service.

Also, there is no dependency or integration with your existing on-premises datacenter. This is typically used by start-ups, Small-Medium Business (SMB) customers, or larger enterprises who want to build out a standalone environment outside of what they are running on-premises.

Hybrid cloud

In a hybrid cloud model, you are building an integration between your existing on-premises datacenter(s) and a public cloud environment. Most often, this is because you want to expand your datacenter capabilities, or you do not wish to perform a full migration to a public cloud-only model. Building a hybrid cloud typically starts with the physical network integration (in Azure offered by ExpressRoute or a site-to-site VPN), followed by deploying Infrastructure as a Service or Platform as a Service. Another aspect of the hybrid cloud is identity; Azure offers you Azure Active Directory as the identity solution. For hybrids, organizations synchronize (all or select) on-premises users and group objects from Active Directory domains to a single Azure Active Directory tenant. This allows for optimization in user and security management, offering users an easy but highly secure authentication procedure for cloud-running workloads.

Multi-cloud

More and more (enterprise) customers are looking at or currently using a multi-cloud strategy. Multi-cloud means using several public or hybrid clouds together. The benefit is using what is available. Imagine your business application relies on a service that is not available in your public cloud of choice, but might already be available in Azure. As long as you can integrate both worlds together in all aspects, such as security, supportability, skilled employees, and so on, there is no reason for not going in that direction. Looking at cost benefits could be another driver. Instead of running all workloads with the same public cloud vendor, it might be cost-effective to split workloads between different cloud vendors. Lastly, embracing things such as DevOps and Infrastructure as Code will also help you in adopting a multi-cloud strategy. Tools such as Jenkins, Terraform, Ansible, and several others provide REST APIs that can communicate with different cloud back ends. As such, your IT teams don't have to learn different cloud-specific templates, but rather can focus on the capabilities of the tooling instead of focusing on the cloud capabilities as such. At the same time, it should be mentioned a multi-cloud strategy also comes with several challenges. Supportability, mixed skillset requirements of your IT staff, and overall complexity because of the need to manage different environments are probably the most critical concerns to warn you about.

Now you have a better understanding of the different cloud models, let's focus some more on public cloud architectures.

Infrastructure as a Service (IaaS)

Part of this first chapter is dedicated to migrating and running your business applications in an Infrastructure as a Service (IaaS) model, using similar concepts to those related to your on-premises datacenter, with virtual networking, virtual storage, and virtual machines as the main architectural building blocks.

However, that is not the only way that you can run your applications in Azure. As a segue to other chapters in this book, let me briefly describe where Azure can help in business innovation, or the digital transformation of your workloads, using other architectures besides virtual machines.

Platform as a Service options (App Service, SQL Database, Azure Container Instances, and Azure Kubernetes Service)

Platform as a Service (PaaS) refers to running your workloads in Azure without deploying virtual machines. You could, for example, run a web application in Azure App Service without deploying the underlying virtual machine first. This brings efficiency and optimization, since you have less operational management to worry about. Alternatively, you could use a service such as Azure SQL Database or Cosmos DB, allowing you to run the exact same flavor of your database solution, but again without having to take any virtual machines into consideration. As mentioned earlier, having this flexibility of architecture while also not needing to deploy and manage your own infrastructure dependencies anymore provides room for innovation. In addition, new capabilities are easier to adopt in a PaaS model than they are in an IaaS model, as the deployment of the service is much faster, thanks to the lack of operating system dependency and development language support, to name just a couple of reasons. PaaS can also be cost-effective, as most PaaS services are cheaper than their IaaS alternatives (for example, using Azure web apps is cheaper than deploying an Azure web virtual machine with the same performance characteristics).

Serverless (Functions, Cosmos DB, Logic Apps, and Cognitive Services)

Outside of these two standard concepts of IaaS and PaaS, you also have serverless and microservices. Looking at Azure serverless services, one option is to use Azure Functions, a serverless compute service that enables you to run code on demand without having to explicitly provision or manage infrastructure. You can use Azure Functions to run a script or piece of code in response to a variety of events. Another serverless service offered by Azure is Azure Logic Apps, a business workflow engine that provides connectors to more than 200 business applications, such as Dropbox, OneDrive, SAP, DocuSign, and Adobe. With Logic Apps, you can build a step-by-step workflow with logical intelligence to replace your current chain of complex, (mostly) virtual machine-based workloads.

Microservices is an application development approach in which a more complex application architecture, known as a monolithic application, gets divided into several smaller components. Each component has a single purpose, such as managing product ordering, order payment, or shipment follow-up, in a broader e-commerce platform solution. Microservices are a very popular strategy for migrating (legacy) applications to the public cloud. Microservices are also known as containers or containerized applications. At present, Docker (http://www.docker.com) is the standard container format for microservices and is fully supported by Azure.

Azure allows you to bring your containers into Azure and run them with Azure Container Instances (ACI) as a standalone container workload. Or, if you are looking for more advanced orchestration capabilities, you can also deploy Azure Kubernetes Service (AKS), providing a Kubernetes clustered environment as a service. Besides the advantage of legacy app support, containers are also very interesting because they are lightweight, running one specific task, and can easily be moved around across different environments. The same container image can run on a developer's Mac, be pushed into an Azure container registry, run on top of Azure Web App for Containers, run as an Azure container instance, or run in your own datacenter on top of RedHat OpenShift infrastructure or some other public cloud infrastructure. This is the main reason why containers are so popular today.

How can these different cloud architectures lead to business innovation? For a long time, businesses were struggling in optimizing IT and streamlining IT processes, searching for ways to align operations and developer teams—not always with huge success. However, by shifting from infrastructure (IaaS) to platform services or serverless (PaaS/SaaS), a huge part of this dependency is removed. The flexibility of using the public cloud and the different operational models it provides will definitely help in business innovation.

Outside of the technical IT-side of optimization, this could also lead to freeing up more resources and saving money that the business can then invest in new innovation. Let's look at some more reasons for moving to the cloud.

Finding the right reasons for moving workloads to the cloud or deploying new workloads directly in the cloud is a vital part of the success of your migration projects. When you look at it through your system administrator's or developer's technical glasses, you will most probably find several good reasons for migrating. Systems can be deployed faster, operations and management become easier, and the cloud gives you scale, high availability, and cost efficiency. But maybe your upper management has a different opinion about it, as they just approved an extension of your physical datacenter. Or, maybe the industry you are in has several compliance regulations to follow, making the public cloud a challenging platform to approve.

Why move to Azure?

Let's try and be as open as possible about moving to the cloud, examining both the benefits and the risks. Know that these are mainly based on experience gained from working as an Azure cloud architect and trainer for several years. Also, keep in mind that what is a benefit for one organization might be a concern for another.

Cloud benefits

There are several common business challenges that make a move to the cloud worthwhile. Some typical scenarios where the cloud is beneficial are listed here:

• You are asked to reduce operational costs.
• Your applications are facing traffic increases and your in-house systems cannot scale to meet the demand.
• Your business requires faster deployments of systems and applications, in different regions in the world, to serve your customers.
• You have security regulations to follow that are hard to implement in your on-premises datacenters or are expensive.
• Your storage capacity is growing exponentially and it is hard to catch up, both technically and cost-wise.
• Your systems are becoming outdated, running no-longer-supported legacy operating systems and applications.
• The well-known CAPEX to OPEX (capital expenditure and operational expenditure): your company wants to shift to a consumption-based, pay-per-use model.
• You are a start-up, not having the financial means or certainty to deploy and maintain your own datacenter(s).

Potential challenges of cloud migration

While you might recognize several of the aforementioned examples in your own organization, thus giving you some good motivation to explore migration to the cloud, know that cloud migrations also come with potential challenges. While these are less and less seen as blocking factors, it is worthwhile to mention some of them:

• Your business is in a specific sector and you are not allowed to store data in the public cloud because of sensitivity or other compliance regulations.
• Your workloads suffer from latency when the datacenter is not close to where your users are.
• Some of your workloads are legacy; they cannot run in a cloud environment.
• You just made a huge investment in your own datacenter.
• You don't want vendor lock-in, and a multi-cloud strategy seems to have too much overhead.

Mapping business justifications and outcomes

If the preceding cloud benefits and potential challenges that come with cloud migrations have already got you thinking about cloud strategies, let's quickly run through a few other topics that you should keep in mind.

The cloud is not the cheapest solution for everybody

Switching or migrating from your own datacenter to the public cloud is a cost-effective solution, but that doesn't mean it is cheaper for everyone. Business analytics calculations might run faster because of cloud scale, which brings in business benefits, but the running costs might be as expensive (or even more expensive) than the costs associated with buying and running a similar workload on-premises. But it would take much longer before that infrastructure would be able to produce similar results.

To get a good view on the consumption costs of Azure resources, always start from the Azure Pricing page: https://azure.microsoft.com/en-us/pricing/.

No public cloud guarantees 100% high availability

This is one of my favorite conference topics to present on. Obviously, a public cloud platform is built with high availability in mind, but you need to be aware that there will not be availability 100% of the time. Looking at IaaS, you as the customer need to architect your high availability by using Azure Availability Sets or Availability Zones, for example. Moving to PaaS could be a solution for this, as it makes it more Microsoft's responsibility to make sure that your app services, data solutions, and so on are running on top of a high-availability platform. The good news is that Azure services have an overall service level agreement (SLA) of 99.9% for most services, with some services such as Azure SQL Database having a 99.99% SLA capability, or a 99.999% for Azure Cosmos DB.

All information related to Azure SLAs can be found at this link: https://azure.microsoft.com/en-us/support/legal/sla/summary/.

The lift and shift migration of virtual machines may not always give the best benefits

While a lift and shift migration of virtual machines to Azure is certainly a good step toward cloud migration, it is not always the most efficient one, from both a technical and also cost perspective. Maybe your systems are getting older, running legacy applications that might not run "better" in a cloud virtual machine. Or, maybe your on-premises systems were not correctly sized for the service they offer. Migrating such a workload to the cloud without changing the system characteristics might result in a huge cost increase for your Azure consumption.

Resources that can help in identifying your Azure Return on Investment (ROI) and Total Cost of Ownership (TCO) can be found here: https://bit.ly/2R4wGc6.

Containers are not always the best solution for cloud migration

We talked about containers a bit in the introduction. Containers are amazing, they truly are! Yet, they are not always the best platform to migrate your applications to, and they certainly shouldn't be the only driver for your cloud migration. Embrace containers as part of your overall cloud strategy, but don't see them as the endgame of your migration to the cloud.

For additional information on running containers on Azure and what services are available, have a look at this link: https://bit.ly/2QFTf8h.

What you learned in this section

You need to be aware of what the cloud can and cannot do for your organization. Decide whether any of the preceding maxims are true for your organization and your specific reasoning for moving to a public cloud scenario.

As you are reading this book, I am sure that you are interested in learning more about the technical side of deploying and running your business applications in Azure. That is exactly what this book is all about.

Any deployment or migration starts with knowing what you have before you are able to know where you are going. This phase is known as the assessment phase, so it makes sense for us to spend time on this phase in the next section.

More than ever before, organizations are rethinking their datacenter strategy and heavily embracing and integrating the public cloud in their long-term IT strategy. Two key factors that are motivating this wave are cloud scalability and cutting down on capital investments. One of the starting points to make this public cloud migration successful is knowing what is supported in the public cloud from a workload perspective and knowing what your current IT landscape looks like. The better the match between these two, the easier your cloud migration will be.

Assessing your organization's cloud readiness

This first section is focused on assessing your on-premises datacenter(s) and determining what workloads, virtual machines, networking, storage, applications, and data solutions you have. You'll need to think about which ones you want to migrate to the public cloud and how to migrate them with the shortest downtime possible and lowest impact on the business. A successful migration relies on using tools to make the job easier. We'll look at several tools available from Microsoft that help in this process. We'll also go through identifying and estimating the cost aspect of the migration, and more specifically, what the running consumption cost could look like once the workload is running in Azure.

Assessment tooling

Helping its customers to perform an easy, or at least less complex, migration to Azure is one of Microsoft's key objectives. The easier (meaning less disruptive for the business) a migration is, the more success the cloud will see. Besides the excellent documentation on all things Azure at https://bit.ly/30kWG7B, you should have a look at the Azure Migration Center: https://bit.ly/384cHRN.

The Azure Migration Center breaks down the phases that you will need to run through in migrating to the cloud. The first of these is the assessment phase. This should always be the first phase of your broader migration project. Know what you have today to find out what you can run tomorrow.

Today, you can choose from the following free Microsoft assessment tools:

• Azure Migrate: Performs an assessment of virtual machine-based workloads
• Azure Data Migration Assistant: Runs an assessment for SQL Server databases, helping in migrating to Azure SQL virtual machines or Azure SQL databases
• Azure Database Migration Service: While not specifically an assessment tool, it helps in migrating from different data solutions on-premises to alternatives in Azure PaaS
• App Service Migration Assistant: Performs a scan of any application endpoint, supporting multiple languages and platforms (such as Java, .NET, Node.js, and PHP)

There is some overlap between assessment and migration for most of these tools, but let me spend some time on each, highlighting the core benefits and reasoning for checking them out.

Azure Migrate

Azure Migrate is the primary tool for running your workload migrations to Azure. It provides a full integration from assessment to migration and follow-up. The key strength of Azure Migrate is that it helps organizations in getting a detailed view on what their existing datacenter virtual machines look like from a characteristics perspective (CPU, memory, and disks), what operating system they are running, and most importantly, if they are supported for migration to Azure. Supporting both VMware and Hyper-V and up to 35,000 source machines (10,000 for Hyper-V environments), it is a viable tool for organizations of all sizes that want to validate migrating their virtual machines to Azure using a lift and shift approach.

Once Azure Migrate has a good view on the source virtual machine, it analyzes the gathered information and maps it with Azure. First of all, it identifies whether the virtual machine is compatible with the Azure virtual machine requirements (whether the operating system is supported, and so on), and it recommends an Azure virtual machine sizing. Lastly, it provides a monthly cost estimate for running that virtual machine as-is in Azure, presented in clear and easy-to-understand dashboard views (Figure 1).

Figure 1: Azure Migrate – Assessment details

Another interesting feature is dependency visualization, where Azure Migrate will identify an application or other dependencies between virtual machines to smooth out the actual migration. Think of an application server having connectivity with a database server. It wouldn't help your migration if the application server was migrated over but the database server was not. Keep in mind that dependency visualization requires the installation of an agent, though (which might not be accepted by all organizations, especially when the decision to actually perform the migration to Azure has not been 100% confirmed).

VMware infrastructure assessment

In the case of an existing VMware infrastructure, where having vCenter is a dependency, you should deploy an Azure Migrate appliance that runs next to the existing virtual machines on VMware. To speed up this deployment, there is an OVA template available for download (around 15 GB), allowing you to deploy as an OVF template directly from within your VMware vSphere client and easing the installation of this appliance. This appliance performs a discovery, which can be scoped at vCenter datacenters, clusters, specific hosts, or select virtual machines. Once the discovery is complete, you will manage most of the assessment output back in the Azure Migrate project in the Azure portal, based on the metadata information sent from the appliance back to Azure Migrate.

Hyper-V infrastructure assessment

If you are using Hyper-V in your datacenter today, you can rely on Azure Migrate for the assessment and discovery. You start from downloading a Hyper-V VHD file (around 10 GB) and then configure it as a new Hyper-V virtual machine. Similar to the VMware scenario, this discovery appliance is responsible for gathering all necessary information from your on-premises infrastructure for the machines you define. It allows for a selective assessment based on Hyper-V hosts or individual virtual machines.

Physical and other cloud infrastructure assessment

With the latest version of Azure Migrate, Migrate not only assists in Hyper-V-based assessment but now also supports physical machines and other cloud providers (such as AWS and GCP) as a source. Similar to VMware or Hyper-V, the magic part is the replication appliance, starting from a Windows Server 2016 instance that you need to prepare.

Besides using the native Microsoft tools, know that the new Azure Migrate works directly with several vendors, offering third-party assessment and migration tools for different workloads. These are sometimes generic and sometimes support a single solution, but they are nicely integrated into the same Azure Migrate service today.

More information on what partners and tools are available can be found at the Azure Migration Center home page:

https://azure.microsoft.com/en-us/pricing/details/azure-migrate/

Azure Data Migration Assistant

If you have on-premises SQL Server-based data solutions running on physical or virtual servers, you can migrate them using the previously described approach, assuming the virtual machines are compatible with Azure virtual machine requirements. Though maybe you don't need to perform a lift and shift migration to Azure virtual machines, as your databases might qualify for running as Azure SQL instances. To find out, the easiest approach is to run an assessment using the Azure Data Migration Assistant (DMA) (Figure 2).

The assessment process could not be easier:

1. You run the tool in your on-premises environment, directly on the SQL Server machine you want to assess, or on a remote machine (for example, the SQL database administrator's workstation).
2. Once the tool is installed, you go through an assessment wizard, where you can specify the source (SQL Server) and target (Azure SQL Database).
3. After clicking on the Start Assessment option, the process begins analyzing your source database and usually completes doing so in minutes. The results are shown within the tool and can be exported as well. From an assessment perspective, it scans for two domains:
   • SQL Server feature parity: This is where you can review details about unsupported features and partially unsupported features, once your database runs in Azure SQL. One example I found out as a customer was the search index feature.
   • Compatibility issues: This is the second check that happens. If any issues should be detected, they will be listed here as a blocking factor for the migration:

Figure 2: DMA – Assessment

Azure Database Migration Service

If, outside of SQL Server data solutions, you are running other databases in your on-premises datacenter, know that Azure offers another tool to assist you in getting them migrated over to Azure as well. This tool allows for smooth migrations from several different database sources to Azure data solutions. Typical uses cases here are:

• Migrating from PostgreSQL to Azure Database for PostgreSQL
• Migrating from Oracle Database to Azure Database for PostgreSQL
• Migrating from MongoDB to Azure Cosmos DB
• Migrating from MySQL to Azure Database for MySQL

So, typically, migration from an infrastructure virtual machine architecture to Azure PaaS, offers easy-to-follow wizards to help you in this process (Figure 3).

Note that this tool allows for both offline and online migration scenarios:

Figure 3: Azure Database Migration Service

App Service Migration Assistant

The App Service Migration Assistant is an updated version of the former Movemetothecloud.net tool. As the name suggests, the core functionality of this free Microsoft tool is helping in migrating your (web) applications to Azure Web Apps.

Besides performing the actual application migration, the other important capability is performing an assessment prior to the actual migration. The assessment starts by connecting to a public endpoint, or connecting to an internal web server, which gets scanned for several details of web server technologies to identify any migration issues, such as:

• Port bindings (since Azure only supports 80/443 for port bindings)
• Protocols (HTTP and HTTPS)
• Certificates (checks whether the site uses certificates, and self-signed or public CA)
• Dependencies in the applicationhost.config file
• Application pools
• Authentication type
• Connection strings

From a web server platform and language perspective, it supports a lot more than Windows Server IIS/.NET-based applications, such as:

• Ruby
• Node.js
• Java
• PHP

The outcome of the assessment and inventory is presented in a detailed web form, which can be exported for documentation purposes (Figure 4):

Figure 4: Azure App Service Migration assessment

Section summary

This section provided an introduction and description of the Microsoft application migration framework, by positioning and describing several Microsoft tools available to assist in the assessment process.

In the next section, the topic of identity and access control will be explained, as another important aspect to take into consideration before/during performing a cloud migration to Azure.

Up until now, we have focused on the assessment and business justification side of your cloud migration projects, primarily from an application and data solutions perspective, but another important aspect to discuss is how you manage your identity and access control in the cloud. This is important for both end users and administrators.

Identity is the core component of all Azure cloud security: whenever any administrator wants to "do" something in the Azure platform, they need to authenticate and get authorization. No matter whether they are using the Azure portal, Azure command-line tools such as PowerShell or the Azure CLI, or using REST APIs. End users can also greatly benefit from Azure Active Directory. Solutions such as self-service password reset, Azure AD domain join for device management, conditional access, user risk, and many more will heavily optimize how users log on to cloud applications and how secure this log on is.

Azure Active Directory as a cloud identity solution

From an identity perspective, there is no way around Azure Active Directory. This cloud identity solution comes in different flavors:

• Azure Active Directory: The core identity component in Azure, offering cloud users, groups, applications, and service principal objects
• Azure Active Directory Domain Services: An emulated Active Directory service, offering Kerberos and NTLM, similar to your on-premises Active Directory domain controllers
• Azure Active Directory B2B: Business-to-business concept, whereby organizations can invite users from each other's Azure AD tenant
• Azure Active Directory B2C: Business-to-consumer concept, whereby organizations allow user authentication from social media identity providers (such as Facebook, Twitter, LinkedIn, and so on)

Besides the different flavors mentioned here, Azure Active Directory itself also comes in different editions:

Table 1: Azure Active Directory tiers

Just based on the rich feature set and advanced security features that come with it, any organization should consider Azure AD Premium P1 for most of their cloud-enabled users, extended with Azure AD Premium P2 for key users such as C-level management, administrators, security officers, and other key persons within the organization with high visibility.

Cloud authentication with Azure Active Directory

Most organizations already have an identity solution in place in their on-premises datacenter, often being Microsoft Active Directory. In this scenario, the recommended topology would be building out a hybrid identity architecture, starting from your Active Directory source environment. Azure AD Connect synchronizes the user and group objects (all or select ones based on filters you define). As such, a user account with the User Principal Name (UPN) peter@company.com from the on-premises Active Directory will authenticate with the same alias in Azure Active Directory.

However, there are three distinct authentication scenarios:

• Azure AD Password Hash Sync (PHS)
• Azure AD Federation using ADFS or third-party federation (ADFS)
• Azure AD Pass-through Authentication (PTA)

The easiest (and most recommended) approach is Azure AD PTA. In this scenario, your Active Directory objects are synchronized to Azure AD using AD Connect, including the domain's password hash. This allows users to log on to cloud apps using their Azure AD credentials, which are identical to the on-premises credentials.

Unfortunately, storing passwords (or the password hash) is a no-go for a lot of organizations, who want to keep control of the credentials from an on-premises perspective. In this scenario, you need to deploy a federation infrastructure, which can be Active Directory Federation Service (ADFS) or a non-Microsoft alternative (Okta is a popular one). While you still need to synchronize AD objects to Azure AD, the password is never stored in the cloud directory. Upon user authentication, Azure AD forwards the request to the ADFS infrastructure, which is typically running in the on-premises datacenter. ADFS sends the received credentials to Active Directory for validation. If these are accepted, the user can authenticate.

Whereas ADFS is the "typical" design to follow when deploying identity in a hybrid cloud model, it also comes with some drawbacks. ADFS servers run on-premises, which means there is a dependency on internet connectivity, as a highly available topology is needed to guarantee that users can always log on to cloud apps whenever needed. ADFS is also complex to manage, and your ADFS proxy server in the DMZ is public internet-facing all the time.

To accommodate the strengths and ease of use of password hash sync, together with the need to keep credentials management in the on-premises Active Directory, Microsoft came up with a third scenario, PTA. Again, you start by synchronizing users and groups with AD Connect. Next, instead of deploying a complex ADFS infrastructure, you deploy Passthrough Agents on your on-premises Active Directory Domain Controllers. These listen on port 443, but only to Azure AD services endpoints public IP addresses. Other requests will be denied. When a user logs on to Azure AD, the request gets passed on to the PTA agent, who sends along the credentials to the on-premises Active Directory, which is still responsible for validating the credentials.

Have a look at the following link for all details on Azure identity and access management documentation:

https://azure.microsoft.com/en-us/product-categories/identity/

Azure governance is a combination of different Azure services and capabilities, allowing for the management of all your Azure resources at scale and following control guidelines. Azure governance works across multiple subscriptions and across resource groups, and is based on a combination of Azure identity, Role-Based Access Control (RBAC), Azure policies, and management groups. You could extend the concept with Azure Resource Graph as well. Some customers also consider cost control as part of governance processes and best practices. If your organization has a Security Operations Center (SOC), this department will most probably take ownership of this process, or at least (should) be hugely involved in this.

Let me describe each of the different Azure services, allowing for governance.

Management groups

For a long time, an Azure subscription was considered the boundary of management and control. This allowed organizations to use multiple Azure subscriptions to "separate" resources from each other. Some organizations subscribed on a geographical level, some others used a dedicated subscription for a specific application workload, and others still separated based on dev/test and production.

This model changed recently, with the introduction of management groups (Figure 5). Where Azure Policy and Initiative were (and still are!) really great sources of governance control, they were linked to a single Azure subscription, which was hard to manage in larger Azure environments where admins wanted to replicate policy settings across multiple subscriptions. That's exactly what Azure management groups provide: a cross-subscription assignment of Azure Policy and Initiative.

Figure 5: Azure management groups

Identity and role-based access control

Again, identity is key in a public cloud platform like Azure. The examples we saw earlier should already make it clear, but there is yet another example I can share: Azure itself heavily relies on RBAC to identify who can do what in the platform.

This "who" can be a user or group from your Azure Active Directory, a user from another Azure Active Directory tenant, or a registered application or service principal.

RBAC in Azure offers more than 75 different roles to choose from, and if you cannot find the specific role mapping for the particular need of your organization, you can create your own custom roles from Azure PowerShell as well.

Azure Policy

Another source of control is available through Azure Policy. This is a true governance management and control mechanism in Azure. As an organization, you define Azure policies: JSON files in which you specify what Azure resource requirements you want to enforce before the deployment of Azure resources can succeed. For example, there is forcing the usage of certain Azure regions because of compliance regulations, or allowing only certain Azure virtual machine sizes in your subscription to keep costs in control, or perhaps you might have certain naming standards you want to enforce for Azure resources, optimizing your asset management and CMDB regulations. One last example of something that a lot of companies find useful is enforcing the use of tags. A tag is like a label that can be attached to a Resource Group or individual resources, for example, a cost center or business unit. It is mainly thanks to these tags that an Azure billing administrator can get a clear view of what an Azure resource is used for, or at least to which business unit or cost center this resource belongs.

Azure policies can be grouped together into so-called Azure policy initiatives. This helps in enforcing several policies at once. After the Azure policies and policy initiatives are defined, they need to be assigned to a scope. This scope can be an Azure subscription, an Azure resource group, or individual Azure resources.

Azure Blueprints

Another mechanism available in Azure today for helping in governance control is Blueprints. Azure Blueprints (Figure 6) allows cloud architects and IT teams to define a structure of reusable, repeatable instructions for deployment and configuration, in compliance with company standards, regulations, and requirements.

Relying on a combination of roles, controls, and infrastructure as code, Azure Blueprints orchestrates the full deployment life cycle of Azure resources.

Figure 6: Azure Blueprints

Blueprints are based on artifacts, which are a collection of settings, parameters, Azure infrastructure as code deployment templates, and policy templates.

Naming standards

Another critical aspect of your migration strategy to a public cloud such as Azure is having a good understanding of the naming standards. Everything in Azure is based on Azure resources. Several of these use dynamic names that you cannot change. Other services are deployed in a fixed namespace domain (azurecri.io for Azure Container Registry, blob.core.windows.net for Azure Storage Account blobs, azurefd.net for Azure Front Door, and so on).

Next, several Azure resources have requirements (and limitations) around the usage of certain characters, capitals, and/or numeric values and complex characters.

There is good documentation available on this exact subject:

https://bit.ly/2FyxKjh

Resource groups

Another item I want to touch on as part of the pre-migration information is resource groups. While it's not that hard to understand what they do—they are groups of Azure resources—there is a lot of confusion around them, specifically regarding how to organize them, or how to organize your resources into them.

As a starting point, it is really up to your organization. Microsoft is not enforcing what resources should go where and how you want to organize your resource groups (with some exceptions). Some organizations have a resource group per workload; others define Resource Groups based on resource types (a Network Resource Group, a Storage Resource Group, and so on). An example of this approach can be seen in the diagram in Figure 7. This could help in allocating RBAC, keeping the same layered structure as their on-premises datacenter. Other organizations use geographical datacenter locations as a guideline (West-EuropeRG, East-USRG, and so on).

And touching on the topic of Resource Groups and Azure resource locations, specifying the location is a hard requirement for any Azure resource, as most resources on the platform are region-specific. Complexity arises when you have a Resource Group in one location containing resources in a different location. While technically fine, this might cause interruptions when the Azure region that the Resource Group is in is not reachable anymore. The resources would remain (for instance, a virtual machine would still be running), but you wouldn't be able to make any changes to the virtual machine (as the information metadata cannot be written to the Resource Group).

Figure 7: Azure Resource Groups

It should be clear now that identity and control are important topics to tackle before starting the actual migration (or deployment) of your business workloads on Azure.

By aligning the cloud architects with business needs, granting the correct roles and permissions, optimizing cloud security by using Azure identity features such as Multi-Factor Authentication (MFA), conditional access, privileged identity management, and Azure identity protection, you can dramatically optimize your security in the cloud. In most situations, that immediately means that you will also optimize the security of your on-premises datacenters, so this is a true hybrid-cloud benefit.

Azure Resource Graph

While not specifically built as a governance service, Azure Resource Graph can definitely help in getting a better view of the Azure resources an organization has deployed. Resource Graph is a service in Azure designed to provide a fast and easy-to-manage way to explore all resources within a single subscription, or even across multiple subscriptions.

Azure Resource Graph allows you to run filtering queries, narrowing the results of what you are looking for.

While Azure Resource Manager also allows you to gather filtered Azure resources, this is starting from the resource providers individually. If you want to get a view of Azure virtual networks, you would "call" the Network Resource Provider. Then, you would connect to the Virtual Machine Resource Provider to get information about your virtual machines.

Azure Resource Graph does this differently, and in a way that allows you to gather information across all those resources, without touching on each and every resource provider individually.

Figure 8: Azure Resource Graph

A result of this by using the Azure portal is shown in Figure 8. Besides the Azure portal, Resource Graph can also be used from Azure PowerShell and the Azure CLI, using the powerful and fast KUSTO query language.

Cost control and Cost Management

One last item that perfectly fits into the topic of Azure governance is Cost Management. Microsoft recently acquired Cloudyn, a multi-cloud cost reporting tool. The Cloudyn service enables any organization to pull up detailed dashboards, exposing cost consumption for any Azure resource or group of resources, based on resource type, region, or tags attached to the Azure resources itself.

Microsoft has now completely integrated the Cloudyn experience into the Azure portal, under a specific service called Cost Management, providing you with reporting dashboards (see Figure 9); there are several options for you to choose from.

Figure 9: Azure Cost Management – cost analysis

Another recently released Cost Management feature is Cost Budgets. This is a soft setting, allowing you to define a ceiling of cost consumption for a certain Azure resource or resource group. Once the budget amount (or any percentage, such as 80%) is reached, Azure administrators can view a dashboard report of the results (see Figure 10) or receive an alert notification by email, for example.

Keep in mind that the budget feature is not stopping Azure consumption as such, and nor will the Azure resource be deleted, but it is at least a useful aid in cost governance.

Figure 10: Cost Budget

Section summary

In this section, we guided you through several Azure governance services and capabilities you can deploy in your Azure subscriptions. Starting from Management Groups, allowing you to scope policies to multiple subscriptions at once, you learned about Azure policies and Azure Blueprints. We also talked about Azure identity as a governance mechanism, providing RBAC. In the last part, we covered the new service, Cost Management, as another governance instrument.

You now have a good understanding of the foundational layers of your cloud migration. Let's take a look at some of the migration tools and processes Microsoft has available today to help smooth this operation.

After having performed the assessment(s) of your source environment and laid out the path toward a solid cloud environment that takes identity, compliance, and governance into account, you are here to take the next step: running your migrations. We already briefly touched on several of these, but mainly from the assessment capabilities perspective that comes with them. This section walks you through the actual migration approaches. Several approaches are possible, and the one you choose will depend on different factors.

Manual migrations

The first option that comes to mind is running a manual migration. Starting from your existing source workload, you build a similar environment in Azure and copy over the data. Let's take a look at some examples.

Migrating VHD disks

If your source environment is Hyper-V and there is enough downtime allowed for your application, you could consider performing a manual migration by copying VHD disks into Azure Storage. Azure supports both Gen1 and Gen2 Hyper-V machines nowadays, with the maximum size of the VHD disk being 1,023 GB.

If your source environment is VMware, although there's a bit more work, it shouldn't be a blocking factor to copy the VM over to Azure. Tools such as Microsoft Virtual Machine Converter can help you in transforming the VMDK file into a VHD file format.

If you want to just migrate a single VHD and run an Azure virtual machine out of it, you don't have to generalize the VHD image; you can instead configure it as a specialized disk. If, however, you want to use this source VHD as a template disk for multiple Azure VM deployments, you should generalize the disk first. This is done using sysprep from within the source VM itself.

Once the disk is ready to be copied, use the Add-azVHD cmdlet in PowerShell to upload the VHD to an Azure Storage account. Other options you have available include using AzCopy and using the free Azure Storage Explorer tool.

Next, define an image from this uploaded VHD by using the New-AzImageConfig and New-AzImage PowerShell cmdlets.

Finally, when you have your image available, you can continue with deploying a new Azure virtual machine based on this source image.

Detailed step-by-step guidance on how to achieve this is documented here:

https://bit.ly/35zF8FK

Migrating SQL databases using bacpac

If your source database solution is an SQL Server database, you might be familiar with SQL Server's built-in backup solution, storing your database in a BACPAC file. This is the perfect way to migrate your database to Azure SQL, if downtime is allowed.

After you deploy a new Azure SQL Database instance in Azure (Figure 11), copy the bacpac file to Azure Storage. Head over to the import database option within Azure SQL Database and you're done! That really is how easy a migration can be.

Figure 11: SQL Azure import from a bacpac file

Migrating websites to Azure Web Apps

The other common workload to migrate to Azure is a web application or a websites. Azure App Service's Web Apps supports both Windows web servers and Linux Apache web servers as underlying source environments, as well as a full list of development languages and frameworks (.NET, Java, Python, Node.js, Ruby, and more).

If you have your source code available, you could most probably push it directly into an Azure web app and run your site from Azure. Tools such as Visual Studio and Visual Studio Code provide this publish mechanism out of the box. If you have used the App Service Migration Assessment tool for an on-premises workload, know that you can also use the same tool to perform the actual web content migration step. Figure 12 shows you a screenshot of what such migration process looks like from within the tool itself.

Figure 12: App Service Migration Assistant

Azure Migration Center

We already described the new Azure Migration Center in terms of its support and guidance in performing source workload assessments. But obviously, it can also guide you through the actual migration of these systems. Thanks to the latest updates, only published July 2019, Azure Migration Center has become the main place to check out when you need to migrate application or data solution systems to Azure. Therefore, Azure Migration Center has now become a central hub for starting, executing, and tracking your migration projects, whether you want to migrate to Azure virtual machines, Azure data solutions, or Azure App Service.

Azure Data Box

By now, it should be clear you have a full set of options to migrate your workloads to Azure, no matter whether the target environment is IaaS or PaaS. The aforementioned scenarios most probably cover about 80-90% of the migration scenarios.

There is one last scenario I would like to touch on here, which is the migration of larger volumes of data (think in hundreds of terabytes or even petabytes). These larger volumes of data are not the best candidate for manual migration, nor will you migrate those storage environments into Azure virtual machines using Azure Site Recovery. The good news is that there is another, more flexible way to do this: Azure Data Box.

Azure Data Box allows for offline data migration, based on a physical device you introduce in your datacenter. You offload the data to this physical device, which gets securely transported to the closest Azure region, where the data gets copied into your Azure environment. All data in transit and at rest is AES encrypted for advanced security and compliance.

Depending on the data volume size, you can choose between any of the three models shown in Table 2:

Table 2: Azure Data Box models for offline large data volume migration

Besides these offline data migration solutions, the Azure Data Box offering was extended with two additional online data migration solutions, Azure Data Box Edge and Azure Data Box Gateway, shown in Table 3:

Table 3: Azure Data Box models for online data volume migration

Having discussed Azure Data Box, let's move on to talk about the deployment of Azure.

Deploying a greenfield Azure environment

Another migration strategy we should look at is deploying a greenfield environment in Azure, which means deploying a virtual datacenter from scratch. Instead of performing a lift and shift migration—as recommended in the previous scenarios—it could be beneficial to start with a totally new environment and only migrate the bare minimum (which would most probably be just data such as source code, file shares, and data solutions).

In order to make this approach a success, you must have a good understanding of how to architect and build such a greenfield environment, mapping it with your business requirements from a technical and non-technical perspective.

Obviously, the same is valid for the other migration scenarios described earlier.

For the remainder of this chapter, the assumption is that you will use IaaS, relying on the several virtual datacenter capabilities available in Azure.

As described earlier, IaaS refers to building a virtual datacenter. In the core, this refers to the following:

• Networking
• Storage
• Compute

Extended with overall security, governance, and monitoring capabilities.

Each of these architectural building blocks will be described in more detail in this section.

Networking

The core foundation of any datacenter, physical or virtual, is networking. This is where you define the IP address ranges and firewall communication settings, as well as define which virtual machines can connect with each other. Next, you also will outline how hybrid datacenter connectivity will be established between your on-premises datacenter(s) and the Azure datacenter(s).

From the ground up, you need to think about and deploy the following Azure services:

• Datacenter hybrid connectivity using Azure site-to-site VPN or ExpressRoute.
• Creating Azure virtual networks and corresponding subnets.
• Deploy firewall-like capabilities using Azure Network Security Groups, Application Security Groups, Azure Firewall, or third-party Network Virtual Appliances.
• Consider how you will perform virtual machine remote management. Regarding advanced security, just-in-time virtual machine access from Azure Security Center or the new Azure Bastion (public preview) might be good options. If neither of these, make sure your RDP/SSH sessions are behind a firewall scenario, never directly exposing your management host or virtual machines to the public internet.
• Just like in your own datacenter, Azure supports load balancing capabilities on its virtual network. You can choose from Azure Load Balancer, a layer-4 capable load balancer, supporting both TCP and UDP traffic on all ports. If you want to load balance web application protocols (HTTP/HTTPS), it might be interesting to deploy Azure Application Gateway, a layer-7 load balancing service, extendable with a Web Application Firewall (WAF) for advanced security and threat detection. The last option for load balancing is deploying a third-party load balancing appliance from trusted vendors such as Kemp, F5, or Barracuda.
• In the case of having multiple Azure datacenters for highly available workload scenarios, deploy Azure Traffic Manager or the new Azure Front Door service, allowing for detection and redirection across multiple Azure regions for failover and avoiding latency issues.

Besides these, running an Azure virtual network infrastructure—see Figure 13 for an example diagram of what this network design could look like—is similar to what it's like in your own datacenters. Here are some of the core characteristics and capabilities:

• Bring your own network: This refers to the aspect of defining your Azure internal virtual network (VNet) IP ranges. Azure supports the standard class-A, class-B, and class-C IP addressing.
• Public IP addresses: Every Azure subscription comes with a default of five public IP addresses that can be allocated to Azure resources (firewall, load balancer, and virtual machine). Know that these IP addresses can be defined as dynamic or static. Also, keep in mind that it will never be a range of IP addresses, but rather standalone. It is also not possible to bring your own range of public IP addresses into an Azure datacenter.
• Internal IP addresses: When you deploy an Azure VNet and subnets, you are in control of the IP range (CIDR-based). Preferably, Azure allocates dynamic IP addresses to resources such as virtual machines (as opposed to the more traditional fixed IP addresses you allocate to servers in your own datacenter). In my opinion, the only servers requiring a fixed IP address in Azure would be software clusters such as SQL or Oracle, or when the virtual machine is running DNS services for the subnet it is deployed in.
• Azure DNS: Azure comes with a full operation DNS as a service that you can leverage for your own name resolution. When deploying an Azure VNet and subnet, it refers to this Azure DNS by default. You can change this setting to refer to your own DNS solution, however. This can be an in-Azure running virtual machine or an on-premises DNS solution (assuming you have hybrid connectivity in place).
• IPv4 / IPv6: Azure virtual networks support IPv4, but currently IPv6 support is in preview. More and more internal services, such as virtual machines and Internet of Things (IoT), are supporting IPv6 for its network connectivity, both inbound and outbound.

Figure 13: Azure virtual network architecture

Further details on Azure networking services, capabilities, and how to deploy and manage them can be found at the following link:

https://docs.microsoft.com/en-us/azure/virtual-network/

Storage

The next layer in the virtual datacenter architecture I will highlight is Azure Storage. Similar again to your on-premises datacenter scenario, Azure offers several different storage services:

• Azure Storage accounts for blobs, tables, queues, and files
• Azure managed disks for virtual machine disks
• Azure File Sync, allowing you to synchronize on-premises file shares to Azure
• Azure big data solutions

Let me describe the core characteristics of each of these services.

Azure Storage accounts

Azure Storage accounts are the easiest way to start consuming storage in Azure. An Azure Storage account is much like your on-premises NAS or SAN solution, on which you define volumes or shares.

When you deploy an Azure Storage account in an Azure region, it offers four different use cases:

• Blob storage: Probably the most common storage type. Blobs allow you to store larger datasets (VHD files, images, documents, log files, and so on) inside storage containers.
• Files: Azure file shares to which you can connect using the SMB file share protocol; this is supported from both Windows endpoints (SMB) a Linux (Mount).
• Tables and queues: These services are mainly supporting your application landscape. Tables are a quick alternative for storing data, whereas queues can be used for sending telemetry information.

Azure Storage accounts offer several options regarding high availability:

• LRS – Local Redundant Storage: All data is replicated three times within the same Azure datacenter building.
• ZRS – Zone Redundant Storage: All data is replicated three times across different Azure buildings in the same Azure region.
• GRS – Geo Redundant Storage: All data is replicated three times in the same Azure datacenter, and replicated another three times to a different Azure region (taking geo-compliance into account, to guarantee the data never leaves the regional boundaries).
• GRS – Read Access: Similar to GRS, but the replicated data in the other Azure region is stored in a read-only format. Only Microsoft can flip the switch to make this a writeable copy.

Azure managed disks

For a long time, Azure Storage accounts were the only storage option in Azure for building virtual disks for your virtual machines, dating back to Azure classic 10 years ago. While storage accounts were good, they also came with some limitations, performance and scalability being the most important ones.

That's where Microsoft released a new virtual disk storage architecture about 3 years back, called managed disks. In the scenario of managed disks, the Azure Storage fabric does most of the work for you. You don't have to worry about creating a storage account or performance or scalability issues; you just create the disks and you're done. Talking about performance, managed disks come with a full list of SKUs to choose from, offering everything from average (500 IOPS-P10) to high-performing disks (20.000 IOPS-P80), and there are also Ultra SSD disk types available, going up to 160.000 IOPS with this model.

It is important to note that the disk subsystem performance is also largely dependent on the actual VM size you allocate to the Azure virtual machine; the same goes for storage capacity, as not all Azure VMs support a large number of disks. Besides having larger disk volumes available from the operating system perspective, having a larger amount of disks available could also be used for configuring disk striping in an Azure virtual machine disk subsystem. This would also result in better IOPS performance.

Azure File Sync

If you have multiple file servers today, you most probably have a solution in place to keep them in sync. In the Windows Server world, this could be done using DFS—Distributed File System—which has been a core service since Windows Server 2012. When migrating applications to the cloud, you might also need to migrate the file share dependencies. One option would be deploying Azure virtual machine-based file servers for this. But that might be overkill, especially if those machines are only offering file share services. A valid alternative is deploying Azure File Sync.

By using Azure File Sync (see Figure 14 for a sample architecture), you can centralize your file shares in Azure Files (as part of Azure Storage accounts), using them in the same way as your on-premises Windows file servers, but without the Windows Server layer in between. Starting from a Storage Sync Service in Azure, you create a Sync Group. Within this Sync Group, you configure registered servers. Once this server is registered, you deploy the Azure File Sync Agent on to it, which takes care of the synchronization process of your file shares.

Azure File Sync also provides storage tiering functionality, allowing you to save on storage costs when storing archiving data that you don't consult often but need to keep because of data compliance.

Data deduplication is another benefit for these cloud tiering-enabled volumes on Windows Server 2016 and 2019.

Figure 14: Azure File Sync

Compute

This brings us to the next logical layer in the virtual datacenter, deploying virtual machines. This is probably one of the most common use cases for the public cloud.

As mentioned in the introductory paragraphs at the beginning of this chapter, virtualization has dramatically changed how organizations are deploying and managing their IT infrastructure. Thanks to solutions such as VMware and Hyper-V, systems can be consolidated with a smaller physical server footprint, are easy to deploy, are easy to recover, and provide other benefits when it comes to moving them across environments (from dev/test to production, for example).

Most of the aspects and characteristics you know about from running virtual machines in your own datacenter can be mapped to running virtual machines in Azure. I often describe it as "just another datacenter." (However, obviously Azure is a lot more than that…)

Just like with the networking layer, let me provide you with an overview of the several benefits that come with deploying virtual machine workloads in Azure:

• Deploying Azure virtual machines allows for agility and scale, offering a multitude of administrative processes to do so. Leverage your expertise of PowerShell to deploy and manage virtual machines, just how you would deploy and manage them in your datacenter. Or, extend to Infrastructure as Code, allowing you to deploy virtual machines from Azure templates. This allows not only for Azure resources deployment but can be extended with configuration management tools such as PowerShell Desired State Configuration, Chef, Puppet, and more.
• Azure virtual machines come with a default SLA of 99.9%, for a single deployed virtual machine with premium disks. If your business applications require an even better SLA, deploy your virtual machines as part of a virtual machine availability set. This guarantees an SLA of 99.95%, whereby the different VMs in the availability set will never run on the same physical rack in the Azure datacenter. Or, deploy VMs in a virtual machine availability zone, leveling up the SLA to 99.99%. In this architecture, your VMs (two or more instances) will be spread across different Azure physical datacenter buildings in the same Azure region.
• You might have business requirements in place, forcing you to deploy virtual machines in different locations, hundreds or thousands of miles apart from each other. Or, maybe you want to run the applications as close to the customer/end user as possible, to avoid any latency issues. Azure can accommodate this exact scenario, as all Azure datacenter regions are interconnected with each other using Microsoft Backbone cabling. From a connectivity perspective, you can use Azure VNet peering or a site-to-site VPN to build out multi-region datacenters for enterprise-ready high availability.
• If you don't need real-time high availability, but rather are looking into a quick and solid disaster recovery scenario, know that Azure has a service baked into the platform known as Azure Site Recovery. Based on virtual machine disk state change replication, Azure VMs will be kept in sync across multiple Azure regions (keeping compliance and data sovereignty boundaries in place). In the case of a failure or disaster happening with one of the virtual machines, your IT admin can start a manual (or scripted) failover process, guaranteeing the uptime of your application workloads in the other datacenter region. The main benefit besides fast failover is cost saving. You only pay for the underlying storage, as long as the disaster recovery virtual machines are offline. During the disaster timeframe, you only pay for the actual consumption cost of the running VMs during the lifetime of the disaster scenario.
• Although the Azure datacenters are owned and managed by Microsoft, it doesn't mean they are only limited to running Windows Server operating systems and Microsoft Server applications. 60% of Azure virtual machines are running a Linux operating system today.
• Many business applications, such as SAP, Oracle, and Citrix, are available in the Azure Marketplace, allowing for easier deployment, just like most other Azure virtual machine workloads. Starting from pre-configured images, any organization can deploy an enterprise application architecture in no time. Support for these third-party solution workloads is provided by Microsoft, together with the vendor.
• Azure offers more than 125 different virtual machine sizes, each having different characteristics and capabilities. Starting from a single CPU core virtual machine with 0.75 GB of memory, you can go up to virtual machines with 256 virtual cores and more than 430 GB memory. Next, you also have specific virtual machine families, supporting specific workloads (for example, the N-Series family is equipped with an Nvidia chipset for high-end graphical compute applications, the H-Series is recommended for high-performance compute (HPC) infrastructure, and you also have specific virtual machines sizes for SAP and SAP HANA).

For an overview of Azure virtual machines types and sizes, use this link to the Azure documentation:

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes

For a broader view on Azure virtual machine compute capabilities in Azure, use this link:

https://azure.microsoft.com/en-us/product-categories/compute/

The last Azure compute characteristic I want to highlight here is Azure Confidential Computing. In early May 2018, Microsoft Azure became the first cloud platform, enabling new data security capabilities. Mainly relying on technologies such as Intel SGX and Virtualization-Based Security (VBS), it offers Trusted Execution Environments (TEEs) in a public cloud. With more and more businesses moving their business-critical workloads to the cloud, security becomes even more crucial. Azure Confidential Computing aims at delivering top-notch security and protection for data in the cloud. The concept is based on the following key domains:

• Hardware: Intel SGX chipset from a hardware security perspective
• Compute: The Azure compute platform allows VM instances with TEE enabled
• Services: Secured platforms enable highly secured workloads such as blockchain
• Research: The Microsoft Research department is working closely with Azure PGs to continuously improve the capabilities of this trusted platform

The last part of the cloud migration and adoption process, regarding IaaS, is providing a solution that allows for enterprise-ready management of your Azure landscape. And where possible, this should be stretched to a hybrid management solution, especially during a longer migration period, where you have systems running in your on-premises datacenter but also in Azure.

Azure comes with a plethora of management, monitoring, and operations tools. Let me walk you through a few of these that you will most probably start using immediately on a day-to-day basis.

Azure Monitor

Azure Monitor provides a unified monitoring solution for Azure, offering a single place to go to extract insights from metrics such as CPU consumption, logs, including event and application logs, and any other telemetry information generated by Azure services. This can be extended to also monitor on-premises running workloads and solutions, resulting in a single, powerful monitoring tool.

Azure Monitor also offers advanced diagnostics and analytics, powered by machine learning. These are surfaced in Azure services such as Azure Monitor for virtual machines, Azure Monitor for Containers, Azure Advisor, and Azure Security Center, to name just a few. Each and every one of these canonical scenarios offers recommendations and insights into how your deployment of Azure resources is performing.

Monitoring in Azure typically falls into two categories: monitoring fundamentals, which are components that are available in the Azure platform automatically without having to enable any services, and scenario-specific monitoring, which includes services within the Azure platform that can be utilized for monitoring but will require additional configuration or may include additional costs. Examples of this would be Azure Monitor Log Analytics, which has a free tier and consumption-based pricing, or Azure Security Center, which also has a free tier and a paid tier. Azure Monitor is part of Microsoft Azure's overall monitoring solution. Azure Monitor helps you track performance, maintain security, and identify trends.

Azure Monitor enables you to consume telemetry to gain visibility into the performance and health of your workloads on Azure. The most important type of Azure telemetry data is the metrics (also called performance counters) emitted by most Azure resources. Azure Monitor provides several ways to configure and consume these metrics for monitoring and troubleshooting.

Azure Monitor information is based on two main log information types, metrics and logs. Metrics are numerical values, typically used for getting real-time feedback. Logs, on the other hand, contain much more detail and are typically used for retrieving or pinpointing correlations between events and activities. Logs would also be stored for a longer period of time, often depending on the compliance requirements of an organization.

Typical metrics for an Azure resource are published in the Overview section of an Azure resource (see Figure 15 for an example related to Azure web apps).

Figure 15: Azure web app resource metrics

Retrieving more complex data from stored logs is done using Azure Monitor Log Analytics, where one needs to use Kusto query language-based queries. An example of what such a query looks like is shown in Figure 16.

Figure 16: Azure Monitor Log Analytics query example

See https://bit.ly/2QFzeyJ for more information and details.

Azure Monitor Log Analytics

Azure Monitor Log Analytics was previously treated as its own service in Azure, known as Operations Management Suite (OMS) Log Analytics. It is now considered a part of Azure Monitor and focuses on the storage and analysis of log data using its query language. Features that were considered part of Log Analytics, such as Windows and Linux agents for data collection, views to visualize existing data, and alerts to proactively notify you of issues, have not changed but are now considered part of Azure Monitor.

You require a log query to retrieve any data from Azure Monitor Log Analytics (Figure 17). Whether you're analyzing data in the portal, configuring an alert rule to be notified of a particular condition, or retrieving data using the Log Analytics API, you will use a query to specify the data you want.

You can create alerts based on your queries, and because you can include Azure metrics data in Log Analytics, you can even perform queries across your metrics and data stored in the Log Analytics service.

Figure 17: Azure Log Analytics query

Log sources are ingested from multiple services as well, just like metrics. In fact, metrics, along with activity and diagnostics logs, can serve as a data source for Log Analytics. Telemetry for virtual machines can be richer, as Log Analytics includes both textual and numeric data types, allowing for application logs, event logs, and additional performance metrics to be written to Log Analytics. The same is true for application data for custom applications. Applications can be instrumented with Application Insights to provide deep insights into application performance and health. Azure Security Center also leverages Log Analytics as a part of its analysis of the virtual machines in your subscriptions. When onboarding a VM to Security Center, you're in fact onboarding that machine to a Log Analytics workspace where its telemetry is stored for analysis by Security Center. There are also marketplace solutions that extend a Log Analytics workspace, bring additional data points into the service for a query, as well as new visualizations based on those data points.

Finally, you can interact with and respond to events based on Log Analytics data with services such as Azure Automation, where you can have an event trigger a runbook or even a webhook in an Azure function.

Azure Security Center

Azure Security Center (Figure 18) provides unified security management and advanced threat protection across hybrid cloud workloads. Many organizations are moving workloads to the cloud or deploying new workloads in the cloud to optimize their security posture.

Figure 18: Azure Security Center

Azure Security Center offers powerful capabilities across three main areas:

1. Cloud Security Posture Management: Azure Security Center provides you with a top-down security posture view across your Azure environment, enabling you to monitor and improve your security posture using the Azure Secure Score. Security Center can help you identify and perform security best practices and hardening tasks and implement them across your machines, data services, and apps. This includes managing and enforcing your security policies and making sure your Azure virtual machines, non-Azure servers, and Azure PaaS services are compliant. With newly added IoT capabilities, you can also reduce the attack surface for your Azure IoT solution and fix issues before they can be exploited. In addition to providing full visibility into the security posture of your environment, ASC also provides visibility into the compliance state of your Azure environment against common regulatory standards.
2. Cloud Workload Protection: Azure Security Center's threat protection enables you to detect and prevent threats at the IaaS layer as well as in PaaS resources in Azure such as IoT and App Service, and finally with on-premises virtual machines. Key features of Azure Security Center threat protection include config monitoring, server EDR, application control, and network segmentation. Azure Security Center also supports container and serverless workloads.
3. Data Security: Azure Security Center includes capabilities that identify breaches and anomalous activities against your SQL databases, Data Warehouse instances, and storage accounts, with support for other services on the way. In addition, Security Center helps you perform the automatic classification of your data in Azure SQL Database.

Security is part of all layers of the public cloud environment. The good news is that Azure Security Center has the capabilities to tackle and report on each of these layers in an Azure environment, as well as in a hybrid cloud scenario.

Azure Sentinel

While Azure Security Center is mainly used as a reactive operations tool, many organizations are struggling to switch to a reactive approach. This is where Azure Sentinel can be of value. Azure Sentinel is a Security Information and Event Management (SIEM) tool in the cloud. Given the huge amounts of security-related data out there, it is important to get a clear view and focus on the key concerns and how to fix them. A lot of different Microsoft services, such as Azure, Office 365, and also non-Microsoft services, can report information back to Sentinel.

All this information goes through a massive data analytics and machine learning engine, helping to identify threats. Also, it comes with more than 100 built-in rules, and you can configure your own alert rules.

When one or more incidents (cases) occur, they will be centralized to allow for further investigation and handling. With a powerful graph view, it becomes easier to present and detect the correlation between stand-alone attacks and vulnerabilities. And all of this is available cross-platform, whether checking Azure resources, on-premises, or hybrid.

Besides the dashboarding views and detections, Azure Sentinel can also help in remediation. Using Security Playbooks—backed by Azure Logic Apps—it doesn't take more than a few clicks to build a step-by-step logical approach of action-taking.

Lastly, a huge community of Microsoft and non-Microsoft security experts and organizations helps to maintain and optimize security detections, centralized in the Sentinel GitHub repo, https://bit.ly/302Yfqq, resulting in an even more powerful security service.

Azure Network Watcher

A core activity as part of managing your own datacenter is getting a clear view of your network traffic, not only from a security perspective but also regarding bandwidth, latency, and suchlike. Vendor tools such as Wireshark and Fiddler have been part of any IT admin's troubleshooting toolbox for years. While these tools are still useful in an Azure environment, they do not always give the same rich, detailed experience. The main reason for this is because you don't own and control the Azure network stack as you do in your on-premises datacenter. There are no firewalls or switches that you can connect a serial console cable onto in order to capture network traffic or read out syslog information.

And that is where Azure Network Watcher (Figure 19 gives a dashboard view of Network Watcher integration with Azure Monitor) comes in. Bringing in a lot of typical network trace features, it is a must-use tool if you take Azure network monitoring seriously:

• IP flow verify: Allows you to get a clear view on the matter if a packet is allowed or denied to or from a virtual machine, using five-tuple information
• Next hop: Provides the next hop from the target virtual machine to the destination IP address
• Effective security rules: Shows the effective rules, based on different Network Security Group (NSG) rules, configured on different levels (NIC, subnet, and so on), thereby making it easy to troubleshoot and see the effective reason why traffic is allowed/denied
• VPN troubleshoot: Diagnoses the health of site-to-site VPN gateways and ExpressRoute, capturing details in a diagnostic log file
• Packet capture: Similar to Wireshark, runs packet captures to analyze all the details of the network stack

Figure 19: Azure Network Watcher connection monitor

Azure Service Health

Sometimes you face an issue or downtime with one of your running Azure workloads. But this is not always caused by your administrators. Like any other datacenter, Azure undergoes continuous updates and requires patching of its infrastructure. Physical components fail all the time, especially if you consider the amount of physical servers, storage, networking, and racks that are running inside each and every Azure region. To help you in troubleshooting, as well as to legally identify you about any issues being faced by the PaaS provider, Azure gives you Azure Service Health (Figure 20). From here, you can get a real-time view of the overall uptime status of any Azure datacenter you have services running with, as well as historic views. If you detect an issue with a workload or service whose configuration has not been changed by yourself, it should be a reflex to open Azure Service Health and validate that all is fine on the Azure physical stack.

Figure 20: Azure Service Health

Azure Advisor

Azure Advisor is yet another Azure monitoring tool, and it is a great one. First of all, it's free, but that's not the main reason why any Azure customer should enable and use it in their subscriptions.

Azure Advisor provides insights and recommendations in four domains:

• High availability
• Security
• Performance
• Cost

All of this is presented in a nice Azure dashboard (Figure 21), allowing you to drill down to see more details regarding the recommendations.

Figure 21: Azure Advisor

The core idea of Azure Advisor is getting guidance on using Azure best practices, helping you optimize running workloads and services in Azure. Based on machine learning in the back end and relying on telemetry information and configuration settings from your actual Azure environments, it will provide recommendations for optimization.

While it would be possible to go after that information yourself, it is probably a lot more time-consuming and cumbersome to find than what Azure Advisor presents nicely and almost in real time, without any hassle or agent needing to be deployed.

Azure Monitor Application Insights

Azure Monitor Application Insights is yet another Azure monitoring tool, with a core focus on monitoring your (web) application landscapes, no matter where they are running. And that is immediately one of the main reasons why you should have a look at it. Although running in Azure, the to-be monitored web apps don't need to run in Azure App Service. Next, it is a very detailed tool, capturing most of the insights a developer is looking for when running web applications. It detects information regarding web app performance, but also helps in analyzing web app traffic. From a language perspective, most popular environments and development languages are supported (.NET, Java, Node.js, Python, Ruby, and more).

You install a small instrumentation package in your application and set up an Application Insights resource in the Microsoft Azure portal. The instrumentation monitors your app and sends telemetry data to Azure Monitor. (The application can run anywhere—it doesn't have to be hosted in Azure.)

Information that Azure Monitor Application Insights is capable of tracking and presenting includes:

• Web app response times and failed requests
• Exceptions in traffic or usage
• Page views and load performance
• Custom metrics, if configured

It allows you to work with four domains of web app hosting:

• Monitoring (availability, performance, and integration with other services such as databases)
• Detecting and diagnosing issues (HTTP errors, providing traces, and so on)
• Synthetic transactions (running web tests)
• Telemetry information

The different sections that are monitored by Azure Monitor Application Insights can be presented in clear and customizable dashboards (see Figure 22 for an example), which can be shared among your Azure administrators.

Figure 22: Azure App Insights

In this first chapter, we outlined the Microsoft best practices around Azure migrations, starting from assessments and what tools Microsoft provides to help in this phase. Next, we discussed Azure Migrate and the newer Azure Migration Center. We looked at how it provides the necessary and useful tools for performing actual workload migrations from on-premises to Azure, covering different architectures. Next, we touched on the different foundational aspects of running a virtual datacenter in Azure, highlighting identity and control, enterprise-ready networking, Azure Storage capabilities, and what Azure virtual machine architectures are available today.

We provided information on business innovation and the digital transformation of traditional workloads with virtual machines, and what other Azure capabilities and services are available to host your business-critical workloads using PaaS, serverless, and microservices.

We also shared insights on Azure monitoring and operations, including how to efficiently manage your cloud environment using core Azure built-in tools.

While most organizations have been using a multitude of similar tools to manage and operate on-premises datacenters, there is no need to worry about additional complexity because of more Azure services and tools being added. Depending on the cloud strategy, an organization can initially start with using the Azure-provided operation services for monitoring and operating Azure workloads only. Yet, know that most of the monitoring services referenced here also extend to your on-premises datacenter, and most often hybrid scenarios as well. So, it might be a good approach to learn how to integrate these Azure tools in your overall IT landscape and leverage their true power. Don't get stuck in an Azure-only mindset.