I’ve been asked numerous times where to start when it comes to Azure.  Getting a handle on Azure concepts, terminology, and features can be more than a little intimidating. Not only is Azure an extremely large platform, the pace of change is *very* fast. This post has taken me quite a while to figure out how to write because where to start depends so much on which services you’re responsible for and what role you are. Each individual service in Azure has its own set of gotchas and lessons learned. So, this post will stay at the 1,000 foot level.

Before we dive in further, I do want to offer a few thoughts suggestions:

• Even though you can create a resource quickly and easily, that doesn’t mean that it’s enterprise-ready immediately. By all means, save time getting started. Just don’t forget that getting everything working securely with sound and repeatable practices is often counter to the “deploy in 10 minutes” goal for the cloud that we hear a lot. So, plan to spend time learning how things work more deeply if you’re building anything besides a test/sandbox environment.
• Always build a proof of concept if you’re developing on an unfamiliar resource. There will be something you expect it to do that it won’t do. New features and functionality are always coming out, but everything these days begins as an MVP: minimally viable product. It can take months for a new service to mature. So, do yourself a favor and POC pretty much everything as normal practice.
• Try to keep up with Azure announcements for the resources you work with. The pace of change is crazy fast and it’s really difficult to keep things straight. However, you need to try because, in addition to new functionality, behavior changes occur and features get deprecated as resources evolve and mature.
• Although it’s tempting to start with a virtual machine solution (IaaS) because it’s the most familiar, give PaaS (platform as a service) a fair shot because it’s really the future and where significant investments are being made by Microsoft.
• Objects in an Azure subscription can turn into a mess really fast if there are no standards. Planning how dev/test/prod will be separated, as well as how resources will be arranged by resource group, are two of the most critical decisions you will make. Naming conventions are also very important (and yes, I know about the pets and the cattle — I still like my naming conventions).
• Choosing a location for services is an extremely important decision. You want to select geographic location based on data storage, proximity to users, co-locating related resources, minimizing latency, backup and recovery needs, service availability in a region, and minimizing data egress charges (data coming into a region is free whereas data leaving a region is not–data egress charges are small but can add up to a surprise bill if a decent volume of data is being transmitted).
• The cloud is not *always* cheaper, and the cloud is not *always* easier. Often both are true (especially for sandbox and POCs), but don’t take it for granted that both are always true for an enterprise solution. It really depends. 
• Developers and administrators have an immense impact on cost in a cloud computing environment. Time spent learning cost savings techniques is well worthwhile.
• ARM (Azure Resource Manager) templates and PowerShell are both your friend when it comes to Azure productivity. However, I wouldn’t get hung up there if you are brand new to Azure. It’s ok to use the portal to create and modify items in Dev and/or while you are learning. You can evolve to use automation techniques as soon as you’re ready and/or when things need to be repeatable.

A number of the above thoughts are part of a presentation I’ve delivered recently. You can find those slides here: Tips for Getting Started with the Azure Data Platform

What is Azure?

Azure offers infrastructure and services for customers (us) to build and deploy software and services through a global network of Microsoft-managed data centers. Although many individual aspects will feel familiar, there can be different design patterns and best practices in cloud and hybrid environments. Here is an overview of the types of resources we can provision in Azure:

The Azure Interactives site (shown above) gives a short snippet as to what each service is, and links to where to find more information. It’s a good way to get a quick sense of what is there.

Azure Terms & Definitions

Here are a few of the most important basic building blocks to know related to Azure:

Subscription: A billing relationship. Each subscription has a directory; a directory can trust multiple subscriptions. Subscriptions have documented limits and quotas. Subscriptions also represent a security boundary.

Tenant (aka Directory): The AAD (Azure Active Directory) service which handles identity management. A global administrator in Azure is also is a global administrator in Office 365.

ARM: The Azure Resource Manager (ARM) framework which allows us to deploy and manage resources in Azure. The various service management APIs behind Visual Studio, command line, and the Azure portal all share the same underlying ARM layer. Checking ARM scripts into source control is referred to as ‘Infrastructure as Code.’ By default, ARM scripts generated by the Azure portal encompass an entire resource group (the exception being Resource Explorer).

Resource Group: A logical container for resources in Azure. Typically, one resource group contains resources with the same lifecycle which should be managed, secured, and deployed together as a unit (for instance, an Azure Virtual Machine and its related Azure Storage Accounts). Resource groups are important for organizing resources, and can also serve as a security boundary (particularly for decentralized administration purposes).

Resource: Resources are the individual services in Azure, such as Azure SQL Database, Azure Virtual Machine, or an Azure Storage account. There is a wide variety of resources available in the Azure platform (as shown in the first screenshot near the top of this post). A resource must be assigned to a resource group.

Resource Provider: Registering a provider allows your subscription to work with a specific type of resource. Many commonly used resources are registered by default, but not all.

And, here are a few more common cloud computing terms:

IaaS: Infrastructure as a Service is a close equivalent to virtual server environments that we’ve been using for years–just that the servers are in Microsoft’s data center instead. Virtual machines are IaaS. With IaaS, the customer is responsible for managing nearly all of the environment (such as the operating system — though there are a few features that blur the lines between IaaS and PaaS a bit because you can allow Azure to install O/S and database patches for certain VM images).

PaaS: With Platform as a Service, the customer manages much less: usually just the data and the custom application. The cloud provider is responsible for everything else and in fact, the customer cannot (typically) even access the VM directly that the PaaS service is really running on. With PaaS, the customer focuses on building a solution and not on managing the environment. PaaS examples include Azure SQL Database, Azure SQL Data Warehouse, and CosmosDB.

SaaS: With Software as a Service, the focus is much more on consumption of a pre-existing application. You can think of it as “renting an application.” SaaS examples include Power BI or Office 365.

Serverless: The term serverless feels like a misnomer — there are many thousands of servers running behind everything in Azure. From the customer’s perspective though, services are “serverless” because the infrastructure is invisible. Azure Functions are considered a serverless technology.

Azure Stack: Although sometimes you hear someone referring to ‘the Azure stack’ as a general term for all of Azure, what Azure Stack actually refers to is a way to deploy Azure resources in a private data center (as opposed to the public cloud) via an appliance from a hardware vendor. Only certain types of resources are available via Azure Stack.

Your Purpose For Going to the Cloud

Following are some of the most common reasons why cloud computing is attractive, and also some common concerns. I know you’re likely most interested in the technical stuff — the reason why I bring this up is because it’s very important for you to really know these objectives. You will continually make tradeoffs during the design and development process, and the tradeoffs you make will depend completely on your goals. By tradeoffs, I mean decisions around:

• Simplicity vs. control   (Do you want the ‘easy’ option, or do you prefer customization & control?)
• Cost vs. features available  (Do you really need feature xyz even if it costs a lot more?)
• Cost vs. complexity  (Are you willing to manage something on your own if it’s a lot cheaper?)
• etc…