Buck Woody : Link Lists, Azure

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/

Plan for Diagnostics in Cloud Computing From the Git-Go

BuckWoody — Tue, 06 Sep 2011 13:11:22 GMT

“Git-Go” is something we say in the South that means “right at the start”. I’ve seen several applications for on-premise systems that don’t have much in the way of diagnostics - the developers rely on a debugger, the event logs on the server and client workstation, and most of all, the ability to watch the system from end-to-end.

This approach is a mistake for an on-premise system, and it’s definitely a problem for a distributed architecture. You simply do not own all of the components from end to end in a cloud environment, nor are you always able to attach a debugger or other remote monitoring tools to the various areas within the code path. So you need to make sure that from the very outset of your design that you build in diagnostics. My personal preference is to build a system such that a control file turns on deeper information gathering from the system, up to a minimal level.

When I do that, I set a high level of logging, a medium level, and a moderate level. I normally use the deepest level of information during the testing and acceptance phase of the deployment, then switch to moderate and then the least level of information gathering. Also in my design I often set an error condition to begin gathering the deeper information along with the exception, where possible.

There are decisions you need to make as to where to store the diagnostics (many operations in the cloud cost money), how often you collect them, and so on. You can get a quick overview on using the diagnostics that come with Windows Azure here: http://www.azuresupport.com/2010/03/getting-started-with-windows-azure-diagnostics-and-monitoring/ This is where you should start first. More detail on that: http://msdn.microsoft.com/en-us/library/gg433048.aspx

My friend Dave Pallman has a great tool he’s released for free: http://davidpallmann.blogspot.com/2009/03/azure-application-monitor-now-on.html

If the issue is in storage apps: http://social.msdn.microsoft.com/Forums/en-US/windowsazuredata/thread/d84ba34b-b0e0-4961-a167-bbe7618beb83

If you have System Center, this is the quickest and easiest way to implement the monitoring – really handy: http://pinpoint.microsoft.com/en-us/applications/windows-azure-application-monitoring-management-pack-release-candidate-12884907699

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

Windows Azure Learning Plan - Other Features

BuckWoody — Tue, 04 Jan 2011 12:11:00 GMT

This is one in a series of posts on a Windows Azure Learning Plan. You can find the main post here. This one deals with the Application Fabric for Windows Azure. It serves three main purposes - Access Control, Caching, and as a Service Bus.

Overview and Training	Overview and general information about other Azure features - what they are, how they work, and where you can learn more.
General Introduction and Overview	http://msdn.microsoft.com/en-us/library/ee922714.aspx
Access Control Service Overview	http://msdn.microsoft.com/en-us/magazine/gg490345.aspx
Microsoft Documentation	http://msdn.microsoft.com/en-gb/windowsazure/netservices.aspx
Learning and Examples	Sources for online and other Azure feature training
Application SDK	http://www.microsoft.com/downloads/en/details.aspx?FamilyID=39856a03-1490-4283-908f-c8bf0bfad8a5&displaylang=en
Caching Service Primer	http://blogs.msdn.com/b/appfabriccat/archive/2010/11/29/azure-appfabric-caching-service-soup-to-nuts-primer.aspx?wa=wsignin1.0
Hands-On Lab: Building Windows Azure Applications with the Caching Service	http://www.wadewegner.com/2010/11/hands-on-lab-building-windows-azure-applications-with-the-caching-service/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+WadeWegner+%28Wade+Wegner+-+Technical%29
Architecture	Azure Internals and Architectures for Scale Out and other use-cases.
Azure Features Architecture Guide	http://blogs.msdn.com/b/yasserabdelkader/archive/2010/09/12/release-of-windows-server-appfabric-architecture-guide.aspx
Windows Azure AppFabric Service Bus - A Deep Dive (Video)	http://www.msteched.com/2010/Europe/ASI410
Access Control Service (ACS) High Level Architecture	http://blogs.msdn.com/b/alikl/archive/2010/09/28/azure-appfabric-access-control-service-acs-v-2-0-high-level-architecture-web-application-scenario.aspx
Applications and Programming	Programming Patterns and Architectures for SQL Azure systems.
Various Examples from PDC 2010 on using Azure Application as a Service Bus	http://tinyurl.com/2dcnt8o
Creating a Distributed Cache	http://blog.structuretoobig.com/post/2010/08/31/Creating-a-Poor-Mane28099s-Distributed-Cache-in-Azure.aspx
Azure Java SDK	http://jdotnetservices.com/

Windows Azure Learning Plan - Storage

BuckWoody — Tue, 23 Nov 2010 15:24:00 GMT

This is one in a series of posts on a Windows Azure Learning Plan. You can find the main post here. This one deals with Storage for Windows Azure.

Overview	Overview and general information about Windows Azure Storage - what it is, how it works, and where you can learn more.
General Overview Whitepaper (registration of a screen name, but free)	http://social.technet.microsoft.com/wiki/contents/articles/understanding-data-storage-offerings
Official Microsoft Site on Azure Storage	http://msdn.microsoft.com/en-us/library/ee924681.aspx
Scalability Targets for Azure Storage	http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx
Understanding Azure Storage by using the API	http://blogs.msdn.com/b/paolos/archive/2011/02/21/yet-another-application-to-handle-windows-azure-storage-services.aspx
Blobs	Blob Storage is a binary-level "container" that can hold one or more streams of data.
Understanding Block Blobs and Page Blobs	http://msdn.microsoft.com/en-us/library/ee691964.aspx
Blob Service Concepts	http://msdn.microsoft.com/en-us/library/dd179376.aspx
Tables	Tables are key-value-pair type storage, and can be in the terabyte range of size.
Understanding the Table Storage Data Model	http://msdn.microsoft.com/en-us/library/dd179338.aspx
Table Service Concepts	http://msdn.microsoft.com/en-us/library/dd179463.aspx
Querying Tables and Entities	http://msdn.microsoft.com/en-us/library/dd894031.aspx
Queues	Queues are actually more table storage - but specifically designed to allow Web and Worker Roles to communicate.
Queue Service Concepts	http://msdn.microsoft.com/en-us/library/dd179353.aspx
Queue Service API	http://msdn.microsoft.com/en-us/library/dd179363.aspx
Azure Drive	An Azure Drive isn't something you mount over the web (although that's possible to do with a little code) - it's a "local" NTFS drive for Windows Azure Applications.
Windows Azure Drives white paper	http://go.microsoft.com/?linkid=9710117
Content Delivery Network	An "Edge" network of storage that buffers after the first use by a client.
General Overview	http://blogs.msdn.com/b/windowsazure/archive/2009/11/05/introducing-the-windows-azure-content-delivery-network.aspx
Delivering High-Bandwidth Content with the Windows Azure CDN	http://msdn.microsoft.com/en-us/library/ee795176.aspx
Tools and Utilities	Free and not-free tools to work with Azure Storage.
Storage SDK	http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.aspx
Benchmarks and Throughput tests	http://azurescope.cloudapp.net/BenchmarkTestCases/
Mount an Azure Drive as an NTFS Drive	http://azurescope.cloudapp.net/CodeSamples/cs/792ce345-256b-4230-a62f-903f79c63a67/
Command-line and other tools for working with Azure Storage	http://tinyurl.com/2acx6d8 and http://blogs.msdn.com/b/windowsazurestorage/archive/2010/04/17/windows-azure-storage-explorers.aspx