What’s In A Name: The Windows Azure Name Game

Alright, I got your attention. I just thought it’s catchy title. But it has nothing to do with a game. Rather, it’s my own observations on how specific Windows Azure components are named and the resulting effect or misconception for those that are new to the Windows Azure platform.

Windows Azure has been around for a while. But because some offerings in Windows Azure are named similar to their non-cloud product counterparts, i.e., SQL Server vs. SQL Azure, Windows AD vs. Azure AD, etc…, people confuse one’s feature set and capabilities with the other.

Worst, people have come to expect the same feature set, control and performance for the corresponding Azure offerings of the products that they’re used to, resulting to failed expectations when they move their applications and infrastructure to the cloud.

This blog post is a list of the most common product and/or service offerings that are often confused between their on-premise and Azure-based counterparts. You may have noticed that I used the word “counterpart” rather than “equivalent” because I think most of these components are not actually equivalent and I think “counterpart” is a better word to refer to them (disclaimer: English is my 2nd language, so please go easy on me on this Smile ).

Please note that I’m not going to try to explain the differences thoroughly or in depth, instead, I’ll be linking to existing documentation/posts that explains the feature differences in more detail.

Windows Azure

How can i install Windows Azure?

Let’s start with the confusion on Windows Azure first. Windows Azure is not a single product you buy and install or subscribe to. It’s a platform. It consists of different sets of cloud-based components that are hosted on Microsoft Data Centers.

There’s Platform-As-A-Service offering. There’s Infrastructure-As-A-Service. There are offerings for data management (blobs, SQL database, etc…). Some on networking (Virtual Networks, VPNs). Some more on compute (Cloud Services, VMs). Components for Identity Management (Azure AD, ACS). There’s one for Big Data (HDInsight). And a lot more.

You’re typical application or infrastructure setup will most likely comprise of one or more combination of these offerings/components. So, when you consider moving or building on the Windows Azure cloud platform, have a look at what is it that you want to run in the cloud and which components will suit you best.

For a nice overview of Windows Azure, have a look at: Introducing Windows Azure

Now let’s start have a look at the “namesakes”

Windows Azure vs. Windows Azure Pack

But I heard I can download and install Windows Azure Pack?

Yes, you can. But just the same, Windows Azure and Windows Azure Pack are not exactly the same. The Windows Azure Pack provides Windows Azure-consistent experiences and services for building your own private cloud via a collection of Windows Azure technologies.

The Pack doesn’t include all the things you get from Windows Azure, just a subset. For example, as of today, you can only get Websites, VMs, and Service Bus.

This blog post provides a good outline of the differences: Windows Azure Pack–Architecture Comparison to Windows Azure

SQL Server vs. Windows Azure SQL Database

I have a problem with my SQL Database!

What? Which SQL database? Prior to Azure, people would commonly refer to their SQL Server database as “SQL Database”. So, the quote above alone already results to confusion. Is it referring to a SQL Server or an Azure-based SQL database? If it’s the latter, we have to qualify it further: if it’s in Azure, is it a Windows Azure SQL Database or a database hosted in a SQL Server Windows Azure hosted VM?

I trying to move my SQL Server database to Azure and it doesn’t work!

But more than confusing where the database actually resides, is confusing Windows Azure SQL Database with SQL Server itself and this is probably the most prevalent one.

Windows Azure SQL Database has been around for a while and you would have thought people would have known it by now as not being the same as SQL Server. However, despite the various name changes (SQL Server Data Services, SQL Azure, SQL Database), people still confuse it with SQL Server. In fact, some people still refer to it as SQL Azure thinking it’s a SQL Server in Azure.

I wish they’d put in the Windows Azure SQL Database product page in big, bold, blinking text: SQL Database != SQL Server.

Take the cue from the name: “Windows Azure SQL Database“, you’re signing up for a database service. Yes, you get a logical server to connect to, but you don’t have access to the underlying Server (both Windows host and SQL Server instance) that’s actually hosting your database. So forget about most of the Server related configuration and administration parts, there’s not much for you to tinker with in that department.

Not only that, with SQL Database you’re simply signing up for the database component, no SQLAgent, SSIS, SSRS, SSAS, MDS, etc…

And even on the database part, there’s a lot to look at in terms of what’s supported and what the overall experience is.

For example, there is no emulator for Windows Azure SQL Database, rather, you work with either SQL Express/LocalDB/SQL Server when developing for SQL Database outside of Azure. So developers get used to these local environment’s behaviour and it’s not uncommon to hear complaints why it behaves differently once they deploy on Windows Azure SQL Database.

Want to find out more about the differences? Have a look at the following links:

If you want to check out the SQL offering vs. the NoSQL data storage offering in Windows Azure, have a look at: Windows Azure Table Storage and Windows Azure SQL Database – Compared and Contrasted

SQL Server Reporting Services vs. Windows Azure SQL Reporting

Well, so much for the comparison on this one as Windows Azure Reporting is going to be retired later this year (see: Windows Azure SQL Reporting )

If you still need to find out what the differences are, check out:
Guidelines and Limitations for Windows Azure SQL Reporting

Windows Azure Active Directory vs. Windows Active Directory

This one I see frequently nowadays.

Cool! We’ve got Windows Azure AD now, let me move our existing Windows AD to Windows Azure AD!

Well, not exactly. Windows Azure AD != Windows AD.

That’s right, you don’t have the same concept of Domain Services you have on Windows AD in Azure AD. Simply put, you can’t join computers to an Azure AD. No Domains, Trees or Forest. No Domain Controllers, or Organizational Units (OUs), or Group Policies and so on.

Windows Azure AD as it is today is mainly an identity and access management cloud solution.

They’re more complimentary rather than interchangeable. In fact, in hybrid scenarios with on-premise and cloud co-existence, you will most likely extend your existing on-premises Windows AD to Windows Azure AD to enable a single sign-on experience.

So hold off to that idea of ripping apart your existing Windows AD infrastructure and replacing it with Windows Azure AD. They’re not the same.

Even the APIs are different. Windows Azure AD get’s a “fancier” REST-based Graph API.

Have a look at these posts that provides a good overview of the differences between the two:

Interested in running Windows AD on Windows Azure VMs? have a look at: Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines

Even better, you may want to download a bunch of whitepapers here on the on-premise to the cloud integration/co-existence: Active Directory from on-premises to the cloud – Windows Azure AD whitepapers

Windows Azure Websites vs. Web Roles

Yes, they can both run web apps. But there are differences in how easy and how fast you can get one up and running, and how much access and control you get on their underlying infrastructure.

Websites for example has a gallery of off-the-shelf web applications that your can readily deploy to get you up and running quickly while Web Roles doesn’t have the same gallery.

Web Roles on the other hand allows Remote Desktop connection to the underlying Virtual Machine hosting your role which you don’t have on Azure Websites.

They’ve got more differences and there are pros and cons for using one over the other.

I won’t delve much on this as my colleague @robdmoore has written a comprehensive blog post that’s frequently updated comparing these two offerings, check out:
Windows Azure Web Sites vs. Web Roles

Windows Azure Mobile Services

Well, this one is a bit different from the items above. It’s not about confusing the Mobile Services with similarly named product, it’s the “Mobile” part in the name.

I ask someone a couple of months back if he has played with Mobile Services and the answer was:

“Nope, I thought it’s just for mobile!”

Yes, it does provide client libraries for most mobile platforms (Windows Store, Windows Phone, iOS, Android, etc…). But it does provide a robust backend service as well.

For example, if you don’t want to expose your Windows Azure SQL Database directly to your client applications (not having to open up your SQL Database firewall settings, no SQL credentials on the client), you’re more likely to build an intermediate service that connects to your database and that your client can consume (WS, REST-based, WebAPI, etc…). The Mobile Services backend can easily provide that backend service (REST, CRUD) interface.

Not to mention, prior to Windows Azure Scheduler and Windows Azure WebJobs, Mobile Services offers a Scheduler Service for you to schedule and execute jobs (i.e., clean up your Mobile Services DB, grab RSS feeds, send notifications, etc…)

For examples on how to consume the backend services from non-mobile applications, have a look at the following:

Windows Azure Mobile Services Scheduler vs. Scheduler Service vs. WebJobs

Speaking of a scheduling service, people used to lament the lack of it on Windows Azure.

Specifically, those moving to Windows Azure SQL Database:

Where’s my SQLAgent?

Now, you have the above options and scratching your head which one to use.

While they all have scheduling as something in common and they have “jobs”/”task”/”script” to execute, they primarily differ on what can be invoked and where the actual execution of the invoked component occurs.

Windows Azure Mobile Services
Windows Azure Mobile Services provides a facility to have Mobile Services server script code executed based on a schedule that you define. It actually uses the Windows Azure Scheduler Service for the scheduling component.

This video provides a good overview of this component: Windows Store app – Getting Started with the Windows Azure Mobile Services Scheduler

Windows Azure Scheduler
Windows Azure Scheduler Service allows you to schedule the invocation of an action such as calling HTTP/S endpoints or posting a message to a storage queue. The good thing about this service is that you can schedule jobs either on the portal or via an SDK.

Have a look at the following links:

Windows Azure WebJobs
Windows Azure WebJobs is the newest kid on the block. WebJobs allows you to run programs or scripts on demand, continuously, or on a schedule. The job can be event-triggered, or can be based on a schedule, or run continuously in the background. It also has an SDK.

This blog post provides a good overview of Azure WebJobs: Introducing Windows Azure WebJobs

Looking at the above options, you’ll see that they all have Scheduling as a common component and they have “jobs” to execute, the really big difference is on the type of “jobs” that you can invoke and where they reside.

Lastly, here’s some other on-prem and Azure-based products/offerings that are named similarly:

BizTalk Server vs. BizTalk Services

For comparison, see: Feature comparison between BizTalk Server and BizTalk Services
BizTalk Offerings: Server, IaaS, and PaaS Feature List

Azure Service Bus vs. Service Bus for Windows Server

For comparison, see: BUSted! A quick comparison of Azure Service Bus and Service Bus for Windows Server

As usual, feel free to send feedback if I missed out on something or if I stated things incorrectly.

Cheers,

JuneT

JuneT's idle thoughts