Today I attended a web seminar from Microsoft entitled “Pragmatic Patterns for Architects – Patterns for moving to the Cloud”, which was actually an introduction to approaches deploying applications into a cloud environment and related patterns. Here, for your enjoyment or argument, is a quick summary of that seminar.

There weren’t any particularly new cloud approaches/patterns mentioned in this seminar, but I really liked some of their visual models they used to describe the patterns and identifying key architectural issues. Azure was mentioned and referenced, but the seminar was largely agnostic about what cloud platform is being used.

The seminar covered 5 different "patterns" (really approaches) to bringing applications to the cloud. An underlying statement (which I disagree with) is that the cloud is only just about moving applications, not about special “cloud” applications. However, for the scenarios they described, the 5 patterns they talked about provided a good introduction to thinking about what it takes to move applications into the cloud.

The 5 patterns they described are:

1. Transference – Moving applications or services from in-premise operation to cloud operation for economic, consolidation, or prototyping purposes. This really is the simplest of the patterns, but only works when applications are generally stand-alone, with no major integration to on-premise services.
2. Scale & Multi-Tenancy – For this they described applications that are subjected to possible rapid growth (e.g. viral web site) that cannot be predicted. They indicated the primary driver for this approach is the economics of avoiding over capacity.
3. Burst Computing – This approach is also driven by the economics of avoiding over capacity.
4. Elastic Storage – The example they used for this approach was storing/sharing MRI images in healthcare, where data growth could occur exponentially. They described the economics for this being driven by storage management costs, not storage technology costs.
5. Inter-organization Communication – The example they used to describe this approach was a clinical trial applications, requiring a large and changing number of organizations to use the application. The primary driver they mentioned for this was the economics of infrastructure management.

The presenters did point out that these were only a “starting set of patterns”, not an exhaustive list.

What I liked in the presentation is the simple visual model they used to describe how the patterns are realized. It’s a almost typical stack model, only that model is used to indicate which components (and when) operate on-premise, in a hosted environment, or on the cloud.

One of their early examples was describing how using Security Token Services to provide brokered authentication services between a hosted app and an on-premise Active Directory server. (yes, the first example was not a cloud based application, just a service) Not surprisingly, the example revolved around hosted Exchange:

What was interesting here was their use of lines, color, callouts, and color animation to provide a clearer example of how this application operates and integrates across layers and across infrastructure/services providers.  In the image above, the red lines/outlines were part of a visual sequence of how authentication (or auth rejection) is accomplished in this model.

Transference

Their ‘takeaway’ for the Transference pattern was to watch for dependencies across different providers. In some cases (with legacy apps, I suspect many cases), the level of refitting or customization of an existing app may be too large to justify a move to the cloud.  However, I suspect this could be an opportunity to for CSC to build/provide services that make it easier to move legacy applications to the cloud while maintaining the illusion of direct integration to any remaining on-premise or hosted systems/components.

Scale/Multi-Tenancy

They made a point to describe this as the “opposite to the pattern of predicting the growth of a web site”.  The walked through an example (see diagram below) where the number of servers being allocated were easily configured (up or down) in the Azure app configuration file. (They did not provide any example of how this scaling could be done dynamically based on load.)

 

They did point out a key aspect of cloud that doesn’t get mentioned enough (except by Mark Masterson): You can turn off what you don’t need. Deprovisioning in the cloud is much easier and cost effective than trying to deal with unused hardware.

Burst Computing

For their Burst Computing pattern example, they got more Azure specific, where Azure supports the notion of "Worker Roles" for processing (ie batch or background processing). Users would never interact directly with these worker roles, but rather use the presentation (‘web role’) components to send/receive data. The data or commands would then be sent to/from the worker roles via tables or queues. Here’s the diagram they use to describe this setup, using a sample application “PrimeSolvr”.

I found it strange that they didn’t use the popular term “cloudbursting”. Someone have a trademark on that already?

Elastic Storage

With Elastic Storage, the described the common problems of file/DB storage & limits of on-premise storage growth, including the issue of server affinity of data. The examples they dived into were more about relatively independent data objects, such as blobs and simple tables. This reminded me of Greenblatt’s idea o
f Moby Address Space that came out many years ago (in my old Lisp Machine/Symbolics days)

In their "MRI Image" storage example, the described that the application (primarily front-ends) would need to take into consideration the access model ("code near" vs "code far" models– e.g. how to chunk the data appropriately for faster response and to avoid timeouts.)

They did allude to the availability of relational data structures in Azure through TDS – Tabular Data Streams; something I’ll have to look at more closely later.

Inter-Organizational Communications

The last pattern focused on applications that have a large or unpredictable number of organizations using & collaborating with a complex application.  Here they described an example (more of a pub/sub model) that uses the .NET Service Bus to route messages coming in from different orgs. They mentioned that this still required a polling model for notifying receivers. There doesn’t seem to be a formal ‘push’ mechanism with Azure yet (but I’m just guessing as I haven’t dived into Azure yet.)

 

In describing the workflow support in Azure, the presenters described the possibilities of hybrid models, where components of an application can be hosted across all three major infrastructure provider types.

 

The web seminar was hosted/presented by Microsoft’s Strategy & Architecture Council, part of Microsoft’s MSDN Architecture Center.

As this was an introductory seminar, they didn’t go into the many aspects/issues still being worked out with cloud computing (e.g. security, compliance, etc.) Still, it was a useful seminar (at least for me), particularly since it gave me some great ideas on how to visualize ‘cloud app’ architectures.  Unless you’re a guru already with Cloud systems, I recommend this seminar, the recording of which should be online soon (go to the SAC blog to find out when.)

Here’s a repost of something I wrote about 4 years ago. I think it still applies.

 

This is my first take at some thoughts on Architecture that have been swirling in my head for many years. Much of this comes from my experiences and the vast knowledge and wisdom of my many architecture friends & colleagues.

The ten deadly sins below summarize many of the common mistakes I’ve seen (and made) in system/software/application architecture over the past 20 years. These traps can be just as fatal as the typical software project management mistakes. The 10 are (by title):

1. Pursuing “Holy Grail” Architectures
2. Set in stone: Fixed Architecture
3. Materials-Free architecture
4. Architecture as first-order goal
5. Architecture by Edict
6. Spray-on architecture
7. “MIT Layer Syndrome”
8. One-size fits all
9. Instant Architecture
10. Pattern Madness

I’ll summarize each of these below and (if I get to it) try to post a more detailed essay on each. Actually, I’d love if others could chime in with their own experiences to support these sins, debunk them, or add new ones. Note that these sins are related to architecture, not just technology or software development.

1. Pursuing “Holy Grail” Architecture

I’ve seen many projects where the architect or designer is targeting a perfect architecture, an ideal state of design. Often this takes the form of a specific architectural target, such as Unlimited scalability, a perfectly abstract object design, a perfectly normalized database, or complete platform independence. Another form of this sin is complete focus on a single architectural design concept, such as Service-Oriented Architecture, or Thin-Client. (“If we implement SOA, we’ll have complete flexibility!”)

2. Set in Stone: Fixed Architecture

This one really annoys me: designing/implementing an architecture with the assumption that it will never change or need to change once deployed. Even worse are architects who assume their architecture design will not change (nor need to) throughout its implementation and deployment. Good Architecture must assume some aspects of change (if not accommodate change). Heck, even a building’s architecture changes over time. One of the best architects I’ve ever worked with describes system architecture more akin to landscaping (rather than building design), as the architects role is to design an evolving, living system.

3. Materials-Free architecture

Software architects love the abstract. Often this love is at the expense of reality. It’s easier to come up with a great architecture if you don’t have to consider the realities of the materials used to implement it. By not considering the building materials, you end up with conceptual great architectures that can still fail because of the materials, like the Titanic’s brittle hull plates. Architecture designs are only hypotheses until they are tested through actual systems.

Don’t, however, think that I’m proposing the opposite: that architecture is entirely driven by materials. Quite the contrary. Materials by themselves make for lousy (or accidental) architectures. It is good architecture design that enables the best use of the materials and build around their limitations. Moreover, architectural practices enable us to change the materials over time. Just don’t expect the architecture to overcome all limitations of the materials.

4. Architecture as first-order goal

Why does the system architecture exist? Unless you’re working with Grant money, it shouldn’t be the architecture itself. Too often architects make the architectural design the goal of the project, relegating the true goal to a secondary, if not lost, priority. Architecture is only a means to the goal – a working system for a shared purpose (usually involving making more money.) (e.g. SOA is not the goal.) If you don’t get this point, read (or listen) to the book The Goal.

5. Architecture by Edict

Pre-designed or pre-fabricated IT/App architectures (e.g. ERP, CRM products) aren’t necessarily a bad thing – if the trade-offs are thoroughly understood. However, too often architectural decisions are made and implemented by edict, rather than reasoning. (This sometime goes together with sin #4). Most of us know of CIOs that have said “we’re going to use ____ to solve our problem”, and then leave the architect or IT staff to perform superhuman acts to actually make it work (and – unfortunately – often do make it work, leading the CIO to think she/he has made the right decision.) With basic technology platform choices, such as J2EE vs. .NET, it may be fine (both can work.) However, simply deciding on an architecture, or worse, core software product, before understanding the business and architecture requirements usually leads to disaster.

6. Spray-on architecture

One of many gems of architecture wisdom it learned from Lynne Whitehorn-Umphres is that you can’t just add architecture after the fact, which she referred to taking “Spray-on” approach (Refactoring can help, but can’t solve fundamental architectural problems.) Scalability, Security, and many core architectural design stances must be addressed early rather than later.

7. “MIT Layer Syndrome”

Over 15 years ago, Bachman Information Systems developers (actually one from MIT) had to design a graphic UI/Window system from scratch in LISP (running in MS-DOS). Too achieve maximum flexibility, it was designed with a large number of abstraction layers (e.g. bitblt, rendering, drawing, shapes, window, canvas, feltboard, etc.) A well designed system with abysmal runtime performance. Abstraction layers are important architectural constructs. There’s a danger, however, of the seductive nature of these layers – they make architecture look/sound better than they actually turn out to be. Joel Splosky has a good writeup on this issue. (Note: As David Krieger once pointed out, all software is based on abstraction. The only real things are valent electrons flowing through silicon – everything else (OS, Apps, architecture) is a set of structured illusions that make systems ‘work’).

8. One-size fits all

Thin Client. Yeah, right. ’nuff said.

9. Instant Architecture

EAI, XML, BPM, SOA, etc. – All you need is one architecture. Or better yet, how about one platform or product? Anyone remember Broadvision? How about your investment in CORBA? Simply buying an ‘architecture’ is not enough, sometimes downright wrong. If you do by a set of architectural practices and implementations, know what you’re getting into. Here’s the basic trade-off: get a basic architecture platform (e.g. J2EE, .NET) and you’ll have to build on top of it. Or, get a pre-build ‘instant’ architecture (e.g. ERP, BPM pure-play) and live with the architectural choices of the vendor (or the death of the vendor).

10. Pattern Madness

I’m still trying to work this one out. Patterns have been around for a long time, but there’s been more interest in patterns recently (read: last 5 years). What I’ve seen in some cases is that some architects equate architecture with patterns. Simply apply a generous amount of Sun Blueprints and, voila!, they expect to have an architecture. Good architectural designs use patterns, but patterns do not themselves make an architecture.