Search results matching tags 'Windows Azure', 'Application Fabric', and 'Azure'

Management and Monitoring Tools for Windows Azure

BuckWoody — Tue, 03 Jul 2012 13:10:00 GMT

(Last updated on 01/15/2013)

With such a large platform, Windows Azure has a lot of moving parts. We’ve done our best to keep the interface as simple as possible, while giving you the most control and visibility we can. However, as with most Microsoft products, there are multiple ways to do something – and I’ve always found that to be a good strength. Depending on the situation, I might want a graphical interface, a command-line interface, or just an API so I can incorporate the management into my own tools, or have third-party companies write other tools.

While by no means exhaustive, I thought I might put together a quick list of a few tools you can use to manage and monitor Windows Azure components, from our IaaS, SaaS and PaaS offerings. Some of the products focus on one area more than another, but all are available today. I’ll try and maintain this list to keep it current, but make sure you check the date of this post’s update – if it’s more than six months old, it’s most likely out of date. Things move fast in the cloud.

The Windows Azure Management Portal

The primary tool for managing Windows Azure is our portal – most everything you need is there, from creating new services to querying a database. There are two versions as of this writing – a Silverlight client version, and a newer HTML5 version. The latter is being updated constantly to be in parity with the Silverlight client.

There’s a balance in this portal between simplicity and power – we’re following the “less is more” approach, with increasing levels of detail as you work through the portal rather than overwhelming you with a single, long “more is more” page.

You can find the Portal here: http://windowsazure.com (then click “Log In” and then “Portal”)

Windows Azure Management API

You can also use programming tools to either write your own interface, or simply provide management functions directly within your solution. You have two options – you can use the more universal REST API’s, which area bit more complex but work with any system that can write to them, or the more approachable .NET API calls in code.

You can find the reference for the API’s here: http://msdn.microsoft.com/en-us/library/windowsazure/ee460799.aspx

All Class Libraries, for each part of Windows Azure: http://msdn.microsoft.com/en-us/library/ee393295.aspx

PowerShell Command-lets

PowerShell is one of the most powerful scripting languages I’ve used with Windows – and it’s baked into all of our products. When you need to work with multiple servers, scripting is really the only way to go, and the Windows Azure PowerShell Command-Lets allow you to work across most any part of the platform – and can even be used within the services themselves. You can do everything with them from creating a new IaaS, PaaS or SaaS service, to controlling them and even working with security and more.

You can find more about the Command-Lets here: http://wappowershell.codeplex.com/documentation (older link, still works, will point you to the new ones as well)

We have command-line utilities for other operating systems as well: https://www.windowsazure.com/en-us/manage/downloads/

Video walkthrough of using the Command-Lets: http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-859T

System Center

System Center is actually a suite of graphical tools you can use to manage, deploy, control, monitor and tune software from Microsoft and even other platforms. This will be the primary tool we’ll recommend for managing a hybrid or contiguous management process – and as time goes on you’ll see more and more features put into System Center for the entire Windows Azure suite of products.

You can find the Management Pack and README for it here: http://www.microsoft.com/en-us/download/details.aspx?id=11324

SQL Server Management Studio / Data Tools / Visual Studio

SQL Server has two built-in management and development, and since Version 2008 R2, you can use them to manage Windows Azure Databases. Visual Studio also lets you connect to and manage portions of Windows Azure as well as Windows Azure Databases.

You can read more about Visual Studio here: http://msdn.microsoft.com/en-us/library/windowsazure/ee405484

You can read more about managing Windows Azure Subscriptions with Visual Studio here: http://fabriccontroller.net/blog/posts/manage-your-subscriptions-with-the-windows-azure-tools-for-visual-studio/

You can read more about the SQL tools here: http://msdn.microsoft.com/en-us/library/windowsazure/ee621784.aspx

Vendor-Provided Tools

Microsoft does not suggest or endorse a specific third-party product. We do, however, use them, and see lots of other customers use them. You can browse to these sites to learn more, and chat with their folks directly on how they support Windows Azure.

Cerebrata: Tools for managing from the command-line, graphical diagnostics, graphical storage management - http://www.cerebrata.com/

Quest Cloud Tools: Monitoring, Storage Management, and costing tools - http://communities.quest.com/community/cloud-tools

Paraleap: Monitoring tool - http://www.paraleap.com/AzureWatch

Cloudgraphs: Monitoring too - http://www.cloudgraphs.com/

Opstera: Monitoring for Windows Azure and a Scale-out pattern manager - http://www.opstera.com/products/Azureops/

Compuware: SaaS performance monitoring, load testing - http://www.compuware.com/application-performance-management/gomez-apm-products.html

SOASTA: Penetration and Security Testing - http://www.soasta.com/cloudtest/enterprise/

LoadStorm: Load-testing tool - http://loadstorm.com/windows-azure

New Relic: Application Monitoring - http://newrelic.com/azure

AppDynamics: Application Monitoring - http://www.appdynamics.com/azure.php

Manage Engine's Application Monitor: http://www.manageengine.com/products/applications_manager/windows-azure-monitoring.html

I ran across this blog entry that deals with storage clients - your mileage may vary, but he has some screen-shots and his impressions: http://cloud.dzone.com/articles/windows-azure-blob-storage

Open-Source Tools

This is probably the most specific set of tools, and the list I’ll have to maintain most often. Smaller projects have a way of coming and going, so I’ll try and make sure this list is current.

Windows Azure MMC: (I actually use this one a lot) http://wapmmc.codeplex.com/

Windows Azure Diagnostics Monitor: http://archive.msdn.microsoft.com/wazdmon

Azure Application Monitor: http://azuremonitor.codeplex.com/

Azure Web Log: http://www.xentrik.net/software/azure_web_log.html

Cloud Ninja:Multi-Tennant billing and performance monitor - http://cnmb.codeplex.com/

Cloud Samurai: Multi-Tennant Management- http://cloudsamurai.codeplex.com/

Azure Storage Explorer: Storage management - azurestorageexplorer.codeplex.com

If you have additions to this list, please post them as a comment and I’ll research and then add them. Thanks!

Rip and Replace or Extend and Embrace?

BuckWoody — Tue, 13 Sep 2011 11:20:05 GMT

As most of you know, I don’t like the term “cloud” very
much. It isn’t defined, which means it can be anything. I prefer “distributed
computing”, which is more technically accurate and describes what you’re doing
in more concrete terms.

So when you think about Windows and SQL Azure, you don’t
have to think about an entire product – you can use parts of the system
together or independently to accomplish what you need to do. You can use the
computing functions, storage, and more and more I see folks leverage the
Service Bus to enable current applications to expose things to the web.

And that brings up the point of this post. Once you decide
that a distributed architecture works to solve a problem, you’re faced with a
decision: should you completely re-write your architecture to take advantage of
the current systems or should you just fold in new code that makes the data or
function available to the web?

Of course, the answer is always “it depends” on the situation
– and it does. But unless you’re fixing a problem with current code, I usually
advocate a migration approach. That means at the very least retaining the
business logic (again, unless it’s not currently working) and as much of the
code as you can. In fact, if you follow this paradigm, you’re on your way to
making a Service Bus out of the functions you currently have. You can expose
the results of a system rather than opening the system up. Let’s take an
example.

Assume for a moment that you have an order-taking system
on-premise. That system performs many functions, one of which might creating a
Purchase Order. Your system might be enclosed, meaning that it has an
application that talks to a middle-tier, and then from there to a database
system. A query is generated from a screen, and passed along to eventually
compute, store and return a Purchase Order Number, along with other
information. Imagine now that you wire up the code not only to return the PO
number to the client, but to make that number available on an endpoint –
actually really not that hard to do.

Now you can make that PO number available to the web using
Azure. You could restrict who can make that call to the system, or open it up
to a broader audience. Or instead of the PO Number, you could make a product
list available. And you can go further than that – EBay, for instance, uses the
OData protocol (which is very cool in and of itself) which you can query from
the web. You could compare your company’s product catalog to what is on EBay,
and list the items you have there if there are no competitors in that space.
And on and on it goes.

So the point is this – where you can, retain what works.
Fold in systems like Azure where they make sense. Extend and Embrace.

Windows Azure Security Review

BuckWoody — Tue, 02 Aug 2011 13:24:50 GMT

Current as of 08/01/2011 - Check the Resources listed below for more up-to-date information on this topic

Background:

Security for any computing platform involves three primary areas:

Principals (users or programmatic access to an asset or other program)
Securables (objects, data or programs that can be accessed)
Channels (methods of access by Principals to Securables)

On-premise systems normally use a central system to control security. In a Windows operating system-based environment, this is often accomplished with Active Directory or other systems that provide sign-on and user identity information. While other networking security paradigms have different terminology, all involve the three areas defined above.

In addition to the names and passwords for a user, Active Directory (like other security mechanisms) store other information about Principals - called Claims. These claims can include any custom fields the provider allows. In many networks, these fields are not used heavily, because applications that eventually need to secure the assets they control are not always deployed on the same platforms everywhere.

In a single environment, security is often quite simple. A Principal is created such as a user or group, and then the Principal is granted access to a Securable such as a a folder, database or other asset. Permissions or Rights (or both) combine to allow a particular Principal to read, write, delete or edit data, or to access or run a particular program.

Figure 1 - On-premise security environment example

The simplicity of this arrangement is due to a single, homogenous boundary. Even if more than one location is used, the Principals and Securables are grouped into a single logical boundary that is managed from one location.

This background serves as the starting point for the Federating Security topic below.

Windows Azure Security Boundaries

Windows Azure is a series of resources - servers, data and service buses, in addition to other features. Developers write code, and the deploy that to the Azure environment.

Figure 2 - Azure Components

The code or data can be deployed to use one or more of the services. In other words, the Web Role in Windows Azure might host a simple website, and no other component need be used.

Figure 3 - Simple Azure Web Role Application - only one feature used

Or, a complex mix of Web, Worker and Data Services, along with a Service Bus, RDBS and even on-site systems can be grouped into a much larger program.

Figure 4 - Complex Windows and SQL Azure Application With Multiple Interactions

For a more basic introduction to Windows and SQL Azure, see this link: http://channel9.msdn.com/Events/TechEd/Europe/2010/COS322

Windows Azure, like any web-based property, has three general layers of security:

Physical Access
Operating Environment (Including the Operating System itself)
Data and Programmatic Security

Each of these layers have additional layers within themselves, and this forms the basis of a secure experience for the end user or program. Some of these layers are the responsibility of Microsoft; others are the responsibility of the architect and developer; others are a joint or shared responsibility of both Microsoft and the client.

Layer One: Physical Access

The first layer of security within a web property such as Windows or SQL Azure is a secure facility. the following data points are important to understand for the worldwide facilities that host Windows and SQL Azure:

Microsoft Global Foundation Services (GFS) is responsible for the physical security of the datacenters located worldwide for Windows and SQL Azure. Information on Microsoft datacenters can be found here: http://www.globalfoundationservices.com/
The address and exact locations facilities are not commonly documented for security reasons.
Microsoft runs it’s own data centers and does not contract this function out.
The GFS controlled facilities hold an ISO/IEC 27001:2005 certification, and are audited to SAS level II.
Standard secure operations protocols are in place, including least-privilege access.

Layer Two: Operating Environment

Windows Azure and SQL Azure do not currently hold certifications. Microsoft does not comment on the security certifications being pursued for Windows or SQL Azure. That being said, the Windows Azure environment is based on a modified Windows 2008 R2 Enterprise environment, developed using the Trustworthy Computing Initiative (TCI).

The system controlling the host machines and their guest environments that ultimately hold the Web and Worker Roles within Windows Azure is called the Fabric - not to be confused with the Application Fabric feature. The Fabric is not accessible by client code - it controls the inner workings of Windows Azure, including Load-balancing, system restarts, maintenance and monitoring.

Within the host machines that house the Web and Worker Roles, special networking constructs broker all conversations between Virtual Machines. Virtual Machines - even ones configured to communicate with each other - move through this network. Direct-machine to machine communication is not allowed, protecting one application from another or one data construct from another.

Figure 5 - Windows Azure Fabric

Windows and SQL Azure support only TCP-based communications. Ports commonly used are:

80 - Default public port used for Web Roles - can be enabled/disabled per configuration
443 - Default secure port used for Web roles - can be enabled/disabled per configuration
9350-9353 - These ports are used by the Windows Azure AppFabric service bus bindings. Refer to http://msdn.microsoft.com/en-us/library/ee732535.aspx for more details
1433 - SQL Azure
3389 - This port is used for RDP access to VM-based roles, only if enabled

Layer Three: Data and Programmatic Security

All internal access through use of keys only. Without the proper key, code or data will not transfer. Storage Accounts have individual keys, so in this manner different security layers may be applied not only programmatically but at the account layer.

Figure 6 - Windows Azure communications between components

Calls to Windows Azure are made using standard SOAP, XML or REST-based protocols. The communications channel can be encrypted between the client and Windows Azure or allow it to remain unencrypted based on security needs.

SQL Azure uses the standard SQL Server Tabular Data Stream (TDS) protocol, but only allows encrypted communications.

Data is unencrypted within Windows Azure Blob or Table Storage - but is only accessible via the key for a storage account. Data can be encrypted client-side and stored in Windows Azure in an encrypted fashion. Microsoft does not inspect internal data for validity or encryption enforcement. The key is that the data is client-side encrypted and decrypted.

Figure 7 - Example data at rest encryption scenario

Alternatively, a hybrid solution can store sensitive data locally and non-sensitive data in Azure Storage. The data can be coalesced at the client level such that the data is never transferred over any channel not owned or controlled by the organization.

Federating Security:

In the case of a single security boundary for Windows Azure, multiple security options are available. Users can be anonymously authorized, such as in the case of a public website for advertisement or informational purposes.

Another option is to create an Internet Information Services (IIS) Internal Security Store. This is not a best-practice (although still possible) approach since the Fabric services within Windows Azure may recycle an instance and the session may sever between a given role and a client. Architecting stateless applications is a preferred approach.

Using Claims-Based Authentication is a better solution. In this approach, the Principal is authenticated through a trusted party, such as Active Directory, OpenID, OpenAuthentication, or LiveID. Many web-properties use these methods, such as Microsoft, Google, Yahoo and Facebook to name a few. After authenticating with one of these services, the client is issued Claims using the WS-Federation (WS-Fed) or Security Assertion Markup Language (SAML) that are passed to Windows Azure. At no time does Windows Azure store, transfer or interrogate the Principal’s security token. Claims can be anything from a group or role membership to location or any other settable attribute. Assets are then secured allowing only the Claim, without regard to the user’s location or access method. In this fashion a single security paradigm covers the Securables, with the Principals being controlled in any number of other mechanisms. This allows single-sign-on and/or federated security access from multiple providers.

The simplest mechanism for building this environment is the Access Control Services (ACS) feature found in the Windows Azure Application Fabric component. It is a federated authorization management service that simplifies user access authorization across organizations and ID providers and performs claims transformation to map identities with access levels.

ACS can:

Create and manage scopes such as URLs
Create and manage claim types
Create and manage signing and encryption keys
Create and manage rules within an application scope
Chain claims rules
Manage permissions on scopes or perform delegation

Figure 8 - Federated Security Example

Full information on the Access Control Service is available at this link: http://social.technet.microsoft.com/wiki/contents/articles/windows-identity-foundation-wif-and-azure-appfabric-access-control-service-acs-survival-guide.aspx?wa=wsignin1.0

Since the Web and Worker Roles within Windows Azure are designed to be stateless, Microsoft created a Certification Store within the Management area to hold Certificates that can be called from within code. An example of using the Certification Store is here: http://blogs.msdn.com/b/jnak/archive/2010/01/29/installing-certificates-in-windows-azure-vms.aspx

Additional Resources:

Official, authoritative security resource list: http://msdn.microsoft.com/en-us/library/ff934690.aspx
Technical Overview of the Security Features in the Windows Azure Platform: http://www.microsoft.com/online/legal/?langid=en-us&docid=11.
Windows Azure Security Overview: http://www.globalfoundationservices.com/security/documents/WindowsAzureSecurityOverview1_0Aug2010.pdf
Windows Azure Privacy: http://www.microsoft.com/online/legal/?langid=en-us&docid=11
Securing Microsoft Cloud Infrastructure: http://www.globalfoundationservices.com/security/documents/SecuringtheMSCloudMay09.pdf.
A list of other security resources is here: http://blogs.msdn.com/b/buckwoody/archive/2010/12/07/windows-azure-learning-plan-security.aspx

Image Attribution: David Pallmann: http://davidpallmann.blogspot.com/2011/07/windows-azure-design-patterns-part-1.html

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 Components

BuckWoody — Tue, 19 Oct 2010 14:08:00 GMT

In a previous post I explained an overview of the storage options you have for Windows Azure. I’d like to pull back a bit today – because Windows Azure is often used as a single term, you might not be aware it actually is composed of three components. These components work together, but can also be used separately.

Windows Azure is a “Platform” – we hear that all the time. But what does that mean, really? It means you don’t have to install, manage, or care very much about the operating system and below. You write code, deploy it, and it runs. You can think of it like a Sandbox or Runtime. To do that, you have three main features you can code against.

The first is Windows Azure “Compute”. This is made up of two kinds of “Roles”. The first is a “Web Role”, which basically means ASP.NET. That’s just the delivery mechanism – within that you can write in languages like C#. The point is, a Web Role is the front end code, screens and so on that you expose to your users. The other Role is a “Worker Role”. This can use various languages as well, and is basically like the Windows Services or DLL’s you use today in typical .NET programming. Worker Roles are the programs that don’t have a front end to the user.

The second component (or feature) in Windows Azure is the Storage – which I explained in my earlier post. You have three types here – Blobs, which are like files, Tables, which are key-value-pair type storage, and Queues, which let Web Roles and Worker Roles communicate to each other.

The third component in Windows Azure is the Application Fabric. From a wide view, this component handles authentication (lots of options here) and transport – not only between Windows Azure applications, but even from servers in your four walls. In other words, you could take that large SQL Server or Oracle system and expose that to an Azure application, and you wouldn’t have to allow the users of the application into your network.

I’ll point back to this post from time to time as I explore each of these areas in more depth.