Each organization has a unique journey to the cloud based on its own starting point, its history, its culture, and its goals. This document is designed to meet you wherever you are on that journey and help you build or reinforce a solid foundation around cloud application development and operations, service management, and governance.
At Microsoft, we have been on our own journey for the past decade, and over the past years we have learned important lessons by developing our own internal and customer-facing systems. At the same time, we've been fortunate to share the experiences of thousands of customers on their own journeys. This document is designed to share those experiences and distill them into proactive guidance. You do not need to follow these recommendations to the letter, but you ignore them at your peril. Our experience has shown that a careful approach to these topics will speed you along on your organization's journey and avoid well understood pitfalls.
For the past several years, we have seen consistent explosive growth as new organizations take on the challenges associated with their individual journeys, and we have seen a shift from the adventurous technician to the aggressive business transformer who engage with us. The pattern is clearly emerging, that deep engagement in cloud computing often leads to digital transformation that drives fundamental changes in how organizations operate.
In the early stages of cloud adoption, many IT organizations feel challenged and even threatened at the prospect of the journey ahead, but as those organizations engage, they undergo their own evolution, learning new skills, evolving their roles, and in the end becoming more agile and efficient technology providers. The result often turns what is perceived as a cost of business into a competitive advantage that makes it possible to redefine long-believed limitations. In many cases, what emerges are new business opportunities.
An important concept covered in this book is a strategy for identifying and moving specific workloads based on their actual value to the business. Some emerge in a new form infused with cloud design principals that were otherwise not available in the past. Others receive targeted improvements to extend their lifetimes. Still others move as-is, using the "lift and shift" approach that requires minimal change. Because of the unique capabilities of the Microsoft Cloud and the Microsoft Azure platform, workloads that must remain on-premises because of latency or compliance requirements can fully participate in the journey because of the ability for an organization to run Azure services on-premises using Azure Stack.
This book is designed for decision makers to gain a high-level overview of topics and by IT professionals responsible for broad implementation. Regardless of where you are personally focused in infrastructure, data or application arena, there are important concepts and learnings here for you. As you read, we hope you will gain insights into recommended general architecture to take advantage of cloud design principles, the evolution possible in application development to DevOps, approaches to service management, and overall governance.
We are on an exciting and challenging journey together and we hope this document will speed you along your way!
When it comes to governance a variety of interpretations exist. For Microsoft, Azure governance has three components (Figure 1-1): Design of Governance, Execution of Governance, and Review of Governance. In this chapter, we take a look at each of these components.
Figure 1-1: Azure governance
The first component is Design of Governance. This component derives from the customer's cloud vision. It comes together with the customer's constraints, such as regulatory obligations or privacyrelated data that needs to be processed. This is the why do we do things.
The second component is Execution of Governance. This component contains all of the measures to fulfill the required needs, like reporting, encryption, policies, and so on, to ensure that the defined component is followed by measures that can be implemented and controlled. This is the how we do things.
Finally, to ensure that all of the measures are fulfilling the intended purpose, a review of the results is needed to verify that the implementation follows the design.
Having digital transformation in mind is already the first step toward envisioning how you can use cloud technology. The next step is to break it down into actionable steps within your enterprise. For additional reading on the topic of cloud strategy and envisioning, we recommend reading Enterprise Cloud Strategy, 2nd Edition by Eduardo Kassner and Barry Briggs. You can find it at https://azure.microsoft.com/resources/enterprise-cloud-strategy/. The book explains and elaborates on actionable ideas, several of which are briefly introduced in the section that follows.
Figure 1-2 and the following list present the main pillars and how to understand them:
Figure 1-2: Digital transformation
Each of these pillars are connected to one another; some customers work on all pillars at the same time, whereas others are working on only one pillar at a time. This depends on the strategic decisions, capabilities, and capacities each customer can assign to the process and the defined timeline.
The top management task is now to name the action areas, give them priorities and the needed resources, and articulate the desired outcomes. This should be considered the company's North Star for orientation, for how to get there. Some enterprises prefer the "top-down" way of defining this, whereas others engage with their workforce for the same purpose.
Examples of cloud visions are, "We want to have 50 percent of our compute power moved to the cloud by 2020," or, "All our new products will be completely cloud-based on DevOps methodologies starting this fiscal year."
If there is a shared vision that guides the company as a whole through the digital transformation, the mission is accomplished.
After the cloud is envisioned as a means for the company's further evolution, the next steps need to be prepared and implemented. Here, envisioning and a clear picture can help you to keep track of your actions and let you prioritize to achieve quick wins while keeping the focus on the digital transformation. Cloud readiness is the next phase. But, to be certain, cloud readiness applies to more than a traditional waterfall project with its highly structured work breakdown structure (WBS). An Agile Scrum approach can be very successful, too, if the cloud vision and the desired outcome are well defined.
In the sections that follow, we describe areas we've identified in which change might be needed for an enterprise to handle cloud services effectively. The list is not exhaustive, and you should consider it as a starting point. If you identify additional areas in your organization that might need to undergo change, you are already in the driver's seat for your digital transformation.
Chapter 2 and Chapter 3 focus on developing a readiness framework and the organizational readiness to support a digital transformation. Following that, this ebook concentrates on more technical aspects, like Azure architecture, application development, and operations, we close with the service management of Azure and an outlook.
A readiness framework can help you to embed your cloud activities into your existing procedures, operational tasks, and responsibilities to make sure that you, as the enterprise, stay in control of your cloud journey. For some companies, the creation of a readiness framework is a huge task because their existing structures are challenged in a way that is very demanding. But that is the basic principle of the digital transformation.
Figure 1-3 is intended to serve as guidance for the next chapters and to give you a high-level overview of the areas that are relevant to Azure and its governance.
Figure 1-3: Cloud readiness framework
The orange blocks in the upper left, Enterprise Portal and Account Portal, with the components
Enterprise, Department, Account, and Subscription below them show the dependencies from the enterprise contractual level down to the more technical element of Azure subscriptions. This part is mainly focusing on the contract, the purchase, and the billing of Azure. But already we can see that there is a strong dependency on Azure Active Directory.
Azure Active Directory is the identity repository for other Microsoft Cloud services like Microsoft Office 365 and Microsoft Dynamics 365. Many enterprises choose to synchronize all or a major part of their on-premises Active Directory with Azure Active Directory. Microsoft's recommended technology for this is the Azure Active Directory Connector, which is free of charge. In this way, companies remain in control of their corporate identities. A combination with federation services is possible and very often used as means of stronger control.
With this level of control, the resources and different ways to interact with Azure are securely accessible through the common interface of the Azure Resource Management layer.
The Azure resource groups now are the main structure where all your resources—for example, virtual machines, Azure storage, as well as platform services like Azure Machine Learning, and so on—are grouped together.
Access to these resources is possible over the internet through secure channels like Virtual Private Networks (VPNs) or Azure ExpressRoute, so long as a dedicated Multiprotocol Label Switching (MPLS) connection with high-bandwidth options and Service-Level Agreements (SLAs) are in place.
Development operations model cloud services
One part of the framework is an operations model that is fit for the purpose of cloud services. The crucial point for many customers is the shift away from an oftentimes years-long, outsourcing model with a huge amount of infrastructure components to an Agile model with a blend of infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS). To be clear, a cloud provider is worlds apart from an outsourcing provider, but we have seen customers that needed to evolve to the new way of interaction and defining the responsibilities to operate their new services in the cloud to be successful.
Customers that have successfully gone that way interacted early with their outsourcing providers and elaborated on new models of a managed cloud service that they could offer instead of the outsourcing model.
Chapter 0 provides more information regarding DevOps, operations, and other related topics.
Cost and order management
To achieve a level of cost transparency and to be able to assign certain cost alerts and limits, the Azure monetary model must be integrated in the adopting companies' processes. We cannot totally describe requirements here, and they can they change in future versions of Azure. Sample requirements are Azure Usage and Azure Rate Cards. These are supported through the Azure Billing API. Azure provides a special billing API, which you can use to build your own solution for billing. Typical scenarios include the following:
Another approach can be to use a third-party provider solution like CloudCruiser or the solution from Cloudyn. Cloudyn was acquired by Microsoft in July 2017 and will be made available to all Azure customers. Cloudyn focuses on three main areas of the customer's cloud business. Table 1-1 lists these areas and their features.
Table 1-1: Cloudyn features
Focus area | Features |
Gain real-time visibility to the Azure cloud environment | Keep track of upfront compute commitments and fees compared with actual consumption |
Reconcile prepay commitments with billing payments | |
Verify Enterprise Agreement (EA) discounts with actual bills | |
Stay on top of expiring resources and agreements | |
Empower enterprise-wide cloud accountability | Facilitate accurate cost allocation and chargeback across your enterprise entities including subscriptions, accounts, departments and cost centers |
Implement your own cost allocation method—blended/average/ normalized rates, CPP (Compute Pre-Purchase) autonomous rates, or any other policy of your choice | |
Assure CPP autonomy—assign zero costs to CPP owners and add OnDemand costs to the departments that used external/borrowed CPPs | |
Track Azure Resource Manager groups' tags for simplified cost allocation | |
Drive Azure cost management and optimization | Monitor your virtual machines' performance-to-price ratio and receive actionable recommendations to maximize usage |
Calculate your most cost-effective upfront monetary and usage commitment | |
Release unused Reserved IP addresses of stopped instances | |
Dispose unattached block-blob storage volumes | |
Apply changes directly through the Azure Operations Management Suite API |
Another area that will change with cloud adoption is the company's procurement. Ordering cloud services is very different from ordering boxes of software or buying blocks of licenses. It begins with adding licenses as needed, negotiating the EA, and understanding the subscription model of Azure, Office 365, and other cloud services from Microsoft.
Therefore, the procurement department needs to be a first-class citizen of the cloud-ready world. It begins by making the procurement team aware of the changes in the products and the way they are purchased. You must modify existing processes, which are based on buying boxed software and assigning it to cost centers, to purchasing and maintaining one or many Azure subscriptions with a possible dynamic cost value per month assigned to projects or cost centers. Especially the as-yetdetermined amount of money that needs to be allocated to the project or cost center are the challenges for every customer.
Most enterprise customers are already acquainted with the contractual construct of a Microsoft Enterprise Agreement (EA) . Additionally, Azure offers the Pay-As-You-Go model. This model includes no commitment and you pay only for the services you actually consume. Payment is handled via credit card or debit card. Because this is not controllable from a technical perspective, most customers prohibit using company credit cards for cloud services. Also, expensing cloud services is very often prohibited by company internal regulations. Your Microsoft sales representative can help you to find the appropriate option for your situation.
Some customers purchase Microsoft Cloud services like Azure and Office 365 via a central group or department and then charge individual departments for services consumed. The infrastructure and organizational processes needed to carry out this type of purchasing would need to be developed and implemented by the customer. Technically, Azure supports this kind of cross-charging by optionally "tagging" Azure resources. These tags are visible on the monthly statement that is issued to the customer. The statement is also available as an Excel file.
Azure employs a subscription-based billing model. All subscriptions are bundled into the statement that comes with the enterprise enrolment. Depending on the technical implementation of solutions, enterprises can have only a few or hundreds of subscriptions. Either way, you should have in place a method of billing the costs associated with the Azure resources used to be able to maintain transparency and control in the billing process. Very often a change of the cost center model is considered to reflect the new cost quality.
In addition to the aforementioned resource tagging option, most customers rename the Azure subscription to include pertinent information such as the cost center. Others add the department name or the name of the project owner. Each of these solutions work if no changes occur, such as assigning new cost centers or assigning a new project owner. If that happens, you must change the respective subscription names manually.
Whether your company can use this kind of model also depends on the way you are using Azure and how many Azure subscriptions you can handle. There is no one-size-fits-all approach to the question of how many subscriptions a company should have. Some companies choose to have as few as possible while watching the limits of a single subscription.
Other companies have decided to go for a more granular approach and assign at least one subscription to each project they start. Both solutions as well as the myriad variations have their limits. In the limited-subscription model, you might reach the upper limit of a resource type and need to expand to more subscriptions. However, purchasing many subscriptions become a complex billing problem and maybe the issue of connecting resources that reside within the subscriptions. Depending on the customer's products, you must define technical and security models.
Security standards and policies
When transitioning to the cloud, security plays a crucial role for all enterprises, and Microsoft is constantly working on the products to adopt to latest developments and support customers' security requirements where possible.
A good starting point for security and Azure is the Trust Center. Here, customers can take advantage of a collection of resources that are specific to the topic. Customers in highly regulated industries like healthcare, or government entities, need to verify that the services of Azure comply with applicable security controls.
The Cloud Security Alliance (CSA) has prepared the Cloud Control Matrix. You can use this matrix to assess the security risk of any cloud provider. As are many other reputable cloud providers, Microsoft is a member of the CSA.
The special landing page for Azure security provides you with further details about the available security measures that you can use to protect your company. This page also offers further guidance with respect to all Azure-related security topics.
When it comes to Azure governance and security, several options exist, and you must always perform a balancing act between customer usability and security. Beyond the high-level options mentioned earlier, per-subscription customers can avail themselves of the built-in Security Center or, on a more granular level, they can use Azure policies. The duty for the governance now is to define the framework which from then on cloud solution architects can use to protect the solutions that reside in Azure. For the latest recommendations on securing your Azure environment, visit the Azure Trust Center.
Rights and role model
Most companies established access rights and user roles for their IT services to support the business and fulfill regulatory requirements as well as to reflect organizational responsibilities and duties. An outsourcing contract is also very often a driver for rights and roles models.
To be able to maintain a clear pattern of duty and responsibility and have that reflected in the rights and role implementation, an adoption of the cloud permission models is highly advised.
With Azure, you can adopt a Role-Based Access Control (RBAC) model. In addition to the long list of built-in roles, you can create your own custom roles.
The best practice is to make use of the built-in roles as much as possible; only if none of these roles apply should you create a custom role. Sometimes roles and duties are mixed. These are technical roles that you can assign to users or groups. Assigning multiple roles to a given user makes it possible for that user to carry out his duties. We know of cases in which customers invested a lot of effort in creating a custom role like User/Group/Computer-Operator, but it would have been easier to assign several existing roles to the users for the same purpose.
Tenant and subscription management
As part of the rights and role model, you must incorporate a new component, the Azure tenant and subscription model. It should reflect your design considerations for Azure tenancy. To help you understand better, the following is Microsoft's description of a tenant:
"In the cloud-enabled workplace, a tenant can be defined as a client or organization that owns and manages a specific instance of that cloud service. With the identity platform provided by Microsoft Azure, a tenant is simply a dedicated instance of Azure Active Directory that your organization receives and owns when it signs up for a Microsoft cloud service such as Azure or Office 365."
More info You can learn more by going to https://docs.microsoft.com/azure/activedirectory/active-directory-whatis.
Each Azure tenant can have multiple Azure subscriptions assigned to it, and these should be managed following a dedicated rights and role model. When it comes to deciding whether to have one or multiple tenants, you need to consider several aspects, some technical as well as organizational:
With the number of tenants, the complexity of the solution grows significantly. We recommend that you limit the number to the absolute minimum. Allow new tenants only if your organization is prepared and they have a dedicated purpose that matches the effort. Some of the most common reasons we see for customers to consider multiple tenants are the following:
More info To learn more about subscription and account management, you can go to https://docs.microsoft.com/azure/virtual-machines/windows/infrastructure-subscription-accounts-guidelines.
Azure administration
Typically, Azure administration is understood to mean using the Azure administrative portal to carry out the tasks related to the solution you are developing. However, when it comes to Azure governance, administration might require a more holistic approach. Depending on your duties and tasks, you might need to visit one of the Azure portals listed in Table 1-2. Table 1-2: Azure administration
Portal | URL | Purpose |
Azure Enterprise portal | Managing the EA and creating department/account levels | |
Azure portal (old) | The first Azure portal. Newer services are not available through this interface. | |
Azure portal | The standard portal to work with Azure | |
Azure Account portal | Managing the subscriptions that are assigned to a specific account level. | |
Office 365 portal | Managing the Office 365 productivity suite with a direct link to manage Azure Active Directory |
Which portal you should use will depend on your business needs.
License management
Usually, each Azure service is licensed as a pay-as-you-go model. The same is true for follow-on support of the service. Some services come with support included in the monthly fee; for others you might need to pay an extra fee. Be sure to read the summary of every installation to get the latest information about the licensing and support model it uses. We recommend contacting your Microsoft sales representative, who might be able to save you license fees through a negotiated EA or through the Azure Hybrid Benefit.
In Microsoft terminology, license management usually was counting the servers or workstations as well as the installed products. This approach was mostly quantitative and did not focus on the individual user. Still, when it comes to Azure, licenses are needed, but they mostly come with subscriptions like Azure subscriptions or Office 365 subscriptions. Again, these are quantitative. When it comes to server products and operating systems, it's a different story. Some of them are automatically licensed when installed via the Azure portal. Still some need additional licenses sometimes even from third-party providers. So, if you use third-party products, you will receive a separate bill from that software provider.
License assignment
Having acquired the licenses on the operating system or the server products may result in the need to allocate the license to the product. Allocation can be done manually by entering license keys into products or by using tools from the vendor to ensure the proper usage of licenses. Please consult the relevant product documentation for virtual machine licensing.
A very different method applies to the subscription-based model of, for instance Office 365 or Azure AD. Acquired licenses can be assigned to your tenant and you can see them in the portal. Still, a peruser assignment of licenses is required. Here are some examples for licensing yourself and your users in Azure Active Directory.
Your organization as well as your technical implementation must pay attention to the life cycle of a user and make sure the right licenses are allocated to the right user object. Very often this process is added to the Identity and Access Management (IAM) processes that are already in place.
Naming Conventions
Very often, a significant amount of effort is put into creating naming conventions. If such conventions exist in your company an adoption of the resources within Azure is required.
Here are the main areas of definition:
Some of the conventions can become very granular and a few resources like storage accounts come with their own restrictions because of internet regulations (RFCs).
For resources that are required to be unique across a region or even the entire Azure platform, a definition that is too strict can be too tight. You can use a naming element that serves as a break-free component—for example, a counter or a random string at the tail—to circumvent the constraint. For further details, refer to the Azure Naming conventions.
Keep in mind that sometimes you might use the command-line interface (CLI) or PowerShell to handle Azure resources. But also, you might sometimes use the Azure portal. Your naming convention should take into account that requirement and insert a distinct qualifier at the beginning of a name instead of putting it at the end where it might be truncated in dialogs.
Next to the functional changes that could be needed to drive your company's digital transformation, another scope requires attention: the organization. Although the first part can be very often described and written down and affects people indirectly, the organizational readiness is directly aimed at empowering your employees.
New technologies, new ways of interacting, or new ways of delivering service inside the company or to our customers are huge changes, especially for established organizations. This kind of disruptive approach, which very often is used to be more successful or copy competitors, sometimes puts an enormous strain on the workforce. Examples are AirBnB and the hotel industry, and Uber and the taxi industry. To avoid AirBnB taking away more and more customers, hotel companies needed to react. The same is true for the cab operators.
Now, for organizations to deliver something similar to Uber or AirBnB and to make sure they also find a new home in the changed world, some companies even use change agents during the process.
The following sections describe approaches that have proven to be valuable for enterprises having the organizational scope in mind.
Cloud competence center
Many customers have found it helpful to establish a "Center of Knowledge" for Azure within their organization. The intention behind that decision is to create a pool of knowledge from which others in the organization can learn. This group can help define blueprints to make sure all of the needed requirements such as security, operations, models, and so on are considered while the new, cloudbased solution is designed and implemented.
There are a lot of training programs available to help companies successfully make the transition to Azure and to build up a highly skilled team. Which program you choose very much depends on your business. Financial considerations are another aspect that you should consider.
There are many online courses as well as instructor-led courses available. Many of them are free of charge. Some are delivered through partners and certified trainers. Table 1-3 provides information about some of these courses.
Table 1-3: Azure training and certification
Topic | Resource |
General skill training | |
Microsoft Virtual Academy | https://mva.microsoft.com/search/SearchResults.aspx#!q=Azure |
Azure certification | |
Design guidance, reference architectures, design patterns, and best practices | |
Azure Essentials |
Following are typical areas of technology and knowledge:
Many customers use this opportunity to review their current IAM system and modernize it to prepare it for new tasks. A profound knowledge about identities, the relation to Azure Active Directory, and its security options should reside in the aforementioned competence center. Typical areas of interest are around the following use cases:
After you have designed the identity integration and identity life cycle, we recommend a use case–based approach to ensure that all applications, on-premises and cloud based, can consume the identities the users will be assigned:
Multiple ways exist to securely connect your on-premises network to your private segment in Azure or give your next business application a secure home in any of your subscriptions even without direct connectivity to your backbone. You can find a comprehensive list of options in the Architecture/Connectivity section of this document.
As with identities, your competence center should be knowledgeable in all aspects of networking and how to connect to Azure.
Development of methodology for cloud integration
One of the major purposes of a Cloud Competence Center in many enterprises is to define standards and develop methodologies for adoption of Azure services. This ensures a higher level of quality and makes sure that a good reuse of knowledge is achieved as well as a permanent alignment with the latest business or security requirements.
Development of cloud-integration blueprints: enterprise level
Some business solutions are designed for internal use only and have the individual contributor in the company as target for the implementation.
Based on the solution's requirements, the competence team should develop technology blueprints that ensure that the overall architecture of Azure with its tenant decisions, network recommendations, operational requirements, and so on are used and a proper SLA can be put on the final implementation.
Development of cloud-integration blueprints: partners, suppliers, and customers
Some other solutions are designed to cooperate with partners or are aiming directly at the customer. Depending on the business of your enterprise, additional blueprints might be needed to serve as a starting point for solutions that are accommodating that purpose.
Special attention should be paid to the topic of identity, network, and security. These areas are to be expected to become very complex depending on the scale of the solution or the integration needs of the solution.
When an enterprise adopts Microsoft Azure as its cloud platform, it will use many different services that are owned and managed by multiple individuals. To allow for governance of its resources, Azure provides some general features, as illustrated in Figure 2-1.
Figure 2-1: The building blocks of Azure governance
You should use Naming Standards to better identify resources in the portal, on a bill, and within scripts; for example:
You can use Azure Policies to establish conventions for resources in your organization. By defining conventions, you can control costs and more easily manage your resources. For example, you can specify that only certain types of virtual machines (VMs) are allowed, or you can require that all resources have a particular tag. Policies are inherited by all child resources. So, if a policy is applied to a resource group, it is applicable to all of the resources in that group. You can use Azure Policies at the subscription level to enforce the following:
The Azure Activity Log is a log that provides insight into the write operations that were performed on resources in your subscription (previously known as "Audit Logs" or "Operational Logs"). Using the Activity Log, you can determine the "what, who, and when" for any write operations (PUT, POST, and DELETE) taken on the resources in your subscription. You can also understand the status of the operation and other relevant properties. You can integrate the Activity log into existing auditing solutions.
You apply tags to your Azure resources to logically organize them by categories. Each tag consists of a key and a value. Use resource tags to enrich your resources with metadata such as the following:
A resource group is a container that holds related resources for an Azure solution. The resource group can include all of the resources for the solution, or only those resources that you want to manage as a group. You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization. Following are some considerations regarding resource groups:
Azure Role-Based Access Control (RBAC) gives you fine-grained access management for Azure. Using RBAC, you can grant only the amount of access that users need to perform their jobs. You should use predefined RBAC roles where feasible, and define custom roles where needed. You should follow the principle of granting the least required privilege.
As an administrator, you might need to lock a subscription, resource group, or resource to prevent other users in your organization from accidentally deleting or modifying critical resources. You can set the lock level to CanNotDelete or ReadOnly. When you consider using Azure resource locks to protect resources from unintended deletion, assign Owner and User Access Administrator roles only to people you want to allow removing locks.
Azure Automation provides a way for users to automate the manual, long-running, error-prone, and frequently repeated tasks that are commonly performed in a cloud and enterprise environment. You can use Azure Automation to define runbooks that can handle common tasks such as shutting down unused resources and creating resources in response to triggers. With Azure Automation, you can do the following:
Azure Security Center helps you to prevent, detect, and respond to threats with increased visibility into and control over the security of your Azure resources. It provides integrated security monitoring and policy management across your Azure subscriptions, helps detect threats that might otherwise go unnoticed, and works with a broad ecosystem of security solutions. You can use the Security Center to keep control of the security status of resources in your subscriptions:
In the next subsections, we do some deep dives into selected topics that you should consider when starting out with Azure as your public cloud platform. You also should refer to Azure Onboarding Guide for IT Organizations. The intent of that document is to help customers that are new to Azure to get underway. It explains the basic concepts of Azure, whereas the guide you're reading now provides a blueprint and best practices to roll out Azure on a large scale for customers with solid knowledge and experience with Azure. Table 2-1 provides resources on Azure architecture.
Table 2-1: Architecture resources
The first thing to understand about cloud security is that there are different scopes of responsibility, depending on what kind of services you are using. In Figure 2-2, green indicates areas of customer responsibility, whereas blue areas are the responsibility of Microsoft.
Figure 2-2: Scope of security responsibility
For example, if you are using VMs in Azure (infrastructure as a service, or IaaS), Microsoft is responsible for securing the physical network and storage as well as the virtualization platform, which includes patching of the virtualization hosts. But you will need to take care of securing your virtual network and public endpoints yourself as well as patching the guest OS of your VMs.
This document focuses on the customer responsibilities. Microsoft responsibilities are not within the scope of this document. Table 2-2 lists where you can find a whitepaper covering that topic. Table 2-2: Security resources
Topic | Resource |
Security responsibility | https://azure.microsoft.com/resources/videos/azure-security101-whose-responsibility-is-that/ |
Microsoft measures to protect data in Azure | |
Azure Security | |
Microsoft Whitepaper Security Incident Response |
Securing a modern enterprise is complex and challenging. Microsoft's cybersecurity portfolio can help you to do the following:
Following are the pillars of a secure modern enterprise (see Figure 2-3):
Figure 2-3: Components of a secure modern enterprise
Phase 1: Build the security foundation
The Securing Privileged Access (SPA) roadmap helps you to implement your security foundation (see Figure 2-4). This roadmap is structured in three stages. In stage 1, you mitigate the most frequently used attack techniques of credential theft by doing the following:
Figure 2-4: Build the security foundation phases
You can implement stage 2 of the roadmap in one to three months and build on the mitigations of stage 1:
Stage 3 of the SPA roadmap strengthens and adds mitigations across the spectrum, allowing for a more proactive posture:
Phase 2: Secure the pillars
The next step after covering the basics of your security foundation is to adopt additional, leadingedge security technologies, including threat detection and better intelligence:
Table 2-3 lists the needed security resources.
Table 2-3: Security resources
Topic | Resource |
Cybersecurity reference architecture | https://mva.microsoft.com/training-courses/cybersecurity-referencearchitecture-17632 |
SPA roadmap | |
ESAE | |
PAW |
It's a universal concept: When you want to protect something, build a perimeter around it.
Traditionally, in IT this perimeter is at the network level in the form of a firewall. A network perimeter has the purpose of repelling and detecting classic attacks but is reliably defeated by phishing and credential theft. At the same time, your data is moving out of the organization via approved or unapproved cloud services. Last but not least, employees need to keep productive wherever they are, using whatever device they carry with them, meaning that your data might be accessed by unmanaged devices. Matching these new challenges requires you to build a new kind of perimeter in addition to your existing network perimeter: an identity security perimeter.
Why you need an identity security perimeter
Identity controls access to your data. To protect your data, protect it directly at the front door by implementing multifactor authentication and conditional access. Conditions for access might depend on the user's current location (or IP address), on the user's device state, or the user's general risk score. If any of these configurable conditions are met, a modern identity system either challenges the user for a second authentication factor or denies access entirely.
What challenges must be matched
Table 2-4 lists what strategies are used to overcome specific challenges and which Microsoft solution you can employ to implement a specific strategy.
Table 2-4: Cloud security challenge matrix
Challenges | Strategy | Solution |
Phishing reliably gains foothold in environment Credential theft allows traversal within environment | Time of click (versus time of send) protection and attachment detonation Integrated intelligence, reporting, policy enforcement Securing privileged access roadmap to protect Active Directory and existing infrastructure | Microsoft Office 365 Advanced Threat Protection Azure Active Directory Identity Protection, Conditional Access Advanced Threat Analytics |
Shadow IT SaaS management | Discover SaaS usage Investigate current risk posture Take control to enforce policy on SaaS tenants and data | Cloud App Security |
Limited visibility and control of sensitive data Data classification is large and challenging | Protect data anywhere it goes Bring or hold your own key Support most popular formats Integration with existing Data Loss Prevention (DLP) systems | Azure Information Protection and Azure Rights Management Edge DLP Endpoint DLP |
Provide secure PCs and devices for sensitive data Manage and protect data on non-corporate devices | Provide a great user experience, hardwarebased security, and advanced detection + response capabilities Mobile Device Management (MDM) and Mobile App Management (MAM) of popular devices via Intune Policy enforcement via Conditional Access | Windows 10 Intune MDM/MAM, Conditional Access System Center Configuration Manager + Intune |
Protect broad attack surface that includes applications, infrastructure, management and administrative practices | Protect Privileged Identities:
Harden Private Cloud Fabric
Secure workloads in the cloud and onpremises
| Active Directory MIM PAM Implement PAW Pattern Credential Guard Controls Flow Guard Windows Defender |
Increased complexity by adding cloud data centers to existing on-premises infrastructure Limited IT security knowledge and tooling to secure cloud/hybrid infrastructure | Broad and deep visibility—get insights into security of your hybrid cloud infrastructure and workloads Provide familiar capabilities—via Security Information and Event Management (SIEM) integration and security capabilities in Azure Marketplace Start with high security—Secure platform, rapidly find and fix basic security issues, critical capabilities | Operations Management Suite Security Center, Threat Protection and Threat Detection Security Appliances from Azure Marketplace DDoS attack mitigation, Backup and Site Recovery, Network Security Groups, Disk and Storage Encryption, Azure Key Vault, Azure Antimalware, SQL Encryption and Firewall |
A Microsoft cybersecurity architect can provide expert advice and help you to build your security roadmap and support the successful integration into your organization. Table 2-5 lists the available resources.
Table 2-5: Identity security perimeter resources
Topic | Resource |
Microsoft Data Guard | |
Microsoft Control Flow | https://msdn.microsoft.com/library/windows/desktop/mt637065(v=vs.85).aspx |
Shielded VMs | https://docs.microsoft.com/system-center/vmm/guarded-deploy-vm |
Azure Site Recovery | |
Azure Backup | |
Key Vault | |
Azure Antimalware | https://docs.microsoft.com/azure/security/azure-security-antimalware |
Security Center | https://docs.microsoft.com/azure/security-center/security-center-intro |
Privileged Identity Management | |
DLP | |
Office 365 Advanced Threat Protection | |
System Center Configuration Manager | https://www.microsoft.com/cloud-platform/system-center-configurationmanager |
Intune MDM | |
Intune MAM | |
Azure AD Conditional Access | https://docs.microsoft.com/azure/active-directory/active-directory-conditionalaccess |
Windows 10 Security | https://docs.microsoft.com/windows/threat-protection/overview-of-threatmitigations-in-windows-10 |
Data is one of the most valuable assets that companies have, and it is critical that this asset is protected against unauthorized access or hostage takers. Access is controlled by giving authenticated users the authorization to read, change, or delete data. Some data might be less critical than other data; that is, information might be publicly available or strictly confidential.
Most companies already have a data classification policy in place. You will need to understand how using Azure as an application platform will affect this policy.
Table 2-6 presents examples of data classes that you might want to differentiate. Table 2-6: Data classification example
Class | Example |
Public | Announced corporate financial data |
Low business impact | Age, gender, or ZIP code |
Moderate business impact | Address, operating procedures |
High business impact | Design and functional specifications |
For each data protection class, your policy should define at least the following:
Review your data protection policy regularly; for instance, once every two years to keep it up to date with new technologies and changes in jurisdiction.
Table 2-7 lists the different features that Azure provides for you to implement your data protection policies.
Table 2-7: Customer-configurable protection options in Azure
Topic | Resource |
Volume-level encryption | https://docs.microsoft.com/azure/security/azure-security-diskencryption |
Key management | |
SSL certificates | https://docs.microsoft.com/azure/app-service-web/web-sites-purchasessl-web-site |
SQL Database encryption | |
Azure Rights Management services | https://docs.microsoft.com/information-protection/understandexplore/what-is-azure-rms |
Azure Information Protection | https://docs.microsoft.com/information-protection/understandexplore/what-is-information-protection |
Azure Information Protection samples | https://github.com/Azure-Samples/Azure-Information-ProtectionSamples |
Microsoft Azure Information Protection is a very powerful solution to enforce the appropriate protection of documents and emails according to your data protection policies.
Using Azure Information Protection, documents are classified at creation-time (see Table 2-8). The document is encrypted from creation for the rest of its life cycle. When an authenticated user has the appropriate permissions according to the applied policy, the document is decrypted, and the user is able to open it—independent of the current location of the document. Table 2-8: Data classification resources
Topic | Resource |
Carnegie Mellon University Guidelines for Data Classification | http://www.cmu.edu/iso/governance/guidelines/data-classification.html |
Microsoft Data Classification Wizard | |
Microsoft Data Classification Toolkit | |
Azure Rights Management | https://docs.microsoft.com/information-protection/understandexplore/what-is-azure-rms |
Protecting data in Microsoft Azure |
Managing data location
When you create an Azure storage account, you define in which Azure datacenter region you want your storage to be located. By choosing one of the following storage redundancy options, you determine how often and to which location your data will be replicated:
For some Azure services, you also have the option to choose a geo-replication location at the application level. Table 2-9 provides the links to read more.
Table 2-9: Data location management resources
Topic | Resource |
Azure SQL Database | https://docs.microsoft.com/azure/sql-database/sql-database-georeplication-portal |
Azure Cosmos DB | https://docs.microsoft.com/azure/documentdb/documentdb-distributedata-globally |
Azure Service Bus | https://docs.microsoft.com/azure/service-bus-messaging/service-busoutages-disasters |
Region Pairs | https://docs.microsoft.com/azure/best-practices-availability-paired-regions |
Ensure that you are storing data in regions according to applicable laws for different countries.
Encryption
If encryption at rest is a required step to be compliant with your enterprise's data protection policy, you should consider implementing the following:
Key management for encryption is an integral part of any data protection solution. You can use Key Vault to manage keys required for any type of encryption in a secure, configurable, auditable, and monitorable way. Optionally, you can use a hardware security module (HSM) with Key Vault.
To protect your data in transit, always use Secure Sockets Layer (SSL)/Transport Layer Security (TLS) whenever data is shipped to different locations. Where possible, you should use IPSec tunnels or a dedicated high-speed WAN link such as Azure ExpressRoute to protect all data in transit. Table 2-10 presents additional resources on encryption.
Table 2-10: Encryption resources
Topic | Resource |
Encryption best practices | https://docs.microsoft.com/azure/security/azure-security-dataencryption-best-practices |
Azure Disk Encryption | https://docs.microsoft.com/azure/security/azure-security-diskencryption |
SQL data encryption | |
SSE | https://docs.microsoft.com/azure/storage/storage-service-encryption |
Key Vault | |
HSM support for Key Vault |
Threat management consists of three phases:
Follow these recommendations to implement your threat management strategy:
Figure 2-5 presents an overview of the Microsoft threat protection architecture.
Figure 2-5: Microsoft threat protection
Azure offers built-in advanced threat detection functionality through services like Azure Active Directory (refer to Chapter 3 for details) and Security Center. This collection of security services and capabilities provides a simple and fast way to understand what is happening within your Azure deployments.
Operations Management Suite is Microsoft's cloud-based IT management solution that helps you to manage and protect your on-premises and cloud infrastructure. In addition to providing valuable services on its own, Operations Management Suite can integrate with System Center components such as System Center Operations Manager to extend your existing security management investments into the cloud. System Center and Operations Management Suite can work together to provide a full hybrid management experience.
The Operations Management Suite Security And Audit dashboard, shown in Figure 2-6, provides a comprehensive view into your organization's IT security posture with built-in search queries for notable issues that require your attention. The Security And Audit dashboard is the home screen for everything related to security in Operations Management Suite. It provides high-level insight into the security state of your computers.
Figure 2-6: The Operations Management Suite Security And Audit dashboard
Operations Management Suite dashboards help you to quickly and easily understand the overall security posture of any environment, all within the context of IT operations, including software update assessment, antimalware assessment, and configuration baselines. Furthermore, security log data is readily accessible to streamline the security and compliance audit processes.
Security Center provides integrated security monitoring and policy management across your Azure subscriptions. Within the service, you are able to define polices against your Azure subscriptions and Resource Groups. Microsoft security researchers have access to an expansive set of telemetry gained from Microsoft's global presence in the cloud and on-premises. This wide-reaching and diverse collection of datasets makes it possible to discover new attack patterns and trends. Thus, Security Center can rapidly update its detection algorithms as attackers release new and increasingly sophisticated exploits.
Security Center threat detection works by automatically collecting security information from your Azure resources, the network, and connected partner solutions. It analyzes this information, correlating information from multiple sources to identify threats. Security alerts are prioritized in Security Center along with recommendations on how to remediate the threat.
In addition to using Azure built-in services, you should establish the following professional services to detect and respond to threats (see also Table 2-11):
Table 2-11: Threat management resources
Topic | Resource |
Azure Advanced Threat Detection | https://docs.microsoft.com/azure/security/azure-threat-detection |
Operations Management Suite | https://docs.microsoft.com/azure/operations-managementsuite/operations-management-suite-overview |
Security Center | https://docs.microsoft.com/azure/security-center/security-center-intro |
Enterprise Threat Detection | |
Persistent Adversary Detection Service | |
Investigation & Recovery | |
Incident Response offering | https://www.microsoft.com/microsoftservices/campaigns/cybersecurityprotection.aspx |
As more and more of a company's digital resources reside outside the corporate network, in the cloud and on personal devices, a great cloud-based identity and access management solution is the best way to maintain control over, and visibility into, how and when users access corporate applications and data.
Azure Active Directory (Azure AD) is Microsoft's multitenant cloud-based directory and identity management service. All Microsoft online business services rely on Azure AD for sign-in and other identity needs. If you subscribe to any Microsoft online business, you get Azure AD with access to all free features. To enhance your Azure AD, you can add paid capabilities using the Azure Active Directory Basic, Premium P1, and Premium P2 editions. Here's what each one offers:
Table 2-12 summarizes the features offered by each Azure AD edition.
Table 2-12: Azure AD feature overview
Azure AD edition | Features |
Free |
|
Basic |
|
Premium P1 |
|
Premium P2 |
|
When implementing your SPA roadmap, the features of Premium P2 are of great importance.
Azure AD Identity Protection is a feature of the Azure AD Premium P2 edition that provides you with an overview of the risk events and potential vulnerabilities affecting your organization's identities. Identity Protection uses existing anomaly detection capabilities in Azure AD, which are available through its Anomalous Activity Reports.
Identity Protection uses adaptive machine learning algorithms to detect that an identity might have been compromised. Using this data, Identity Protection generates reports and alerts with which you can investigate and take appropriate mitigation action.
Based on risk events, Identity Protection (Figure 2-7) calculates a user risk level for each user so that you can configure risk-based policies to automatically protect the identities of your organization.
These risk-based policies, in addition to other conditional access controls provided by Azure AD and Enterprise Mobility + Security (EMS), can automatically block or offer adaptive remediation actions that include password resets and multifactor authentication enforcement.
Figure 2-7: Azure AD Identity Protection
With Azure AD Privileged Identity Management, you can manage, control, and monitor access within your organization. This includes access to resources in Azure AD and other Microsoft online services like Office 365 or Microsoft Intune.
Azure AD Privileged Identity Management helps you to do the following:
Hybrid identity is achieved by integrating your on-premises Active Directory with Azure AD using Azure AD Connect. You can use this to provide a common identity for your users for Office 365, Azure, and on-premises apps or SaaS applications integrated with Azure AD. With hybrid identity, you effectively extend your on-premises environment to the cloud for identity and access.
With Windows 10, Azure AD Enterprise State Roaming users gain the ability to securely synchronize their user settings and application settings data to the cloud to achieve the following:
In addition to the features included in the different Azure AD editions, there are several Azure AD satellite services available, which we look at next.
Azure AD business-to-business
Azure AD business-to-business (B2B) collaboration capabilities make it possible for any organization using Azure AD to work safely and securely with users from any other organization, small or large. Azure AD B2B brings the following key features to you:
Work with any user from any partner
Simple and secure collaboration
No management overhead
Azure AD business-to-cloud
Azure AD business-to-cloud (B2C) is a cloud identity management solution for your web and mobile applications. It is a highly available global service that scales to hundreds of millions of identities.
With Azure AD B2C, your application can authenticate to the following:
Azure AD Domain Services
Azure AD Domain Services provides managed domain services such as domain join, group policy, Lightweight Directory Access Protocol (LDAP), Kerberos/NTLM authentication that are fully compatible with Windows Server Active Directory. You can consume these domain services without the need for you to deploy, manage, and patch domain controllers in the cloud. Azure AD Domain Services integrates with your existing Azure AD tenant, thus making it possible for users to sign in using their corporate credentials. Additionally, you can use existing groups and user accounts to secure access to resources, thus ensuring a smoother "lift-and-shift" of on-premises resources to Azure Infrastructure Services. Azure AD Domain Services functionality works seamlessly regardless of whether your Azure AD tenant is cloud-only or synchronized with your on-premises Active Directory. Table 2-13 provides a list of security resources that you can use with Azure AD.
Table 2-13: Identity security resources
Each Azure subscription is associated with an Azure AD tenant (see Figure 2-8). Azure AD manages identities on a tenant level. Those identities are used to grant access to resources for individuals. You can have multiple Azure AD tenants—for example, for production, QA, and development environments—but each Azure subscription can be associated with just one of those Azure AD tenants.
Table 2-8: Azure AD tenant-to-subscription relationship
Nevertheless, you can grant permissions on Azure resources to identities from other Azure AD tenants—either development tenants or tenants of business partners—by using Azure AD B2B features, as shown in Figure 2-9.
Table 2-9: Identities using Azure resources
Enterprise customers usually keep their on-premises Active Directory as the leading identity management system (see Figure 2-10). To use your existing identities, you need to synchronize all identities to Azure AD. SSO is supported by either synchronizing users' password hash between Active Directory and Azure AD by using Azure AD Connect or setting up Active Directory Federation Services for authentication or using pass-through authentication.
Figure 2-10: Identities managing subscriptions
You can join Azure VMs to a domain in two ways:
Most enterprise customers currently choose to extend their on-premises domain to Azure. Following best practices, you will implement at least a redundant pair of domain controllers in an Azure hub virtual network and configure a dedicated domain site for Azure for each Azure geo.
Table 2-14: Domain resources
Topic | Resource |
Azure AD (including Azure AD Domain Services) | https://docs.microsoft.com/azure/architecture/referencearchitectures/identity/azure-ad |
Active Directory Connect | https://docs.microsoft.com/azure/active-directory/connect/activedirectory-aadconnect |
Federated authentication | https://docs.microsoft.com/azure/architecture/referencearchitectures/identity/adfs |
Pass-through authentication | |
Azure AD seamless SSO | https://docs.microsoft.com/azure/active-directory/connect/activedirectory-aadconnect-sso |
Extending on-premises domain into Azure IaaS | https://docs.microsoft.com/azure/architecture/referencearchitectures/identity/adds-extend-domain |
Setting up datacenters on Azure | https://docs.microsoft.com/azure/active-directory/active-directorydeploying-ws-ad-guidelines |
How Azure subscriptions are associated with Azure AD | |
RBAC in Azure | https://docs.microsoft.com/azure/active-directory/role-basedaccess-control-what-is |
Using the Azure Virtual Network service, you can securely connect Azure resources to one another by using virtual networks. A virtual network is a representation of your own network in the cloud. A virtual network is a logical isolation of the Azure cloud dedicated to your subscription. You also can connect virtual networks to your on-premises network.
Virtual networks are isolated from one another. You can create separate virtual networks for development, testing, and production that use the same CIDR address blocks. Conversely, you can create multiple virtual networks that use different CIDR address blocks and connect networks together. You can segment a virtual network into multiple subnets. Azure provides internal name resolution for VMs and Cloud Services role instances connected to a virtual network. You can optionally configure a virtual network to use your own DNS servers, instead of using Azure internal name resolution.
All Azure VM connected to a virtual network have access to the internet, by default. You can also turn on inbound access to specific resources, as needed.
You can connect Azure resources such as Cloud Services and VMs to the same virtual network. The resources can connect to one another using private IP addresses, even if they are in different subnets. Azure provides default routing between subnets, virtual networks, and on-premises networks, so you don't need to configure and manage routes.
You can connect virtual networks to one another; thus, resources connected to any virtual network can communicate with any resource on any other virtual network.
You can connect virtual networks to on-premises networks through private network connections between your network and Azure, or through a site-to-site Virtual Private Network (VPN) connection over the internet.
You can filter inbound and outbound VM and Cloud Services role instances network by source IP address and port, destination IP address and port, and protocol.
You can optionally override Azure's default routing by configuring your own routes, or by using Border Gateway Protocol (BGP) routes through a network gateway. Table 2-15 provides a link to additional connectivity information.
Table 2-15: Connectivity resources
Topic | Resource |
Azure Virtual Networks | https://docs.microsoft.com/azure/virtual-network/virtual-networksoverview |
Connecting Azure virtual networks with your local network is referred to as hybrid networking. You can use the following concepts to access your virtual networks in Azure:
There is also the Service Bus Hybrid Relay option. This approach does not require a Layer 3 integration between your on-premises network and Azure; instead, it uses a secure socket connection via the internet.
To integrate your Azure-based resources with your on-premises resources, consider which network connectivity option fits best for you.
In Azure, ExpressRoute and VPN are both implemented physically redundant. If you need georedundancy, you will need to implement two separate ExpressRoute or VPN connections in different regions or even geo-locations.
For high availability with ExpressRoute, you should create ExpressRoute circuits with two different providers to provide resilience if one provider has a problem.
You can use the same concepts to integrate either Azure virtual networks to your on-premises networks or Azure virtual networks to Azure virtual networks—or Azure virtual networks to virtual networks in any other cloud. You can connect virtual networks with one another by using virtual network peering. Virtual network peering is generally available within a single region. (As of this writing, cross-regional peering is in public preview. As soon as it is generally available, Microsoft recommends using cross-regional peering instead of using an ExpressRoute circuit.) Many enterprise customers begin with an ExpressRoute circuit in one region.
Azure virtual networks in a region are typically organized in a hub-and-spoke network design pattern, as illustrated in Figure 2-11.
Figure 2-11: Hub-and-spoke network design sample
The hub virtual network contains the connection to the ExpressRoute circuit and any other centrally shared resources, like a next generation firewall and domain controllers for the new Azure site.
When setting up an Azure virtual network, you can configure whether to use Azure DNS service or your own DNS servers. Azure DNS automatically allows VMs in the same virtual network to resolve machine names to IP addresses as soon as a new VM is deployed. When using your own DNS server, you are responsible for creating appropriate DNS records for new VMs; that is, by joining them to your domain. Table 2-16 provides links to additional information.
Table 2-16: Hybrid networking resources
You can deploy a VM or any other resource only to a virtual network in the same subscription as the virtual network. Additionally, a virtual network can span only a single Azure region. If you need all of your resources to have a network connection to each other, but need to separate your resources into different subscriptions and/or regions, you must use dedicated virtual networks in each subscription/ region. To allow for network connectivity for resources in different virtual networks, it's possible to link virtual networks to one another. There are three options available to achieve this:
Virtual network peering can be used to connect two Azure virtual networks. Cross-regional peering is in preview at the time of writing. VNet2VNet VPN connections are IPSec tunnels that are initiated between two virtual network gateways located within each virtual network. This can be either an Azure virtual network gateway or a virtual appliance of your choice. All traffic routed between different Azure regions will never leave the Microsoft networking backbone. Using one of these first two options makes it possible for you to link your virtual networks either in a mesh or a hub-and-spoke design.
If you use the third option, an ExpressRoute circuit, you will be able to use this circuit as a transfer net for your virtual networks as long as the virtual networks are in the same region as the ExpressRoute circuit. Traffic between your virtual networks is routed via your ExpressRoute circuit and will not leave the Microsoft networking backbone. If you want to connect a virtual network from another region or geography, you must upgrade to ExpressRoute premium. Note that there are limits to how many virtual networks that you can connect to an ExpressRoute circuit. In this case (again), no network traffic leaves the Microsoft networking backbone. Figure 2-12 illustrates an example network topology of a customer with two subsidiaries connected to two Azure datacenter regions.
Figure 2-12: Sample network topology
Our customers' global network designs vary strongly. You can use any of the introduced building blocks to achieve the best individual solution, depending on your requirements. Table 2-17 provides links to global networking resources.
Table 2-17: Global networking resources
Topic | Resource |
Virtual network peering | https://docs.microsoft.com/azure/virtual-network/virtual-networkpeering-overview |
VNet2VNet VPN | https://docs.microsoft.com/azure/vpn-gateway/vpn-gateway-howtovnet-vnet-resource-manager-portal |
ExpressRoute circuit | https://docs.microsoft.com/azure/expressroute/expressroute-howtolinkvnet-portal-resource-manager |
ExpressRoute limits | https://docs.microsoft.com/azure/expressroute/expressroutefaqs#expressroute-premium |
Design considerations | https://docs.microsoft.com/azure/virtual-network/virtual-network-vnetplan-design-arm |
Azure virtual networks are isolated from one another. Optionally, you can link virtual networks as described in Chapter 3. Each virtual network supports the following default routing between devices:
Enterprise customers usually have a security requirement forbidding any internet-bound traffic unless routed via a dedicated internet break-out that is secured by a next-generation firewall. You can address this requirement by implementing any or all of the following measures:
To minimize potential threads, a general best practice for networking is separating internal- and external-facing resources in different virtual networks or subnets, as follows:
Figure 2-13 illustrates and example topology for a perimeter network with a multilayered application in Azure.
Figure 2-13: Sample perimeter network design in Azure
In Azure, monitoring is available on all network resources. Azure Network Watcher includes packet capture, next hop, IP flow verify, security group view, and NSG flow logs. Resource monitoring comprises diagnostic logs, metrics, troubleshooting, and resource health. Table 2-18: Network security resources
You can manage your Azure resources by using the Azure portal ( https://portal.azure.com) or via scripting (PowerShell, CLI, ARM, Rest API). Additionally, you can use domain policies to configure domain-joined VMs. Nevertheless, you might need to sign in to your Azure VMs for administrative purposes. There are several options available to do this in Azure, which you can see in Table 2-19. Table 2-19: Remote Access Options
Option | Comment |
RDP/SSH via public IP | A public IP in Azure assigned to your VM or a load balancer in front of your VM allows access to your VM https://docs.microsoft.com/azure/virtual-machines/windows/connectlogon https://docs.microsoft.com/azure/virtual-machines/linux/ssh-fromwindows |
RDP/SSH via jump box | A dedicated VM with a public IP is used to sign in from the internet. In a second hop within your virtual network, you connect to your other VM(s) Alternatively, you could configure P2S VPNs to the jump box from each machine you want to use for administration of Azure VMs. |
RDP/SSH via ER/VPN | No public IP required. From within your corporate network you access your VM via private IP address. |
Citrix XenApps Essentials | Via Citrix, an application running either in an Azure VM or on-premises can be published. Consumers can stream the screen output of the application. For more information go to https://channel9.msdn.com/ Events/Ignite/Australia-2017/INF431 |
RDS | Same as jump box approach, but using a terminal server to allow multiple users to sign in simultaneously. For more information go to https://blogs.technet.microsoft.com/hybridcloudbp/2017/01/09/quicklydeploy-rds-2016-in-azure/ |
Enterprise customers usually prefer to connect to Azure virtual networks via hybrid networking, hence enabling access through private IP addresses. This approach minimizes the attack vector because there are no additional public endpoints required.
All options based on a public IP address should be protected appropriately; for example, locate a jump box in a dedicated subnet and route all traffic between jump box and other subnets via a firewall. In case you are using a proxy on your corporate internet break out, make sure to configure RDP/SSH connections to Azure.
Application design is a huge topic, which we do not cover in detail in this document. The intent here is to give some idea as to what you need to consider when designing applications for the cloud.
Most applications today are not simple. They might consist of many separate features that are implemented as services, components, third-party plug-ins, and other systems or resources. Integrating these items when all of the components are hosted locally in your datacenter is not a trivial task, and it can become even more of a challenge when you move your applications to a cloudbased environment.
Classically, applications are broken down into three tiers: UI, business logic, and serialization. Within these three tiers, different components or functions serve different use cases. When it comes to scale, you can either scale-up within a tier or scale-out, adding additional servers to one of the tiers. If you need to add new functionality or fix a bug, the entire tier usually is updated, including various types of testing. When using microservices, the components within a classic tier are more loosely coupled, each having its own unique communication endpoint. This makes it possible for code and state to be individually versioned, deployed, and scaled, as illustrated in Figure 2-14.
Figure 2-14: Monolithic versus microservices architecture
Dealing with unexpected failures is one of the most difficult problems to solve, especially in a distributed system. What happens when the machine on which the microservice is running fails? We schedule microservices onto different compute nodes, use naming services so that they can locate one another. We can move microservice instances if they die, the compute node dies, or for capacity reasons. Ideally, a microservice is resilient to failures in dependent services and does not itself die when a dependent service fails.
Here are some of the more common problems an application architect still needs to consider:
These common problems are usually addressed by an underlying infrastructure fabric for microservices such as Kubernetes, Azure Service Fabric, Cloud Foundry, OpenShift, Docker Swarm, or DC/OS.
The benefits of a microservices-based architecture come at the cost of enhanced complexity. You need to control release management on the microservices level as well as implement and operate a microservices fabric infrastructure in addition to your application. Also, an overhead of network traffic between microservices must be considered. As a best practice, you should use a microservices-based architecture only if the gained benefits outweigh the higher complexity. In some cases, it might be sufficient to decompose a tier by using native Azure services such as Web and API Apps, Azure Functions, Storage or Service Bus Queues, and Logic Apps.
Table 2-20 provides links to resources where you can learn more about pros and cons of microservices-based versus monolithic applications design.
Table 2-20: Microservices versus monolithic sources
Topic | Resource |
Understanding microservices | https://docs.microsoft.com/azure/service-fabric/service-fabric-overviewmicroservices |
Service Fabric and microservices | |
Cloud Foundry | https://docs.microsoft.com/azure/virtual-machines/linux/cloudfoundry-getstarted |
OpenShift | https://blog.openshift.com/tag/azure/https://blog.openshift.com/tag/azure/ |
DC/OS | https://docs.microsoft.com/azure/container-service/dcos-swarm/ |
Building a reliable and performant application in the cloud is different than building it in an onpremises environment. Whereas historically you might have purchased higher-end hardware to scale up, in a cloud environment you must scale out instead of up. Costs for cloud environments are kept low by using commodity hardware. Instead of focusing on preventing failures and optimizing Mean Time Between Failures (MBTF), in this new environment, the focus shifts to Mean Time to Recovery (MTTR) with the goal of minimizing the impact of a failure.
The Table 2-21 gives a brief overview of the cloud design challenges and patterns to address them.
Table 2-21: Challenges in cloud development
Challenge | Patterns |
Availability | Availability can be affected by system errors, infrastructure problems, malicious attacks, and system load. Applications typically provide users with an SLA, so applications must be designed to maximize availability.
|
Data management | Data management influences most of the quality attributes. Data is typically hosted in different locations and across multiple servers for reasons such as performance, scalability, or availability, and this can present a range of challenges. For example, data consistency must be maintained, and data will typically need to be synchronized across different locations.
|
Design and implementation | Good design encompasses factors such as consistency and coherence in component design and deployment, maintainability to simplify administration and development, and reusability so that components and subsystems can be used in other applications and in other scenarios. Decisions made during the design and implementation phase have a huge impact on the quality and the total cost of ownership of cloud-hosted applications and services.
|
Messaging | The distributed nature of cloud applications requires a messaging infrastructure that connects the components and services, ideally in a loosely coupled manner in order to maximize scalability. Asynchronous messaging is widely used, and provides many benefits, but also brings challenges such as the ordering of messages, poison message management, idempotency, and more.
|
Managing and monitoring | Cloud applications run in a remote datacenter where you do not have full control of the infrastructure or, in some cases, the operating system. Applications must expose runtime information that administrators and operators can use to manage and monitor the system as well as support changing business requirements and customization without requiring the application to be stopped or redeployed.
|
Performance and scalability | Cloud applications typically encounter variable workloads and peaks in activity. Applications should be able to scale out within limits to meet peaks in demand, and then scale in when demand decreases. Scalability concerns not just compute instances, but other elements such as data storage, messaging infrastructure, and more.
|
Resiliency | Resiliency is the ability of a system to gracefully handle and recover from failures. The nature of cloud hosting, where applications are often multitenant, use shared platform services, compete for resources and bandwidth, communicate over the internet, and run on commodity hardware means there is an increased likelihood that both transient and more permanent faults will arise. Detecting failures, and recovering quickly and efficiently, is necessary to maintain resiliency.
|
Security | Security is the capability of a system to prevent malicious or accidental actions outside of the designed usage, and to prevent disclosure or loss of information. Cloud applications are often open to the public and may serve untrusted users. Applications must be designed and deployed in a way that protects them from malicious attacks, restricts access to only approved users, and protects sensitive data. |
Note that resiliency is the ability to recover from failures and continue to function. It's not about avoiding failures, but responding to failures in a way that avoids downtime or data loss. The goal of resiliency is to return the application to a fully functioning state after a failure. Two important aspects of resiliency are high availability and disaster recovery.
High availability
High availability (HA) is the ability of the application to keep running in a healthy state, without significant downtime. By "healthy state," we mean the application is responsive, and users can connect to it and interact with it.
Disaster recovery
Disaster recovery (DR) is the ability to recover from rare but major incidents; For instance, nontransient, wide-scale failures, such as service disruption that affects an entire region. Disaster recovery might include data backup and archiving, and can include manual interventions, such as restoring a database from backup.
Resiliency is not an add-on. It must be designed into the application and put into operational practice. We recommend following this general model when designing a resilient cloud app:
Please also use the Azure Architecture resiliency checklist for more detailed design considerations of your cloud app before starting to code.
In Azure, the SLA describes Microsoft's commitments for uptime and connectivity. You should define your own target SLAs for each workload in your solution. Think about the time window against which your SLA is measured. The smaller the window, the tighter the tolerances. It probably doesn't make sense to define your SLA in terms of hourly or daily uptime. A good practice is to work with monthly availability.
Also browse through the Azure reference architectures. We will add additional reference architectures and best practices to this list over time.
Table 2-22 lists additional resources on application design.
Table 2-22: Application design resources
Before we can talk about operations, we should look at the application landscape and the organization that is common for most enterprises.
Traditionally, enterprise IT organizations have their own datacenter infrastructure running the following:
These types of applications are primarily accessed by PCs and laptops. The new default in the digital world is to create and run business applications on top of Microsoft Azure; standard applications are consumed as platform as a service (PaaS) or software as a service (SaaS), and these applications are accessed by PCs, laptops, tablets, and phones. The reality for most organizations is that there is a mix of traditional on-premises applications and new, modern cloud applications, and operations must deal with that.
Companies often are organized similar to the depiction in Figure3-1.
Figure 3-1: A common corporate organization
The IT organization is headed by a CIO, and there is often a split in IT between the heads of infrastructure and app development. In the business units, there are typically leaders, the business leaders, and, again, a head of application development.
The role of applications is dramatically changing as part of digital transformation (Figure 3-2). Today, every company is becoming a software company. Applications are no longer just support, they are key differentiators. They are an important part of the business. This also means that the mindset to produce quality software has come to dominate.
Figure 3-2: Growing importance of software
Independent of the approach that will be taken for creating and running applications, it is necessary to think about the following three aspects:
The ability to develop and deliver software is an important piece of any organization's ability to deliver value to customers, pivot when necessary, beat competitors to market, and respond to regulatory and compliance requirements. Delivering value with software often requires a technology transformation, and these transformations necessitate improving key capabilities.
In the past, the most in-demand approach to project management was the Waterfall approach.
This is a linear and sequential approach that had separately set goals for each defined phase of the project: requirement definition, software design, implementation, testing, deployment, maintenance, retirement. The entire process of software development was divided into distinct processes, each having its own beginning and end, and each cascaded into the next process in a linear, "waterfall" fashion, as illustrated in Figure 3-3.
Figure 3-3: Waterfall approach to software development
But with the growing complexities and variations of the IT world, there came a need for a change in this typical approach. The Agile software methodology, shown in Figure 3-4, evolved as an incremental model in which the software is developed, tested, and implemented in incremental and rapid cycles. The results are incremental releases, with each release depending upon the previous release's operations and success ratio. The primary advantage is that errors and loopholes are addressed before the project goes live. But the time between the releases didn't typically change in comparison to the Waterfall approach.
Figure 3-4: Agile approach to software development
Still, some of the key business requirements, such as faster time to market and enhanced agility weren't being fulfilled by either of these approaches. Furthermore, the handoff from development to operations was very difficult and time consuming, and the knowledge from the development team never really moved to the operations team. Because of that, the development team continued to be involved during operations (change management, incident management, etc.)
In both approaches, developers didn't concern themselves with how to deploy a product or how to promote it in the target environment; developers were supposed to produce the code, implement new features, and not bother with its delivery. Usually, developers wrote code on desktop computers and had little or no interest in how production servers were configured. For its part, an operations team had no influence upon a development team and didn't worry about product development. Furthermore, operations and development teams belonged to different departments with different managers and success criteria.
Organizations regularly faced situations in which the provided code did not work in the staging environment or an operations team was not able to deploy it. The development team was armored with the same rejoinder: "But it was working on my workstation!"
Operations blamed development, development blamed the operations: it was a nonstop battle between the two teams leading to unpredictable delivery dates and all the further negative consequences.
We can summarize the problems with those approaches into the following issues:
DevOps was a response to the growing awareness that there has been a disconnect between what is traditionally considered a development activity and what is traditionally considered an operations activity. The development crew is employed to respond to change in an organization, and thus it is the goal of that team to ensure that there are continuous changes. On the other hand, the operational crew has a view of change being an enemy, owing to the fact that the business depends on operations to keep the lights on and maintain stability and reliability in the organization. Apparently, there are two areas of interest in a team which will, no doubt, create a wall of confusion between these two departments; hence, the need for DevOps (Figure 3-5) to break this wall and instead create a bridge that will allow for flow and quick deployments of deliverables in each life cycle. (See Figure 3-6.)
Figure 3-5: Changes versus stability Key characteristics are:
Figure 3-6: The DevOps approach
Governance is often left out of DevOps, but it also needs attention. DevOps is fundamentally changing the funding model for application development (Figure 3-7). In Waterfall and Agile development projects, we had predefined releases with a concrete set of functions and an estimated budget to deliver those. The business granted the budget separately for every release. In a DevOps model with Continuous Delivery and Continuous Integration, there must be continuous funding for the application development.
Figure 3-7: DevOps funding
DevOps is the most modern approach. It makes the business happier due to more frequent releases of an application and should be the default for all new software development projects, wherever possible.
DevOps is the union of people, process, and products to make possible the continuous delivery of value to your end users. The contraction of "Dev" and "Ops" refers to replacing siloed development and operations to create multidisciplinary teams that now work together with shared and efficient practices and tools. Essential DevOps practices include Agile planning, Continuous Integration, Continuous Delivery, and monitoring of applications. DevOps makes it possible for teams to deliver more secure, higher-quality solutions faster and cheaper.
Customers expect a dynamic and reliable experience when consuming software and services. Teams must rapidly iterate on software updates, measure the impact of the updates, and respond quickly with new development iterations to address issues or provide more value. Azure has removed traditional bottlenecks and helped commoditize infrastructure. Software reigns in every business as the key differentiator and factor in business outcomes. No organization, developer, or IT worker can or should avoid the DevOps movement.
Mature DevOps practitioners adopt several of the following practices. These practices involve people to form strategies based on the business scenarios. Tooling can help automate the various practices.
The following sections explain the DevOps culture and processes (based on some publications written by Sam Guckenheimer, Partner PM Manager at Microsoft) without focusing on specific technologies. You can achieve DevOps on Azure by using the Microsoft ecosystem or by using the open-source ecosystem. Table 3-1 provides links where you can find more information.
Table 3-1: DevOps resources
Topic | Resource |
Azure DevOps integrations | |
Complete DevOps solution | |
CI and deployment | |
DevOps on Azure |
DevOps culture
The DevOps culture stresses small, multidisciplinary teams, that work autonomously and take collective accountability for how actual users experience their software. For those working in DevOps, there's no place like production. Everything they do is about making the customers' live experience better.
DevOps teams apply Agile practices and include operations in the team responsibility. Teams work in small batches, focus on improving the end-to-end delivery of customer value, and strive to eliminate waste and impediments along the way. There are no silos and no blame game, because the team is mutually accountable.
DevOps teams apply a growth mindset. They make beliefs explicit, hypothesize impact to create better results, and implement the hypotheses as experiments. DevOps teams use monitoring and telemetry to gather evidence in production and observe results in real time. When evidence diminishes hypotheses, the experiences become opportunities to fail fast or gather validated learning quickly from the experiment. When evidence supports hypotheses, the team uses the opportunity to persevere, or double-down, on the actions that led to improvement.
In transitioning to DevOps, teams shift their priority from optimizing Mean Time Between Failure (MTBF) to Mean Time to Mitigate (MTTM) and Mean Time to Recovery (MTTR). Unlike in the past, when lengthy processes were designed to prevent changes that might lead to problems in the field, DevOps teams stress being able to move fast, understand the impact, and react quickly.
DevOps teams think in terms of competencies, not roles. Although they include both developmental and operational skills and awareness, they share responsibility for running the live site. This means that developers on the team accept responsibility for the health of the running services and will rotate time on-call. The principle is: if you build it, you run it.
Continuous Integration
Continuous Integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control. CI encourages developers to share their code and unit tests by merging their changes into a shared version-control repository after every small task completion. Committing code prompts an automated build system to grab the latest code from the shared repository and to build, test, and validate the full master branch.
CI emerged as a best practice because software developers often work in isolation, and then they need to integrate their changes with the rest of the team's code base. Waiting days or weeks to integrate code creates many merge conflicts, difficult-to-fix bugs, diverging code strategies, and duplicated efforts. With CI, the development team's code is merged to a shared version-control branch continuously to avoid these problems.
CI keeps the master branch clean. Teams can take advantage of modern version-control systems such as Git to create short-lived feature branches to isolate their work. A developer submits a "pull request" when the feature is complete, and on approval of the pull request, the changes are merged into the master branch. Then, the developer can delete the previous feature branch. Development teams repeat the process for additional work. The team can establish branch policies to ensure that the master branch meets desired quality criteria. Teams use build definitions to ensure that every commit to the master branch sets the automated build and testing processes in motion. By implementing CI this way, bugs are caught earlier in the development cycle, which makes them less expensive to fix. Automated tests run for every build to maintain consistent quality.
Continuous Delivery
Continuous Delivery (CD; Figure 3-8) is the process of building, testing, configuring, and deploying from a build to a production environment. Multiple testing or staging environments create a release pipeline to automate the creation of infrastructure and deployment of a new infrastructure. Successive environments support progressively longer-running activities of integration, load, and user acceptance testing (UAT). CI starts the CD process, and the pipeline stages each successive environment upon successful completion of tests.
Figure 3-8: Continuous Delivery
CD might sequence multiple deployment "rings" for progressive exposure. Progressive exposure groups users who try new releases to monitor their experience in rings. The first deployment ring is often a "canary," which you use to test new versions in production before a broader rollout. CD automates deployment from one ring to the next, which might optionally depend on an approval step, wherein a decision-maker signs off on the changes electronically. CD can create an auditable record of the approval to satisfy regulatory procedures or other control objectives.
Prior to CD, software release cycles were a bottleneck for application and operation teams. Manual processes led to unreliable releases that produced delays and errors. These teams often relied on handoffs that resulted in issues during release cycles. The automated release pipeline affords a fail fast approach to validation, in which the tests most likely to fail quickly are run first, and longer-running tests happen after the faster ones complete successfully.
CD is a lean practice. The goal of CD is to keep production fresh by achieving the shortest path from the availability of new code in version control or new components in package management to deployment. By automation, CD minimizes the Time-to-Deploy and Time-to-Mitigate (TTM) or Timeto-Remediate (TTR) production incidents. In lean terms, this optimizes process time and eliminates idle time.
CD is helped considerably by the complementary practices of Infrastructure as Code and Monitoring. Continuously delivering value has become a mandatory requirement for organizations. To deliver value to your end users, you must release continually and without errors.
Infrastructure as Code
Infrastructure as code (IaC) is the management of infrastructure (networks, VMs, load balancers, and connection topology) in a descriptive model, using the same versioning as the DevOps team uses for source code. Like the principle that the same source code generates the same binary, an IaC model generates the same environment every time it is applied. IaC is a key DevOps practice and is used in conjunction with CD.
IaC evolved to solve the problem of environment drift in the release pipeline. Without IaC, teams must maintain the settings of individual deployment environments. Over time, each environment becomes a snowflake; that is, a unique configuration that cannot be reproduced automatically. Inconsistency among environments leads to issues during deployments. With snowflakes, administration and maintenance of infrastructure involves manual processes that are difficult to track and contribute to errors.
Idempotence is a principle of IaC. Idempotence is the property that a deployment command always sets the destination environment into the same configuration, regardless of the environment's starting state. You achieve Idempotency by either automatically configuring an existing destination or by discarding the existing destination and re-creating a fresh environment.
Accordingly, with IaC, teams make changes to the environment description and version the configuration model, which is typically in well-documented code formats such as JSON. The release pipeline runs the model to configure target environments. If the team needs to make changes, it edits the source, not the target.
For Azure, you can use Cloud Deployment Projects that use Azure Resource Management application programming interfaces (APIs) to create and manage Azure Resource Groups. This makes it possible for you to describe your environments with JSON. Azure Resource Groups also give you the ability to manage group-related resources together, such as websites and SQL databases. With cloud deployment projects, you can store your provisioning requirements in version control and perform Azure provisioning as part of an automated release pipeline.
With IaC, DevOps teams can test applications in production-like environments, early in the development cycle. These teams expect to provision multiple test environments reliably and on demand. Infrastructure represented as code can also be validated and tested to prevent common deployment issues. At the same time, the cloud dynamically provisions and tears down environments based on IaC definitions.
Teams that implement IaC can deliver stable environments rapidly and at scale. They avoid manual configuration of environments and enforce consistency by representing the desired state of their environments via code. Infrastructure deployments with IaC are repeatable and prevent runtime issues caused by configuration drift or missing dependencies. DevOps teams can work together with a unified set of practices and tools to deliver applications and their supporting infrastructure rapidly, reliably, and at scale.
Monitoring
Monitoring provides feedback from production. Monitoring delivers information about an application's performance and usage patterns.
One goal of monitoring is to achieve high availability by minimizing Time to Detect (TTD) and TTM. In other words, as soon as performance and other issues arise, rich diagnostic data about the issues are fed back to development teams via automated monitoring. That's TTD. DevOps teams act on the information to mitigate the issues as quickly as possible so that users are no longer affected. That's TTM. Resolution times are measured, and teams work to improve over time. After mitigation, teams work on how to remediate problems at root cause so that those problems do not recur. That time is measured as TTR.
A second goal of monitoring is to promote validated learning by tracking usage. The core concept of validated learning is that every deployment is an opportunity to track experimental results that support or diminish the hypotheses that led to the deployment. Tracking usage and differences between versions gives teams the ability to measure the impact of change and drive business decisions. If a hypothesis is diminished, the team can fail fast or "pivot." If the hypothesis is supported, the team can double-down or "persevere." These data-informed decisions lead to new hypotheses and prioritization of the backlog.
Telemetry is the mechanism for collecting data from monitoring. Telemetry can use agents that are installed in the deployment environments, a software development kit (SDK) that relies on markers inserted into source code, server logging, or a combination of these. Typically, telemetry distinguishes between the data pipeline optimized for real-time alerting and dashboards and higher-volume data needed for troubleshooting or usage analytics.
Monitoring is often used to "test in production." A well-monitored deployment streams the data about its health and performance so that the team can spot production incidents immediately. Combined with a CD release pipeline, monitoring detects new anomalies and allows for prompt mitigation. This makes it possible for you to discover the "unknown unknowns" in application behavior that cannot be foreseen in preproduction environments.
Effective monitoring is essential for DevOps teams to deliver at speed, receive feedback from production, and increase customer satisfaction, acquisition, and retention.
Microservices
Microservices describes the architectural pattern of composing a distributed application from separately deployable services that perform specific business functions and communicate over web interfaces. DevOps teams encapsulate individual pieces of functionality in microservices and build larger systems by composing the microservices like building blocks, as demonstrated in Figure 3-9. Microservices apply an example of the open/closed principle: they are open for extension (using the interfaces they expose), and closed for modification (in that each is implemented and versioned independently). Microservices provide many benefits over monolithic architectures. They can remove single points of failure (SPoFs) by ensuring that issues in one service do not affect other parts of an application. DevOps teams can scale-out individual microservices independently to provide additional availability and capacity. Teams can extend functionality by adding new microservices without affecting other parts of the application.
Figure 3-9: Microservices architecture
Microservices architecture can increase team velocity. DevOps practices, such as CI and CD, are used to drive microservice deployments. Microservices nicely complement cloud-based application architectures by allowing software development teams to take advantage of several patterns such as event-driven programming and autoscale scenarios. The microservice components expose APIs, typically over Representational State Transfer (REST) protocols for communicating with other services.
An emerging pattern is to use container clusters to implement microservices. Containers allow for the isolation, packaging, and deployment of microservices; orchestration scales-out a group of containers into an application.
Competencies
Nearly every IT organization wants to embrace DevOps and its promise of increased software development speed and greater business agility that results from streamlining and accelerating the interactions between development and operations.
The problem is that there's no easy or quick way to get there. A successful journey begins with the right people and the right DevOps competencies—and a willingness to collaborate. These competencies are well explained in 7 DevOps roles you need to succeed and include the following:
Checklist
DevOps is the integration of development, quality assurance, and IT operations into a unified culture and set of processes for delivering software. Use this checklist as a starting point to assess your DevOps culture and process.
A lot of IT organizations are facing challenges in moving to a DevOps approach. The necessary changes of the companies' organization require management buy-in, and ramping-up the new skills requires training of existing employees and probably hiring new employees. To manage the upcoming challenges in IT, you should consider making DevOps your new default:
DevOps and classic IT service management will coexist for some time. Continue running your existing services in the classic model. But to prepare the movement to the DevOps model, it is reasonable to apply some of the DevOps concepts to the existing development and operations of services using the Waterfall or Agile approach. Here's how to do that:
Table 3-2 provides links to resources where you can learn more about automating infrastructure and application.
Table 3-2: Automating infrastructure and application deployments
Topic | Resource |
Best practices for creating Azure Resource Manager templates | https://docs.microsoft.com/azure/azure-resourcemanager/resource-manager-template-best-practices |
Design patterns for Resource Manager templates when deploying complex solutions | |
Azure Automation DSC overview | https://docs.microsoft.com/azure/automation/automationdsc-overview |
Introduction to the Azure DSC extension handler | https://docs.microsoft.com/azure/virtualmachines/windows/extensions-dsc-overview |
Get started on Azure with Puppet | |
Chef Automate |
Distributed applications and services running in the cloud are, by their nature, complex pieces of software that comprise many moving parts. In a production environment, it's important to be able to track the way in which users utilize your system, trace resource utilization, and generally monitor the health and performance of your system. You can use this information as a diagnostic aid to detect and correct issues and to help spot potential problems and prevent them from occurring.
Azure has offerings available for monitoring your services from bare-metal infrastructure to application telemetry. Most companies employ a hybrid model in which in addition to the onpremises IT, they have a significant cloud footprint that has IaaS, PaaS, and probably SaaS (Microsoft Office 365) components. It is important to have a consistent experience to manage backups across the IT assets in such a hybrid model. From a backup perspective, an application administrator should be able to sign up for backup and do self-service restores without having to go through a central IT process to provision compute/storage in the cloud to set up backup. Furthermore, customers are seeking freedom from infrastructure. This is one of the fundamental benefits when you move your IT to the cloud, and because backup has a significant infrastructure footprint in on-premises IT (storage, compute, licenses, etc.), an infrastructure-less backup solution is a natural expectation. Azure Backup is built in a PaaS model to deliver backup as a service and is designed to provide a consistent management experience to both on-premises infrastructure as well as backup for born-in-the-cloud applications.
Azure Recovery Services contribute to your business continuity and disaster recovery (DR) strategy. Azure Backup keeps your data safe and recoverable. Site Recovery replicates, performs failover, and recovers workloads, so that they remain available when failure occurs.
Azure Automation provides a way for users to automate the manual, long-running, error-prone, and frequently repeated tasks that are commonly performed in a cloud and enterprise environment. It saves time and increases the reliability of regular administrative tasks and even schedules them to be automatically performed at regular intervals. You can automate processes using runbooks or automate configuration management using Desired State Configuration.
Microsoft has long been providing products for managing enterprise environments. Multiple products were consolidated into the System Center suite of management products in 2007. This included Configuration Manager, which provides such features as software distribution and inventory; Operations Manager, which provides proactive monitoring of systems and applications; Orchestrator, which includes runbooks to automate manual processes; and Data Protection Manager for backup and recovery of critical data.
With more computing resources moving to the cloud, System Center products gained more cloud features such as Operations Manager and Orchestrator managing resources in Azure. They were still fundamentally designed as on-premises solutions, though, and require a significant investment in deploying and maintaining on-premises management environment. To completely take advantage of the cloud and support future applications, a new approach to management was required.
Operations Management Suite is a collection of management services that were designed in the cloud from the start. Rather than deploying and managing on-premises resources, Operations Management Suite components are entirely hosted in Azure. But, just because Operations Management Suite services run in the cloud doesn't mean that they can't effectively manage your on-premises environment. The core functionality of Operations Management Suite is provided by a set of services that run in Azure. Each service provides a specific management function, and you can combine services to achieve different management scenarios. Let's take a look at the components that make up Operations Management Suite:
The primary intent of IT organizations is to have an end-to-end monitoring for complex business applications (as shown in Figure 3-10) that consist of Azure infrastructure and platform services as well as on-premises components.
Figure 3-10: Monitoring complex applications
You can use monitoring to gain an insight into how well your application is functioning. Monitoring is a crucial part of maintaining quality-of-service targets. Common scenarios for collecting monitoring data include the following:
More info To read detailed instructions, go to Monitoring and diagnostics.
Azure addresses those requirements with a set of services that are well integrated with one another. The best monitoring strategy combines use of all three to gain comprehensive, detailed insight into the health of your services:
Figure 3-11 presents an overview of the Azure monitoring landscape.
Figure 3-11: Azure monitoring landscape
Azure Monitor
Monitor is the platform service that provides a single source for monitoring your Azure resources. It includes metrics, activity logs, diagnostic logs, and alert rules.
The most important type of Azure telemetry data is the metrics (also called performance counters) emitted by most Azure resources. Monitor (see Figure 3-12) provides several ways to configure and consume these metrics for monitoring and troubleshooting. Metrics are a valuable source of telemetry, and we recommend making use of it as follows:
Figure 3-12: Metrics in Monitor
All metrics have one-minute frequency: You receive a metric value every minute from your resource, giving you near-real-time visibility into the state and health of your resource. Metrics are available immediately and there is no need to opt in or set up additional diagnostics. You can access 30 days of history for each metric, and you can quickly look at the recent and monthly trends in the performance or health of your resource.
Consider creating a metric alert rule that sends a notification or takes automated action when the metric reaches the threshold that you have set. Furthermore, we recommend configuring an autoscale setting rule to scale in or out based on a metric crossing a threshold. To gain a holistic view of your application health, you should consider routing all metrics to Application Insights or Log Analytics to set up instant analytics, search, and custom alerting on metrics data from your resources. You can also stream metrics to Azure Event Hubs, and then route them to Azure Stream Analytics or to custom apps for near-real-time analysis. You set up Event Hubs streaming using diagnostic settings.
For long-term analytics and reporting, it might be helpful to archive your metrics to Azure Blob storage. You can do that by configuring diagnostic settings for your resource.
You can consume the metrics via the Monitor REST APIs, query it by using PowerShell cmdlets or the Cross-Platform REST API, or view all metrics in the Azure portal. Table 3-3 lists links to resources where you can find more information on working with metrics.
Table 3-3: Monitor: working with metrics
Topic | Resource |
Overview of autoscale in Azure Virtual Machines, Cloud Services, and Web Apps | https://docs.microsoft.com/azure/monitoring-anddiagnostics/monitoring-overview-autoscale |
Azure Monitoring REST API Walkthrough | https://docs.microsoft.com/azure/monitoring-anddiagnostics/monitoring-rest-api-walkthrough |
Azure Monitor PowerShell quick start samples | https://docs.microsoft.com/azure/monitoring-anddiagnostics/insights-powershell-sample |
Collect Azure service logs and metrics for use in Log Analytics | https://docs.microsoft.com/azure/log-analytics/loganalytics-azure-storage |
Activity Log is a log that provides insight into the operations that were performed on resources in your subscription. The Activity Log was previously known as "Audit Logs" or "Operational Logs," because it reports control-plane events for your subscriptions. Using Activity Log, you can determine the "what, who, and when" for any write operations taken on the resources in your subscription. You can also understand the status of the operation and other relevant properties. Activity Log does not include read operations. It differs from Diagnostic Logs in so much as Activity Logs provide data about the operations on a resource from the outside; Diagnostics Logs are emitted by a resource and provide information about the operation of that resource. Figure 3-13 shows an overview of Activity Log.
Figure 3-13: Activity Log in Monitor
Here are some of the things that you should consider doing with Activity Log:
Table 3-4 provides links to additional resources.
Table 3-4: Monitor: working with Activity Log
Topic | Resource |
View events and activity logs | https://docs.microsoft.com/azure/monitoring-anddiagnostics/insights-debugging-with-events |
Create Activity Log alerts | https://docs.microsoft.com/azure/monitoring-anddiagnostics/monitoring-activity-log-alerts |
Stream Activity Log to Event Hubs | |
Archive activity logs | https://docs.microsoft.com/azure/monitoring-anddiagnostics/monitoring-archive-activity-log |
View activity logs to audit actions on resources | https://docs.microsoft.com/azure/azure-resourcemanager/resource-group-audit |
Audit Logs content pack for Power BI | https://powerbi.microsoft.com/documentation/powerbicontent-pack-azure-audit-logs/ |
Diagnostic Logs are logs emitted by a resource that provide rich, frequent data about the operation of that resource. The content of these logs varies by resource type. For compute resources, you can use Azure Diagnostics. You can use the diagnostics extension from several different sources. Currently supported are Azure Cloud Service Web and Worker Roles, Virtual Machines running Microsoft Windows and Azure Service Fabric. Other Azure services have their own separate diagnostics described in Supported services and schema for Diagnostic Logs. Here are some of the things that you should consider doing with Diagnostic Logs:
Figure 3-14 shows the Diagnostic Logs landscape.
Figure 3-14: Diagnostic Logs in Monitor
Diagnostic Logs for noncompute resources are configured by using Diagnostic Settings. Table 3-5 directs you to where you can find more information.
Table 3-5: Monitor: working with Diagnostic Logs
Topic | Resource |
Archive Diagnostic Logs | https://docs.microsoft.com/azure/monitoring-anddiagnostics/monitoring-archive-diagnostic-logs |
Stream Diagnostic Logs to Event Hubs | |
Collect Azure service logs and metrics for use in Log Analytics | https://docs.microsoft.com/azure/log-analytics/log-analyticsazure-storage |
Automatically configure Diagnostic Settings at resource creation |
Alerts are a method of monitoring Azure resource metrics, events, or logs and being notified when a condition you specify is met. Alerts are available across different services, including the following:
The following list contains guidance how to use alerts in Monitor.
Figure 3-15 depicts the Alerts ecosystem.
Figure 3-15: Alerts in Monitor
Table 3-6 provides links where you can learn more about creating alerts in Application Insights and Log Analytics.
Table 3-6: Monitor: working with alerts
Topic | Resource |
Create metric alerts in Monitor for Azure services: Azure portal | https://docs.microsoft.com/azure/monitoring-anddiagnostics/insights-alerts-portal |
Create metric alerts in Monitor for Azure services: Cross-platform CLI | https://docs.microsoft.com/azure/monitoring-anddiagnostics/insights-alerts-command-line-interface |
Create metric alerts in Monitor for Azure services: PowerShell | https://docs.microsoft.com/azure/monitoring-anddiagnostics/insights-alerts-powershell |
Configure a webhook on a Metric Alert | https://docs.microsoft.com/azure/monitoring-anddiagnostics/insights-webhooks-alerts |
Create a metric alert with a Resource Manager template | https://docs.microsoft.com/azure/monitoring-anddiagnostics/monitoring-enable-alerts-using-template |
Application Insights
It's essential to monitor a modern application while it is running. Most important, you want to detect failures before your customers do. You also want to discover and fix performance issues that, while not catastrophic, perhaps slow things down or cause some inconvenience to your users. And when the system is performing to your satisfaction, you want to know what the users are doing with it. Application Insights is aimed at the development team, to help you understand how your app is performing and how it's being used.
Here's what it monitors:
Consider activating Application Insights (Figure 3-16) on various apps and platforms, including Azure App or Cloud Services, .NET, Node.js, Java, JavaScript, and Docker, hosted on-premises or in the cloud. Application Insights integrates with your DevOps process and has connection points to a variety of development tools. You install a small instrumentation package in your application and set up an Application Insights resource in Azure. The instrumentation monitors your app and sends telemetry data to the portal. You can instrument not only the web service application, but also any background components as well as the JavaScript in the web pages themselves. After the initial setup, you have a lot of options to analyze the collected data, as shown in Table 3-7.
Figure 3-16: Application Insights
Table 3-7: Application Insights
Topic | Resource |
Dashboards in the Azure portal | https://docs.microsoft.com/azure/application-insights/appinsights-dashboards#dashboards |
Diagnostic search for instance data | https://docs.microsoft.com/azure/application-insights/appinsights-diagnostic-search |
Metrics Explorer for aggregated data | https://docs.microsoft.com/azure/application-insights/appinsights-metrics-explorer |
Application map | https://docs.microsoft.com/azure/application-insights/appinsights-app-map |
Live Metrics Stream | https://docs.microsoft.com/azure/application-insights/appinsights-live-stream |
Analytics | https://docs.microsoft.com/azure/application-insights/appinsights-analytics |
Visual Studio | https://docs.microsoft.com/azure/application-insights/appinsights-visual-studio |
Power BI | https://docs.microsoft.com/azure/application-insights/appinsights-export-power-bi |
REST API | |
Continuous export | https://docs.microsoft.com/azure/application-insights/appinsights-export-telemetry |
After you've deployed your web app or website to any server, you should set up web tests to monitor its availability and responsiveness. Application Insights sends web requests to your application at regular intervals from points around the world. It alerts you if your application doesn't respond or responds slowly. You can set up web tests for any HTTP or HTTPS endpoint that is accessible from the public internet. You don't need to add anything to the website you're testing. It doesn't even need to be your site: you could test a REST API service on which you depend. There are two types of web tests:
Furthermore, Application Insights can alert you to changes in performance or usage metrics in your web app. We encourage you to use these three kinds of alerts:
More info For further details, refer to Set Alerts in Application Insights.
Integrating your Application Insights apps to Operations Management Suite increases your organization's visibility over your applications by having operation and application data in one place. You can use the Application Insights Connector solution (Preview) in Operations Management Suite (OMS) to do the following:
Log Analytics
Log Analytics is a service that monitors your cloud and on-premises environments to maintain their availability and performance. It collects data generated by resources in your cloud and on-premises environments and from other monitoring tools to provide analysis across multiple sources. At the center of Log Analytics is the Operations Management Suite repository which is hosted in Azure, as illustrated in Figure 3-17. Data is collected into the repository from connected sources by configuring data sources and adding solutions to your subscription. Data sources and solutions each create different record types that have their own set of properties but can still be analyzed together in queries to the repository. This makes it possible for you to use the same tools and methods to work with different kinds of data collected by different sources.
Figure 3-17: Operations Management Suite Log Analytics
Consider using Log Analytics to gain a holistic view about your entire application landscape. Therefore, you need to configure how to collect the data from various sources, query your data, analyze your data to gain insights, and alert operations teams in case of any issues.
Log Analytics supports different types of connected sources. Connected sources are the computers and other resources that generate data collected by Log Analytics. Computers can reside in your onpremises datacenter as physical servers or VMs, or VMs in a cloud-hosted service like Amazon Web Services (AWS) or Microsoft Azure. Make sure to connect all relevant sources to Log Analytics:
More info For further explanation, go to Collect Azure service logs and metrics for use in Log Analytics.
The data that is collected from each is defined by the data sources that you configure. Data in the Operations Management Suite repository is stored as a set of records. Each data source creates records of a particular type with each type having its own set of properties. Here are the data sources that are currently available in Log Analytics:
At the core of Log Analytics is the log search feature, which you should use to combine and correlate any machine data from multiple sources within your environment. On the Search page, you can create a query, and then, when you search, you can filter the results by using facet controls. You also can create advanced queries to transform, filter, and report on your results. From a log search result in Azure Log Analytics, you can also select Take Action to run an Automation runbook. You can use the runbook to remediate the issue or take some other action such as collect troubleshooting information, send an email, or create a service request.
To get a single lens to view your environment, we recommend that you configure the Log Analytics dashboards to create visualizations of all of your saved log searches. You can customize and organize the dashboard according to your requirements. Using the View Designer in Log Analytics, you can create custom views in the Operations Management Suite console that contain different visualizations of data in the Operations Management Suite repository. Additionally, you can Export Log Analytics data to Power BI. When you configure Power BI with Log Analytics, you create log queries that export their results to corresponding datasets in Power BI. The query-and-export continues to automatically run on a schedule that you define to keep the dataset up to date with the latest data collected by Log Analytics.
Analyzing your data in a proactive manner is very important, but creating alerts that inform you about any issues is equally important. You create Alerts via alert rules that automatically run log searches at regular intervals. If the results of the log search match a particular criterion, an alert record is created. The rule can then automatically run one or more actions to proactively notify you of the alert or invoke another process. Different types of alert rules use different logic to perform this analysis. Alert Rules are defined by the following details.
When an alert is created in Log Analytics, you have the option of configuring the alert rule to perform one or more of the following actions:
Most IT organizations already have an IT Service Management (ITSM) solution such as ServiceNow, Systems Center, Provance, or Cherwell in place. For those companies, we recommend integrating it with Log Analytics to centrally monitor and manage work items. The IT Service Management Connector provides for bidirectional integration with ITSM products, where it provides the Operations Management Suite users an option to create incidents, alerts, or events in ITSM solution. The connector also imports data such as incidents, and change requests from ITSM solution into Operations Management Suite Log Analytics. With IT Service Management Connector, you can do the following:
Log Analytics provides a set of more than 30 solutions that you should use to monitor your environment. Log Analytics management solutions are a collection of logic, visualization, and data acquisition rules that provide metrics that you can pivot around a particular problem area. The Azure Marketplace contains the list of management solutions for Log Analytics. A good practice is to begin with the relevant out-of-the-box solutions and enhance them with individual dashboards and alerts per your needs.
Security monitoring
Many organizations learn how to respond to security incidents only after suffering an attack. To reduce costs and damage, it's important to have an incident response plan in place before an attack occurs. An effective plan depends on three core capabilities: being able to protect, detect, and respond to threats. Protection is about preventing incidents, detection is about identifying threats early, and response is about evicting the attacker and restoring systems to mitigate the impacts of a breach. We strongly recommend using Azure Security Center to gain control over the security of your Azure resources. It provides integrated security monitoring and policy management across your Azure subscriptions, helps detect threats that might otherwise go unnoticed, and works with a broad ecosystem of security solutions.
The first step is to configure a security policy per your company's security needs. A security policy defines the set of controls that are recommended for resources within the specified subscription or resource group. We advise to activate all areas of available recommendations of the prevention policy (e.g., System Updates, OS Vulnerabilities, Endpoint Protection, and Disk Encryption) as well as turning on data collection for each of your subscriptions to ensure that security monitoring is available for all existing and new VMs.
Security Center periodically analyzes the security state of your Azure resources. When Security Center identifies potential security vulnerabilities, it creates recommendations. The recommendations guide you through the process of configuring the needed controls. Current policy recommendations center on system updates, baseline rules, antimalware programs, network security groups on subnets and network interfaces, SQL database auditing, SQL database transparent data encryption, and web application firewalls. After reviewing all recommendations, decide which one you should apply first. We recommend that you use the severity rating as the main parameter to evaluate which recommendations you should apply before everything else.
There have been significant changes in the threat landscape over the past years. In the past, companies typically had to worry only about website defacement by individual attackers who were mostly interested in seeing "what they could do." Today's attackers are much more sophisticated and organized. They are now interested in stealing information, financial accounts, and private data—all of which they can use to generate cash on the open market or to take advantage of a particular business, political, or military position.
Microsoft security researchers are constantly on the lookout for threats. They have access to an expansive set of telemetry gained from Microsoft's global presence in the cloud and on-premises. This wide-reaching and diverse collection of datasets gives Microsoft a unique ability to discover new attack patterns and trends across its on-premises consumer and enterprise products as well as its online services. As a result, Security Center can rapidly update its detection algorithms as attackers release new and increasingly sophisticated exploits. This approach helps you to keep pace with a fastmoving threat environment. Security Center employs advanced security analytics, which go far beyond signature-based approaches. Breakthroughs in big data and machine learning technologies are used to evaluate events across the entire cloud fabric, detecting threats that would be impossible to identify using manual approaches and predicting the evolution of attacks.
Security Center provides you with a list of prioritized security alerts that have been detected. Each alert contains the following:
Additionally, Security Center can provide you with a single view of an attack campaign and all of the related alerts. This helps you to understand what actions the attacker took and what resources were affected. In Security Center, a security incident is an aggregation of all alerts for a resource that align with kill-chain patterns. Incidents appear in the Security Alerts tile and blade. An incident will reveal the list of related alerts with which you can obtain more information about each occurrence.
Most companies today have implemented a hybrid model, which means that in addition to their onpremises IT, they have a cloud footprint in Azure that has IaaS that possibly extends to PaaS ("born-inthe-cloud" applications) and SaaS (i.e., Office 365). It is important to have a consistent experience to manage backups across the IT assets in this hybrid model. In general, there are three possible approaches backup solutions can take to use the cloud for backup solutions:
Infrastructure and applications
Azure Backup is the Azure-based service you should use to back up and restore your data in the Microsoft cloud. Azure Backup was designed from the ground-up as a PaaS service, as described in the aforementioned third approach. Azure Backup offers multiple components that you download and deploy on the appropriate computer, server, or in the cloud. The component, or agent, that you deploy depends on what you want to protect. You can use the complete range of Azure Backup components (no matter whether you're protecting data on-premises or in the cloud) to back up data to an Azure Recovery Services vault.
Azure Backup seamlessly integrates with IaaS VM by providing an enable-backup experience in the VM blade itself. A VM extension is deployed when you choose to turn on backup. You also can turn on Backup via Resource Manager templates, and it supports all the features of IaaS VMs such as drive encryption, premium drives, and so on. The foundation of Azure Backup is the Recovery Services vault. This is an online storage entity in Azure used to hold data such as backup copies, recovery points, and backup policies. Backing up VMs is a local process. You cannot back up VMs from one location to a Recovery Services vault in another location. So, for every Azure location that has VMs that you need to back up, at least one Recovery Services vault must exist in that location. With the storage replication option, you can choose between geo-redundant storage and locally redundant storage. By default, your vault has geo-redundant storage; leave this setting if this is your primary backup. Choose locally redundant storage if you want a less-expensive option that isn't quite as durable.
Before registering a VM with a vault, run the discovery process to ensure that any new VMs that have been added to the subscription are identified. The process queries Azure for the list of VMs in the subscription, along with additional information like the cloud service name and the region. Prior to your first backup, you must define a backup policy or use the default policy. The policy is the schedule for how often and when recovery points are taken. The policy also includes the retention range for the recovery points.
The Azure VM Agent must be installed on the Azure VM for the Backup extension to work. If your VM was created from the Azure gallery, the VM Agent is already present on the VM. If not—for example, you moved a VM from an on-premises datacenter—you need to install the VM Agent manually to protect the VM.
To manage the VM snapshots, the backup extension needs connectivity to the Azure public IP addresses. Without the right internet connectivity, the VM's HTTP requests time-out and the backup operation fails. If your deployment has access restrictions in place (e.g., through a network security group), choose one of these options for providing a clear path for backup traffic:
When the Azure Backup service initiates a backup job at the scheduled time, it signals the backup extension to take a point-in-time snapshot, as demonstrated in Figure 3-18. When the data transfer is complete, the snapshot is removed and a recovery point is created. The Azure Backup service uses the VMSnapshot extension in Windows, and the VMSnapshotLinux extension in Linux.
Backing up and restoring business-critical data is complicated by the fact that this data must be backed up while the applications that produce it are running. To address this, Azure Backup supports application-consistent backups for both Windows and Linux VMs. When taking a snapshot of Windows VMs, the Backup service coordinates with the Volume Shadow Copy Service (VSS) to get a consistent snapshot of the VM's drives. If you're backing up Linux VMs, you can write custom scripts to ensure consistency when taking a VM snapshot. Azure Backup provides a scripting framework. To ensure application consistency when backing up Linux VMs, create custom prescripts and postscripts that control the backup workflow and environment. Azure Backup invokes the prescript before taking the VM snapshot, and invokes the postscript after the VM snapshot job completes. For more details, see application consistent VM backups using prescript and postscript.
Figure 3-18: Azure Backup extension
Like backup software that is deployed on-premises, you should plan for capacity and resource utilization needs when backing up VMs in Azure. Backup data copied from a storage account adds to the input/output operations per second (IOPS) and egress (or throughput) metrics of the storage account. At the same time, VMs are also consuming IOPS and throughput. The goal is to ensure that Backup and VM traffic don't exceed your storage account limits.
Restores are based on the recovery points in the recovery services vault. If or when it is necessary to repair or rebuild a VM, you can restore the VM from any of the saved recovery points. As Figure 3-19 illustrates, when you restore a recovery point, you can create a new VM, which is a point-in-time representation of your backed-up VM, or restore drives and use the template that comes along with it to customize the restored VM or do an individual file recovery. The Azure portal provides a Quick Create option for restoring VMs. If you want to customize the VM restore configuration (e.g., special network configuration, names of created resources), you can use PowerShell.
Figure 3-19: Restore virtual machines
You also can restore the drives of a backed up VM to a storage account that is in the same location as the recovery services vault. After the restoring operation is completed, you can do the following:
You can recover items such as files and folders from an Azure VM backup. This restore-as-a-service feature is currently in public preview and uses a unique approach to mount a cloud recovery point as a volume and browse it to facilitate item-level-restore. You do not need to provision any infrastructure, and the egress from Azure is free. The feature is available for IaaS VMs (Windows and Linux).
Using Azure Backup, you can restore backed up VMs to the paired datacenter in the event that the primary datacenter (where your VMs are running) experiences a disaster and you configured the Backup vault to be geo-redundant. During such scenarios, you need to select a storage account, which is present in the paired datacenter and the rest of the restore process remains the same. Azure Backup uses Compute service from the paired region to create the restored VM.
With Azure Backup, you can back up your files and folders on Windows Server or Windows Clients (Figure 3-20). Therefore, you need to install the Recovery Services agent on the VM and register it with the Recovery Services vault. You can use this capability for Windows machines running in the cloud or on-premises. If required, you can provide your proxy server information to establish outbound internet connectivity from the Windows machine to the recovery service in Azure. The Microsoft Azure Backup agent provides network throttling. Throttling controls how network bandwidth is used during data transfer. This control can be helpful if you need to back up data during work hours but do not want the backup process to interfere with other internet traffic.
Figure 3-20: Backup and restore files and folders
With Azure Backup Server, you can protect application workloads such as Hyper-V VMs, VMware VMs, Microsoft SQL Server, Microsoft SharePoint Server, Microsoft Exchange, and Windows clients, all from a single console. Backup Server inherits much of the workload backup functionality from Systems Center Data Protection Manager. Though Backup Server shares much of the same functionality as Data Protection Manager, it does not back up to tape, nor does it integrate with System Center. You can install Backup Server on an Azure VM or in your datacenter. After installing and configuring the software, you need to establish the connectivity to the Recovery Services vault. Afterward, you can configure the details for the workload that you want to protect.
More info To read more, refer to Preparing to back up workloads using Azure Backup Server and Preparing to back up workloads to Azure with DPM.
Table 3-8 provides additional information for protecting specific workloads.
Table 3-8: Backing up specific workloads
Topic | Resource |
Back up VMware server to Azure | https://docs.microsoft.com/azure/backup/backup-azure-backup-servervmware |
Back up an Exchange server to Azure Backup with Backup Server | https://docs.microsoft.com/azure/backup/backup-azure-exchangemabs |
Back up a SharePoint farm to Azure | https://docs.microsoft.com/azure/backup/backup-azure-backupsharepoint-mabs |
Back up SQL Server to Azure using Backup Server | https://docs.microsoft.com/azure/backup/backup-azure-backupsharepoint-mabs |
Table 3-9 provides an overview of the various options to back up the aforementioned workloads.
Table 3-9: Backup overview
Component | Benefits | Limits | What is protected? | Where are backups stored? | |
Azure Backup (MARS) agent |
|
|
|
| |
System Center Data Protection Manager |
|
|
|
| |
Azure Backup Server |
|
|
|
| |
Azure IaaS VM Backup |
|
|
|
|
More info You can find an overview on how and when to use each component in Overview of the features in Azure Backup.
Platform services
As of this writing, you cannot use Azure Backup to back up Azure Platform Services. The Azure backup service will be extended in the future for Azure SQL Database, Azure Files, and other Azure PaaS assets like Web Apps and Service Fabric for a first-class backup experience in Azure.
For the time being, you must use the native backup capabilities of the platform services, which you can see listed in Table 3-10.
Table 3-10: Backup platform services
Topic | Resource |
Snapshot Blob storage | https://docs.microsoft.com/rest/api/storageservices/SnapshotBlob |
SQL Database backups | https://docs.microsoft.com/azure/sql-database/sql-databaseautomated-backups |
Recover a database in Azure SQL Database using automated database backups | https://docs.microsoft.com/azure/sql-database/sql-databaserecovery-using-backups |
Automatic online backup and restore with DocumentDB | https://docs.microsoft.com/azure/documentdb/documentdbonline-backup-and-restore |
Back up your app service in Azure | https://docs.microsoft.com/azure/app-service-web/web-sitesbackup |
Restore an app in Azure | https://docs.microsoft.com/azure/app-service-web/web-sitesrestore |
Protect data in Data Lake | https://docs.microsoft.com/azure/data-lake-store/data-lakestore-troubleshooting-guidance |
Service configuration
IT organizations that have a DevOps-based approach for application development will deploy their infrastructure as code. The code, therefore, is managed in a source code repository, and re-creating the same infrastructure in case of any issues with the current infrastructure is straightforward.
Using Azure Resource Manager, an IT organization can repeatedly deploy an application and its infrastructure and have confidence that resources are deployed in a consistent state.
IT organizations that haven't yet adopted the DevOps model should consider exporting the configuration of their services on a regular basis. With Resource Manager, you can export a Resource Manager template from existing resources in your subscription. You can use that generated template to automate the redeployment of your solution as needed. It is important to note that there are two different ways to export a template:
More info For further details, refer to Export an Azure Resource Manager template from existing resources.
Azure is divided physically and logically into units called regions. A region consists of one or more datacenters in close proximity. Under rare circumstances, it is possible that facilities in an entire region can become inaccessible; for example, due to network failures. Or, facilities can be lost entirely, perhaps due to a natural disaster. Fortunately, there is a lot of valuable guidance on how to design resilient applications for Azure and how to recover from a region-wide service disruption. Protecting your stateful VMs from regional disasters and other failures was challenging in the past. Using globally redundant storage wasn't sufficient, and a DR strategy based on backup and restore couldn't always fulfill the required Recovery Point Objective (RPO) and Recovery Time Objective (RTO).
Azure Site Recovery is an Azure service that orchestrates the protection and recovery of your virtualized applications for business continuity DR (BCDR) purposes. Failover is made possible by Site Recovery, which initially copies designated VMs from a primary datacenter to the secondary datacenter and then periodically refreshes the replicas. Until now, Site Recovery supported scenarios to replicate on-premises VMs to Azure and to replicate on-premises VMs from one on-premises location to another on-premises location.
A capability has been added that supports DR of Azure VMs from one Azure region to another Azure region. Protecting your VMs is straightforward:
The first time you replicate a VM, Site Recovery creates a new replication policy with default settings of 24 hours for recovery point retention, and 60 minutes for app-consistent snapshot frequency. You can adjust those settings as you need. Recovery point retention specifies the duration of the retention window for each recovery point. Protected machines can be recovered to any point within a retention window. App-consistent snapshot frequency specifies how often recovery points that contain application-consistent snapshots are created.
After the initial protection of your VMs is completed, we recommend running a test failover to validate your replication strategy or perform a DR drill without any data loss or downtime. Doing a test failover doesn't have any impact on the ongoing replication or on your production environment.
The unplanned failover option initiates the actual failover of the VM from the original Azure location to the failover location. We strongly suggest that you run a test failover before performing an unplanned failover because many of the changes under an unplanned failover are not reversible. Site Recovery will also display a warning if an unplanned failover is attempted without a prior test failover 60 days before the unplanned failover. In many scenarios, it is appropriate to select the option to shut down machines before beginning failover to specify that Site Recovery should try to shut down the protected VMs and synchronize the data so that the latest version of the data will be failed-over. You can use one of the following options to select your preferred recovery point:
After you are satisfied with the failed-over VM, you can commit the failover. This deletes all the recovery points available with the service, and the Change Recovery Point option will no longer be available.
After failover is complete, the VMs start and are running at the secondary location. However, they aren't protected or replicating. When the primary site is available again with the same underlying infrastructure, you must reverse-replicate the VM. This ensures that all of the data is replicated back to the primary site, and that the VM is ready for failover again. After reprotection has been completed your VMs are ready to be failed back to the original site. This involves performing an unplanned failover in the opposite direction to that done before. After failback (failover from destination site to source site) is complete, the VMs start and are running at the secondary location. However, they aren't protected or replicating. You need to turn on replication to the destination site, following the same steps explained earlier.
Figure 3-21 depicts a typical multitier application that has a resource group, a virtual network with some subnets, a public IP address to access the applications, and each of the tiers are in an availability set with a load balancer in front of it. Multiple storage accounts are used for the various applications tiers.
Figure 3-21: DR of Azure VMs from one Azure region to another Azure region
When you turn on replication with Site Recovery, identical resources are created on the secondary site. This includes the resource group, the virtual network, the storage accounts, and the availability sets. The data is moved from the primary storage account to a cache storage account in the same region, and from there to the secondary storage account in the other region. At the point in time when the failover happens, the VMs are created within that precreated infrastructure. Site Recovery supports the failover of multiple VMs with multiple drives in a consistent way. Site Recovery doesn't replicate network security groups, Public IP addresses, and load balancers. You must precreate those resources in the secondary location.
Before setting up Site Recovery, you need to review the following comments:
Managed services are not a new business model. For more than 20 years, large enterprises have relied on service providers (internal IT departments or external service providers) to manage their IT assets. Managed-service providers have been managing their customers' workloads—either in their own datacenters or those operated by their customers. This section focuses on internal IT organizations that act as managed service providers. However, the basic concepts remain the same for external managed service providers.
The cloud requires a new method of management because of its focus on scale, elasticity, and automation. The cloud represents a paradigm shift in the way that we think about embracing IT. DevOps has completely changed the way applications are developed and maintained. The hyperscale nature of the cloud provides a completely new meaning to scalability, elasticity, and resiliency, and has redefined how applications are designed and delivered. The pay-as-you-go model provides a failfast, Agile method of app development. Because of the cloud, IT organizations require a new way to think about data governance and security.
Managed-service providers for cloud services are organizations that helps their customers transition to this paradigm shift in technology by guiding the customers in various aspects of the cloud journey. Successful Azure managed-service providers differentiate themselves by building a practice around DevOps, automation, and cloud-native application design. They use the best Azure features while designing solutions—be it IaaS, PaaS, or SaaS offerings—to meet their customers' business requirements. Essentially, they act as a one-stop shop for their customers by providing a common support, provisioning, and billing experience—all with a flexible pay-as-you-go business model.
For managed service providers, automation and orchestration are extremely important functions to a successful practice. The ability to automate routine tasks makes it possible for you to lower your delivery costs and offer superior SLAs, driving a virtuous cycle of efficiency and repeat business. Automation is the key to creating the right balance between cost, reliability, speed, and time to market.
Managed services are centrally managed along the entire application life cycle and include all operational components such as Backup, monitoring, updating, and so on and are managed according to the organization's standards. They are typically offered in different pricing tiers, such as those shown in Figure 3-22.
Figure 3-22: Pricing tiers for managed services
IT organizations require a comprehensive integrated solution that gives their consumers the complete visibility and control of their cloud resources while letting them fully exploit Azure's extensive capabilities and empowering agility. Therefore, providers can take advantage of different frameworks to build such an integrated solution. This section doesn't focus on any specific framework; rather, it outlines only the required capabilities and the conceptual layers of such a solution.
The required logical layers are shown in Figure 3-23.
Figure 3-23: Conceptual model for managed services
The consumption layer presents a service catalog to the consumer, with various configuration options (Application, Compute, RAM, Storage, Location, Network, SLA, etc.), including pricing information. Approval workflows need to be available to control costs and to govern the consumption of the services.
The service layer is used for managing the service catalog, defining the SLAs (Availability, Performance, Time to React, etc.) that are associated with the provided services and to design the service itself. A service consists not only of a VM with an operating system. Enterprises require managed services for operating systems, databases, middleware products, webservers, or complex business applications (e.g., an ERP solution) that are based on multiples of these components. The service layer must support an efficient way to design new services based on standard products as well as the ability to orchestrate multiple products and services to a new complex business service.
The services must include availability monitoring, backup and restore processes, antivirus protection, security, and compliance monitoring and must be managed according to service management standards.
The service provisioning as well as the integration with the operational support systems and the IT service management tooling is part of the service delivery layer. Those processes are ideally automated but could also be semi-automated or run manually with a defined service level for delivering the service to the consumer.
Finally, there is a Resource Provider Layer with IaaS-, PaaS-, and SaaS-based services that is used as foundation to create managed services. A large portion of enterprise IT is still focused on IaaS, but the obvious benefits of PaaS and SaaS are leading to a higher adoption of those services.
We observe that customers are sometimes aiming for a multivendor strategy on the resource provider layer called multicloud support or cloud brokerage. But there are a lot of caveats with such an approach:
IT organizations should rate for themselves the pros and cons of multicloud support.
The user-self-service capability is an essential characteristic of cloud computing, and it must be present in any implementation. The intent is to permit users to approach a self-service capability and be presented with options available for provisioning. The capability can be basic (such as provisioning of a VM with a predefined configuration), more advanced (such as allowing configuration options to the base configuration), or complex (such as implementing a platform capability or service).
The self-service capability is a critical business driver for customers to become more agile in responding to business needs with IT capabilities that align and conform to their internal business and IT requirements. The interface provided by the IT organization should be abstracted to a well-defined, simple, and approved set of service options. The options should be presented as a menu in a portal. Customers should be able to select these services from the catalog, start the provisioning process, and be notified upon completion. Customers should be charged only for the services they actually used.
The challenge is to find the right balance between the required configuration options to fulfil the business needs and the complexity to implement those options and provision the services accordingly. Adding all configuration options that Azure provides for a service to the service catalog doesn't make sense. It would end up in re-creating the Azure portal which isn't achievable for any IT organization. A common approach is to add the most important parameters, that allow a basic automated provisioning of the service from the service catalog. Detailed configuration settings could be requested by the customer in separate service request (ideally via the same portal) and could be performed by IT staff within a defined service level.
The infrastructure for an application is typically made up of many components—maybe a VM, storage and virtual network, or a web app, database, database server, and probably third-party services from the Azure Marketplace or custom solutions that have been developed by the business. These components shouldn't be considered as separate entities, instead you should view them as related and interdependent parts of a single entity. IT departments should use Azure Resource Manager combined with DSC, Puppet, or Chef to deploy, manage, and monitor them as a group. Using Resource Manager, you can deploy, update, or delete all the resources of an application in a single, coordinated operation. Templates could be used for deployment, and that template can work for different environments such as testing, staging, and production. The template includes the infrastructure for the application, how to configure that infrastructure, and how to publish the application code to that infrastructure. Resource Manager also provides security, auditing, and tagging features to help service providers to manage the resources after deployment.
Consumers require the ability to get an accurately predicted price before deploying an application. As they move from a capital expenditure (Capex) to an operating expenditure(Opex) model, they also need the ability to do showback versus chargeback analysis as well as provide mode fidelity in estimation and billing, especially for large deployments.
The Azure Resource Usage and Rate Card APIs (Figure 3-24) address these needs by providing new insights into the consumption of Azure resources. With the Azure Usage API, you can programmatically pull in usage data to gain insights into the consumption. The granularity (hourly usage information) and resource metadata information available through the API provides the necessary dataset to support flexible Showback or Chargeback models.
Figure 3-24: Metering consumption
The data available through the Azure Usage API includes not only consumption information, but also resource metadata including any tags associated with it, as illustrated in Figure 3-35. Tags provide an easy way to organize application resources, but to be effective, you must ensure the following:
Figure 3-24: Metering consumption
Table 3-11 lists some additional resources.
Table 3-11: Backup platform services
Topic | Resource |
Understand your bill for Microsoft Azure | https://docs.microsoft.com/azure/billing/billing-understand-your-bill |
Use Azure Billing APIs to programmatically get insight into your Azure usage | https://docs.microsoft.com/azure/billing/billing-usage-rate-cardoverview |
A proper price prediction for a potentially consumed service from the service catalog is a common demand. Managers require this information to approve large cloud application deployments. Price prediction requires detailed knowledge about the Azure elements that a service consist of (defined at design time) along with estimated pricing information for each.
The Azure Resource RateCard API delivers a list of available Azure resources and pricing information. The API provides Azure offer-level rate information versus subscription-level. The caller of this API must pass in the offer information to get resource details and rates. As Enterprise Agreement (EA) offers have customized rates per enrollment, the API is unable to provide the EA rates at this time.
For EA scenarios, you can use another API for Enterprise Agreement that allows usage access price sheet and other billing information in CSV and JSON format. The report contains the same data content as the "Price sheet" downloaded from the EA portal under the "Download Usage Data" section.
IT service management is not obsolete when you use cloud technologies— on the contrary, effective management of cloud resources and service integration becomes more important than ever. However, the role of IT service management does change, especially with product teams delivering and operating their products at a faster pace.
The classic IT Infrastructure Library (ITIL) service life cycle shown in Figure 4-1 demonstrates how a continuous cycle of service improvement can be centrally coordinated and organized for an organization. The challenge and the opportunity in today's cloud world is to effectively manage, together with the individual product teams, an organization's workloads to utilize the possibilities for optimization now available through hybrid and public cloud infrastructures.
Figure 4-1: ITIL service life cycle with private, hybrid, and public cloud infrastructure options
In the cloud and hybrid world, the diversity of services and operations means that there is not one service management for all; each workload must be evaluated individually with the team responsible for the workload. An agreement, or contract of sorts, should be defined per workload that defines which organizational policies and best practices will be used from IT, and which responsibilities are overtaken by the product team to best serve the business and users as well as ensure optimal operations. It is very important to have a clear agreement between IT and the product teams before you first deploy the service.
Figure 4-2 shows the service management areas divided between the IT and the product teams, because in every case, both organizations will be involved to different degrees. Also important is the flow of information regarding organizational policies and best practices from IT to the product teams, and in the other direction, the overtaking of some responsibilities by the product teams from IT.
Figure 4-2: Modern service management with an agreed approach between IT and product teams
The goal of incident management is, as its name implies, to restore functionality as soon as possible to the business, or to respond as soon as possible to a service request in the event of unstable performance. In both cases the goal is that operations continue at the agreed level without interruptions.
The integration of incident response processes across private, hybrid, and cloud infrastructures is one of the first challenges of cloud readiness.
Figure 4-3 shows how monitoring is simplified in the public cloud (regional Microsoft Azure status information replaces individual hardware and network monitoring), but also the challenge of unifying monitoring across the private, hybrid, and public infrastructures.
Figure 4-3: Monitoring across private, hybrid, and public cloud infrastructure
Incidents with apps deployed in the public cloud usually occur in the following scenarios (see also Figure 4-4):
Figure 4-4: Decision process for incident response
In the same way that hardware and network monitoring information can prompt alerts and operations processes for private infrastructure, we recommend that you integrate the Azure status and monitoring information into the IT organization in the same way.
The global and regional status of all Azure platform services and datacenters is available at the Azure Status website, shown in Figure 4-5.
Figure 4-5: The Azure Status site including RSS feed link and status history
Any alerts or current incidents that might affect customers are published at the top of the page. Users can subscribe to an RSS feed to get updates pushed immediately. Customers are responsible for monitoring this information and taking preemptive action if a regional incident could be of importance to their deployments.
A detailed history of all status alerts is also provided with the resolution time and incident details. Table 4-1 provides a link where you can find additional information about Azure status.
Table 4-1: Azure status
Topic | Comment |
Azure status |
Just as important as the global Azure status is the status and health of the user's individual services and deployments. This information is available in the Azure portal, both as a dashboard (Figure 4-6) and historical health data for individual Azure resources such as Virtual Machines and SQL Database (click Help + Support > Resource Health). Resource health is organized by resource group so that you can get an overview of the health status for a logical group of Azure services.
Figure 4-6: Resource health dashboard in the Azure portal
Historical data of the resource health is automatically saved for 14 days, as illustrated in Figure 4-7.
Figure 4-7: Historical resource health data in the Azure portal
More info To read more about Service Health and Service Health Alerts, see the section "Monitoring" in Chapter 3.
Table 4-2 provides links to where you can find additional information.
Table 4-2: Service health
Topic | Comment |
Resource health overview | https://docs.microsoft.com/azure/resource-health/resource-healthoverview |
Reduce troubleshooting with Azure Resource Health | https://azure.microsoft.com/blog/reduce-troubleshooting-time-withazure-resource-health/ |
How to use the Resource Health API | |
Azure Insights Alerts Portal | https://docs.microsoft.com/azure/monitoring-and-diagnostics/insightsalerts-portal |
Integrate Azure alerts with PagerDuty, OpsGenie, VictorOps | https://azure.microsoft.com/blog/webhooks-for-azure-alerts/?v=17.23h |
IT Service Management (ITSM) integration can drastically help in simplifying the monitoring landscape, especially when both on-premises and cloud resources are in use. The Azure component in use for this integration is Operations Management Suite, which offers a comprehensive operations suite across both on-premises and cloud resources and offers the integration into ITSM systems to manage work items across products and services.
Operations Management Suite Log Analytics is described in more detail in Chapter 3, in the section "Log Analytics." The feature ITSM Connector (currently in preview) provides integration of work items and incidents with these ITSM solutions:
Table 4-3 provides a link where you can find more information.
Table 4-3: ITSM Integration
Topic | Comment |
Centrally manage ITSM work items using IT Service Manager Connector (Preview) | https://docs.microsoft.com/azure/log-analytics/log-analytics-itsmcconnections |
An advantage of public cloud Azure deployments is that they benefit from the automatic outer perimeter protection that Microsoft provides to the entire Azure infrastructure. This means that antimalware programs, distributed denial of service protection (DDoS), and advanced threat analytics are active and protect every Azure workload. You can use the Azure DDoS Standard service to customize the DDoS protection your application receives.
Microsoft has decades of experience in the world of internet security and protecting user's most valuable data; the company applies that experience and associated processes to every Azure subscription and deployment. This protection is an advantage of Azure public cloud deployments and helps IT, product, and Security teams focus their attention on the internal security of deployed workloads. Figure 4-8 shows how the potential attack area is reduced in cloud deployments, visualized by the white boxes. The gray boxes on the right side are no longer vulnerable because of the built-in protections of the Azure platform.
Figure 4-8: The advantage of utilizing Azure infrastructure protection
The Microsoft Security Response Center (MSRC) receives every potential security escalation. Figure 4-9 depicts the process it follows for managing both security and availability incidents in Azure. This process provides the response path for every reported incident, with the clear goal of restoring normal operations as quickly and smoothly as possible.
Figure 4-9: Security incident response life cycle at Microsoft
Customers are responsible for monitoring and detecting security threats and incidents in their own software deployments, but they can take advantage of the included security integration through Operations Management Suite Log Analytics to further detect security incidents.
Log Analytics also provides security incident integration to your on-premises analytics/Security Information and Event Management (SIEM) system through the Azure log integration functionality, as illustrated on Figure 4-10.
Figure 4-10: The flow of Azure security information to a local SIEM system
Integrating Azure Log information into your Log Analytics/SIEM system has the advantage of collecting all logs in one place and helps integrate Azure resources with existing infrastructure and alert configurations.
Azure Security Log Integration has partner integrations out of the box with these systems:
The Azure Security Center is available in the Azure portal and gives security guidance based on the current resources deployed in the Azure subscription. It is a best practice to periodically review this information together with IT security experts and the product team.
The security of all Microsoft and Azure cloud products is described at the Microsoft Trust Center. While you're there, if you have a registration, you can view and download copies of compliance and regulation certifications. Table 4-4 provides links to additional information.
Table 4-4: Security incidents
Topic | Comment |
Azure Log integration overview | https://docs.microsoft.com/azure/security/security-azure-logintegration-overview |
Azure Log SIEM configuration steps | https://blogs.msdn.microsoft.com/azuresecurity/2016/08/23/azure-logsiem-configuration-steps/ |
Microsoft whitepaper Security Incident Response | |
Azure Security Center | https://docs.microsoft.com/azure/security-center/security-center-intro |
Microsoft Trust Center | |
Azure DDoS Protection Standard overview | https://docs.microsoft.com/en-us/azure/virtual-network/ddosprotection-overview |
To ensure that you can remedy incidents with as little delay as possible, we strongly recommend that you include Microsoft support in the clarification process. Microsoft support engineers bring the experience from similar deployments, and they can help clarify root causes early to avoid costly searching. Microsoft support can also help with security and architecture reviews at an early stage in the service life cycle to help avoid incidents from occurring in the first place.
Every Azure subscription has the option of adding support that is directly integrated in the Azure portal (Figure 4-11), which greatly simplifies opening and tracking tickets. You can create support tickets in the Azure portal, via the API, by telephone, or by email.
Figure 4-11: Microsoft support plan options for Azure
Furthermore, it is possible to automate and integrate Microsoft support through email or API calls, as illustrated in Figure 4-12; for example, into the corporate incident management system. This way, there is no danger of losing the connection between an incident and any support assistance that Microsoft can provide.
Figure 4-12: Integration between a corporate incident ticketing system and Microsoft support
Because Microsoft support is connected to a support contract, it is a governance decision as to who should be allowed to create support tickets. You can limit this to dedicated users in the Azure portal.
You can, for example, assign mission-critical apps to have direct access to request Microsoft support, but internal or apps with a lower priority must go through an internal process to validate the support request before sending. Table 4-5 provides links to additional information.
Table 4-5: Microsoft support
Topic | Comment |
Microsoft Support plans | |
Support Requests Access Control |
Problem management simply means recording recurring incidents and problems of all types, and implementing processes to guide solutions that can reduce or eliminate those problems in the future—of course, prioritized to the problems with the biggest business impact.
In the Scrum framework, this is referred to as a Retrospective, in which all stakeholders gather together after a sprint to collect change suggestions that can be implemented in the next sprint. The principle of continuous feedback is important. You need to continually observe what worked and what didn't, and take action to improve recurring and fixable problems for the future.
DevOps and cloud operations can bring a new dynamic to continuous improvement. This happens because feedback and input come much faster—continuous deployment means that software is released much more often; thus, feedback and input for improvement come much more often, as well. Figure 4-13 illustrates the process.
Figure 4-13: DevOps emphasizes collaboration and a continuous cycle of release and feedback
Azure feedback can be given on Twitter under (#AzureSupport), through a Microsoft Support plan, or through the Azure Feedback portal. Table 4-6 provides links to additional information.
Table 4-6: Problem management
Topic | Comment |
Microsoft support plans | |
Azure support via Twitter | |
Azure feedback |
Because continuous delivery is focused on the relatively short-term development and delivery cycle, it is very helpful to have a dedicated innovation and change track that thinks longer term.
This change and innovation track should take input from incidents, problems, vendor roadmaps, technology innovations, and other sources to plan the mid- to long-term technology and innovation strategy of the organization, so thinking in months and years instead of in weeks and sprints.
Figure 4-14 demonstrates how you should integrate factors that influence change—whether coming through problem management, service life cycles, or roadmaps—into an innovation cycle that drives change in an organization. This can help avoid (sometimes costly) surprises if important changes are not taken into account.
Figure 4-14: Input from suppliers, project teams and cloud infrastructure providers, in addition to business and customers, to drive change and innovation
Figure 4-14 is a living part of the Azure team, as well. Input is gathered from a variety of sources, and fed into the Azure roadmap. Customers and users are also heavily involved in this process and are invited to give feedback and vote on features at the Azure Feedback website.
The results of the change cycle are posted on the Azure Roadmap website (Figure 4-15), which is available to the public. Here features are documented that are in development, preview, and release stages.
Figure 4-15: The Azure Roadmap website lists features in development, in preview, and in general availability
All updates and changes to the Azure platform, including new features and rollouts of existing features to new regions, are documented on the Azure Updates site, as shown in Figure 4-16.
Figure 4-16: The Azure Updates website lists all new features and rollouts of existing features to new regions
As illustrated in Figure 4-17, this cycle continually drives the Azure platform forward and delivers a rapid pace of innovation and delivery for Azure customers and users.
Figure 4-17: Input from customers through feedback drives the roadmap, which results in continuous updates
Despite this rapid pace of innovation, stability and reliability are key pillars of the Azure platform, and are backed up by Service-Level Agreement (SLA) guarantees for every nonpreview released service.
The individual life cycles of the Azure platform services are documented on the Microsoft Lifecycle site.
For all paid and nonpreview Azure services, you are guaranteed at least a 12-month notification for a service cancellation without a replacement product. Additional support and migration assistance is available through the Microsoft Support service plans. Table 4-7 has links where you can learn more.
Table 4-7: Platform change
Topic | Comment |
Microsoft Support Life cycles | |
Microsoft Support Plans | |
All service SLAs | |
Azure Roadmap | |
Azure Update |
The goal of IT capacity management is to ensure that IT resources are properly sized to meet current and future resource demands, and also to ensure that those resources are provisioned in a costeffective manner. A major advantage of Azure cloud resources is that you can flexibly manage and dynamically scale the capacity as needed on a minute-by-minute basis, which allows for maximum cost efficiency compared to static on-premise resources.
This is nothing short of a revolution in capacity planning when compared to the lead and ordering times of provisioning servers and hosting in the past. There are basically no downsides to this flexibility, the cloud is ultimately delivering on the process of dynamically allocated compute resource pools that have been the dream of datacenter operators for decades. Finally, "right-sizing" is a reality.
You manage Azure capacity by using subscriptions and resource groups, with which you can set limits on spending (on a subscription level) and assign roles and teams (on both subscription and resource group level).
Because you can plan, assign, and change the resources on demand, capacity planning becomes a fluid topic that provides an organization with the ability to flexibly change and react and use resources as effectively as possible at any given time. Enterprise Agreement (EA) customers can define department spending limits per account in the EA portal, which helps to give an initial guidance to departments for specific projects. Figure 4-18 shows an overview.
Figure 4-18: Hierarchy for organizing Azure resources from the EA contract level down to individual subscriptions
Azure subscriptions have set limits on the number of certain resource types that can be created. You can find more information at the Azure Subscription Service Limits website. The site posts the default and maximum limits. You must monitor limits, and if a higher limit is needed, you'll need to make a support request to increase it.
We recommend that you provision at least one subscription for IT cloud management, where central IT topics such as identity and Azure Active Directory, hybrid networking, or encryption key management are managed. Because of the organization (multiple teams are involved in these topics), multiple subscriptions can make sense.
Azure DevTest Labs is another tool to manage compute capacity for development and testing purposes. With DevTest Labs, you template, configure, and manage pools of virtual machines (VMs) centrally, and then give access to groups of users for specific purposes like load or environment testing. You can set usage and consumption limits for each environment. Additionally, DevTest Labs has a flexible user rights system so that only configured users can start a pool of VMs, run their tests, or configure a new environment. DevTest Labs encourages fine-grained control of lab and test environments, which fits perfectly with the capabilities of Azure to provision and start large-scale environments on demand, and then stop and deallocate them just as quickly when they are no longer needed.
Another tool for capacity management is the Azure Advisor, which can help you to identify unused resources, review performance metrics for running resources, and perform immediate resizing or deallocating of identified resources to improve efficiency. Azure Cost Management (formerly Cloudyn) is a new service with which you can monitor Azure expenditure, drive organizational accountability, and optimize Azure efficiency. Table 4-8 presents links to more resources on Azure capacity management.
Table 4-8: Capacity management
Topic | Resource |
Azure billing documentation | |
Azure service limits | https://docs.microsoft.com/azure/azure-subscription-service-limits |
DevTest Labs | https://docs.microsoft.com/azure/devtest-lab/devtest-lab-overview |
Azure Advisor | |
Azure Limits | https://docs.microsoft.com/azure/azure-subscription-service-limits |
Azure Cost Management |
Assets are grouped into Azure Resource Manager groups, as depicted in Figure 4-19, which are logical containers of resources for tracking and management purposes.
Figure 4-19: This resource group contains a web app, a data table, a VM, and a database in SQL Database
Resource groups are managed per subscription. To access them, in the Azure portal, in the pane on the left, click resource groups, as shown in Figure 4-20. Resource groups can be filtered by subscription, and retrieved via the Azure APIs for integration in custom management applications.
Figure 4-20: Resource groups function in the Azure portal
System and device configuration can be centrally managed for cloud, hybrid and on-premise infrastructure in Azure using System Center Configuration Manager, which offers strong system and infrastructure management across cloud, hybrid, and private on-premises systems.
Using Azure Automation Desired State Configuration (DSC), you can configure systems directly in the automation runbook to enforce a DSC. These jobs can store their configuration as assets in Azure Automation, and be applied to systems in Azure, other clouds, or on-premises.
Chef is also a very strong tool for managing DSC; you can use a Chef Server to configure and deploy VMs with a specific configuration. For more information, follow the links in Table 4-9.
Table 4-9: Configuration management
Topic | Resource |
Azure Automation DSC | https://docs.microsoft.com/azure/automation/automation-dscoverview |
System Center Configuration Manager | https://docs.microsoft.com/sccm/core/understand/configurationmanager-on-azure |
Chef Automation in Azure | https://docs.microsoft.com/azure/virtual-machines/windows/chefautomation |
Updating and patching cloud infrastructure depends on the type of cloud resource being considered.
The Azure platform and its underlying infrastructure are updated via deployment rings, as illustrated in Figure 4-21, starting with inner test rings, and then gradually rolled out to datacenters worldwide.
This deployment ring roll-out strategy helps to prevent update issues from reaching users in the outer production rings because you can catch them early in the inner test and pilot rings. If an issue does occur because of Azure platform updates, any service interruptions are covered by the SLA of the relevant Azure services in a region, and incident information is published on Azure Update.
Figure 4-21: Azure deployment rings
The Azure platform itself is not versioned to the public. It is a stable and constant basis for all Azure services, and maintains compatibility to the higher-level Azure services.
Software as a service (SaaS) products, such as Microsoft Office 365, are completely patched and updated by the software provider (including operating systems and related components). Any downtime caused by updates are covered by the SLA for the software.
Azure platform as a service (PaaS) products are patched and updated by Microsoft;, however, any software running on the platform must be updated and patched by the operations team responsible for the deployment.
The same principle of ring deployment is taken for Azure PaaS services. This minimizes the risk that errors or problems make it beyond the internal rings into the outer production environments. If any unforeseen unavailability of PaaS platform services should occur through a rolling update, it is covered through the PaaS platform's SLA.
PaaS platform libraries such as Java, .NET, PHP, or Python, which are included in Azure PaaS platforms such as Web Apps, are maintained in the currently available major versions, each patched to the latest minor and patched version. For this reason, it is important that deployed PaaS services are always tested with the latest patch from the platform libraries to avoid problems from PaaS platform updates.
If a major version of a platform library such as Java or PHP should be deprecated from a PaaS platform, this would have major consequences for customers and would be announced in advance to give them the chance to move to a supported version.
Customers are responsible for patching their VMs that are deployed on Azure. A solution to help with this is included in the Operations Management Suite, which utilizes an agent that runs on both Windows and Linux to schedule, deliver, and install OS patches and updates, as depicted in Figure 4-22.
Figure 4-22: Deployment of updates and patches
The Operations Management Suite agent runs the update plan using the OS update mechanism, meaning either with Windows Update or a Windows Server Update Services instance for Windows Servers, or through Yum, Apt or Zypper on Linux.
Operations Management Suite gives an overview of the patch status of all configured clients in the dashboard, as shown in Figure 4-23. You can schedule updates for a specific time period for a group of clients.
Figure 4-23: OMS Update Summary
Operations Management Suite Log Analytics has the logs from all updates for searching, alerts, and diagnostic purposes, as shown in Figure 4-24.
Figure 4-24: Operations Management Suite Log Analytics with update logs
In the end, you are responsible for patching and maintaining your IaaS VMs, but tools such as Operations Management Suite Update Management can help you to organize and optimize the patching process. Table 4-10 provides a link where you can read more about update and patch management.
Table 4-10: Update and patch management
Topic | Resource |
Update management solutions in Operations Management Suite | https://docs.microsoft.com/azure/operations-management-suite/omssolution-update-management |
In Azure, the SLA describes Microsoft's commitments for uptime and connectivity. If the SLA for a particular service is 99.9%, it means you should expect the service to be available 99.9% of the time.
You should define your own target SLAs for each workload in your solution. An SLA makes it possible to evaluate whether the architecture meets the business requirements. For example, if a workload requires 99.99% uptime but depends on a service with a 99.9% SLA, that service cannot be a single point of failure in the system. One remedy is to have a fallback path in case the service fails; another is to take other measures to recover from a failure in that service. Table 4-11 shows the potential cumulative downtime for various SLA levels.
Table 4-11: SLA management
SLA | Downtime per week | Downtime per month | Downtime per year |
99% | 1.68 hours | 7.2 hours | 3.65 days |
99.9% | 10.1 minutes | 43.2 minutes | 8.76 hours |
99.95% | 5 minutes | 21.6 minutes | 4.38 hours |
99.99% | 1.01 minutes | 4.32 minutes | 52.56 minutes |
99.999% | 6 seconds | 25.9 seconds | 5.26 minutes |
Of course, higher availability is better, everything else being equal. But as you strive for more 9's, the cost and complexity to achieve that level of availability grows. An uptime of 99.99% translates to about five minutes of total downtime per month. Is it worth the additional complexity and cost to reach five 9's? The answer depends on the business requirements. Here are some other considerations when defining an SLA:
Consider an App Service web app that writes to Azure SQL Database. As of this writing, these Azure services have the following SLAs:
If either service fails, the entire application fails. In general, the probability of each service failing is independent, so the composite SLA for this application is 99.95% × 99.99% = 99.94%. That's lower than the individual SLAs, which isn't surprising, because an application that relies on multiple services has more potential failure points. On the other hand, you can improve the composite SLA by creating independent fallback paths. For example, if SQL Database is unavailable, put transactions into a queue, to be processed later, as illustrated in Figure 4-25.
Figure 4-25: Composite SLA
With this design, the application is still available even if it can't connect to the database. However, it fails if the database and the queue both fail at the same time. The expected percentage of time for a simultaneous failure is 0.0001 × 0.001, so the composite SLA for this combined path is as follows:
Database OR queue = 1.0 − (0.0001 × 0.001) = 99.99999%
Here's the total composite SLA:
Web app AND (database OR queue) = 99.95% × 99.99999% = ~99.95%
But there are trade-offs to this approach. The application logic is more complex, you are paying for the queue, and there can be data consistency issues to consider.
Another high-availability technique is to deploy the application in more than one region and use Azure Traffic Manager to failover if the application fails in one region. For a two-region deployment, the composite SLA is calculated as follows:
Combined SLA for both regions = 1 − (1 − N)(1 − N) = N + (1 − N)N
Composite SLA = 99.99% × (combined SLA for both regions)
Also, failing-over is not instantaneous and can result in some downtime during a failover. See Traffic Manager endpoint monitoring and failover.
The calculated SLA number is a useful baseline, but it doesn't tell the entire story about availability. Often, an application can degrade gracefully when a noncritical path fails.
The potential of cloud computing for all organizations is immense, but it also requires changes in governance, architecture, operations and service management. We have tried to show in this document that not everything needs to change; however, adjustments and new ideas in key areas can unlock a lot of the potential and make cloud transformation in any IT organization possible.
Here are some key points from each of the chapters:
For certain, the change will not stop and the drive for ever more efficient and advanced cloud infrastructure will continue to make it possible for teams to deliver increasingly advanced products at a faster pace. The teams and organizations that profit the most will be those that fully utilize and integrate cloud platforms, thereby freeing them up to spend most of their time delivering customer value. Taking advantage of the cloud and the effective implementation and integration of cloud technologies is a key part of the transformation to win the battle for users' hearts, minds, and, most important, their screen time.
| Joachim Hafner is a cloud solution architect at Microsoft Germany, helping clients to integrate the Azure platform into their enterprise architecture and providing guidance for designing modern cloud applications based on Azure technologies. Before he joined Microsoft, he worked as a senior enterprise architect for one of the largest IT service providers with a strong focus on hybrid cloud strategies. |
| Simon Schwingel is a cloud solution architect at Microsoft Germany where he assists customers to move to the cloud. He provides guidance in how to unleash the potential of public cloud–based architectures and technologies. Simon started his career 19 years ago as a web developer. Since then, he performed inter alia as consultant for Enterprise Content Management solutions and as lead architect for cloud-based collaboration services for one of the largest IT service providers with focus on private cloud infrastructure. |
| Tyler Ayers is a cloud solution architect at Microsoft Germany working with customers to define and integrate their cloud strategy with Azure in the financial services and media industries. Previously, he worked as lead architect for enterprise software products in the retail and banking industries, and was an early proponent for integrating cloud and hybrid technologies into every IT organization's toolbox. |
| Rolf Masuch is a cloud solution architect at Microsoft Germany with a focus Azure Governance, Infrastructure, and Security. Rolf started his career as a Microsoft Certified Trainer for Windows in 1996. While maintaining his status as a trainer he worked for various Microsoft partners in several roles mainly in the consulting area around large Active Directory consolidations and implementing large-scale messaging systems based on Microsoft Exchange. He also was honored with the status of Most Valuable Professional (MVP) for his efforts in the PowerShell community. |