I read a lot of articles on technology and it always amazes me the degree of heated debate that goes on in the blogosphere, social media and elsewhere over simple definitions.  What caught my attention today was the number of posts and comments on Twitter about what was or was not Cloud.

So the question is: What is Cloud?

The reality is there is no agreement on this point, so I offer up my own view on this matter for debate.  Feel free to flame away.

The Paul Michaud Definition of Cloud Computing
Any application which can be deployed and scaled (preferably dynamically) against a, potentially globally, distributed cluster of, homogeneous or heterogeneous, compute resources is a Cloud based application.

So what’s my point?  The point is that almost anything is potentially Cloud based by that definition.  Let’s look at some examples that were being tossed about today on Twitter and the Blogosphere.

They were:

• JPMC’s internal server cluster
• Google’s Cluster
• Facebook’s Clusters

James Watters in his “Not So Fast Public Cloud: Big Players Still Run Privately” contends that’s JPMC’s cluster of servers represent an internal Cloud.  James then took some heat from others claiming that a dedicated internal cluster is not Cloud.  The argument then extended to bring in Google and the argument was that it is also a dedicated internal cluster and not cloud, but that Facebooks cluster is a Cloud because they openly admitted to using Hadoop to some extent.

For the record, I think this whole Internal Cluster/ External Cloud debate is all nonsense.  To be honest all of the systems listed above are Cloud in my opinion.  All of them allow for dynamic deployment of processing load against a distributed cluster of compute resources.  From the perspective of the company owning the cluster, its an Internal Cloud.  Once they open it up by providing a public interface into those resources, then its a public cloud resource from the standpoint of an external user of those resources.

Cloud is not the sole property of our latest Web 2.0 startups.  It’s not a function of some particular piece of software that we collectively decide is “Cloud” like Hadoop.  Cloud is a design pattern and a business choice to allow us to take advantage of vast compute resources of all kinds in a more dynamic, efficient and cost effective manner, period.  Furthermore, to effectively use Cloud resources I think you ideally need to be SOA.

Let the Flaming begin.

This is the first in a series of articles on Service Oriented Architecture (SOA) that I will be doing over the coming weeks.  Given that every middleware vendor defines SOA differently and every Systems Architect seems to have their own definitions for various aspects of an SOA, I am going to use this first article to present a sample of what I personally think an SOA stack should be comprised of and I will define the major components using a set of consistent terminology that I will use in the coming articles.  I will focus on the technical part of the stack and not items such as Governance (which I personally feel a lack of is one of the major causes for SOA project failure in large corporations), Infrastructure, etc.  We can discuss those in future articles.

So for most of you who have done some rigorous SOA, I apologize in advance for the SOA 101 Tutorial, but I am always amazed at how much people define the pieces of an SOA (or anything else architecture wise) differently, so this next section is purely to provide us with a common set of definitions on which to base further discussion.

Lets look at the following stack which depicts the typical application stack for a single service component.

A Simple SOA Stack

So what are the main parts to this stack, and what is their role.

Service Component:
This is the true heart of the SOA (not the service interfaces which most people focus on).  The Service Component is that logical unit of code which implements the functionality to support the Service.  The Service Component exposes one or more Services.  A Service Component (at least a foundational one, which I will define shortly) is also usually associated with a data store of some kind.  This can contain data about a fundamental data type (defined below), control data, process, data, etc depending on the nature of the particular service component.

Service:
The Service is a public interface which is exposed by a Service Component.  It can be exposed in a wide array of protocols and need not be just SOAP Web Services.  In fact I will argue that even 20 years ago, that good systems were designed as SOA even though we exposed Services on a socket.

Legacy System Adapter:
It is my personal opinion that any time a Service Component needs to interface to a legacy system, that an Adapter Pattern should be used.  This Adapter performs a number of tasks.  Its primary function is to convert to/from data formats spoken by the legacy system and the common data formats used by the Foundational Service Components.  In order to perform the conversions, it may be necessary for an adapter to interface with many Service Components in order to perform data enrichment or break data apart into its fundamental data types.

Enterprise Service Bus:
Its common for people to use an ESB, at least on paper.  The definition of the ESB is a bit amorphous in my opinion.  Many middleware vendors will tell you that the ESB contains everything including the kitchen sink functionality wise or else it’s not an ESB.  Typically people expect the ESB to provide abstraction, dynamic content based routing, optionally process choreography, Security and a boat load of other features.  Personally, if I am going to use an ESB at all, its most likely not much more than an ultrafast messaging layer with none of these bells and whistles, but that is more a function of the fact that most of what I build needs to be ultra high performance (systems capable of millions of transactions per second with response times as low as 20 microseconds, so no room for overhead).

Application:

So no surprise here.  On top of it all is an Application.  An Application is going to combine the functionality which is exposed by many Service Components.  More importantly, if and only if, the SOA is done well, then many Applications can aggregate the functionality provided through the Services, by those same Service Components to meet completely different end user requirements, without change to any component, except those which need to support a specific process or function for a specific Application.  This should be the goal of any SOA.

Here is one more diagram to consider.

Layering Service Components

In this diagram I am going to contend that the Role Service Component and the Party Service Component are what I will call Foundational Service Components and that the Customer Service Component is a Composite Service Component.

Foundational Service Component:
I am going to define this in a controversial manner.  I am going to content that a Foundational Service Component has one and only one job and that is to support all actions related to a Fundamental Data Type.  So in the case of the Party Service Component it’s job is to provide a Service interface and a supporting implementation in the Component which allows a user to Create, Read, Update and Delete Party Data.  That’s all it should do

Fundamental Data Type:
A Fundamental Data Type is a basic data type, or business object which is typically common across a wide array of applications.

Composite Service Component:
A Composite Service Component is a component which combines the functionality of one or more other Foundational or Composite Service Components.  It may also encapsulate additional functional and data enrichment, business process, etc. In some cases, a Composite Service Component may be purpose built to support one and only one business process or application, where it makes sense to encapsulate a piece of reusable functionality on the server side instead of in the application.

Well this ends our discussion of the basic Anatomy of an SOA.  For those who made it to the end without their brain dripping from their ears, I congratulate you.

Now that we have this common framework and terminology, the next topic will be about “The Importance of Enterprise Data Modeling for Service Oriented Architecture”, and will discuss why starting with the service definition without having identified the Fundamental Data Types or the Foundational Service Components leads to an SOA with little to no reusability.

Over the last few decades, the technologies we used and the approaches we took to make our systems reliable have undergone a steady evolution. In some cases the technology has just gotten more reliable through quality control at the hardware level (consider an Intel Blade today compared to my 1986 Zenith 8088 that I wrote my first automated trading programs on. Hard to believe 8MHz, 2×5.25″ floppy’s and 512K of RAM was once the best machine money could buy, short of a mainframe. AHH.. the nostalgia……NOT)

For most of the time pre mid 90′s we relied on hardware to make our systems reliable. We had mainframes for most things business critical and towards the latter part of that time, the Unix machines were starting to be taken seriously by business as well as the scientific community. Regardless of whether you used Tandem Non-Stop technology, IBM Series 3X0′s or Stratus, you relied on the hardware to be fault tolerant and to just stay up. And for the most part they did, but at great cost and with relatively poor price/performance compared to the other platforms that were becoming available. Coupled with this resilient hardware we would have typically 2 data centers (and sometime 3) with essentially identical hardware for disaster recovery. Two of these centers were usually less than 30 miles apart and the data was synchronized between them again using hardware, with technology such as EMC’s SAN replication technology. In fact a lot of systems still do this today where performance and latency in the systems response time is not critical. Although post 9/11 the SEC mandated financial firms to have their DR site 300 miles apart which means this SAN replication approach cannot be used for most new systems as it’s distance limited. Most other countries followed the SEC’s lead (Do you know how hard it is to find site’s 300 km apart in Switzerland and still be within Switzerland, because Swiss data (depending on the data type) can’t be stored or transmitted outside of Switzerland, which is something for SaaS vendors to keep in mind. Well you can’t so we cheat. Usually one in Zurich and one in Lugano which is as good as you can do.)

By the mid 90′s though we were starting to use more UNIX machines. SUN Sparc Systems, IBM R6000′s and HP-UX machines were coming on strong. Their hardware was better than a typical Intel desktop at the time but it still didn’t have the 9′s of uptime that a mainframe had. Now for stateless applications such as those that were emerging on the web, we could throw an IP sprayer or Load balancer, such as the BIG-IP product line by F5, in front of a hot-hot pair and be pretty good to go. This is still the best way to achieve HA for most stateless applications today, but I digress. So in order to assure reliability, and for this era we defined that mostly as no loss of data more so than sheer system uptime, we had to do more with software to provide that reliability.

This software augmentation centered around two primary software technologies.

• Messaging Middleware such as IBM’s MQ, Tibco EMS and Rendevous
• Databases such as DB2, Oracle, Sybase and Informix

Well I won’t spend to much time on how we used these technologies back 10 years ago, because to be honest it really hasn’t changed much up to today. With the messaging software, we moved from a world in which all inter-process communication happened over a raw socket, to instead using messaging middleware, which removed the burden for message reliability from the programmer. No longer did we have to implement transactional semantics in every application by hand. We could instead rely on the middleware to make sure the messages got from point A to point B. Today we use IBM MQ to handle every message for virtually every trade of US treasuries, Eurobonds, Stocks, etc in the world. We can rely on it to deliver messages of any size from one application to another, even if one of the machines goes down and doesn’t come back online for weeks, MQ ensures it gets delivered. (Hopefully, being down for weeks doesn’t actually ever happen in production, but the guys at IBM’s Hursley labs due test these things.)  Now I will say, we don’t use TIBCO, or MQ when low latency and very high throughput are required.  There is a new breed of messaging technologies out recently which are prefered and I will touch on some of them in coming articles.

With the databases, we moved all of the transactional abilities we knew and loved off the mainframes and onto the distributed platforms. In addition, the database companies implemented ways to run the databases in a cluster. This meant that if the database server failed, I would in theory, with a slight pause, fail over to the backup, with no intervention on the part of my application. Now in practice this took a few missteps to get right but today is old hat and everyone relies on the big commercial databases to be able to do this. Some of the open source ones are not so strong here as their paid for counterparts, but in time we will probably see this happen as well.

So this brings us pretty much up to today’s state of the world (or atleast a few years ago for a typical enterprise application) in a very Cliff’s Notes sort of summary. In the next article we will start a hypothetical design exercise as a way to ground the discussions going forward. This hypothetical will form the basis of the next few articles to come after it.

With all of the talk about reliability, or lack thereof, of SaaS and Cloud based applications, I thought I would write a series on designing applications to be Resilient and Highly Available.  The series sort of started with this post “It’s Inadequate Design That Lets Systems Fail, Not Whether They Are SaaS or Deployed in The Cloud“.

As any of you who have read my Bio are aware, I have spent most of my career designing very large, high volume and high performance applications for the World’s largest financial institutions.  In these systems High Availability and Reliability is Key, as systems I have been involved in designing carry Trillions of dollars of transactions on them each day.  Also in the Financial Markets world, and down time can cost millions of dollars per minute. We have also been center stage in the evolution of technology and design best practice when it comes to performance and reliability.  We have gone from just using a robust mainframe and assuming it stays up with hot swap hardware to high performance distributed applications handling millions of transactions per second in statefull applications (much harder to make HA than stateless Web apps), where time from failure to detection and takeover by a hot standby can be as little at 7 milliseconds.

The articles which will follow in this series will represent my personal opinion on how this is done.  It is by no means the only way to do it and I am sure others will clearly have other opinions.

Topic’s will tentatively the following:

1. The Evolution Of Reliability and High Availability
2. Guaranteeing No Loss Of Data
3. Designing For Disaster Recovery
4. Designing For Maximum Uptime In A Distributed World
5. High Availability in a High Volume Transactional Environment

Other topics will be considered based on feedback, user requests or if something just pops into my head.  So if you have a particular question or topic you would like answered just ask and if it is something I feel I can write about, I will.

We will start in the next article in the series with a brief discussion of The Evolution Of Reliability and High Availability.