Article
10/01/2015

October 2015

Volume 30 Number 10

Microsoft Azure - Microsoft Azure--the Big Picture

By Tony Meleg | October 2015

Every month, this magazine delves into the details of some new or interesting service in Microsoft Azure. There’s a never-ending stream of things developers apparently must know about, but at the same time confusion around all the different ways of accomplishing the same thing. It’s not easy to put all these pieces together and see the “big picture.” With the pace of innovation our industry is currently experiencing, failing to see the big picture presents a real challenge for IT organizations and IT practitioners alike. Well, this article is all about helping you make sense of Azure without drilling into any specific service—the opposite of what we normally do.

Let’s face it, developers aren’t always very good at making complex things simple. Usually we take some simple problem and implement a very complex solution. We need to understand how things work, especially things we didn’t build ourselves. This is partly a trust issue, but it’s also so we can understand how to tweak and fine-tune a component or a whole piece of software for our particular needs. It’s a control thing, as well.

Microsoft’s Big Bet

If my assertions about developers ring a bell, then you’re not going to like what I’m going to tell you next. Azure is a collection of application building blocks or “services,” each providing a different capability you might need sometime in an application you want to build. Microsoft believes these blocks should be inherently resilient, highly scalable and self-managing. You can provision any service anywhere in the world, pay only for what you consume and, most important, be able to change your consumption anytime, anywhere. Here’s the bit you won’t like: These services just work. They abstract you away from the complexity; you don’t have much control over them; you can’t see inside of them. In other words, you have to just trust them. Doesn’t sound like something you might be interested in, does it, because you want control, you don’t “trust” and you like complexity?

You can roughly segment Azure into three layers—the datacenter infrastructure, infrastructure services and platform services, as shown in Figure 1.

Figure 1 Microsoft Azure Conceptual View

You should think of these three layers as stacked on top of each other, with each layer an abstraction of the layer below. So, Infrastructure as a Service (IaaS) is largely an abstraction of the underlying physical servers, storage and networking. Platform as a Service (PaaS) is an abstraction of the application software infrastructure you’d normally install on servers and use when you create applications, such as Web servers, databases, messaging systems and identity infrastructure. It’s the service’s job not to provide this software for you, but to give you an entire running, resilient, always-on service (and work behind the scenes to monitor and fix any issues transparently without your application skipping a beat).

These services are available not only in the Azure public cloud, but anywhere. This could be your datacenter, a host or an outsourcer. Microsoft recently announced Azure Stack to make this possible—think packaging up the Azure secret sauce and services and deploying this on your own hardware. After all, it’s just software built on top of the core foundations of Windows Server and Hyper-V. In this new world, though, you don’t really care because your focus is just on the services you need, how to architect your solution properly and how to program against the services.

The Platform Building Blocks

So let’s take a broad look across all of Azure. Figure 2 lays out all the services in a set of capability groups split across infrastructure services and platform services. You should think of infrastructure services as those capabilities that allow you to create the low-level infrastructure for your existing applications. You need computers that have disks; you need to network them together; you need shared disks; and you need to connect them to other systems and networks in other places and so on.

Figure 2 Microsoft Azure Services

At the infrastructure services level, the abstractions are more familiar because they represent the underlying physical datacenter, such as a computer in the form of a virtual machine (VM) and virtual disks that you attach to the machine. This allows you to run systems you already have and do things the same way you do today because the only abstraction is the computer, not the application software you might use. It’s still your responsibility to install, manage, patch, fix and make resilient any software you run in or across a set of network-connected VMs, just as you do today in your own datacenter.

Platform services, in contrast, involve capabilities that distance you from the lower levels of the computer/storage/network the service is utilizing; that’s all abstracted away from you. As a general rule, if you can’t actually touch or connect to the underlying VM in a particular service, the service is PaaS. Also, you don’t get to choose the software that provides the service, and you don’t get to tune or control that software. It’s the services job to just work, to fix and patch itself and to monitor all the parts of the service needed across all the Azure datacenters. You get to focus on just using it—which is really what your job is, anyway.

An Aside—the Azure Datacenter Infrastructure

You might be interested, because we’re all geeks at heart, in all the underlying complex computing and datacenter infrastructure that powers Azure. You might want to understand the physical hardware specs of the servers, what switches are used, how the racks are built. You might want to know about the complex network topology that provides crazy fast consistent speed across all services and the global network that connects Azure datacenter regions together. Maybe you’re curious about all the 24 datacenter regions around the world where Azure exists today (or will soon, as the five new regions in Canada and India come online), as shown in Figure 3.

Figure 3 Global Microsoft Azure Datacenter Footprint

This is your first test as a developer in the new world: You have to stop caring about that, at least in Azure. If you wanted to build your own “Azure” in your own datacenter with the Azure Stack, then you (or someone in your organization) would still have to care about all these physical things. One of the reasons you had to care in the past, even about the infrastructure needed for a particular application, was because the cost of getting things wrong was too high. You never really knew the number and size of servers needed; you assumed the worst possible case and added a bit more, just in case. In Azure, those problems don’t exist because if you need more of something you just provision more. If you need a bigger machine, you get one; if you get too much, you just change it. In Azure, you just need to work out where your application users are and which are the best datacenters to use to deliver the solution. Usually it’s the closest one.

Infrastructure Services—More Control, More Work

When you look across the 60 or so services in Figure 2, it’s a bewildering list. But most of the apps you’ve built, most of the time, contain only a few capabilities. Usually there’s a Web server and a relational database at the core, plus a bunch of other pieces for identity, reporting and maybe some batch processes. Let’s just focus on the Web infrastructure and the database for now.

Straightaway, you have a choice to make: Do you work at the infrastructure or the platform level of abstraction? Do you spin up some VMs, install your Web server and your database and just get going? Remember, this abstraction is primarily about the physical servers, storage/disks and network but not the software you need to run on those servers. Sounds easy, sounds familiar, and—guess what—it is. It’s exactly what you do and have done for your entire career. Take a look at Figure 4. A VM has virtual disks and these can be shared across VMs or attached to a specific machine. VMs can be put inside virtual networks so they can communicate and networks can be connected to your own datacenter, as well as across Azure regions. This is all done through this software abstraction and it means you end up with a computer that has one or more disks and sits on a network connected to other computers.

Figure 4 Virtual Machine Abstraction of Servers, Disks and Networking

Everything inside the set of VMs you need, you get to control and tune and tweak and mess with. In fact, it’s even better than your own on-premises world, because of the abstraction. You don’t care anymore about the physical machine, the host OS, the hypervisor. You don’t have to worry about the resilience of the underlying storage infrastructure for your virtual disks. There’s an almost mind-boggling set of choices of VM sizes (different combinations of CPU and RAM, with different disk sizes and speeds and network bandwidths).

Better still, it’s all self-service, and everything can be automated so it’s incredibly easy to define the infrastructure you need and spin up hundreds of instances with a simple script.

Let’s say your app requires a decent level of scale and resilience. It’s easy to create a Web farm of VMs and Web servers and create a database cluster. You know (or your IT Pro best friend knows) how to do all this—it’s not easy but it’s doable. You can do it any time, day or night; you can provision it anywhere in the world; you pay only for what you use and at any time you can change your mind, tear it all down and pay absolutely nothing. How awesome is that? But it sounds too good to be true, so what’s the catch?

The catch, at the infrastructure level, is that you still have to do a lot of work to get everything deployed and running. Once it’s all running, you have to do even more work to keep it running. There is help, though, especially for the “get it running” part, deriving from the on-premises world where it’s even more problematic to deploy a complex set of interrelated VMs, including capabilities in Azure such as Azure Resource Manager and automation through Windows PowerShell, as well as many other solutions from third parties. Once it’s all working, you still have to patch all the software you’re using inside the VMs, including whatever OS you’re running. You have to manage the health of all the application software, which isn’t too difficult for the Web server and database, but much more difficult when you scale this out or add in five other capabilities.

You’re trading control against work or effort. If you want control, you have to expend more effort building what you need and keeping it all working.

Platform Services—Less Control, Less Work

You might remember the saying “There’s no problem in computer science that can’t be solved by adding another level of indirection to it.” Well, there’s another phrase I’ve seen added to this, along the lines of “… but this will usually create another problem.”

It’s true, and platform services are a great example. The Azure Services picture in Figure 2 shows the two platform service abstractions for the two building blocks needed in the example—a Web server and a database. In Azure, these abstractions are Web Apps (in the Web and Mobile section) and SQL Database (in the Data section). You provision these services in Azure in the same way you provision any service, by going to the Azure Management Portal, selecting the service you want and filling in the required details: service name, datacenter location, initial performance/pricing level and so on.

Here’s where the less control/less work thing comes into play. Let’s take the database, for example. I provision a database in the North Europe datacenter. In less than a minute, I get a fully working database and then it’s my job to deploy my schema and data to the database and hook up my Web app. There’s no software to install; I get what I get, which is a SQL database. In fact, I don’t just get a database, I get three of them, all working together in a highly available cluster, giving me incredible levels of resilience. I can dial the performance of the three databases up and down simply by selecting a different performance level (which changes the price I pay). You can’t choose not to have this three-way clustered database; you just get it because the service always wants to make sure it can give you a working database and this is the best way to do that.

As you can see in Figure 5, there’s a similar model in play when you provision the Web infrastructure for your app using Azure Web Apps. You’re able to select the number of instances you want using a simple slider. You dial the instance count up or down and the service does the rest. You can even tell the system to do this for you based on load or schedule. Most important, it’s the service’s job to always provide the instance count you specified and to monitor and fix instances that are broken. Your job is simply to write your Web app code and hand the bits to the service so it can make sure they’re all the places they need to be across your instances.

Figure 5 Changing Web App Instance Count

So, the abstraction for platform services generally provides a service that takes care of the provisioning, resilience and management of the service for you. The “additional problem” that was created with the abstraction is that you lose some control. You can’t choose the software, and you can’t get “inside the box” and tweak or tune the software being used from the OS all the way up the stack—it’s a black box to you. The other control you lose is that you’re now locked into the capabilities of that service, as well as the API for the service; that is, how your application code interacts with the service. Maybe you need something specific, for example, in the database, that the service doesn’t provide. Maybe it’s a specific data type or even an entire capability like full-text search. Maybe you’re moving an existing application to the cloud and the capabilities used in your app don’t match the capabilities of the service in Azure. What do you do?

The Azure services building blocks picture in Figure 2 layered all the services into either IaaS or PaaS, but don’t think you can’t use these “together” and cross that boundary, because you can. There’s no reason, for example, that you couldn’t use the PaaS Web App service with, say, a VM where you installed Oracle running on Linux or SQL Server running on Windows. Now you have a balance of control and effort. In fact, you can take this even further. Because all of these building blocks are just there waiting to be used, you can, of course, use them from anywhere. All it takes is a simple API or some existing protocol you already use to talk to these services. You can use any of these blocks with your existing systems in your own datacenter. You can use these blocks with other blocks from third parties and even from other cloud providers. This is assuming, of course, an application can tolerate the latency challenges you might introduce, but it’s possible.

The Other Services

So why do you need all these other capabilities in Azure? Well, if you look around your own IT shop, across all the applications that are running in production today, you’ll find quite a broad collection of application software powering these apps—messaging systems, data analysis capabilities, identity infrastructure, security layers, backup systems, data warehouses, monitoring and management systems, and so on. Collectively, across your entire IT portfolio, you need all this “stuff.” I like to think of Azure as a collection of “IT legos.” You won’t need every type of block all the time as you’re building the next great thing, but you do need them all in your toolkit.

How do you decide which blocks to use when you’re building a new solution? It’s really no different than it’s ever been—you have to understand what the building blocks do and match them to the specific needs of your application, and make a call. The perception is that building applications in the cloud is different and more complex. It’s neither, but there are some additional things you have to do because of the fundamental concept that you’re working in a “shared” infrastructure. This means many services have constraints and these constraints will differ depending on the various functional levels and pricing tiers you’re using; you need to know what these are. Remember, you don’t want these to be constant; you want to vary what you need based on application load and demand. You have to program defensively for these constraints, as well as service availability and responsiveness. You can use the same tools, the same languages and frameworks, to build solutions, and all services at the lowest level have REST-based APIs plus framework-specific wrappers to use. This means you can get to the building blocks literally from anything that has a simple Web stack—like a sensor, a reason the cloud is driving the explosion of Internet of Things solutions.

The upside in the cloud is that you can iterate fast (because it’s easy to spin up the services); you can try some alternatives; and you can fail fast and cheaply because you’ve invested very little. Look back at Figure 2. Is anything missing? You might see things in the picture you think you’ll never need, but I bet you’d have a hard time finding some capability you need or already have that’s not represented. There’s a lot of guidance out there to help you, broad guidance and detailed implementation guidance service by service.

It’s in the DNA of most developers, liking to learn new things. Chances are, you like to play with technology, to try new things. Even if your company is never in a million years going to build anything and put it in a public cloud, it’s still the world’s best developer playground for you to learn and grow.

Dealing with Change

I want to deal with one final topic before finishing and that’s all about dealing with change. I have to admit, I find it hard to keep up with all the innovation that’s being delivered in Azure at the crazy pace it’s happening, and it’s sort of my job to keep up with it. Gone are the days when you had a three- to five-year roadmap of features and capabilities that would be delivered. These days it’s six months if you’re lucky. You’ll find that during the course of building something, new capabilities, even whole new services, appear and it’s tempting to evaluate and refactor these into your solution. Capabilities and services can also be removed with a one-year notice period, not the 10-plus year support cycle that’s traditionally been in place for server software.

Service versioning is now occurring, which means new capabilities are added to a service that might break the implementation of that service and the apps built on it. So a decision has to be made whether to version, that is, to create a new side-by-side implementation. This was recently done on Azure with Azure SQL Database. See the article on what’s new in Azure SQL Database version 12 at bit.ly/1Dcjpo4.

The point is that there’s a tax to pay in the cloud and you need to be aware of that and factor in the cost of the tax. You have to be connected into the cloud support/change notifications process so you can plan ahead and not be caught off guard. The tax, of course, is change and that cost is higher and more frequent than it is on-premises. Don’t let that put you off, though, the upside is much greater. The pace at which you can do things is much faster, the quality will be higher and the risks you take are much lower.

Want to learn more? The AzureCon virtual event lets you hear from Azure experts, view Q&As and find out about all the latest Azure innovations. You can sign up to access all the archived conference content at bit.ly/1KRD76d.

Tony Meleg is a technical product manager in the Microsoft Azure team. He spends his time creating technical content for various audiences, evangelizing Azure and turning complexity into simple concepts.