Buck Woody : Links

The Windows Azure Software Development Kit (SDK) and the Windows Azure Training Kit (WATK)

BuckWoody — Wed, 12 Sep 2012 13:40:40 GMT

Windows Azure is a platform that allows you to write software, run software, or use software that we've already written. We provide lots of resources to help you do that - many can be found right here in this blog series. There are two primary resources you can use, and it's important to understand what they are and what they do.

The Windows Azure Software Development Kit (SDK)

Actually, this isn't one resource. We have SDK's for multiple development environments, such as Visual Studio and also Eclipse, along with SDK's for iOS, Android and other environments. Windows Azure is a "back end", so almost any technology or front end system can use it to solve a problem.

The SDK's are primarily for development. In the case of Visual Studio, you'll get a runtime environment for Windows Azure which allows you to develop, test and even run code all locally - you do not have to be connected to Windows Azure at all, until you're ready to deploy.

You'll also get a few samples and codeblocks, along with all of the libraries you need to code with Windows Azure in .NET, PHP, Ruby, Java and more.

The SDK is updated frequently, so check this location to find the latest for your environment and language - just click the bar that corresponds to what you want:

http://www.windowsazure.com/en-us/develop/downloads/

The Windows Azure Training Kit (WATK)

Whether you're writing code, using Windows Azure Virtual Machines (VM's) or working with Hadoop, you can use the WATK to get examples, code, PowerShell scripts, PowerPoint decks, training videos and much more. This should be your second download after the SDK. This is all of the training you need to get started, and even beyond. The WATK is updated frequently - and you can find the latest one here:

http://www.windowsazure.com/en-us/develop/net/other-resources/training-kit/

There are many other resources - again, check the http://windowsazure.com site, the community newsletter (which introduces the latest features), and my blog for more.

Windows Azure End to End Examples

BuckWoody — Tue, 29 May 2012 13:45:59 GMT

I’m fascinated by the way people learn. I’m told there are several methods people use to understand new information, from reading to watching, from experiencing to exploring.

Personally, I use multiple methods of learning when I encounter a new topic, usually starting with reading a bit about the concepts. I quickly want to put those into practice, however, especially in the technical realm. I immediately look for examples where I can start trying out the concepts. But I often want a “real” example – not just something that represents the concept, but something that is real-world, showing some feature I could actually use.

And it’s no different with the Windows Azure platform – I like finding things I can do now, and actually use. So when I started learning Windows Azure, I of course began with the Windows Azure Training Kit – which has lots of examples and labs, presentations and so on. But from there, I wanted more examples I could learn from, and eventually teach others with. I was asked if I would write a few of those up, so here are the ones I use.

CodePlex

CodePlex is Microsoft’s version of an “Open Source” repository. Anyone can start a project, add code, documentation and more to it and make it available to the world, free of charge, using various licenses as they wish. Microsoft also uses this location for most of the examples we publish, and sample databases for SQL Server.

If you search in CodePlex for “Azure”, you’ll come back with a list of projects that folks have posted, including those of us at Microsoft. The source code and documentation are there, so you can learn using actual examples of code that will do what you need. There’s everything from a simple table query to a full project that is sort of a “Corporate Dropbox” that uses Windows Azure Storage.

The advantage is that this code is immediately usable. It’s searchable, and you can often find a complete solution to meet your needs. The disadvantage is that the code is pretty specific – it may not cover a huge project like you’re looking for. Also, depending on the author(s), you might not find the documentation level you want.

Link: http://azureexamples.codeplex.com/site/search?query=Azure&ac=8

Tailspin

Microsoft Patterns and Practices is a group here that does an amazing job at sharing standard ways of doing IT – from operations to coding. If you’re not familiar with this resource, make sure you read up on it. Long before I joined Microsoft I used their work in my daily job – saved a ton of time. It has resources not only for Windows Azure but other Microsoft software as well.

The Patterns and Practices group also publishes full books – you can buy these, but many are also online for free. There’s an end-to-end example for Windows Azure using a company called “Tailspin”, and the work covers not only the code but the design of the full solution. If you really want to understand the thought that goes into a Platform-as-a-Service solution, this is an excellent resource.

The advantages are that this is a book, it’s complete, and it includes a discussion of design decisions. The disadvantage is that it’s a little over a year old – and in “Cloud” years that’s a lot. So many things have changed, improved, and have been added that you need to treat this as a resource, but not the only one. Still, highly recommended.

Link: http://msdn.microsoft.com/en-us/library/ff728592.aspx

Azure Stock Trader

Sometimes you need a mix of a CodePlex-style application, and a little more detail on how it was put together. And it would be great if you could actually play with the completed application, to see how it really functions on the actual platform.

That’s the Azure Stock Trader application. There’s a place where you can read about the application, and then it’s been published to Windows Azure – the production platform – and you can use it, explore, and see how it performs.

I use this application all the time to demonstrate Windows Azure, or a particular part of Windows Azure.

The advantage is that this is an end-to-end application, and online as well. The disadvantage is that it takes a bit of self-learning to work through.

Links: Learn it: http://msdn.microsoft.com/en-us/netframework/bb499684 Use it: https://azurestocktrader.cloudapp.net/

Application Lifecycle Management Overview for Windows Azure

BuckWoody — Tue, 07 Feb 2012 14:58:39 GMT

Developing in Windows Azure is at once not that much different from what you’re familiar with in on-premises systems, and different in significant ways. Because of these differences, developers often ask about the specific process to develop and deploy a Windows Azure application - more formally called an Application Lifecycle Management, or ALM.

There are specific resources you can use to learn more about various parts of ALM - I’ve referenced those at the end of this post. But ALM has multiple definitions, from the governance of code injection, domain upgrade, testing, process flow and more. Many developers are interested in the finer-grained information, like how do I develop and deploy an application? What tools do I need, and how do I get the code running somewhere that I can test?

I’ll cover the very high-level process here, and refer you to specifics at the end of each section, so that you can take it all in at one viewing, and then bookmark for more detail when you need more information. I won’t be covering processes like Continuous Integration or Agile and other methodologies in this post - I’ll blog those later.

Initial Development

You start with writing code. You have three ways to do this. You can use Visual Studio (even the Express Edition Works), Eclipse, or by leveraging the REST API format. You can do this in a standalone (non-connected) environment like your laptop.

Using Visual Studio is one of the simplest methods to create an Azure application, allowing you to combine the Azure components you want to leverage (Storage, Compute, SQL Azure, the Service Bus, etc.) along with the on-premises code you have now or are creating. Once you’ve installed and patched Visual Studio, just download and install the Windows Azure Software Development Kit (SDK) and you’ll have not only all the API’s you need to talk to Azure, but a fully functioning local environment to run and test your code before you deploy it. You’ll also get a robust set of samples. You can download what you need for all of that (free) here: http://www.windowsazure.com/en-us/develop/downloads/ . There’s a step-by-step process here: http://msdn.microsoft.com/en-us/magazine/ee336122.aspx

You can also use Eclipse to develop for Windows Azure. You won’t get the full runtime environment in just that kit alone, but you can use this successfully on a Linux system. I have several folks using this method. The downloads and documentation for that is here: http://www.windowsazure4e.org/

You can use REST API’s to hit Azure Assets and control them. Not my preferred method, but possible. There are REST API’s for various sections of Azure. You can find the main reference for that here: http://msdn.microsoft.com/en-us/library/windowsazure/ff800682.aspx

Note: We recently demonstrated using a Cloud-based Integrated Development Environment (IDE) for Node.js deployment to Windows Azure. More on that here: http://www.readwriteweb.com/cloud/2012/01/cloud9-ide-to-enable-nodejs-ap.php

Deploying to a Test Instance

After you write the code, you’ll need to test it somewhere. The Azure Emulator on your development laptop is for a single user on that laptop, and it also has some subtle differences from the production fabric as you might imagine. Normally you’ll set up a small subscription to run and test the application, just like you would have a set of test servers. Each subscription has its own management keys and certificates, so this assists in keeping the testing environment separate for billing and control.

More on that general information here: http://msdn.microsoft.com/en-us/library/ff803362.aspx

Deploying to Production

Once you have developed the code and tested it, you need to move it to a location where users can access it. In reality, there is no physical difference in the type of machines, fabric or any other component in “Production” Windows Azure accounts and the “Test” accounts, but you’ll most often pick smaller systems to deploy on in testing, and you’ll probably keep the URL in the plain format.

In the Production Windows Azure account, the team normally limits the access to the account for deployment to a separate set of developers. This ensures code flow and control. A DNS name is normally mapped to the longer, Microsoft-generated URL so that your users access the application or data the way you want them to.

More on setting up an account here: http://techinch.com/2010/06/14/setup-your-windows-azure-account/

Managing Code Change

With the application deployed, there are two broad tasks you need to consider. One is managing changes through the application, and the other involves management, monitoring and performance tuning for an application.

To make a code change, the standard ALM process is followed, just as above. You can use command-line tools to automate the process as you would with an on-premises system. A vide on that shows you how: http://www.microsoftpdc.com/2009/SVC25. Normally this is used with an “In-Place” upgrade into Production Account, since your testing is completed in a separate account. More on that process here: http://msdn.microsoft.com/en-us/library/windowsazure/ee517255.aspx

One difference is the “VIP Swap” process you can use for the final push to Production. In essence, this allows you to have two copies of the application running on the Production account, with a quick way to cut over and back when you’re ready. The process for that is detailed here: http://msdn.microsoft.com/en-us/library/windowsazure/ee517253.aspx

For monitoring, you have several options. You should enable the Windows Azure Diagnostics in your code - more on that here: http://archive.msdn.microsoft.com/WADiagnostics.

You can observe uptime and other information on the Windows Azure Service Dashboard, where you can also consume the uptime as an RSS feed: http://www.windowsazure.com/en-us/support/service-dashboard/

From there, you can also use System Center to monitor not only Windows Azure deployments but internal applications as well. The Management Pack and documentation for that is here: http://www.microsoft.com/download/en/details.aspx?id=11324.

There are also 3rd-party tools to manage Windows Azure. More on that here: http://www.bing.com/search?q=monitor+Windows+Azure&form=OSDSRC

Other References:

There is a lot more detail in this official reference: https://www.windowsazure.com/en-us/develop/net/fundamentals/deploying-applications/

Bryan Group explains the ramifications of the Secure Development Lifecycle (SDL) with lots of collateral you can review: http://blogs.msdn.com/b/bryang/archive/2011/04/26/applying-the-sdl-to-windows-azure.aspx

Windows Azure Use Case: High-Performance Computing (HPC)

BuckWoody — Mon, 28 Feb 2011 15:52:31 GMT

This is one in a series of posts on when and where to use a distributed architecture design in your organization's computing needs. You can find the main post here: http://blogs.msdn.com/b/buckwoody/archive/2011/01/18/windows-azure-and-sql-azure-use-cases.aspx

Description:

High-Performance Computing (also called Technical Computing) at its most simplistic is a layout of computer workloads where a “head node” accepts work requests, and parses them out to “worker nodes'”. This is useful in cases such as scientific simulations, drug research, MatLab work and where other large compute loads are required. It’s not the immediate-result type computing many are used to; instead, a “job” or group of work requests is sent to a cluster of computers and the worker nodes work on individual parts of the calculations and return the work to the scheduler or head node for the requestor in a batch-request fashion.

This is typical to the way that many mainframe computing use-cases work. You can use commodity-based computers to create an HPC Cluster, such as the Linux application called Beowulf, and Microsoft has a server product for HPC using standard computers, called the Windows Compute Cluster that you can read more about here.

The issue with HPC (from any vendor) that some organization have is the amount of compute nodes they need. Having too many results in excess infrastructure, including computers, buildings, storage, heat and so on. Having too few means that the work is slower, and takes longer to return a result to the calling application. Unless there is a consistent level of work requested, predicting the number of nodes is problematic.

Implementation:

Recently, Microsoft announced an internal partnership between the HPC group (Now called the Technical Computing Group) and Windows Azure. You now have two options for implementing an HPC environment using Windows. You can extend the current infrastructure you have for HPC by adding in Compute Nodes in Windows Azure, using a “Broker Node”. You can then purchase time for adding machines, and then stop paying for them when the work is completed. This is a common pattern in groups that have a constant need for HPC, but need to “burst” that load count under certain conditions.

The second option is to install only a Head Node and a Broker Node onsite, and host all Compute Nodes in Windows Azure. This is often the pattern for organizations that need HPC on a scheduled and periodic basis, such as financial analysis or actuarial table calculations.

References:

Blog entry on Hybrid HPC with Windows Azure: http://blogs.msdn.com/b/ignitionshowcase/archive/2010/12/13/high-performance-computing-on-premise-and-in-the-windows-azure-cloud.aspx

Links for further research on HPC, includes Windows Azure information: http://blogs.msdn.com/b/ncdevguy/archive/2011/02/16/handy-links-for-hpc-and-azure.aspx

Windows Azure Use Case: Hybrid Applications

BuckWoody — Tue, 22 Feb 2011 19:44:09 GMT

Description:

Organizations see the need for computing infrastructures that they can “rent” or pay for only when they need them. They also understand the benefits of distributed computing, but do not want to create this infrastructure themselves. However, they may have considerations that prevent them from moving all of their current IT investment to a distributed environment:

Private data (do not want to send or store sensitive data off-site)
High dollar investment in current infrastructure
Applications currently running well, but may need additional periodic capacity
Current applications not designed in a stateless fashion

In these situations, a “hybrid” approach works best. In fact, with Windows Azure, a hybrid approach is an optimal way to implement distributed computing even when the stipulations above do not apply. Keeping a majority of the computing function in an organization local while exploring and expanding that footprint into Windows and SQL Azure is a good migration or expansion strategy.

A “hybrid” architecture merely means that part of a computing cycle is shared between two architectures. For instance, some level of computing might be done in a Windows Azure web-based application, while the data is stored locally at the organization.

Implementation:

There are multiple methods for implementing a hybrid architecture, in a spectrum from very little interaction from the local infrastructure to Windows or SQL Azure. The patterns fall into two broad schemas, and even these can be mixed.

1. Client-Centric Hybrid Patterns

In this pattern, programs are coded such that the client system sends queries or compute requests to multiple systems. The “client” in this case might be a web-based codeset actually stored on another system (which acts as a client, the user’s device serving as the presentation layer) or a compiled program. In either case, the code on the client requestor carries the burden of defining the layout of the requests.

While this pattern is often the easiest to code, it’s the most brittle. Any change in the architecture must be reflected on each client, but this can be mitigated by using a centralized system as the client such as in the web scenario.

2. System-Centric Hybrid Patterns

Another approach is to create a distributed architecture by turning on-site systems into “services” that can be called from Windows Azure using the service Bus or the Access Control Services (ACS) capabilities. Code calls from a series of in-process client application. In this pattern you move the “client” interface into the server application logic.

If you do not wish to change the application itself, you can “layer” the results of the code return using a product (such as Microsoft BizTalk) that exposes a Web Services Definition Language (WSDL) endpoint to Windows Azure using the Application Fabric. In effect, this is similar to creating a Service Oriented Architecture (SOA) environment, and has the advantage of de-coupling your computing architecture. If each system offers a “service” of the results of some software processing, the operating system or platform becomes immaterial, assuming it adheres to a service contract.

There are important considerations when you federate a system, whether to Windows or SQL Azure or any other distributed architecture. While these considerations are consistent with coding any application for distributed computing, they are especially important for a hybrid application.

Connection resiliency - Applications on-premise normally have low-latency and good connection properties, something you’re not always guaranteed in a distributed and hybrid application. Whether a centralized client or a distributed one, the code should be able to handle extended retry logic.

Authorization and Access - In a single authorization environment like a Active Directory domain, security is handled at a user-password level. In a distributed computing environment, you have more options. You can mitigate this with using The Windows Azure Application Fabric feature of ACS to make the Azure application aware of the App Fabric as an ADFS provider. However, a claims-based authentication structure is often a superior choice.

Consistency and Concurrency - When you have a Relational Database Management System (RDBMS), Consistency and Concurrency are part of the design. In a Service Architecture, you need to plan for sequential message handling and lifecycle.

Resources:

How to Build a Hybrid On-Premise/In Cloud Application: http://blogs.msdn.com/b/ignitionshowcase/archive/2010/11/09/how-to-build-a-hybrid-on-premise-in-cloud-application.aspx

General Architecture guidance: http://blogs.msdn.com/b/buckwoody/archive/2010/12/21/windows-azure-learning-plan-architecture.aspx

Windows Azure Use Case: Web Applications

BuckWoody — Mon, 14 Feb 2011 17:22:42 GMT

Description:

Many applications have a requirement to be located outside of the organization’s internal infrastructure control. For instance, the company website for a brick-and-mortar retail company may want to post not only static but interactive content to be available to their external customers, and not want the customers to have access inside the organization’s firewall.

There are also cases of pure web applications used for a great many of the internal functions of the business. This allows for remote workers, shared customer/employee workloads and data and other advantages. Some firms choose to host these web servers internally, others choose to contract out the infrastructure to an “ASP” (Application Service Provider) or an Infrastructure as a Service (IaaS) company.

In any case, the design of these applications often resembles the following:

In this design, a server (or perhaps more than one) hosts the presentation function (http or https) access to the application, and this same system may hold the computational aspects of the program. Authorization and Access is controlled programmatically, or is more open if this is a customer-facing application. Storage is either placed on the same or other servers, hosted within an RDBMS or NoSQL database, or a combination of the options, all coded into the application.

High-Availability within this scenario is often the responsibility of the architects of the application, and by purchasing more hosting resources which must be built, licensed and configured, and manually added as demand requires, although some IaaS providers have a partially automatic method to add nodes for scale-out, if the architecture of the application supports it. Disaster Recovery is the responsibility of the system architect as well.

Implementation:

In a Windows Azure Platform as a Service (PaaS) environment, many of these architectural considerations are designed into the system.

The Azure “Fabric” (not to be confused with the Azure implementation of Application Fabric - more on that in a moment) is designed to provide scalability. Compute resources can be added and removed programmatically based on any number of factors. Balancers at the request-level of the Fabric automatically route http and https requests. The fabric also provides High-Availability for storage and other components. Disaster recovery is a shared responsibility between the facilities (which have the ability to restore in case of catastrophic failure) and your code, which should build in recovery.

In a Windows Azure-based web application, you have the ability to separate out the various functions and components. Presentation can be coded for multiple platforms like smart phones, tablets and PC’s, while the computation can be a single entity shared between them. This makes the applications more resilient and more object-oriented, and lends itself to a SOA or Distributed Computing architecture.

It is true that you could code up a similar set of functionality in a traditional web-farm, but the difference here is that the components are built into the very design of the architecture. The API’s and DLL’s you call in a Windows Azure code base contains components as first-class citizens. For instance, if you need storage, it is simply called within the application as an object. Computation has multiple options and the ability to scale linearly.

You also gain another component that you would either have to write or bolt-in to a typical web-farm: the Application Fabric. This Windows Azure component provides communication between applications or even to on-premise systems. It provides authorization in either person-based or claims-based perspectives.

SQL Azure provides relational storage as another option, and can also be used or accessed from on-premise systems. It should be noted that you can use all or some of these components individually.

Resources:

Design Strategies for Scalable Active Server Applications - http://msdn.microsoft.com/en-us/library/ms972349.aspx

Physical Tiers and Deployment - http://msdn.microsoft.com/en-us/library/ee658120.aspx

Windows Azure Use Case: New Development

BuckWoody — Tue, 08 Feb 2011 13:46:34 GMT

Description:

Computing platforms evolve over time. Originally computers were directed by hardware wiring - that, the “code” was the path of the wiring that directed an electrical signal from one component to another, or in some cases a physical switch controlled the path. From there software was developed, first in a very low machine language, then when compilers were created, computer languages could more closely mimic written statements. These language statements can be compiled into the lower-level machine language still used by computers today.

Microprocessors replaced logic circuits, sometimes with fewer instructions (Reduced Instruction Set Computing, RISC) and sometimes with more instructions (Complex Instruction Set Computing, CISC).

The reason this history is important is that along each technology advancement, computer code has adapted. Writing software for a RISC architecture is significantly different than developing for a CISC architecture. And moving to a Distributed Architecture like Windows Azure also has specific implementation details that our code must follow.

But why make a change? As I’ve described, we need to make the change to our code to follow advances in technology. There’s no point in change for its own sake, but as a new paradigm offers benefits to our users, it’s important for us to leverage those benefits where it makes sense.

That’s most often done in new development projects. It’s a far simpler task to take a new project and adapt it to Windows Azure than to try and retrofit older code designed in a previous computing environment. We can still use the same coding languages (.NET, Java, C++) to write code for Windows Azure, but we need to think about the architecture of that code on a new project so that it runs in the most efficient, cost-effective way in a Distributed Architecture.

As we receive new requests from the organization for new projects, a distributed architecture paradigm belongs in the decision matrix for the platform target.

Implementation:

When you are designing new applications for Windows Azure (or any distributed architecture) there are many important details to consider. But at the risk of over-simplification, there are three main concepts to learn and architect within the new code:

Stateless Programming - Stateless program is a prime concept within distributed architectures. Rather than each server owning the complete processing cycle, the information from an operation that needs to be retained (the “state”) should be persisted to another location c(like storage) common to all machines involved in the process. An interesting learning process for Stateless Programming (although not unique to this language type) is to learn Functional Programming.

Server-Side Processing - Along with developing using a Stateless Design, the closer you can locate the code processing to the data, the less expensive and faster the code will run. When you control the network layer, this is less important, since you can send vast amounts of data between the server and client, allowing the client to perform processing. In a distributed architecture, you don’t always own the network, so it’s performance is unpredictable. Also, you may not be able to control the platform the user is on (such as a smartphone, PC or tablet), so it’s imperative to deliver only results and graphical elements where possible.

Token-Based Authentication - Also called “Claims-Based Authorization”, this code practice means instead of allowing a user to log on once and then running code in that context, a more granular level of security is used. A “token” or “claim”, often represented as a Certificate, is sent along for a series or even one request. In other words, every call to the code is authenticated against the token, rather than allowing a user free reign within the code call. While this is more work initially, it can bring a greater level of security, and it is far more resilient to disconnections.

Resources:

See the references of “Nondistributed Deployment” and “Distributed Deployment” at the top of this article for more information with graphics: http://msdn.microsoft.com/en-us/library/ee658120.aspx

Stack Overflow has a good thread on functional programming: http://stackoverflow.com/questions/844536/advantages-of-stateless-programming

Another good discussion on Stack Overflow on server-side processing is here: http://stackoverflow.com/questions/3064018/client-side-or-server-side-processing

Claims Based Authorization is described here: http://msdn.microsoft.com/en-us/magazine/ee335707.aspx

Windows Azure Use Case: Agility

BuckWoody — Tue, 25 Jan 2011 14:56:44 GMT

Description:

Agility in this context is defined as the ability to quickly develop and deploy an application. In theory, the speed at which your organization can develop and deploy an application on available hardware is identical to what you could deploy in a distributed environment. But in practice, this is not always the case. Having an option to use a distributed environment can be much faster for the deployment and even the development process.

Implementation:

When an organization designs code, they are essentially becoming a Software-as-a-Service (SaaS) provider to their own organization. To do that, the IT operations team becomes the Infrastructure-as-a-Service (IaaS) to the development teams. From there, the software is developed and deployed using an Application Lifecycle Management (ALM) process.

A simplified view of an ALM process is as follows:

Requirements
Analysis
Design and Development
Implementation
Testing
Deployment to Production
Maintenance

In an on-premise environment, this often equates to the following process map:

Requirements	Business requirements formed by Business Analysts, Developers and Data Professionals.
Analysis	Feasibility studies, including physical plant, security, manpower and other resources. Request is placed on the work task list if approved.
Design and Development	Code written according to organization’s chosen methodology, either on-premise or to multiple development teams on and off premise.
Implementation	Code checked into main branch. Code forked as needed.
Testing	Code deployed to on-premise Testing servers. If no server capacity available, more resources procured through standard budgeting and ordering processes. Manual and automated functional, load, security, etc. performed.
Deployment to Production	Server team involved to select platform and environments with available capacity. If no server capacity available, standard budgeting and procurement process followed. If no server capacity available, systems built, configured and put under standard organizational IT control. Systems configured for proper operating systems, patches, security and virus scans. System maintenance, HA/DR, backups and recovery plans configured and put into place.
Maintenance	Code changes evaluated and altered according to need.

In a distributed computing environment like Windows Azure, the process maps a bit differently:

Requirements	Business requirements formed by Business Analysts, Developers and Data Professionals.
Analysis	Feasibility studies, including budget, security, manpower and other resources. Request is placed on the work task list if approved.
Design and Development	Code written according to organization’s chosen methodology, either on-premise or to multiple development teams on and off premise.
Implementation	Code checked into main branch. Code forked as needed.
Testing	Code deployed to Azure. Manual and automated functional, load, security, etc. performed.
Deployment to Production	Code deployed to Azure. Point in time backup and recovery plans configured and put into place.(HA/DR and automated backups already present in Azure fabric)
Maintenance	Code changes evaluated and altered according to need.

This means that several steps can be removed or expedited. It also means that the business function requesting the application can be held directly responsible for the funding of that request, speeding the process further since the IT budgeting process may not be involved in the Azure scenario.

An additional benefit is the “Azure Marketplace”, In effect this becomes an app store for Enterprises to select pre-defined code and data applications to mesh or bolt-in to their current code, possibly saving development time.

Resources:

Whitepaper download- What is ALM? http://go.microsoft.com/?linkid=9743693

Whitepaper download - ALM and Business Strategy: http://go.microsoft.com/?linkid=9743690

LiveMeeting Recording on ALM and Windows Azure (registration required, but free): http://www.microsoft.com/uk/msdn/visualstudio/contact-us.aspx?sbj=Developing with Windows Azure (ALM perspective) - 10:00-11:00 - 19th Jan 2011

Windows Azure and SQL Azure Use Cases

BuckWoody — Tue, 18 Jan 2011 15:14:00 GMT

The key to effectively leveraging “Cloud Computing” or more accurately, Distributed Computing architectures like Windows and SQL Azure is to implement them where they make the most sense. This is actually good advice for any computing paradigm, but some folks believe that a particular tool should be used in all circumstances. Microsoft does not recommend that you take all of the computing resources you have on-premise and move them to a distributed architecture.

A Use Case is defined as “when or where you use a technology” and a Pattern/Practice is defined as “how you implement a technology”. In this series of posts, I’ll cover the use cases, and I’ll also give you resources to leverage to implement them. If you are looking for a way to learn "cloud" or Distributed Computing, check out the Azure Learning Plan here.

Windows Azure Use-Cases
Elastic Scale - Bursting workloads up and down in use patterns	http://blogs.msdn.com/b/buckwoody/archive/2011/01/18/windows-azure-use-case-elastic-scale.aspx
Agility - The ability to quickly develop and deploy an application	http://blogs.msdn.com/b/buckwoody/archive/2011/01/25/windows-azure-use-case-agility.aspx
New Development- Code option for new applications	http://blogs.msdn.com/b/buckwoody/archive/2011/02/08/windows-azure-use-case-new-development.aspx
Web-Centric Applications - Applications that are developed for a web paradigm	http://blogs.msdn.com/b/buckwoody/archive/2011/02/14/windows-azure-use-case-web-applications.aspx
Hybrid Applications and Data - Applications and data that need to be both on-premise and in a distributed environment	http://blogs.msdn.com/b/buckwoody/archive/2011/02/22/windows-azure-use-case-hybrid-applications.aspx
High-Performance Computing - Apllications that require multiple processing nodes, such as scientific, research or financial data (also known as Technical Computing)	http://blogs.msdn.com/b/buckwoody/archive/2011/02/28/windows-azure-use-case-high-performance-computing-hpc.aspx
Infrastructure Limits - Inability or unwillingness to add more physical computers to the environment	http://blogs.msdn.com/b/buckwoody/archive/2011/03/08/windows-azure-use-case-infrastructure-limits.aspx
Fast Acquisitions - The ability to quickly migrate a newly acquired business to the current computing environment	http://blogs.msdn.com/b/buckwoody/archive/2011/03/15/windows-azure-use-case-fast-acquisitions.aspx
SQL Azure Use-Cases
Application Data Store - Uses SQL Azure to provide a central location for department-level or other collaborative applications	http://blogs.msdn.com/b/buckwoody/archive/2011/03/22/sql-azure-use-case-department-application-data-store.aspx
Shared Data Hub - Provides a common data store for multiple organizations to handle data between them	http://blogs.msdn.com/b/buckwoody/archive/2011/04/05/sql-azure-use-case-shared-data-hub.aspx
Web-Based Applications - Using SQL Azure as a data store type for web applications	http://blogs.msdn.com/b/buckwoody/archive/2011/04/19/sql-azure-use-case-web-based-applications.aspx
Shared Storage Application - Using SQL Azure as a hybrid data store or as part of a HA/DR plan.	http://blogs.msdn.com/b/buckwoody/archive/2011/04/26/sql-azure-use-case-shared-storage-application.aspx

Windows Azure Use Case: Elastic Scale

BuckWoody — Tue, 18 Jan 2011 14:54:00 GMT

Description:

“Elastic Scale” is a description of computing where the demands for the compute resources expands and contracts. Normally this involves increased user activity for the system, but the compute functions might also be driven by activity within the code itself. Let’s take a quick look at each.

In a centralized computing model (such as client/server), there is a finite set of resources for Compute and Storage, defined by the limits of the server architecture in place. The compute and storage resources are at a constant, assuming that they are at their maximum levels. In effect, you’re paying for and maintaining a a high level of computing whether you use it or not.

In a distributed computing model (such as “Cloud Computing” and Windows Azure) computing and storage resources can be added - and removed - dynamically. This means that as demand increases, you can add more resources to the pool based on a trigger of your choosing, and establish the ceiling for those resources if you want one. Conversely, as the load decreases, the resources also decrease. In this design, the use drives the capacity you pay for.

Implementation:

The key to implementing a distributed application is to keep it stateless. In a program, “state” is loosely defined as maintaining track of the previous operations within a program. Normally this record is kept in memory during the run of a particular program.

For instance - when you begin a bank transaction, the ATM machine takes your card, accepts your PIN, accepts the money you deposit and the withdrawals you make, and then returns your card, closing out the transaction. It maintains the “state” of your entire process, bookmarked on each end by taking your card and giving it back to you.

In stateless computing, the assumption is that the components within the process will come and go at various times. A good analogy here is e-mail. An e-mail system is made up of multiple parts:

Mail Client Software
Message
Transport
Server
Processing
Transport
Recipient(s)

When you compose an e-mail message, none of the other components are aware of your activities. When you send it, your client program is no longer aware of what is happening to the message. When the server receives it, your client software might even be powered off. The “state” is maintained by each component.

To adequately scale your workload, each component should be largely unaware of other components. That means you need to design your code such that it has more of the characteristics of an e-mail system. Keep in mind that even a bank ATM machine transaction can still be coded as a stateless application - I’m using it here as an example. In fact, very few things cannot be created in a stateless way.

You can “persist” state - that is, save it - to storage that each component can access. This is in fact the purpose of the Message Queue storage in Windows Azure. It allows one component to write a message and then leave. The next component can pick up that message and work on it. It’s similar to what you see in a restaurant. The waiter takes your order and drops it off in the kitchen, and the cook looks at each order to prepare it. In this analogy, the “message” is the meal order ticket.

Resources:

Design Strategies for Scalable Active Server Applications - http://msdn.microsoft.com/en-us/library/ms972349.aspx

Physical Tiers and Deployment - http://msdn.microsoft.com/en-us/library/ee658120.aspx

Presentation Links: SQL Server Performance Tuning (Quest)

BuckWoody — Wed, 21 Jul 2010 09:54:15 GMT

I worked with a team of folks brought together by Quest software, and we presented multiple sessions on SQL Server Performance Tuning. Here are the links I mentioned during those presentations:

Blitz! SQL Server Takeovers (Brent)

You're minding your own business in your corner office - well, no, you're a DBA, so it's just your cubicle - when somebody says, "Did you know about this SQL Server over here?" Suddenly, you have to find out what the server's doing, how it was set up, and whether things are working correctly. In this real-time session, Brent will show you how he tackles unknown servers in 60 minutes to find problems, take an inventory, and set the server up for easier management down the road.

· SQL Server Best Practices Article: http://technet.microsoft.com/en-us/library/cc966412.aspx

· How to determine proper SQL Server configuration settings: http://support.microsoft.com/kb/319942

· Setting Server Configuration Options (SQL Server 2008 R2, other versions available) : http://technet.microsoft.com/en-us/library/ms189631.aspx

· Running SQL Server 2008 in a Hyper-V Environment - Best Practices and Performance Recommendations: http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/SQL2008inHyperV2008.docx

· Checklist: SQL Server Performance: http://msdn.microsoft.com/en-us/library/ms979169.aspx

· Script Repository for SQL Server Information: http://gallery.technet.microsoft.com/ScriptCenter/en-us/site/search?f%5B0%5D.Type=RootCategory&f%5B0%5D.Value=databases&f%5B0%5D.Text=Databases&f%5B1%5D.Type=SubCategory&f%5B1%5D.Value=sqlserver&f%5B1%5D.Text=SQL%20Server

“Turn your head and cough” – Quick Health Check Using Wait Stats for the SQL Server Takeover (Kevin)

So you’ve survived the SQL Server Blitz and have made sure that your server is properly setup, configured, and under proper preventative maintenance. Now it’s time to play doctor and determining the health of your SQL Server. Kevin will slip on the latex gloves and show you how to determine the health of an unknown server and the applications running on that SQL Server with a quick physical.

· SQL Server Best Practices Analyzer (SQL Server 2008 R2, other versions available) : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0fd439d7-4bff-4df7-a52f-9a1be8725591

· Microsoft Assessment and Planning (MAP) Toolkit for SQL Server 2008 (will detect all the way down to SQL Server 2000): http://technet.microsoft.com/en-us/solutionaccelerators/dd537572.aspx

· DMV Stats: http://www.codeplex.com/sqldmvstats

· SQL Server 2005 Performance Dashboard Reports: http://www.microsoft.com/downloads/details.aspx?familyid=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en

Lose Wait Fast with Wait Stats (Brent)

It's time for you to get serious about wait loss - no, not weight loss, but wait loss. SQL Server wait stats will tell you what your queries and your server have been waiting on, and you don't even have to use Profiler or tracing! Brent will show you how to troubleshoot issues in real time and check historical data. He'll also show tools to make this process easier.

· Troubleshooting Performance Problems in SQL Server 2008 Whitepaper (2005 version also available) : http://msdn.microsoft.com/en-us/library/dd672789.aspx

· SQL Server 2005 Performance Tuning using Waits and Queues: http://technet.microsoft.com/library/cc966413.aspx

· SQL Server 2005 Waits and Queues: http://sqlcat.com/whitepapers/archive/2007/11/19/sql-server-2005-waits-and-queues.aspx

· OLTP Top 6 Performance Issues for OLTP Applications: http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/oltp-performance-issues.mspx

· Top SQL Server 2005 Performance Issues for OLTP Applications: http://sqlcat.com/top10lists/archive/2007/11/21/top-sql-server-2005-performance-issues-for-oltp-applications.aspx

PerfMon is “Irie Mon” (Kevin)

They say “irie mon” in Jamaica when everything is going well. Performance Monitor is irie! It’s an extremely important tool in the pocket of any IT professional because it’s available on every version of Windows and provides valuable performance information across all of the components of SQL Server, from the relational and storage engine to SSIS, SSAS, and SSRS. Kevin will show you how to make sense of PerfMon’s multitude of counters, how to store PerfMon data for long-term analysis, and how to correlate PerfMon

· Windows Reliability and Performance Monitor : http://technet.microsoft.com/en-us/library/cc755081(WS.10).aspx

· Overview of Windows Performance Monitor: http://technet.microsoft.com/en-us/library/cc749154.aspx

· Scripts and Tools for Performance Tuning and Troubleshooting SQL Server 2005: http://www.microsoft.com/technet/scriptcenter/scripts/sql/sql2005/default.mspx

· Troubleshooting Performance Problems in SQL Server 2008: http://sqlcat.com/whitepapers/archive/2009/04/14/troubleshooting-performance-problems-in-sql-server-2008.aspx

Designing Dashboards

BuckWoody — Wed, 14 Jul 2010 14:44:06 GMT

Not all data professionals get into the "front end" of the applications that hit their data. But most of us end up having to do a "dashboard" of information, even if it's a dashboard of our system information and performance tracking. I do this quite often for myself and for other folks, and I wanted to share a resource I use for that. It's from a site called "Quince", and I really like the way they break down all kinds of User-Interface (UI) information. Well worth your time to take a look, and share with your dev friends: http://quince.infragistics.com/#/Main/ViewPattern$pattern=Dashboard/PatternExamples$guid=0cdc0314-2ab3-4981-bbef-0b7a038adab2

Data-tier Applications in SQL Server 2008 R2

BuckWoody — Tue, 25 May 2010 10:47:45 GMT

I had the privilege of presenting to the Adelaide SQL Server User Group in Australia last evening, and I covered the Data Access Component (DAC) and the Utility Control Point (UCP) from SQL Server 2008 R2. Here are some links from that presentation:

Whitepaper: http://msdn.microsoft.com/en-us/library/ff381683.aspx

Tutorials: http://msdn.microsoft.com/en-us/library/ee210554(SQL.105).aspx

From Visual Studio: http://msdn.microsoft.com/en-us/library/dd193245(VS.100).aspx

Restrictions and capabilities by Edition: http://msdn.microsoft.com/en-us/library/cc645993(SQL.105).aspx

Glen Berry's Blog entry on scripts for UCP/DAC: http://www.sqlservercentral.com/blogs/glennberry/archive/2010/05/19/sql-server-utility-script-from-24-hours-of-pass.aspx

Objects supported by a DAC: http://msdn.microsoft.com/en-us/library/ee210549(SQL.105).aspx

SQL Server for the Oracle DBA Links

BuckWoody — Wed, 28 Apr 2010 14:29:00 GMT

I do a presentation (and a class) called "SQL Server for the Oracle DBA". It's a non-marketing overview that gives you the basics of working with SQL Server if you're already familiar wtih how Oracle works. This class and these links DO NOT help you with "Why should I use Oracle/SQL Server instead of Oracle/SQL Server" - I'll assume you're already there, and if not, there are LOTS of sites to help you make that decision.

Although these links might contain slight marketing slants (I don't control them) I've tried to get the best links I can. Feel free to comment here to add more/better links.

As such, these aren't links that help you work with Oracle - they are links to help you work with SQL Server. Some of them contain more information than you actually need, others don't have near enough. Taken together (and with the class) you're able to get done what you need to do.

"Practical SQL Server for Oracle Professionals" - A Microsoft Whitepaper, probably the best place to get started: http://download.microsoft.com/download/6/9/d/69d1fea7-5b42-437a-b3ba-a4ad13e34ef6/SQLServer2008forOracle.docx

Free Training: http://technet.microsoft.com/en-us/sqlserver/dd548020.aspx

Classroom training (will cost you): http://www.microsoft.com/learning/en/us/course.aspx?ID=50068A&locale=en-us

Terminology Differences: http://www.associatedcontent.com/article/2383466/oracle_and_sql_server_basic_terminology.html

Datatype mapping between Oracle and SQL Server: http://msdn.microsoft.com/en-us/library/ms151817.aspx

The "other" direction - can still be useful for the Oracle professional to see the other side: http://blog.benday.com/archive/2008/10/23/23195.aspx

Consolidation Strategy References

BuckWoody — Tue, 09 Mar 2010 13:11:19 GMT

I have a presentation that I give on SQL Server Consolidation Strategies, and in that presentation I talk about a few links that are useful. Here are some that I’ve found – feel free to comment on more, or if these links go stale:

Consolidation using SQL Server: http://msdn.microsoft.com/en-us/library/ee692366.aspx

SQL Server Consolidation Guidance: http://msdn.microsoft.com/en-us/library/ee819082.aspx

More references for SQL Server and Hyper-V: http://www.sqlskills.com/BLOGS/KIMBERLY/post/Virtualization-with-SQL-Server.aspx

Quick overview of Virtual Server licensing implications: http://www.microsoft.com/uk/licensing/morethan250/learn/virtualisation.mspx

SQL Server and Hyper-V best practices: http://sqlcat.com/whitepapers/archive/2008/10/03/running-sql-server-2008-in-a-hyper-v-environment-best-practices-and-performance-recommendations.aspx

High-Availability and Hyper-V: http://technet.microsoft.com/en-us/magazine/2008.10.higha.aspx

Virtualization Calculator: http://www.microsoft.com/Windowsserver2008/en/us/hyperv-calculators.aspx

May not be current, but here’s a whitepaper from VMWare for SQL Server: http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf

More information on SQL Server and VMWare: http://blogs.msdn.com/cindygross/archive/2009/10/23/considerations-for-installing-sql-server-on-vmware.aspx

Server Virtualization Validation Program: http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm