Feasible Cloud Computing Architecture (and implementation)

“There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies
and the other is to make it so complicated that there are no obvious deficiencies.” — C A R Hoare

How very witty, true and simple. Perhaps we could just follow this witty but actually very crucial IT Systems advice.  Is IT that simple? Are we done here then ?

Well … perhaps not. I think, it is not that simple for the organization, to come to feasible Cloud Computing Architecture, also tailored for the  Enterprise.

Especially if the “one” is a large corporation or any kind of large institutions.  Any kind of IT enterprise which is currently severely exposed to myriad of mission critical but in the same time “deep legacy” systems. The kind of IT systems which are here to stay “forever” inside any given large organization today.

The really big issue hidden here is the one, we all dread and we all know is beneath:

Legacy systems are staying with us, “for good”.

All together with “legacy strategies”, vested interests and a such.

When faced with the Cloud marketing, “defenders of the legacy” (people and organizations)  will surely mix-in an additional requirement and difficulty: One Cloud is not Enough! Meaning: no single Cloud Computing Vendor can produce an SLA that can satisfy. Very often (or always) it is claimed that due to compliance and security requirements, (which are sometimes pure assumptions), one Cloud provider can not satisfy.

There and then, will mushroom all sorts of reasons (some less true, some more), where Security and Compliance are unbreakable and unquestionable, and they will always come firmly on top of the list of the reasons of actually not going for the Cloud. And remember: Legacy IT is not secure and not compliant.

Thus the added (non) critical decision to be made: Single or multiple Clouds, public or private or any combination of the two. Saas? PaaS? IaaS? None of which can deliver the ever elusive “full compliance”.
Should we just give up then? Not yet.

Enterprise Cloud Agnostic Architecture

Whoever tries to fly to the clouds will experience a long and deep dive, it the enterprise cloud agnostic architecture is not prepared in advance of investments.

I would like to think, I am an IT Architect. My favorite saying is:

“Where diplomacy stops I do the Architecture”.

I also do not advise “cloud vendor lock-in”. Let me try and evolve legacy defenders assumptions together with actual requirements. I shall try and transform them into valid requirements and then lastly into an inter-cloud IT architecture for enterprise. And yes: Safe and Compliant at that.

After all, do not expect a single cloud vendor to deliver an inter cloud architecture for you.

We shall start by using an ancient “lore”

Very simple, almost primordial, but very scale-able and robust architecture, an special variant of what was in those days called: client/server system, circa 1970 (gasp!):

Client Server MQ Fortified
Client Server Decoupled aka MQ Fortified

A bit of a legacy but still very nice, simple and resilient, is this not? Well … Believe it or not, this is not what most of the legacy systems are based on. This is in essence one “ancient” but proven, tried and tested architecture.  Here the key advantage is Decoupling of the Client and the Server.  The existence of that Message Queuing (MQ) infrastructure and concept, in the middle,  which is in turn based on communication paradigm for Asynchronous communication . (Anybody remember middle-ware ?) From that history, I do like the term “fire and forget” … which nicely depicts the desired relationship and thus behavior of a message sender, and message consumer.

FFwd to 2014,15 … 18 …

Today and to some of you, this might look almost identical to architecture of the usual IT marketing produced  “Slideware Architecture”.  Perhaps, but please observe the key difference. “Slideware Architecture” is where client and server are connected with an innocently looking single line on some  power point diagram, and nothing else. I can assure you the diagram above is very different to that.

Not having decoupled,  asynchronous, event driven communication was and is the key problem with every legacy client server system.  That is a true “ticking bomb”  in most legacy IT systems, in all large organizations today.  Here we are talking ancient IT Systems from those hazy days of CORBA, DCOM, Sockets, etc. Those happy times, when people imagined  OOD, OOA, OOP and Objects are the “final solution”. Implemented usually as early C++ objects/classes, that will “just talk” to each other, in a “locationally transparent manner” . Popular term from “Slideware Architectures” of 1980-es.

Alas, that “final solution” of course never worketh. First generation client server systems, immediately met the reality of complex (16 bit) networks, even more complex network appliances, and above all  (very) complex personalities of network administrators. Thus very quickly every twentieth century budding OO Architect realized:

Network is not a transparent resource.

It is impossible to keep things together, physically based “just” on LAN. However well managed LAN that is. And then enter: WAN.  Why not “just” use WAN? Short answer: WAN is, and always was, out of the question. The unquestionable and untouchable resource. Guarded by religious armies of before mentioned complex network admin personalities.

WAN is infrastructure foundation. You  do not design a functional buildings with infrastructure in the front. It is transparent and it just has to work.

Out of pure necessity, and very quickly sinking into this muddle-ware , some “enterprise” client/server Architectures, equally quickly found a firm foothold in a good old messaging concepts and infrastructure. And all of a sudden, all (seemingly) was good again.  (IBM) MQ has taken the pedestal (again). Not OOA or OOD or OOP, but system resilience became (again) more important than anything else.

Slightly before that “heroic period”, few other “clever people”, designed and implemented a concept of an network of asynchronous senders/receivers aka “nodes”, which network also had this magical ability to re-route around failed nodes. This later became ARPA net, which (rather quickly) became the foundation of what we simply call today “the Net” (where  www is a part of that).

The outcome is that event/driven asynchronous communication is today recognized as the only way to keep arbitrary set of nodes together as one heterogeneous distributed system (think Internet) . And message queuing (MQ) concepts pre-date all of that.

Concept maturity

This is the key. Concept maturity, which is not stopping me today to base all of my resilient architectures on messaging, as a concept. For example whenever I need a non-trivial (but feasible) solution , which is (of course) used by end users over a web, I do something (almost always) like this:


After all these years and all these projects, I am still amazed how much is such a simple concept as messaging, giving me. The ultimate resilience. Both in space and time. And of course the ultimate scalability. Without complex hardware, needed for allowing server clustering. I can (and will) simply add more web servers, if more is needed, that is.

Them servers will all PUT messages, on the same queue. And on the other side I will simply add more servers if required. They will all GET from that same queue. First come first served. And the opposite flow is handled the same way. All the back room server are PUT-ing on the same queue, and all the Web servers are GET-ing from the second queue.

Cllient to Service with MQ in the back
Client to Service+Resources; with  2 Queues in the middle

There you have it. In two evolutionary steps we have arrived to the resilient architecture of an modern “screen to cloud” IT solution.

Cloud? Yes that Cloud. Here is how.

Cloudification

I assume you dear reader are well versed in vagaries of IaaS, Paas and Saas. At least you where reading all of this until here.

Now. Instead of hiding the whole data centre side, in one cloud we will hide it in two clouds. With our bellowed MQ infrastructure (somewhere) in the middle. Why two clouds? Because of  the legitimate security requirements. Compliance requirements. And yes because of “legacy people” trying to stop the Cloudification :)

Thus we need the solution part, which is owned by organization, to stay inside that organization. Physically in its data-centre. Logically in its private cloud. Where “private Cloud” is ultimately a containerized instant Cloud parked in the courtyard.

Cloudification
Step One: Orange is Private and Blue is Public Cloud. Data is in the Orange Cloud.

And now that we have it, we can apply this architecture to address the requirements of every bank, or similar organization, which wants and needs to keep the core of its “hybrid” solution forever “inside”. In essence this is IaaS as a private solution and PaaS as a public hosted solution.

Here we have public cloud (cyan colored, on the left) to which users (aka customers) are connecting from their “screens” (aka browsers). This is a PaaS (in the cloud) which is optimized (by the Cloud vendor) to handle all the Internet issues. The huge number of users, scalability, security, HTTPS, and the rest. On the right we have a, rather smaller, but specialized and rather important private cloud (orange colored). And the MQ infrastructure between the two which again, gives ultimately resilient, controllable and manageable traffic between the two clouds. By the way, this is also a core of modern on-line banking solution.

One detail one devil, many details many devils

Devils are in the details, and this time these devilish details I am not going to leave as an proverbial exercise for the reader :)  How do I suggest this to be implemented? Up till now we have more or less, studied in the realm of logical or conceptual. I have described resilient hybrid-cloud architecture with messaging infrastructure in the middle. I think it is simple and robust.

But in reality this is just a hardware and platform. Installed and configured. What is missing is key application components to make this work, and do something useful for customers, using their web app’s on the client side. From here onwards, I will describe first key parts, of the architecture , I would put “on top” of this, So called Technical Architecture a.k.a. TA2.

The first one I will use is the concept of Messaging Service (MQS)1. Whereas we will encapsulate the messaging infrastructure inside (yet another) little cloud which will basically expose two service end-points : Put and Get.

Messaging Infrastructure exposed as a Service
Step Two: Messaging Infrastructure as a Service

This diagram mixes logical and physical, which I usually do not do, but still it nicely describes the role of MQ as a Service. It decouples and keeps the Messaging Infrastructure in the center of inter-server, inter-cloud resilient communication infrastructure, and in the same time allows us to abstract-away the existence of particular infrastructure, and all the other similar issues. Hint: Think Amazon SQS.

Thanks to this (almost) complete encapsulation and decoupling foundations, we can focus on the actual service functionality, on the logical level of the overall solution, so called Solution Architecture (SA). I have not mentioned SA until now because I knew in advance we do care how is MQ implemented. In SA in particular we are primarily interested how is messaging effectively used in communication between multiple senders and multiple receivers. But. How this SA works actually?