Hands-On Cloud Solutions with Azure

There are no technical requirements for this chapter, but these are important links you should review:

It is the delivery of computer services over the internet to assist with resource flexibility, scale, and innovation. These services include servers/VMs, physical storage, data repositories, networking resources, analytics, software, and more. These services are offered at a much smaller pay-for-use model than physical data centers and organizations generally migrate to the compute service model for the following reasons:

Cloud computing comes in private, public, and hybrid types, with each offering its own benefits:

But at the end of the day, what problems do clouds solve? Let’s understand this in the following section.

The biggest benefit of the cloud is it allows organizations to expand without a large capital cost, and also allows new/small businesses to shrink their startup or capital into a pay-as-you-go model. The cloud allows for innovation to happen without the traditional fears of infrastructure purchases, giving the ability to bring up and tear down in a rapid and cost effective way with little concern for the infrastructure needed.

Think of it as an unlimited playground where the only true limit is your imagination. You can now build, migrate, or rebuild your applications, so you truly only have to worry about the application and not about everything around it. So, the problem it solves is allowing your organization to scale faster, while controlling cost and offline responsibilities to help streamline IT operations.

The cloud targets not only development but operational resources, allowing you to focus on the things that truly matter to an organization. It fosters increased communication between all facets of the organization, from requirement gathering to automated deployment and testing. Let’s take a look at Microsoft’s cloud solution, Azure.

Azure is Microsoft’s cloud offering, which comes in private, on-premise (Azure Stack), government, and public versions (refer to this link for further details https://azure.microsoft.com/en-us/overview/what-is-a-private-cloud/). It was announced on October 2008, released on February 2010, and is the next evolution of virtualization. The magic of Azure is built on top of a technology called Service Fabric and Fabric controllers; it works as a distributed application system that handles the allocation of servers or services, monitors the health of these, and heals them as needed. Each Fabric Controller orchestrates all the resources needed within the Azure platform. All the network resources and servers have been abstracted out of your view and there is no longer a need to support and maintain these resources. This will create what is referred to as a closed ecosystem, and Azure offers its services in this closed ecosystem for mass consumption. This closed ecosystem allows its consumers to not have to worry about the underlying technology and, in most cases, the operating system needs to support that technology. This has helped in abstracting away the need to support the many facets of technology in today's organizations.

As I grew up in the development world, I had to learn firsthand how frameworks moved the line of responsibility. In the development of applications, this leads to some uncomfortable moments as I had to learn to adjust to these new lines. This learning process allowed me to focus more on the application I was developing and less on how each piece needed to be integrated with the underlying system. New frameworks such as the Entity Framework for database integration or the Windows Identity Framework for security integration simplified these layers in application development. Azure begins the next evolution of these abstractions and is referred to as a closed ecosystem. A closed ecosystem gives the infrastructure resources or operations managers within an organization new lines of responsibility. 

These new lines have created an opportunity for organizations to support their daily operations and have put less pressure on underlying infrastructure concerns. This has led to a new way for operational engineers to secure organization resources, which has been simplified and codified. Cloud resources have also stretched passed the need for managing virtual machines alone and have moved to a more utility-based structure (referred to as compute), as you can just deploy your enterprise applications without much regard to the underlying infrastructure. Now, in the past, I have been asked by these operations folks Why would they want to eliminate my job function? The simple answer is the same as it was for the developer. It will enhance your ability to complete your job function, and not eliminate it. My answer, personally, when asked this question, is do you like getting up in the night and on weekends to patch or support your infrastructure?, to which the answer is always a resounding No!, I then ask, If I could remove this from your view, would that be ok? This is always answered with a Yes!, and I then say, Welcome to Azure! 

Overall, this is to helped organizations focus on their application development, infrastructure resource needs, and security, without the concern of maintaining, patching, or updating the underlying resources or technology. One of the biggest things organizations have to grasp is the changes to budgeting in this new utility-based cost model. Gone are the days of needing to rent data centers or rack space to house your servers and routers. In their place steps the consumption model. This model follows more of a pay as you go aspect for resources and has opened the door for organizations and startups to better structure budgets and the upfront costs of development or infrastructure. With that comes some caveats, as with electricity, some things you put into this model can create unexpected costs. For example, plugging in a refrigerator or pool pump can increase your monthly bill, and so resources such as CosmosDB or VM sizing can affect your Azure monthly bill.  As we progress through this book, we will hopefully bring more of these issues to light and learn how to control costs better.

With the adoption of the cloud, there has come new guidance on the usage of resource types, cost, as well as deployment needs. These needs and deployment strategies differ by a cloud provider, but one I have been very accustomed to us is Azure.  Azure provides Platform as a service (PaaS), Software as a service (SaaS), and Infrastructure as a service (IaaS) for a large variety of programming languages. One of the biggest hurdles in your journey beside which type of resources to use is the cost associated with spinning up that type of resource. Most of the clients I work with have struggled with cost management. I try to leverage the Azure pricing calculator as much as I can; however, with Azure being a utility, it never tells the tale of consumption.  So, as we begin our journey to Azure enlightenment, we will look at the cost or highlighting the things you need to consider when selecting a resource. Let’s take a moment to look at the responsibility to understand what responsibilities you are keeping and are releasing Microsoft, in following figure:

Now that we understand the responsible parties on the type of resources we pick, let’s dive into Azure and see how to leverage it to run solutions.

One of the things you want to do before you start your journey is to put a plan or governance together.  This will help with keeping everyone honest and set the expectation on what is important to consider when building your solutions.  As you can see in the following figure, we look at governance from a design, execute, and review perspective to keep things simple.

Azure governance approach

This is meant to answer the questions as to “Why we do things”, “How we do things”, then how we verify and change our governance.  The “why” component becomes your vision and constraints such as regulatory obligations, privacy, or data related needs.  The “how” component is the required needs like policies, encryption, and so on, which can be implemented and controlled.  The “verify” component provides the verification of the implementation of the design, but also, we flexible enough to allow changes based on new innovations in the cloud.

Your journey to the cloud should provide the following key attributes:

Not that we have our plan, let’s look at how we get started using Azure.

When one starts using Azure, there are many new things to learn, like how resources are configured and used in the environment. So, I headed over to the Azure portal (https://portal.azure.com) and created an account. There are several things to consider here; you can pay as you go, configure an Enterprise Agreement, use an Azure Pass, sign up for Dev Essentials, or use an MSDN subscription to set up how you will pay for the resources. You can also configure spending limits to help control costs and also control enterprise costs. With an Enterprise Agreement, you can use a Dev/Test subscription to help offset costs. Enterprise Agreement Dev/Test subscriptions get you a significant price reduction, percentage-wise, over production versions. If you plan on using Azure a lot, I would recommend engaging with Microsoft to get an Enterprise Agreement. To get an Enterprise Agreement, you will need to reach out to a Microsoft account representative for the requirements, which you can review here: https://www.microsoft.com/en-us/licensing/licensing-programs/enterprise.aspx. As a side note, you can also create your account through Office 365 services, but for the sake of simplification, we will stick with the Azure portal side. Once your account has been created, you will access the portal and be presented with the Azure default dashboard. For a Tenant to be created, you must have what is referred to as a privileged account, which is defined as an Azure account in the Tenant or Enterprise Agreement. At the end of the day, it is an organization's network account.

Once the Tenant has been created, it will act as a virtual representation of your organization within Azure. This equates to the earlier physical network structures that were used within an organization which was secured by firewalls, network resources, and directory services that were usually housed in a data center. A Tenant in Azure follows the same structural basis but is a virtual instance of the organization that is backed by the Azure Active Directory (AAD) services. All Tenants require AAD, as this is the digital identity service model for securing all SaaS, IaaS, and PaaS resources. Think of the Tenant as your organization container, with the same type of physical boundaries as a physical data center network would have. The following diagram shows a simplified view of a Tenant:

AAD services, as shown in the preceding diagram, can be synchronized with an on-premise Active Directory (AD) through a process called Active Directory Federation Service (ADFS). This is the process of syncing users/groups and helps with providing access to cloud and on-premises resources without the need to add users to both directory services. Now that we have our Tenant, it has hard resource sharing boundaries that can’t be broken, just like your physical network. A Tenant is also assigned a Tenant ID that is used to identify the organization, and the privileged account is assigned the owner. Within your Tenant, you have an Office 365 or O365 container that houses your SaaS products such as Exchange, SharePoint, Power App, and so on, and the Azure Container that houses your subscriptions and resource groups. This book isn’t about O365 and the SaaS-based container, but more about the Azure container and the guidance needed to architect, develop and deploy solutions. Now, regarding Azure, we need to discuss the structure of how resources are handled: you start with a Tenant, then you have a subscription, and then you have a resource group, as shown in the following diagram:

A Subscription (Sub) in Azure is a container that groups together resources and users, and also has limits. The limits have changed over time and can be increased with support tickets from Microsoft. You can review the limits at https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits. Subs themselves have sharing limits as well. For instance, currently, Key Vaults, App Service Certs, and Express Routes, to name a few, do not span subscriptions. You can also include resources in Resource Groups (RG) from another subscription. You also do not have the intellisense in the portal for resources, not in the same subscriptions. RGs are application life cycle resource containers within a subscription that houses all the resources that make an application or piece of an application or infrastructure. You create a subscription when your tenant is created. You can also do this through your Enterprise Portal.

I have set up my Tenant – what's next?

After you have configured and set up your Tenant and Subs, perform the following steps:

1. Let’s login into the portal at https://portal.azure.com/. Once you have signed into Azure, you will enter the default dashboard.

Note

Dashboards are extremely powerful, and we will discuss leveraging them at each step in supporting and monitoring the resources that are built.

2. Now, there are several ways we can add resources through the portal, but in this first section, we will add them into the portal. There are several ways to search for resources using the portal once you have logged in, as shown in the following screenshot:

Resource search on Azure Portal

3. You can use the top search for quick resource lookup by typing in the name of the resource you need, for example, App Service Cert or Certificates.

4. If you would like to search by visible name, you can use the All Services link from the side menu. This will bring up the services blade, as shown in the following screenshot:

All services blade

Now, some resources come from the Azure Marketplace, such as VM images and Web Applications. These are provided from the Marketplace via ARM resource deployments that are created by Microsoft or certified vendors. The Azure Resource Management (ARM) are template systems that are used by Azure deployment mechanisms. These are basically JSON files that describe the resources being deployed.  We will discuss them in details in Chapter 6, Deploying Solutions to Azure.  The marketplace is a great starting place for applications such as WordPress.

 

Let's walk through a marketplace example

Let's walk through an example of how to set up a WordPress site using on the Portal and Marketplace. This will not only provide an understanding of how to use the Marketplace but how the underlying ARM templates are leveraged in the deployment of resources from the Marketplace:

1. In the top search bar, type Marketplace, as follows:

2. Select Marketplace from the services menu.

3. Once the Marketplace blade is open, select Everything and type WordPress, as follows:

4. Select the first WordPress in the list.

 

5. Click on the Create button, as shown in the following screenshot:

6. Enter an App Name, Subscription, Resource Group Name, and Database Provider to Azure Database for MySQL. Leave the App Service plan/Locations settings as their default options for the demo:

7. For this walk-through, when you click on Database and the Database blade comes up, just add a password, select a basic pricing tier, and click OK:

8. Then, click the Create button.
9. Once this has been created, you will receive a notification stating that is has been completed. Click on Go to resource, where you will be able to access and configure your WordPress site.

Optional steps to add a custom domain and SSL Certificate

10. Go to your App Service Resource and click on Custom Domains, use the IP Address to point your domain at, once you add your A record, then click on + Add Hostname to add.

11. You will need to add your private or public certs, which you can leverage App Service Certificates (which I recommend), and once added, +Add a Binding and turn on HTTPS only.

 

During this exercise, we created several things: an App Service, an App Service Plan, a MySQL server, and a MySQL database instance. An App Serviceis the instance of code needed to run the application. In this case, this is the WordPress PHP code. This is connected to the Marketplace code repository that, in most cases, keeps the code updated based on refreshes to the Marketplace.  It is deployed from the Marketplace using a process called ARM template. AnARM templateis a JSON representation of the resources that are deployed to an Azure Resource Group.  The ARM template process leverages aDesired State Configuration(DSC), to manage the configuration state of the resources, and this process helps with creating or updating the resources should the template be run again to update the resources within the application Resource Group.  In the case of WordPress, the updates are handled by the portal. AnApp Service Plan, commonly call VM backed, is the virtual resources allocated to the App Service. Think of the VM as something that houses the web server, and the App Service as an IIS app on the box. TheMySQL serverinstance houses the MySQL database instance for the WordPress site, which is almost the same as the on-premise version in IIS, but is instance-based and hides the server's implementation. So, as you can see, the implementation of the application is basically the same as it would be on-premise, but it is more instance-based in Azure. There is no need to worry about the infrastructure implementation as you would with an on-premise solution.

Note

The App Service Plan controls the resources used to back up your App Service for dev or demo environments. I would use Free or Shared to help keep the cost down.  If you require custom URLs or SSL, you will need to use a basic or standard plan, which will increase the cost significantly, so be mindful of the requirements you need for your App Service. For larger organization you can get premium tiers and for those using PII or GDPR you can leverage isolated tier or App Service Environment or ASE to isolate applications and protect data.

Organizations have leveraged Directory Services and Identity Services for years, and they have manifested in the Azure Active Directory in Azure. The Azure Active Directory (AAD), is important for securing services for Azure-based solutions.  Before we discuss moving existing applications to Azure in Chapter 2, Moving existing apps to Azure, it is a good practice to synchronize directories so that resources can be shared from on-premise to Azure in hybrid scenarios.  A hybrid scenario would be defined as moving your web front-end virtual machines into Azure while your databases' virtual machines remain on-premise.  You can leverage Azure Connect to solve the syncing of your on-premise Active Directory to Azure Active Directory, as shown in the following diagram:

Azure AD Connect

While this book is about Hands-On Solutions with Azure, the configuration of the synchronization to Azure can be complex based on the directory services configured within your organization. You can find Azure Connect in the portal, as shown in the following screenshot.

You can also learn how to set up Azure Active Directory to sync with your organization by using the guide at https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect, as you can see below in Figure 1.7.

Azure Connect in the portal

No matter how you choose to use Azure, it is important to get the security right upfront.  Now, one of the biggest differences is that the Azure Active Directory has pricing plans based on the type of services you need, and you can review that pricing here: https://azure.microsoft.com/en-us/pricing/details/active-directory/. 

Once everything has been completed, your users should be able to change their passwords on both fronts.  You will also have the ability to access and secure resources without having to add them to Azure AD and cut down on your user management.

These words have very specific meanings in Azure, and need to be referenced in the proper context to avoid confusion:

Now that we have created our tenant, subscriptions, and our first resource group using the Marketplace, let's review some key points and terminology.  A tenant is the virtual representation and the main container for all of your organization resources in Azure and is Azure Active Directory backed for security and identity management. A subscription is a container that groups resources and users together and has resource limits. You want to take a simplistic approach to create a subscriptions as they have sharing boundaries. Additionally, you want to use resource groups as an application life cycle container to house the resources required for your application. You will want to leverage the marketplace or ARM templates as deployment process for your resources within a resources group, allowing the DSC to manage the state of the resources within the resource group.  Use dashboards to view your resource groups in order to monitor and support your deployed resources.

With this new understanding, you might ask, I have an existing application I would love to move to Azure.  The next part of our journey will look at migrating or leveraging parts of Azure with your existing applications. We will cover everything from lift and shift to hybrid solutions, and what it means to host them.

Let's take a look at what we have learned so far:

These links will be helpful in understanding a few of the topics we have covered in more detail: