Microsoft Azure For Dummies book cover

Microsoft Azure For Dummies

By: Timothy L. Warner Published: 03-24-2020

Your roadmap to Microsoft Azure 

Azure is Microsoft’s flagship cloud computing platform. With over 600 services available to over 44 geographic regions, it would take a library of books to cover the entire Azure ecosystem.  Microsoft Azure For Dummies offers a shortcut to getting familiar with Azure’s core product offerings used by the majority of its subscribers. It’s a perfect choice for those looking to gain a quick, basic understanding of this ever-evolving public cloud platform.

Written by a Microsoft MVP and Microsoft Certified Azure Solutions Architect, Microsoft Azure For Dummies covers building virtual networks, configuring cloud-based virtual machines, launching and scaling web applications, migrating on-premises services to Azure, and keeping your Azure resources secure and compliant. 

  • Migrate your applications and services to Azure with confidence
  • Manage virtual machines smarter than you've done on premises
  • Deploy web applications that scale dynamically to save you money and effort
  • Apply Microsoft's latest security technologies to ensure compliance to maintain data privacy

With more and more businesses making the leap to run their applications and services on Microsoft Azure, basic understanding of the technology is becoming essential. Microsoft Azure For Dummies offers a fast and easy first step into the Microsoft public cloud.

Articles From Microsoft Azure For Dummies

page 1
page 2
11 results
11 results
Microsoft Azure For Dummies Cheat Sheet

Cheat Sheet / Updated 03-14-2021

If I were to summarize the best approach to Microsoft Azure in three words, those words would be “always be learning.” The Azure product development teams release new features every workday, so if you aren’t actively working to stay current, you’ll fall behind, and your career will suffer. This Cheat Sheet provides you some reminders of some essential ingredients in Azure automation. Remember that the Azure portal is all well and good until you’re tasked with deploying 50 virtual machines!

View Cheat Sheet
How to Use Azure Log Analytics

Article / Updated 03-27-2020

If you’ve spent any time in Azure Monitor, you’ve seen some of the myriad log files that your Azure resources create. Think of all the ways that data is represented in Microsoft Azure, and imagine a way to put all your logs in a single data lake and run queries against it seamlessly. Azure Log Analytics is a platform in which you do just that: aggregate VM and Azure resource log files into a single data lake (called a Log Analytics workspace) and then run queries against the data, using a Microsoft-created data access language called Kusto (pronounced KOO-stoh) Query Language (KQL). You’ll find that Log Analytics somehow normalizes all these different log streams into a tabular structure. You’ll also discover that KQL is similar to Structured Query Language (SQL), the data access language that is standard for relational databases. Creating a Log Analytics workspace The first order of business is to deploy a Log Analytics workspace. Then you can on-board as few or as many Azure resources to the workspace as you need. You can also deploy more than one Log Analytics workspace to keep your log data separate. To create a new Azure Log Analytics workspace, follow these steps: In the Azure portal, browse to the Log Analytics Workspaces blade, and click Add. The Log Analytics workspace blade appears. Complete the Log Analytics workspace blade. You'll need to provide the following details: Workspace name Subscription name Resource group name Location Pricing tier Click OK to create the workspace. Click OK to submit your deployment. Log Analytics has a free tier as well as several paid tiers. The biggest free tier limitations are Data ingestion limit of 5 GB per month 30-day data retention limit Connecting data sources to the Azure Log Analytics workspace With your workspace online, you’re ready to on-board Azure resources into said workspace. To connect Azure resources to the workspace, go back to Monitor Diagnostic settings, enable diagnostics, and point the log streams to your workspace. You can connect VMs to the workspace directly from the workspace’s Settings menu. Follow these steps: In your Log Analytics workspace settings menu, click Virtual Machines. You see a list of all VMs in the workspace’s region. You can see which VMs are connected to the workspace and which are not. If necessary, use the filter controls until you see the VM you want to connect. You can link a VM to only one workspace at a time. Below for example,the vm1 virtual machine is linked to another workspace. Select the desired VM, and click Connect. Behind the scenes, Azure deploys the Log Analytics agent (formerly called Microsoft Monitoring Agent) to the VM. Verify that the VM is connected to the workspace. You can see this information in your workspace settings. Or you can revisit your VM’s Extensions blade and verify that the MicrosoftMonitoringAgent extension is installed. You should know that Log Analytics can on-board on-premises VMs, particularly those managed by Systems Center Operations Manager, just as it can native cloud Linux and Windows Server VMs. You can disconnect a VM from its current workspace and connect it to another one. This operation is trivial, taking only two minutes or so to complete. To do this, simply select the VM from within the workspace and click Disconnect from the toolbar. Writing KQL queries You need to know a bit about how to access your Log Analytics workspace data with KQL. KQL is fast and easy to learn, and it should seem familiar to you if you’ve used Splunk Search Processing Language, SQL, PowerShell, or Bash shell. Touring the Log Search interface You can get to the Log Search interface by opening Monitor and selecting the Logs blade. Another way to get there (is to go to your Log Analytics workspace and click the Log setting. A third method is to use the Log Analytics Query Playground, where you can work with an enormous data set, getting to know Log Analytics before generating a meaningful data set. Follow these steps to run some sample KQL queries: Go to the Log Analytics portal demo. This site is authenticated, but don’t worry: You’re using Microsoft’s subscription, not your own. Expand some of the tables in the Schema list. There’s a lot in this list. Log Analytics normalizes all incoming data streams and projects them into a table-based structure. Expand the LogManagement category; then expand the Alert table, where you can use KQL to query Azure Monitor alerts. The t entries (shown under the expanded SecurityEvent item below) are properties that behave like columns in a relational database table. On the Log Search toolbar, click Query Explorer, expand the Favorites list, and run the query Security Events Count by Computer During the Last 12 Hours. This environment is a sandbox. Microsoft has not only on-boarded untold resources into this workspace but also written sample queries to let you kick the tires. In the results list, click Chart to switch from Table to Chart view. You can visualize your query results automatically with a single button click. Not every results set lends itself to graphical representation, but the capability is tremendous. Click Export, and save your query results (displayed columns only) to a CSV file. Note the link to Power BI, Microsoft’s cloud-based business intelligence/dashboard generation tool. Writing basic KQL queries For fun, let’s try an obstacle course of common KQL queries. Click the plus sign in the Log Search query interface to open a new tab — a multitab interface like those in Visual Studio and Visual Studio Code. To get a feel for a table, you can instruct Azure to display any number of rows in no particular order. To display 10 records from the SecurityEvent table, for example, use the following command: SecurityEvent | take 10 Did you notice that the query editor attempted to autocomplete your query as you typed? Take advantage of that convenience by pressing Tab when you see the appropriate autocomplete choice appear. Use the search keyword to perform a free-text query. The following query looks in the SecurityEvent table for any records that include the string "Cryptographic": search in (SecurityEvent) "Cryptographic" | take 20 When you press Enter, you’ll doubtless notice the pipe character (|). This character functions the same way here as it does in PowerShell or the bash shell. Output from one query segment is passed to the next segment via pipe — a powerful construct for sure. You can ramp up the complexity by finishing with filtering and sorting. The following code both filters on a condition and sorts the results in a descending manner based on time: SecurityEvent | where Level == 8 and EventID == 4672 | sort by TimeGenerated desc If you’re thinking, “Wow, these KQL queries act an awful lot like SQL!” you’re right on the money. Welcome to Log Analytics!

View Article
Deploying Azure VMs from the Microsoft Azure Marketplace

Article / Updated 03-27-2020

Ready to work with Microsoft Azure’s technology? Here, you learn how to deploy Linux and Windows VMs (virtual machines) from Azure Marketplace. Deploying a Linux VM It’s understandable that most Azure experts to get a kick out of the fact that Microsoft supports Linux natively in Azure. It was inconceivable up until a handful of years ago that we’d be able to run non-Windows VMs by using Microsoft technologies. Here, you learn how to deploy a simple Linux web server in a new virtual network, using an Ubuntu Linux 18.04 Long-Term Support (LTS) VM image from the Azure Marketplace. Deploying from the Azure portal Follow these steps to deploy a Linux VM in the Azure portal: Choose Favorites→Create a Resource, and choose Ubuntu Server 18.04 LTS. Alternatively, you can browse to the Virtual Machines blade and click Add to deploy a new resource. If Ubuntu doesn’t show up in the Azure Marketplace list, type its name to find it in the VM template gallery. On the Create a Virtual Machine blade, complete the Basics tab. The following image shows the Create a Virtual Machine blade. Oh, boy, it’s tough not to feel overwhelmed when you see all the tabs: Basics, Disks, Networking, Management, Advanced, Tags, and Review + Create. Use the following information to complete the other fields: Virtual Machine Name: The name needs to be unique only within your resource group. Pay attention to the validation helpers that pop up when you place your cursor in a field. Availability Options: If you don’t see both Availability Zone and Availability Set in the drop-down menu, choose a different region. (East us 2 is a good choice.) Because this is a practice deployment, you can choose No Infrastructure Redundancy Required. Image: You specified the Ubuntu image in step 1, but if you’re curious about other options, open the drop-down menu to see the most popular VM images. You can also click Browse All Public and Private Images to view all templates in the Azure Marketplace. Size: For now, accept the Microsoft-recommended default VM size. Authentication Type: Linux VMs are different from Windows because you can use Secure Shell (SSH) key-based authentication or password-based authentication. For this exercise, choose password. You should choose a creative default administrator account name. ARM won’t let you use commonly guessed administrator account names such as root an, admin. Public Inbound Ports: For testing purposes, associate a public IP address with this VM, and connect to the instance via SSH. You’ll tighten network security group security later to prevent unauthorized access attempts by Internet-based bad actors. Select Inbound Ports: Choose SSH. Complete the Disks tab. This tab is where you make an initial choice about the VM’s OS and data disks. Choose Standard HDD to save money. The number of data disks you can create depends on your chosen VM instance size. You can always add data disks later, so for now, proceed to the next blade. Note that the default number of data disks Azure provides the new VM is zero; it’s up to you as administrator to decide whether you want to use them. Complete the Networking tab. You have some crucially important decisions to make in terms of where you want to place your VM and how you want to configure its connectivity. Here are the configuration options: Virtual Network: The template deploys a new virtual network by default. That’s what you want here, so leave this setting alone. If you place your VM on the wrong virtual network, you’ll need to redeploy it to move it, which is a pain, so try to make the right choice the first time around. Subnet: Leave this setting at its default. Public IP: Leave this setting at its default. You do in fact want a public IP address, at least initially. NIC Network Security Group: Select Basic. Public Inbound Ports: Allow Selected Ports. Select Inbound Ports: Select SSH. Accelerated Networking: Not all VM templates support this option. For VM templates that support this feature, accelerated networking gives the VMs a network speed boost by allowing the VM to use the Azure networking backbone more directly. Load Balancing: Select No. Complete the Management tab. Ensure that Boot Diagnostics is enabled and all other options are off. Boot Diagnostics is required to use the VM serial console, so it’s always a good idea to enable it sooner rather than later. Review the Advanced and Tags tabs. You don’t need any of these options right now, but they’re worth examining. Extensions allow you to inject agent software and/or management scripts into the VM. You can handle configuration after deployment, however. Taxonomic tags are a way to track resources across subscriptions for accounting purposes. Submit the deployment, and monitor progress. Click the Review + Create tab; then click Create after ARM informs you that your selections passed validation. If an error occurs, ARM places a red dot next to the configuration blade(s) where it detects invalid settings. Connecting to the VM Use Azure Cloud Shell to make an SSH connection to your VM. Follow these steps: In Azure portal, browse to the Overview blade of your newly created VM, and note the public IP address. You see a VM’s configuration below. Open Cloud Shell, and connect to your Linux VM by specifying your default administrator account name and the VM’s public IP address. To connect to a Linux VM at 13.68.104.88 using my tim admin account, you type: ssh [email protected] Type yes to accept the VM’s public key and then type your password to enter the SSH session. At this point, you’re working directly on the Linux VM. You can get help for any Linux command by typing man . Scroll through the help document with your arrow keys, and press Q to quit. Deploying a Windows Server VM Here, you learn how to create a Windows Server VM by using Visual Studio 2019 Community Edition and an ARM template. Visual Studio 2019 Community Edition is a free Visual Studio version that you can use for testing, development, and open-source projects. Microsoft does make a Visual Studio version for macOS. This procedure is especially important for you to understand for two reasons: ARM templates form a basis for administrative automation, development, and operations. You’ll use ARM templates to complete most tasks. Setting up your development environment Follow these high-level steps to get your Visual Studio environment set up: Download Visual Studio 2019 Community Edition, and run the installer. You need administrative permissions on your Windows 10 workstation to install the software. Choose the Azure workload. This step is the most important one. Visual Studio is an integrated development environment that supports multiple development languages and frameworks. For the purpose of deploying a Windows Server VM, you need to install the Microsoft Azure software development kits and tools. The image below illustrates the user interface. You can leave the Azure workload components set at their defaults. After installation, open Visual Studio, and log in to your Azure administrator account. When you start Visual Studio 2019, you’ll see a Get Started page. Click Continue Without Code; then open the Cloud Explorer extension by choosing View→Cloud Explorer. Authenticate to Azure Active Directory, and select the Azure subscription(s) you want to work with. Deploying the VM Assuming that you have Visual Studio open and you’re logged into your Azure subscription, you’re ready to rock. Here, you’re deploying a Windows Server VM from the Azure Quickstart Templates gallery. In this example, you use a template definition that includes Managed Disks. Follow these steps: In Visual Studio, choose File→New→Project. The Create a New Project dialog box opens. Search the Visual Studio template gallery for Azure Resource Group, select it, and click Next. Name and save your project. Choose a meaningful project name such as Simple Windows VM, choose your favorite directory location, and click Create. Select the 101-vm-with-standardssd-disk template in the Azure Quickstart Templates gallery and click OK. Here’s the interface. Double-click your azuredeploy.json template file. This action loads the JavaScript Object Notation (JSON) file into your code editor. Pay particular attention to the JSON Outline pane. Browse the ARM template’s contents. The three elements shown in JSON Outline view are parameters: You supply these values to the template at deployment time. Note the allowedValues element on lines 26–30; the template author prepopulated the VM disk types to make validation and deployment simpler. variables: These values represent fixed or dynamic data that is referenced internally within the template. resources: In this deployment, you create four resource types: virtual machine, virtual NIC, virtual network, and public IP address. In Solution Explorer, right-click the project and choose Validate from the shortcut menu. The Validate to Resource Group dialog box opens. Fill in the fields of the dialog box and then click Edit Parameters to supply parameter values. Visual Studio allows you to validate your template before deploying it to Azure. The resource group is the fundamental deployment unit in Azure. Therefore, your deployments must specify a new or existing resource group. Click Validate, and watch the Output window for status messages. Make sure to look behind your Visual Studio application; Azure spawns a PowerShell console session to prompt you to confirm the admin password. The feedback you’re looking for in the Output window is: Template is valid. If the template fails validation, Visual Studio is pretty good about telling you the template code line(s) on which it found an issue. You can debug and retry validation as many times you need to until the template passes. Deploy the VM by right-clicking the project in Solution Explorer and choosing Deploy from the shortcut menu. The shortcut menu contains a reference to your validation configuration. Monitor progress, and verify that the VM exists in the Azure portal. You’ll know that the deployment completed successfully when you see the following status line in the Output window: Successfully deployed template 'azuredeploy.json' to resource group 'your-resource-group'. Connecting to the VM You normally use Remote Desktop Protocol to manage Windows Servers remotely on-premises, and Azure is no different. Browse to your new VM’s Overview blade, and click Connect. The Remote Desktop Connection dialog box opens. You can download the .rdp connection file and open it from here. The steps to make an RDP connection are Click Connect from the Overview blade toolbar. Download the RDP connection file to your local computer. Open the connection using your preferred RDP client software. Microsoft makes a native Remote Desktop Protocol client for macOS; it’s available in the Mac App Store.

View Article
A Quick Tour of Microsoft Azure App Service

Article / Updated 03-27-2020

In a nutshell, Microsoft App Service is a Hypertext Transfer Protocol (HTTP)-based web application hosting service. Think of Microsoft App Service as GoDaddy, but with much more power. The idea is that if you're willing to surrender full control app’s underlying infrastructure (which is what Azure Virtual Machines is for) you’ll receive in exchange Global replication and geoavailability Dynamic autoscaling Native integration into continuous integration/continuous deployment pipelines Yes, App Service uses virtual machines (VMs) under the hood, but you never have to worry about maintaining them; Microsoft does that for you. Instead, you focus nearly exclusively on your source code and your application. Microsoft App Service development frameworks and compute environments Microsoft App Service supports several development frameworks, including the following: .NET Framework .NET Core Java Ruby js Python PHP You can use any of the following as your underlying compute environment in App Service: Windows Server VM Linux VM Docker container Web apps The static or dynamic web application is the most commonly used option in App Service. Your hosted web apps can be linked to cloud- or on-premises databases, API web services, and content delivery networks. API apps An application programming interface (API) is a mechanism that offers programmatic (noninteractive) access to your application by using HTTP requests and responses — a programming paradigm known as Representational State Transfer (REST). Nowadays, Microsoft supports API apps from App Service and the API Management service. Mobile apps A mobile app provides the back end to an iOS or Android application. Azure mobile apps provide features most smartphone consumers have grown to expect as part of the mobile apps they use, such as social media sign-in, push notifications, and offline data synchronization. Azure Logic apps A logic app provides a way for developers to build business workflows without having to know all the underlying APIs in different services. You might create a logic app that triggers whenever someone mentions your company’s name on Twitter, for example. Then this app may perform several actions, such as posting a notification message in your sales department’s Slack channel or creating a record in your customer relationship management database. Azure Function apps A function app allows developers to run specific code at specific times without worrying about the underlying infrastructure. That’s why function apps are called serverless applications, or Code as a Service (CaaS) solutions. One company has a function app that sends a confirmation email message to a prospective customer whenever that user creates a new account on his website. Function apps support the C#, F#, and Java programming languages. Both logic apps and function apps operate on the basis of a trigger. This trigger could be a manual execution command, a time schedule, or a discrete operation that occurs inside or outside Azure. Azure App Service logical components The following image shows the components that make up App Service. An App Service web app is powered by an associated App Service plan. This plan is an abstraction layer; you control how much virtual compute you need to power your application or applications, and you dynamically scale vertically to suit your performance requirements and budgetary needs. The App Service plan is the only required component. You can extend the app’s capabilities by integrating it with any of the following: Storage account: An App Service plan has persistent storage, but many developers like to use a flexible storage account for additional space. Virtual network: You can link an App Service app to a virtual network — perhaps to connect your web app to a database running on a VM. Databases: Most web apps nowadays use relational, nonrelational, and/or in-memory databases to store temporary or persistent data. Content delivery network: You can place static website assets in a storage account and let Azure distribute the assets globally. This way, your users get a much faster experience because their browsers pull your site content from a low-latency, geographically close source. App Service plans are organized in three increasingly powerful (and expensive) tiers: Dev/Test: F- and B-series VMs with minimal compute and no extra features. This compute level is the least expensive but offers few features and shouldn’t be used for production apps. Production: S- and P-series VMs with a good balance of compute power and features. This tier should be your App Service starting point. Isolated: Called the App Service Environment and very expensive; Microsoft allocates hardware so that your web app is screened from the public Internet You can move within or between tiers as necessary. This capability is one of the greatest attributes of public cloud services. Here, you see an App Service plan. Azure uses the Azure Compute Unit as a standardized method to classify compute power. You see it referenced in Azure VMs, App Service, and any other Azure resource that uses VMs. Having a standardized performance metric is crucial, because Microsoft uses several types of hardware in its data centers. Just because you can associate more than one web app into a single App Service plan doesn’t mean that you should. Sure, you can save money (the App Service plan incurs run-time costs based on instance size), but the more apps you pack into a single plan, the greater the burden on the underlying VM. Want to learn more about Microsoft Azure? Check out these ten Azure educational resources.

View Article
Top 10 Azure Educational Resources

Article / Updated 03-27-2020

If you really want to be successful with Microsoft Azure, you’ve got to keep up to date with it. To help you with that, here are ten hand-selected Azure educational resources. Happy reading! Azure documentation The Azure documentation library is your ultimate source of truth on how Azure products work. Microsoft has open-sourced the documents to GitHub, so community members (like you!) can edit them and submit your for review. The living nature of the library means that the documentation evolves with Azure products. You’ll also find plenty of multimedia resources to address educational styles that cater more to a hands-on or visual approach. If you have yet to skill up on Git source-code control and the GitHub collaboration workflow, consider checking out Sarah Guthals’ and Phil Haack’s splendid GitHub For Dummies (John Wiley & Sons, Inc.). Azure Architecture Center Microsoft has long since eaten its own dog food, so to speak, which means two things: It uses the products, technologies, and frameworks that it develops. It shares its best practices with customers. The Azure Architecture Center includes two super-valuable online guides: Azure Application Architecture Guide: How Microsoft approaches designing scalable, resilient, performant, and secure application architectures in Azure Microsoft Cloud Adoption Framework for Azure: How Microsoft helps customers transition from fully on-premises to hybrid cloud to cloud-native architectures The center also includes a reference architecture library as well as a varied collection of topology diagrams and explanations. Many of the diagrams are available for free as Microsoft Visio drawing files. If you haven’t invested in Visio or an equally good technical diagramming tool, consider doing so. Practically every Azure architect uses either Visio or Microsoft PowerPoint to create Azure architectural diagrams. Azure REST API Browser Every action you take in your Azure subscription translates into Representational State Transfer (REST) API calls to the Azure public cloud. The Azure REST API Browser enables you to deep-dive into resource providers, view available operations, and even test them. After the API Browser shows you how the Azure Resource Manager API request/response life cycle works, you can productively build custom applications that interact directly with the ARM REST API. Microsoft @ edX edX is a not-for-profit company that hosts massive open online courses (MOOCs, pronounced mooks). Microsoft bought into the edX ecosystem heavily. You’ll find a large collection of Azure-related courses that cover most disciplines, including Architecture Administration Development Security Internet of Things Data engineering Data science Machine learning These courses are free and require only that you log in with your Microsoft account to track your progress. The company’s multimedia approach is an excellent way to reach people who have different (or multiple) learning styles. Microsoft Learn Microsoft Learn is similar in ways to edX, with the exception that Learn is entirely homegrown at Microsoft. You’ll find hundreds of free, curated labs on most Azure job roles; the labs are well-written and complete. Microsoft includes a sandbox environment in many hands-on labs that gives you access to Microsoft’s Azure subscription. This means you learn Azure by working with Azure directly rather than working with a mock-up or simulation. Azure Certification If you ask five IT professionals their views on professional certification, you’ll likely get five different responses. Some folks require Azure certification to keep up their Microsoft Partner status; other people want certification to differentiate themselves in a crowded job market. Regardless, this site is the one you want to delve into for Azure role-based certification. In 2018, Microsoft moved from a monolithic Azure certification title to role-based badges. This way, you can demonstrate your Azure expertise in a way that’s closely aligned with your present or desired job role, be it administrator, developer, architect, DevOps specialist, and so forth. It’s a good idea to bookmark the Microsoft Worldwide Learning Certification and Exam Offers page. Most of the time, you can find the Exam Replay offer, as well as discounts on MeasureUp practice tests. Exam Replay gives you a voucher for a second exam if you don’t pass on your first attempt. MeasureUp MeasureUp is Microsoft’s only authorized practice exam provider. It can’t be overstated how crucial practice exams are to success on the Azure certification exam. There have even been seasoned experts walk into an exam session smiling and exit crying because they didn’t pass because they weren’t expecting the myriad ways that Microsoft Worldwide Learning tests the candidate’s skills. Oh, by the way: Microsoft Learn referes to Microsoft Worldwide Learning’s online technical education hub. Yes, they are different things. MeasureUp gives you an accurate exam experience. Just as important as understanding the theory is understanding and being comfortable with how Microsoft assesses your knowledge. On the Azure exams, you can expect to see performance-based labs in which you’re given an Active Directory (AD) login to the real Azure portal and required to complete a series of deployment and/or configuration tasks. The exams also feature case studies that present a fictional company’s current situations, Azure-related goals, and technical limitations; then you’re asked to answer several questions by analyzing each the case. These exams are no joke and deserve dedicated preparation time. Meetup When you make professional connections, it’s a natural outcome that your name will arise when opportunities make themselves manifest. To that point, you should visit Meetup.com and search for Azure user groups in your area. At this writing, there are 716 groups worldwide with more than 300,000 members. Azure meetups are great opportunities to find out new stuff, and you’ll meet neighbors who do the kind of work you’re doing or want to do in the future. IT recruiters make a habit of sponsoring user groups, so you can get plugged into job-search networks at meetups as well. You should also try Microsoft Reactor, which is a Microsoft-run community hub listing free meetups for learners and community organizers. The subject matter covers Azure and most other Microsoft technologies and job roles. CloudSkills CloudSkills is a boutique cloud consultancy that has Microsoft Azure education as its principal aim. Mike Pfeiffer is a Microsoft Most Valuable Professional (MVP) who has worked as a cloud architect for both Amazon web Services and Microsoft. He created CloudSkills As a training company that offers free and paid training, professional consulting, and general cloud and career guidance. You can find training sessions at CloudSkills.io, free podcasts interviews at CloudSkills.fm, and free tutorials at CloudSkills.tv. Pluralsight Many of the world’s Azure experts train with Pluralsight. Pluralsight and the Azure teams partnered to create an industry-leading online learning library. Many of these video training courses, covering all the major Azure job roles, are available for free. Pluralsight also offers pre- and post-skills assessments as well as mentoring services.

View Article
Implementing Azure Cosmos DB

Article / Updated 03-27-2020

When it comes to Microsoft Azure, Cosmos DB is the data store solution. Relational databases are all about schema, or structure. Many say that to be a relational database administrator, you should be a micromanager, because every data row needs to be heavily constrained to fit the table, relationship, and database schema. Although relational databases offer excellent data consistency, they tend to fall down in the scalability department because of all the schema overhead. Enter the nonrelational database. Rather than call a nonrelational database schemaless, it’s more accurate to say that NoSQL databases have a flexible schema. At first, you may think that a flexible schema would make querying nearly impossible. But NoSQL databases can overcome this hurdle by partitioning the data set across multiple clustered nodes and apply raw compute power to the query execution. NoSQL is generally understood to mean not only SQL. Azure Cosmos DB features Cosmos DB (originally called Document DB) is Azure’s multimodel, georeplicated, nonrelational data store. You can implement Cosmos DB in conjunction or instead of a relational database system. Look below for a tour of Cosmos DB’s features. Cosmos DB is Multimodel Originally Document DB was a JavaScript Object Notation (JSON) document-model NoSQL database. Microsoft wanted to embrace a wider customer pool, however, so it introduced Cosmos DB, which supports five data models/application programming interfaces (APIs): Core (SQL): This API is the successor to the original Document DB. The data store consists of JSON documents, and Core API provides a SQL-like query language that should be immediately comfortable for relational database administrators and developers. Azure Cosmos DB for MongoDB API: This API supports the MongoDB wire protocol. MongoDB, also a JSON document store, allows you to query Cosmos DB as though it were a MongoDB instance. Cassandra: This API is compatible with the Cassandra wide column store database and supports Cassandra Query Language. Azure Table: This API points to the Azure storage account’s table service. It’s a key/value data store that you can access with ARM’s representational state transfer (REST) APIs. Gremlin (graph): This API supports a graph-based data view and the Apache Gremlin query language. Do you see a theme? The idea is that just about any developer who needs a NoSQL data store should be able to use Cosmos DB without sacrificing original source code or client-side tooling. Azure Cosmos DB has turnkey global distribution With a couple of mouse clicks, you can instruct Azure to replicate your Cosmos DB database to however many Azure regions you need to put your data close to your users. Cosmos DB uses a multimaster replication scheme with a 99.999 percent availability service level agreement for both read and write operations. Azure Cosmos DB has multiple consistency levels Relational databases always offer strong consistency at the expense of speed and scale. Cosmos DB offers flexibility in this regard, allowing you to select (dynamically) any of five data consistency levels: Strong: Reads are guaranteed to return the most recently committed version of an item. This level is the slowest-performing but most accurate. Bounded Staleness, Session, and Consistent Prefix: These consistency levels offer balance between performance and consistent query results. Eventual: Reads have no ordering guarantee. This choice is the fastest but least accurate. Data consistency refers to the requirement that any database transaction change affected data only in allowed ways. With regard to read consistency specifically, the goal is to prevent two users from seeing different results from the same query due to incomplete database replication. How to Create a Cosmos DB account Now, you get down to business. The first task is getting Cosmos DB off the ground to create a Cosmos DB account. After you have the account, you can define one or more databases. Follow these steps to create a Cosmos DB account: In the Azure portal, browse to the Azure Cosmos DB blade, and click Add. The Create Azure Cosmos DB Account blade appears. On the Create Azure Cosmos DB Account blade, complete the Basics page, using the following settings: Account Name: This name needs to be unique in its resource group. API: Select Core (SQL). Geo-Redundancy: Don’t enable this option. If you do, Azure replicates your account to your region’s designated pair. Multi-Region Writes: Don’t enable this option. You can always enable it later if you need multiple read/write replicas of the account throughout the world. Review the Network page. Click Review + Create and then click Create to submit the deployment. Running and debugging a sample Cosmos DB application One of the best ways to gain general familiarity with a new Azure service is to visit its Quick Start page. Let’s do this now with Cosmos DB. The following image shows Cosmo DB Quick Start page. If you follow the Cosmos DB Quick Start tutorial, you can accomplish the following goals: Create a new Cosmos DB database and container. Download a .NET Core web application that connects to the Cosmos DB database. Interact with the container and data store on your workstation by using Visual Studio. To run a sample application, follow these steps: On your Cosmos DB account’s Quick Start blade, choose the .NET Core platform, and click Create ‘Items’ Container. Azure creates a container named ‘Items’ with 10 GB capacity and 400 request units (RUs) per second. As you may rightly guess, the RU is the standardized Cosmos DB performance metric. Click Download to download the preconfigured .NET Core web application. Unzip the downloaded archive on your system, and double-click the quickstartcore.sln solution file to open the project in Visual Studio 2019 Community Edition. In Visual Studio, build and run the solution by choosing Build→Build Solution. Choose Debug→Start Debugging to open the application in your default web browser. In the To-Do App with Azure DocumentDB web application that is now running in your web browser, click Create New, and define several sample to-do items. When you add to-do items, you’re populating the Items container in your Azure Cosmos DB database. Close the browser to stop debugging the application. For extra practice, use the Visual Studio publishing wizard (which you find by right-clicking your project in Solution Explorer and choosing Publish from the shortcut menu) to publish this app to Azure App Service. This exercise is a great test of the skills you’ve developed thus far. Interacting with Cosmos DB To practice interacting with Cosmos DB and your database, return to the Azure portal and look at your Cosmos DB account settings. Here, some key settings are highlighted to make sure you know where to find them: Data Explorer: Perform browser-based query and database configuration. The following image shows Data Explorer. Replicate Data Globally: Click the map to replicate your Cosmos DB account to multiple regions. (Additional costs apply.) Default Consistency: Switch among the five data consistency levels. Firewall and Virtual Networks: Bind your Cosmos DB account to specific virtual network(s). Keys: View the Cosmos DB account endpoint Uniform Resource Identifier, access keys, and connection strings. Now follow these steps to interact with your new Cosmos DB database directly from the Azure portal: In your Cosmos DB account, select Data Explorer. Click the Open Full Screen button on the Data Explorer toolbar. This button takes you to Azure's Cosmo DB page in a separate browser tab, giving you more screen real estate to run queries. The ToDoList planet icon represents the icon, and the Items icon represents the container. The container is the Cosmos DB replication unit. Right-click the Items container and choose New SQL Query from the shortcut menu. The Save Query button is handy for retaining particularly useful queries. View your existing items by running the default query. The default query provided by Azure in the Data Explorer, SELECT * FROM c, retrieves all documents from your Items container. c is an alias for container. You’ll find the alias to be super useful when you work with the Cosmos DB Core API. Experiment with different SELECT queries. The double dash (--) denotes a one-line comment in Data Explorer. Try entering these queries in Data Explorer. -- select two fields from the container documents SELECT c.name, c.description from c -- show only incomplete todo items SELECT * from c WHERE c.isComplete = false Use Data Explorer to update a document. In the SQL API tree view on the left side of the image above, expand the Items container, and select Items. Click the document you want to edit, and update the isComplete field on at least one document from “false” to “true,” or vice-versa. Click the Update toolbar button to save your changes. Bookmark the Microsoft Azure DB page that you can easily access Cosmos DB Data Explorer in a full-window experience. Also, Microsoft offers excellent Cosmos DB SQL query cheat sheets.

View Article
Building Workflows with Azure Logic Apps

Article / Updated 03-26-2020

Microsoft Azure includes Logic Apps to help you build in workflows. This allows you to automate certain processes rather than manually manage. Suppose that your company’s marketing department wants to be notified any time a current or prospective customer mentions your corporate handle on Twitter. Without Logic Apps, your developers would have to register for a developer Twitter account and API key, after which they’d need to immerse themselves in the Twitter API to understand how to integrate Twitter with your corporate notification platform. Instead, your developers can configure a Logic App to trigger on particular Twitter tweets and send an email message to an Outlook mailbox without knowing Twitter or Office 365 APIs. Creating an Azure Logic App You’re going to create a Logic App that triggers on mentions of the keyword Azure in public tweets. The resulting action sends email notifications to a mailto:[email protected] designated email address. You’ll develop your Logic App in three phases: Deploying the Logic App resource Defining the workflow Testing the trigger and action Deploying the resource in the Azure portal Follow this procedure to create the Logic App resource: In the Azure portal, browse to the Logic Apps blade, and click Add. The Create blade opens. Complete the Logic App Create blade. There’s not much to creating the resource. Provide the name, subscription, resource group, and location, and specify whether you want to monitor with Log Analytics. Click Create to submit the deployment. When deployment is complete, click Go to Resource in the Azure notification menu to open the Logic App. You’ll be taken to the Logic Apps Designer by default. Click the X button in the top-right corner of the interface to close the blade. Defining the Azure Logic App workflow Follow these steps to define the Logic App workflow: If you want to follow along with this exercise, you need Twitter and Office 365 accounts. Twitter accounts are free, but Office 365 typically is a paid SaaS product. If you like, use another email account (such as Gmail). The Logic Apps connector library is so vast, chances are good that you’ll find a service that works for you. Go to your new Logic App’s Overview blade. Choose Logic App Designer from the Settings menu. This command takes you to the view you saw the first time you opened the Logic App. Scroll to the Templates section, and select Blank Logic App. Starting with a blank Logic App enables you to become more familiar with the workflow design process, but Azure provides lots of templates and triggers that you can use for other purposes. In the Search Connectors and Triggers field, type Twitter. In the search results, select the Twitter trigger category and then click the When a New Tweet Is Posted trigger. Click Sign In, and log in to your Twitter account. Complete the When a New Tweet Is Posted form. Maybe you want the Logic App to trigger whenever someone mentions the keyword Azure in a tweet, so you complete the options this way: Search Text: “Azure” Interval: 1 Frequency: Minute Configuring a Logic App to trigger on the keyword Azure generates lot of trigger events and creates a potentially bad signal-to-noise ratio in your results. If you’re creating a Logic App for this purpose, experiment with writing more-granular trigger keywords to produce the results you desire. Click New Step. Scroll through the connector library list and look for Outlook. When you find the Outlook connectors, click the Office 365 Outlook connector. Search the actions list for Send, and select the Send an Email action. In the Office 365 Outlook connector dialog box, click Sign In, and authenticate to Office 365. Complete the Send an Email dialog box, preferably using dynamic fields. This step is where the procedure can get a bit messy. Put your destination Office 365 email address in the T: field. Place your cursor in the Subject field. Click Add Dynamic Content to expose the dynamic content pop-up window. Dynamic fields allow you to plug live data into your workflow. Click Save. Don’t overlook this step! It’s easy to miss. Testing the Logic App trigger and action To trigger the action, follow these steps: On the Logic App workflow toolbar, click Run. You must— absolutely must — switch the Logic App to a running state for it to catch the trigger. On Twitter, and post a tweet that includes a reference to Azure. Await notification. The tweet should trigger an email to the address you designated. Another place to check workflow run status is the Overview page, which shows how many times the trigger was tripped, the workflow run, and/or any errors.

View Article
Working with Azure Functions

Article / Updated 03-26-2020

The first step in designing an Azure Function is deciding what you want it to do. Suppose that you created a web application in Azure App Service that allows users to upload image files. Your fictional app’s source code places the user’s uploaded image files in a container named (appropriately enough) images, inside an Azure storage account blob (binary large objects) service container. What if you want to take automatic action on those uploads? Here are some examples: Automatically converting and/or resizing the image Performing facial recognition on the image Generating notifications based on image type As it happens, it’s possible to trigger an Azure Function based on a file upload. Currently, Azure Functions includes the following trigger, among others: HTTP: Triggers based on a web hook (HTTP request) Timer: Triggers based on a predefined schedule Azure Queue Storage: Triggers based on a Queue Storage message Azure Service Bus Topic: Triggers based on a message appearing in a designated topic Azure Blob Storage: Triggers whenever a blob is added to a specified container (the trigger you need for the example) Durable Functions HTTP Starter: Triggers when another Durable Function calls the current one Creating an Azure Function A Function App is a container object that stores one or more individual functions. The image below shows the Function workflow. First, you need to create the Function App. Next, you define the Azure Function itself. Finally, you test and verify that your function is triggered properly. Creating the Function App Follow these steps to deploy a new Function App in the Azure portal: On the Function App blade, click Add. The Basics tab of the Function App blade appears. Complete the Function App Deployment form. Here are some suggested values: App Name: This name needs to be unique because Function Apps are part of the App Services family and have DNS names within Microsoft’s public azurewebsites.net zone. OS: Choose the type of operating system you have. Hosting Plan: Consumption Plan is a good place to start. You can change this setting later if you want or need to do so. Runtime Stack: Your choices include .NET Core, Node.js, Python, Java, and PowerShell Core. Storage: A general-purpose storage account is necessary to store your code artifacts. Application Insights: It’s a good idea to enable Application Insights to gain as much back-end telemetry as you can from your Function App. Click Create to submit the deployment. Currently, Microsoft is previewing a new creation experience for Azure Function Apps. Therefore, don’t be surprised if you see the new experience instead of what is shown above. The configuration options are the same, but they’re presented differently. Change in the Azure portal is one thing in life you can always depend on. Defining the Azure Function The next step in the Azure Function creation workflow is defining the Function itself. Not too many people find the Function App’s nonstandard user interface to be intuitive. At all. The following explains what’s going on. A single Function App (A) contains one or more Functions. Each Function that runs in the Function App’s run space is stored here (B). A Function Proxy (C) allows you to present a single API endpoint for all Functions in a single Function app to other Azure or non-Azure API Function Apps support deployment slots (D); they serve the same purpose as deployment slots for App Service web apps, and they support slot swapping. Function App Settings (E) is where you specify settings for a Function App, Function, or Proxy, depending on the context. Before you create the function, you should create the images blob container you’ll need for this website-upload example. If you have Azure Storage Explorer installed, proceed! Azure Storage Explorer is a free, cross-platform desktop application that makes working with Azure storage accounts a snap. Follow these steps to create a blob container for the new Azure Function: Open Azure Storage Explorer, and authenticate to your Azure subscription. Expand the storage account you created for your Function App, right-click Blob Containers, and choose Create Blob Container from the shortcut menu. Azure creates the container and places your cursor next to it, all ready for you to name the new object. Name the container images, and press Enter to confirm. Creating the Azure Function Excellent. You’re almost finished. Now you need to create a function. Follow these steps: Open your Function App in the Azure portal. In the Functions row, click the plus sign. The details pane on the right leads you through a Function wizard, the first step of which is choosing a development environment. Choose In-Portal as your development environment, and click Continue. Both Visual Studio and Visual Studio Code have native support for writing Functions. In the Create a Function pane, More Templates, and click Finish and view templates. Click View Templates to view the Azure Function trigger gallery. In the gallery, select the Azure Blob Storage trigger. You’ll probably be prompted to install the Azure Storage extension; click Install, and let the process complete. Complete the New Function blade. Complete the following fields: Name: This is the name of the Function that will be contained inside the Function App. The name should be short and descriptive. Azure Blob Storage Trigger Path: This setting is important. You want to leave the {name} bit alone because it’s a variable that represents any uploaded blob. The path should look like this: images/{name} Storage Account Connection: Click New, and select your Function’s storage account. Click Create when you’re finished. When you select your function on the Function App’s left menu, you can see your starter C# source code. For this example, the code should look like this: public static void Run(Stream myBlob, string name, ILogger log) { log.LogInformation($”C# Blob trigger function Processed blob\n Name:{name} \n Size: {myBlob.Length} Bytes”); } This code says “When the function is triggered, write the name and size of the blob to the console log.” This example is simple so that you can focus on how Functions work instead of getting bogged down in programming-language semantics. The new Function contains the following three settings blades: Integrate: This blade is where you can edit your trigger, inputs, and outputs. Manage: This blade is where you can disable, enable, or delete the Function, as well as define host keys that authorize API access to the Function. Monitor: Here, you can view successful and failed Function executions and optionally access Application Insights telemetry from the Function. Testing your Azure Function All you have to do to test your function is follow these steps: In Azure Storage Explorer, upload an image file to the images container. To do this, select the container and then click Upload from the Storage Explorer toolbar. You can upload individual files or entire folders. Technically, you can upload any file, image or otherwise, because all files are considered to be blobs. In the Azure portal, select your Function App, switch to the Logs view, and watch the output. Configuring Azure Function App settings You may want to switch from Consumption to App Service plan pricing, for example, or vice versa. Or maybe you want to test a different run-time environment. Navigating the Function App configuration blades can be difficult, mainly because they’re completely different from the rest of the Azure portal UI. I also think there’s some redundancy in the places where some settings controls are located. To make things easier, here’s a summary of the major capabilities of each settings blade in the Function App: You need to be at the Function App scope (above Functions in the navigation UI). You can see this convention below. Overview: Use this blade to stop, start, and restart the Function App. You also can download all site content for use with a local integrated development environment. Platform Features: This blade is where most Function App settings categories reside. Function App Settings: From this blade, you can view usage quota and manage host keys. Configuration, Application Settings: This blade is where you manage application key/value pair settings and database connection strings. Configuration, General Settings: This blade is where you can configure Architecture; FTP state, HTTP version; Remote debugging.

View Article
A Brief Introduction to Azure Kubernetes Service

Article / Updated 03-25-2020

AKS (Azure Kubernetes Service) began life as Azure Container Service (ACS), which supported multiple container orchestration platforms, including Kubernetes, Swarm, and DC/OS. The downsides of ACS were its complexity and the fact that most customers wanted first-class support for Kubernetes only. Therefore, although you may see an occasional reference to ACS in the Azure portal or elsewhere, let’s just ignore them and focus exclusively on AKS. Here, you learn a bit about the AKS architecture, some of its benefits, and a bird’s-eye perspective on using AKS in Azure. Developers don’t necessarily start containers because they’re fun to use; developers start containers because they’re practical. Containers host application components such as web servers or database servers and then form application solutions. Therefore, try to relate the words container and application from now on. Azure Kubernetes Service architecture The image below shows the basic elements of AKS: Master node: Microsoft abstracts the control plane (called the master node in Kubernetes nomenclature), so you can focus on your worker nodes and pods. This hosted Platform as a Service (PaaS) platform is one reason why many businesses love AKS. The master node is responsible for scheduling all the communications between Kubernetes and your underlying cluster. Worker node: In AKS, the worker nodes are the VMs that make up your cluster. The cluster gives you lots of parallel computing, the ability to move pods between nodes easily, to perform rolling updates of nodes without taking down the entire cluster, and so on. One option is using ACI to serve as worker nodes. The below image also shows ACR, from which AKS can pull stored images. Isn’t all this Azure integration compelling? Pod: The pod is the smallest deployable unit in the AKS ecosystem. A pod may contain one Docker container, or it might contain a bunch of containers that you need to stay together, communicate with one another, and behave as a cohesive unit. Azure Kubernetes Service administration notes Now, let’s take a look at how developers and administrators interact with AKS. From a control-plane perspective, you have AZR, with which you can protect your AKS cluster with role-based access control, upgrade your Kubernetes version, scale out the cluster, add or remove worker nodes, and so on. From the application-plane perspective, Microsoft wanted to ensure that customers don’t have to learn a new tool set to work with containers in AKS. kubectl command-line tool Most Kubernetes professionals use the kubectl (generally pronounced KOOB-see-tee-el, KOOB-control, or KOOB-cuttle) to interact with their Kubernetes cluster and its pods programmatically. If you have Azure CLI installed on your workstation, you can install kubectl easily by issuing the following command: az aks install-cli In fact, Azure CLI seems to borrow quite a bit from kubectl syntax in terms of the app context command workflow. To list your running pods (containers) with kubectl, for example, run $ kubectl get pods READY STATUS RESTARTS AGE azure-database-3406967446-nmpcf 1/1 Running 0 25m azure-web-3309479140-3dfh0 1/1 Running 0 13m Kubernetes web UI The Kubernetes web UI is a graphical dashboard that gives administrators and developers a robust control surface. This image shows the interface. Once again, you should use Azure CLI to connect to the dashboard; doing so isn’t possible from the Azure portal. Here’s the relevant command: az aks browse --resource-group myResourceGroup --name myAKSCluster The az aks browse command creates a proxy between your workstation and the AKS cluster running in Azure; it provides the connection URL in its output. The typical connection URL is http://127.0.0.1:8001.

View Article
Getting Familiar with Azure Regions

Article / Updated 03-25-2020

Microsoft Azure provides various services by region. In public cloud computing, you store your resources in Microsoft’s physical infrastructure. This infrastructure consists of an enormous data-center network spread around the world. This world wide web (as it were) of Azure data centers means that you can place your cloud resources geographically close to your customers, thereby giving them low-latency, high-performance connections to your applications. Currently, Microsoft has 54 regions spread across 140 countries. Each region consists of one or more discrete physical data centers with redundant, high-speed network interconnectivity. Availability zones in Azure When you host customer-facing services in Azure, high availability should be uppermost in your mind. What plans do you have if a failure occurs in your home region’s data center? Microsoft has been gradually rolling out availability zones throughout its region map. Essentially, an availability zone allows you to place replica VMs in different data centers in the same region. In other words, availability zones represent separate locations within a single Azure region. The following image illustrates this concept, with two identically configured web server VMs are placed in two availability zones in one region. An Azure load balancer in front of the VMs makes both of them available under the same IP address or Domain Name System host name. With this setup, if one VM goes offline (through and admin error or a Microsoft data-center outage), they service remains online and functional. In Azure nomenclature, region and location are interchangeable. Geographies and Azure Microsoft organizes its regions into geographies to support corporate compliance and data residency requirements. Microsoft Azure special regions Azure is called a public cloud service because most of its regions and services are available for purchase by the general public. That said, Microsoft hosts special regions called government clouds or sovereign clouds for exclusive use by particular governmental bodies around the world. Azure Government regions are inaccessible (invisible) to nongovernment employees. At this writing, Microsoft maintains separate regions, availability zones, and data centers for the governments of the United States, China, and Germany. Azure’s paired regions You can place redundant copies of your Azure services in more than one region for failover redundancy. When you do so, you should first determine Microsoft’s designated paired region to ensure minimal latency. Microsoft builds additional high-speed network connectivity between paired regions, which assures customers that their multiregion deployments won’t suffer undue latency. Search Microsoft’s Azure page for the article “Business continuity and disaster recovery (BCDR): Azure Paired Regions,” which includes the master list of paired regions. It’s recommended that customers test the latency between their location and Azure by visiting Azure Speed Test 2.0. You may find that the lowest-latency Azure region wasn’t what you thought it was. Azure’s feature availability Azure product teams gradually roll out new features across the region map, so some products may not be available at the moment in your home region. For this reason, it’s important to keep an eye on the Products Available by Region page. The same guidance applies to Azure Government regions. Most of the time, new features begin their life cycle in the Azure public cloud and only much later make their way to the sovereign clouds.

View Article
page 1
page 2