Today I spoke at VirtG Boston’s annual Deep Dive Day. The title of my talk, Meet Windows Azure, Your Next Data Center, is probably descriptive enough to get the gist of it.
My slide deck follows.
Today I spoke at VirtG Boston’s annual Deep Dive Day. The title of my talk, Meet Windows Azure, Your Next Data Center, is probably descriptive enough to get the gist of it.
My slide deck follows.
Examine your Windows Azure MANAGEMENT CERTIFICATES in the Windows Azure Portal (under “SETTINGS” in the left nav, then “MANAGEMENT CERTIFICATES” in the top nav). These are the certificates that control which people or which machines can programmatically manipulate your Windows Azure resources through the Service Management API.
Every time you initiate a Publish Profile file download (whether through the portal, with PowerShell, or through the CLI), a new certificate is generated and added to your list of management certificates. You cannot control these names – they are generated.
Upon examination, you may find that some certificates – like #1 shown below – have generated names. And also look at the several certificates immediately below #1 – they have similar names – also generated. These are hard to distinguish from each other.
But this is okay some of the time – it is convenient to let tools create these certificates for you since it saves time. It may be perfectly adequate on low security accounts – perhaps a developer’s individual dev-test account from MSDN, or an account only used to give demos with. But for a team account running production, you probably don’t want it to have 17 untraceable, indistinguishable certificates hanging off it.
Now look at the names for #2 and 3 shown above. They are custom names.
While we can debate whether the custom names shown above are truly meaningful (this is a demo account), you can probably appreciate that seeing a certificate name like “BUILD SERVER” or “Person/Machine” (e.g., “Maura/DRAGNIPUR”) or “Foobar Contractor Agency” might be more useful than “Azdem123EIEIO” to a human.
The Windows Azure Management Portal has some heuristics for deciding what to display for a certificate’s name, but the first one it considers is the Common Name, and will display its value if present. So the short answer: take control of the Common Name.
Here we show creating a Service Management certificate manually in two steps – first the PEM (for use locally) and second deriving a CER (for uploading to the portal).
openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout mycert.pem -out mycert.pem -subj "/CN=This Name Shows in the Portal" openssl x509 -inform pem -in mycert.pem -outform der -out mycert.cer
Note the use of
-subj "/CN=This Name Shows in the Portal" when generating a PEM in the first command. The specified text will appear as the description for this certificate within the Windows Azure Portal. OpenSSL is available on Linux and Mac systems by default. For Windows, you can install it directly, or – if you happen to use GitHub for Windows – it gets installed along with it.
For a pure Windows solution, use makecert to create a Management Certificate for Windows Azure.
Once you assume responsibility for naming your own certificates, you are simultaneously also taking on generating them, deploying the certificates containing the private keys to the machines from which your Windows Azure resources will be managed using the Service Management API, and uploading the CER public keys to the portal. To make some parts of this easier – especially if you are distributing to a team – consider building your own publish settings file. Also, realize the same certificate can be used by more than one client, and the can also be applied to more than one subscription on Windows Azure; its a many-to-many relationship that’s allowed.
When deploying an application or service to Windows Azure, a public IP address is assigned, making it easy to host a web server, API, or other services. Here are some of the more frequently asked questions asked about these IP addresses.
Short answer: Yes. Longer answer: For Cloud Services and Virtual Machines (but not Azure Web Sites) the IP address – once assigned – is stable, provided you do not remove the deployment. If you delete the deployment, your IP address goes back into the pool. For most production cloud applications it would very unusual to ever delete the deployment, so this is reasonable. Windows Azure supports in-place updates as well as the VIP Swap approach for Cloud Services, both of which always preserve the IP Address. Windows Azure Web Sites also has an IP Address-preserving swap feature.
Short answer: Yes. The formal name for a so-called “naked” domain is a zone apex. But regardless of what we call it, it is simply a domain without any subdomain prefix. The address “devpartners.com” is a “naked” or “apex” domain, whereas “www.devpartners.com” is not. And it is not just about counting periods in the domain: “amazon.co.jp” is also an apex domain. A DNS Address Record – or “A Record” for short – is used to configure an apex domain, and an A Record must be mapped to an IP Address. As noted in the question immediately above, you can have a stable IP address in Windows Azure, so therefore a stable A Record is possible, so therefore you can definitely map an apex record to your Windows Azure application or service. You can also use a DNS Canonical Name Record – or “CNAME” for short – to refer to a subdomain in your service. This is easy since, in addition to the stable IP address support mentioned above, Windows Azure provides a DNS name you can assign CNAMEs against. In Cloud Services (which includes Virtual Machines) this is of the form mycloudservice.cloudapp.net. [As opposed to Azure Web Sites which are of the form mywebsite.azurewebsites.net.]
Short answer: Yes. Longer answer: Microsoft publishes the IP Address Ranges used, organized by data center. So this published list of ranges can be consulted to review the possible IP address ranges. Specifically, the IP Address Ranges are documented here (http://msdn.microsoft.com/en-us/library/windowsazure/dn175718.aspx) and are expressed in Classless Inter-Domain Routing (CIDR) format. Be aware that as capacity increases and new data centers come on line, these ranges will evolve (I assume mostly the number of addresses will grow).
Today I spoke at the NYC Code Camp. My talk was Telemetry: Beyond Logging to Insight and focused on Event Tracing for Windows (ETW), ETW support in .NET 4.5, some .NET 4.5.1 additions, Semantic Logging Application Block (SLAB), Semantic Logging, and a number of other tools and ideas for using logging and other means to generate insight and answer questions. In order to allow this, “logging” needs to be structured, which ETW facilitates. In order for the structured data to make sense, developers need to be disciplined, which the Semantic Logging mindset supports.
The talk abstract and the slide deck used are both included below.
What is my application doing? This question can be difficult to answer in distributed environments such as the cloud. Parsing logs doesn’t cut it anymore. We need insight. In this talk we look at current logging approaches, contrast it with Telemetry, mix in the Semantic Logging mindset, and then use some new-fangled tools and techniques (enabled by .NET 4.5) alongside some old-school tools and techniques to see how to apply this goodness in our code. Event Tracing for Windows (ETW), the Semantic Logging Application Block, and several other tools and technologies will play a role.
[This post is part 21 of the 31 Days of Server (VMs) in the Cloud Series – I contributed the article below, but all others have been contributed by others – please find the index for the whole series by clicking here.]
As technology professionals we need to be careful about how we spend our time. Unless we want short careers, we find time to keep us with at least some new technologies, but there isn’t time in anyone’s day to keep up with every technology. We have to make choices.
For the IT Pro looking at cloud technologies, the IaaS capabilities are a far more obvious area on which to spend time than PaaS capabilities. In this post, we’ll take a peek into PaaS. The goal is to clarify the difference between IaaS and PaaS, understand what PaaS is uniquely good for, and offer some reasons why a busy IT Pro might want to invest some time learning about PaaS.
While the concepts in this point can apply generally to many platforms – including public and private clouds, Microsoft technologies and competing solutions – this post focuses on IaaS and PaaS capabilities within the Windows Azure Cloud Platform. Virtual machines and SQL databases are highlighted since these are likely of greatest interest to the IT Pro.
The NIST Definition of Cloud Computing (SP800-145) defines some terms that are widely used in the industry for classifying cloud computing approaches. One set of definitions delineates Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). You can read the NIST definitions for more details, but the gist is this:
|Service Model||What You Provide||Target Audience||Control & Flexibility||Expertise Needed||Example|
|SaaS||Users||Business Users||Low||App usage||Office 365|
|PaaS||Applications||Developers||Medium||App design and mgmt||Windows Azure Cloud Services|
|IaaS||Virtual Machines||IT Pros||High||App design and mgmt
+ VM/OS mgmt
|Windows Azure Virtual Machines (Windows Server, Linux)|
Generally speaking, as we move from SaaS through PaaS to IaaS, we gain more control and flexibility at the expense of more cost and expertise needed due to added complexity. There are always exceptions (perhaps a SaaS solution that requires complex integration with an on-premises solution), but this is good enough to set the stage. Now let’s look at the core differences between PaaS and IaaS as they relate to the IT Pro.
Even though Windows Azure has vastly more to offer (more on that later), the most obvious front-and-center offering is the humble VM. This is true both for PaaS and IaaS. So what distinguishes the two approaches?
The VMs for PaaS and IaaS behave very differently. The PaaS VM has a couple of behaviors that may surprise you, while the IaaS VM behavior is more familiar. Let’s start with the most far-reaching difference: On a PaaS VM, local storage is not durable.
This has significant implications. Suppose you install software (perhaps a database) on a PaaS VM and it stores some data locally. This will work fine… at least for a short while. At some point, Azure will migrate your application from one node to another… and it will not bring local data with it. Your locally-stored database data, not to mention any custom system tuning you did during installation, are gone. And this is by design. (For list of scenarios where PaaS VM drive data is destroyed, see the bottom of this document.)
How can this possibly be useful: a VM that doesn’t hold on to its local data…
You might wonder how this can possibly be useful: a VM that doesn’t hold on to its data. The fact of the matter is that it is not very useful for many applications written with conventional (pre-cloud) assumptions (such as guarantees around the durability of data). [PaaS may not be good at running certain applications, but is great at running others. So please keep reading!]
The PaaS VM drives use conventional server hard drives. These can fail, of course, and they are not RAID or high-end drives; this is commodity hardware optimized for high value for the money. And even if drives don’t outright fail, there are scenarios where the Azure operating environment does not guarantee durability of locally stored data (as referenced earlier).
On the other hand, IaaS VMs do have persistent/durable local drives. This is what makes them so much more convenient to use – and why they have a more familiar feel to IT Pros (and developers). But these drives are not the local server hard drives (other than the D: drive which is expected to be used only for temporary caching), they use a high capacity, highly scalable data storage service known as the Windows Azure Blob service (“blobs” for short, where each blob is roughly equivalent to a file, and each drive referenced by the VM is a VHD stored as one of these files). Data stored in blobs is safe from hardware failure: it is stored in triplicate by the blob service (each copy on a different physical node), and is even then geo-replicated in the background to a data center in another region, resulting (after a few minutes of latency) in an additional three copies.
IaaS VMs have persistent/durable local storage backed by blobs… this makes them so much more convenient to use – and more familiar to IT Pros
Storing redundant copies of your data offers a RAID-like feel, though is more cost-efficient at the scale of a data center.
Since blobs transparently handle storage for IaaS VMs (operating system drive, one or more data drives) and is external to any particular VM instance, in addition to being a familiar model, it is extremely robust and convenient.
Summarizing Some Key Differences
|PaaS VM||IaaS VM|
|Virtual Machine image||Choose from Win 2008 SP2, Win 2008 R2, and Win 2012. There are patch releases within each of these families.||There are many to choose from, including those you can create yourself. Can be Windows or Linux.|
|Hard Disk Persistence||Not durable. Could be lost due to hardware failure or when moved from one machine to another.||Durable. Backed by a blob (blobs are explained below).|
|Service Level Agreement (SLA)||99.95% for two or more instances (details). No SLA offered for single instance.||99.95% for two or more instances. 99.9% for single instance. (Preliminary details.)|
SLA details for the IaaS VM are preliminary since the service is still in preview as of this writing.
Windows Azure offers a PaaS database option, formerly called SQL Azure, and today known simply as SQL Database. This is really SQL Server behind the scenes, though it is not exactly the same as SQL Server 2012 (“Denali”).
SQL Database is offered as a service. This means with a few mouse clicks (or a few lines of PowerShell) you can have a database connection string that’s ready to go. Connecting to this database will actually connect you to a 3-node SQL Server cluster behind the scenes, but this is not visible to you; it appears to you to simply be a single-node instance. Three copies of your data are maintained by the cluster (each on different hardware).
Consider the three copies of every byte to be great for High Availability (HA), but offers no defense against Human Error (HE). If someone drops the CUSTOMER table, that drop will be immediately replicated to all three copies of your data. You still need a backup strategy.
One big benefit of the SQL Database service is that the server is completely managed by Windows Azure… with the flip side of that coin being that an IT Pro simply cannot make any adjustments to the configuration. Note that SQL tuning and database schema design skills have not gone anywhere; this is all just as demanding in the cloud as outside the cloud.
SQL Database has some limitations. The most obvious is that you cannot store more than 150 GB in a single instance. What happens when you have 151 GB? This brings to light another PaaS/IaaS divergence: the IaaS approach is to grow the database (“scale up” or “vertical scaling”) while the PaaS approach is to add additional databases (“scale out” or “horizontal scaling”). For the SQL Database service in Windows Azure, only the “horizontal scaling” approach is supported – it becomes up to the application to distribute its data across more than one physical database, an approach known commonly as sharding, where each shard represents one physical database server. This can be a big change for an application to support since the database schema needs to be compatible, which usually means it needs to have been originally designed with sharding in mind. Further, the application needs to be built to handle finding and connecting to the correct shard.
For PaaS applications that wish to support sharding, the Federations in SQL Database feature provides robust support for handling most of the routine tasks. Without the kind of support offered by Federations, building a sharding layer can be far more daunting. Federations simplifies connection string management, has smart caching, and offers management features that allow you to repartition your data across SQL Database nodes without experiencing downtime.
The alternative to SQL Database is for you to simply use an IaaS VM to host your own copy of SQL Server. You have full control (you can configure, tune, and manage your own database, unlike with the SQL Database service where these functions are all handled and controlled by Windows Azure). You can grow it beyond 150 GB. It is all yours.
But realize that in the cloud, there are still limitations. All public cloud vendors offer a fixed menu of virtual machine sizes, so you will need to ensure that your self-managed IaaS SQL Server will have enough resources (e.g., RAM) for your largest database.
Any database can outgrow its hardware, whether on the cloud or not.
It is worth pointing out that any database can outgrow its hardware. And the higher end the hardware, the more expensive it becomes from a “capabilities for the money” point of view. And at some point you can reach the point where (a) you can’t afford sufficiently large hardware, or (b) the needed hardware is so high end that it is not commercially available. This will drive you towards a either a sharding architecture, or some other approach to make your very large database smaller so that it will fit in available hardware.
Another significant difference between the SQL Database service and a self-hosted IaaS SQL Server is that the SQL Database service is multitenant: your data sits alongside the data of other customers. This is secure – one customer cannot access another customer’s data – but it does present challenges when one customer’s queries are very heavy, and another customer [potentially] experiences variability in performance as a result. For this reason, the SQL Database service protects itself and other customers by not letting any one customer dominate resources – this is accomplished with “throttling” and can manifest in multiple ways, from a delay in execution to dropping a connection (which the calling application is responsible for reestablishing).
Don’t underestimate the importance of properly handling of throttling. Applications need to be written to handle these scenarios in order to function correctly. Throttling can happen even if your application is doing nothing wrong.
Handling the throttling should not be underestimated. Proper throttling handling requires that application code handle certain types of transient failures and retry. Most existing application code does not do this. Blindly pointing an existing application at a SQL Database instance might seem to work, but will also potentially experience odd errors occasionally that may be hard to track down or diagnose if the application was written (and tested) in an environment where interactions with SQL Server always succeeded.
The self-managed IaaS database does not suffer this unpredictability since you presumably control which application can connect and can manage resources more directly.
The SQL Database service has some easy to enable features that may make your like easier. One example is the database sync service that can be enabled in the Windows Azure Portal. You can easily configure a SQL Database instance to be replicated with one or more other instances in the same or different databases. This can help with an offsite-backup strategy, mirroring globally to reduce latency, and is one area where PaaS shines.
Windows Azure today offers the SQL Database service based on SQL Server 2012. If your application (for some reason) needs an older version SQL Server (perhaps it is a vendor product and you don’t control this), then your hands are tied.
Or perhaps you want another database besides SQL Server. Windows Azure has a partner offering MySQL, and other vendor products will likely be offered over time. NoSQL Databases are also becoming more popular. Windows Azure natively offers the NoSQL Windows Azure Table service, and a few examples of other third-party ones include MongoDB, Couchbase, RavenDB, and Riak. Unless (or until) these are offered as PaaS services through the Windows Azure Store, your only option will be to run them yourself in an IaaS VM.
The main thrust of PaaS is to make operations efficient for applications designed to align with the PaaS approach. For example, applications that can deal with throttling, or can deal with a PaaS VM being migrated and losing all locally stored data. This is all doable – and without degrading user experience – it just so happens that most applications that exist today (and will still exist tomorrow) don’t work this way.
The PaaS approach can be used to horizontally scale an application very efficiently (whether computational resources running on VMs or database resources sharded with Federations for SQL Database), overcome disruptions due to commodity hardware failures, gracefully handle throttling (whether from SQL Database or other Azure services not discussed), and do so with minimal human interaction. But getting to this point is not automatic.
WazOps – DevOps, Windows Azure style! – is the role that will build out this reality. There are auto-scaling tools, both external services, and some that we can run ourselves — like the awesome WASABi auto-scaling application block from Microsoft’s Patterns & Practices group – that can be configured to scale an application on a schedule or based on environmental signals (like the CPU is spiking in a certain VM).
There is also the mundane. How to script a managed deployment so our application can be upgraded without downtime? Windows Azure PaaS services have features for this, such as the in-place update and the VIP Swap. But we still need to understand them and create a strategy to use them appropriately.
Further, there are at least some of the same-old-details. For example, it is easy to deploy an SSL certificate to my PaaS VM that is being deployed to IIS… but it still will expire in a year and someone still needs to know this – and know what to do about it before it results in someone being called at 2:00 AM on a Sunday.
Clearly there are some drawbacks to running PaaS since most existing applications will not run successfully without some non-trivial rework, but will work just fine if deployed to IaaS VMs.
However, that does not mean that PaaS is not useful. It turns out that some of the most reliable, scalable, cost-efficient applications in the world are architected for this sort of PaaS environment. The Bing services behind bing.com take this approach, as only one example. The key here is that these applications are architected assuming a PaaS environment. I don’t use the term “architected” lightly, since architecture dictates the most fundamental assumptions about how an application is put together. Most applications that exist today are not architected with PaaS-compatible assumption. However, as we move forward, and developer skills catch up with the cloud offerings, we will see more and more applications designed from the outset to be cloud-native; these will be deployed using these PaaS facilities.
A stateless web-tier (with no session affinity in the load balancer) is a good example today of an application that could run successfully in a PaaS environment – though I’ll be quick to note that other tiers of that application may not run so well in PaaS. Which bring up an obvious path going forward: hybrid applications that mix PaaS and IaaS. This will be a popular mix in the coming years.
Consider a 3-tier application with a web tier running in IIS, a service tier, and a SQL Server back-end database. If built with conventional approaches, not considering the PaaS cloud, none of these three tiers would be ready for a PaaS environment. So we could deploy all three tiers using IaaS VMs.
As a software maintenance step, it would be reasonable to upgrade the web site (perhaps written in PHP or ASP.NET) to be stateless and not need session affinity (Windows Azure PaaS Cloud Services do not support session affinity from the load balancer). These types of changes may be enough to allow the web tier to run more efficiently using PaaS VMs, while still interacting with a service tier and database running on IaaS VMs.
A future step could upgrade the service tier to handle SQL Database throttling correctly, allowing the SQL Server instance running on an IaaS VM to be migrated to the SQL Database service. This will reduce the number of Windows servers and SQL Servers being managed by the organization (shifting these to Windows Azure), and may also simplify some other tasks (like replicating that data using the Data Sync Service). Each services and VM also has its own direct costs (our monthly bill to Microsoft for the Windows Azure Cloud services we consume), which are detailed in the pricing section of the Windows Azure Portal.
Still another future step could be to migrate the middle tier to be stateless – but maybe not. All of these decisions are business decisions; perhaps the cost-benefit is not there. It depends on you application and your business and the skills and preferences of the IT Pros and developers in the organization.
I’ll summarize here with some of the key take-aways for the IT Pro who is new to PaaS services:
Feedback always welcome and appreciated. Good luck in your cloud journey!