Search results matching tags 'SOA' and 'Cloud'

Preparation is key to a successful cloud deployment

BuckWoody — Tue, 01 May 2012 13:09:16 GMT

If you want to be wise, watch the actions and outcomes of others. Emulate the successful actions, and avoid the actions that cause failure. That’s true in life in general - and in technology projects in specific.

I’ve worked with several clients who have created or migrated an application to “the cloud” - meaning using Microsoft Windows Azure or another provider. Although the statement in the title of this post is trite, I cannot over-emphasize how accurate it is. In every case of those who had a great experience with a distributed computing environment (which is thankfully the vast majority of my projects),

What kind of preparation do you need to do? Here are some tips I’ve learned in the successful (and not-so-successful) deployments I’ve seen:

Follow standard recommendations for successful projects in general

You and your organization have probably done a few projects before - this one should have the same general attributes: a well-defined goal, a small, motivated team, a realistic timeline, and an adequate budget. I know, I know, you *never* seem to get those things - but if you don’t, you’ll fail. Simple as that.

Educate yourself

Computing technology started out on a single set of hardware for a single purpose - and realizing the limits of the hardware at hand, systems designers quickly realized that scale-out and virtualization was key. No, that’s not new - mainframes almost always worked on the concept of scale-out and virtual machines. But we switched in the 1980’s to single-user systems again, and we’ve been there ever since. By that I mean you install an OS on the things you work on. Now we move back to distributed system concepts, and there are some real differences. You’ll need to learn how those work, and do things a new way. Hey, we’re IT - we LOVE learning new things, right?

Get a partner if needed

There are a few of us white-haired Gandalf’s around that remember how to work in a distributed system, but if it’s new to you, that’s completely OK. You can save yourself a world of trouble by working with someone who’s done this before - a partner you hire, someone from Microsoft Consulting, whatever.

And don’t forget support - who will handle each issue, what is the escalation model, who are your contacts at Microsoft, and what is your “light’s out” strategy?

“A new broom sweeps clean”, the old adage goes, but the old brooms know where the dirt is.

Build a model

Take some time to do a Proof of Concept on your local system and using your Azure hours from your MSDN account if you have one. Going through this build - and being willing to throw it away and try it a different way - is invaluable.

Test your theories

Three statisticians are walking in a field. They see a rabbit - the first guy raises his gun, firing far in front of the rabbit. The second guy simultaneously raises his gun and fires far behind the rabbit. The third guy yells “We got him!”

Not every theory is correct - not every attempt is the right one. Build in your success tests while you’re building your model. Then check them - don’t leave this step out.

Rinse, lather, repeat

This is advice from a shampoo bottle - which I’ve never used (I don’t really have that much hair - especially now). But in a “Cloud” project, it’s important. It’s an evolving system, that gains new improvements at an amazing rate. As soon as you deploy and stabilize you need to start the process over again. If you created your system in a Services model, with contracts for the APIs and abstracted code, this is far easier.

It’s not hard to do a cloud project right. But it’s really simple to do it wrong. Follow these guidelines and you’ll learn from the successes - and mistakes - of others.

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 Use Case: Hybrid Applications

BuckWoody — Tue, 22 Feb 2011 19:44:09 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:

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