Tech - xCloud Architecture (Part 2): It's Elementary My Dear Developer

As I described in my earlier post, every component of the application needs to be in the cloud. Let's now get into the business of identifying the various cloud providers that we want to use. There are several factors to consider.

Litany of Choices

"When you see a web-based accounting system, the architecture of that system should scream accounting at you." - Uncle Bob. I am going to take a leaf from this quote. An application is always built to deliver a customer feature(s). And, almost always we will have constraints like time, cost, capabilities etc that we need to overcome. This forces us to prioritize the features, accept trade off's and focus on the most important aspects in the application. 

The constraints also help us take decisions on Build vs Buy vs Rent. The Build here refers to building a bespoke software, Buy is buying an off the shelf software and Rent is renting a software on the cloud. On a similar note -
  • Less critical feature of the application - use a SaaS. We could use a ready made service / product to deliver a feature.
  • Medium critical feature of the application - use a PaaS/IaaS. This is where some amount of customization is required to deliver a feature.
  • Highly critical feature of the application - use an PaaS/IaaS. This is where a bespoke service / product needs to be built. Possibly, we may want to build a feature that is unique or different from competition.
Note: Sometimes, I feel that the lines are blurring between IaaS/PaaS/SaaS. So, don't read too much into the definitions per-se, think of these as a set of guidelines.

Feature Map

A feature map is list of all the capabilities categorized in some sort of hierarchy. Analyse the feature map in the cloud providers. Look for some of the key aspects like -
  • Adherence to SOLID design principle, not necessarily from a code perspective but from a from a feature point of view.
  • Capabilities should be based on industry standards (like interfaces, messaging protocols, data formats etc.). This allows for easier integration and interoperability when you want to combine stuff.
  • Ease of customization or extensibility.
  • Developer tools, SDK's, guides, discussion forums and quality of support.
  • Where applicable, look for accreditation, certification (like ISO 27001 certificate).
  • Last but not the least - security, reliability and performance.


It is now almost given that systems should adopt a service oriented architecture (SOA). Services are the lynchpin of the xCloud Architecture. In this case alone, I am going to be a bit prescriptive.
  • Every feature/capability should be exposed through a web service. 
  • As much as possible, build them as fine grained services. Also, be prepared to build orchestration and aggregation services on top of these fine grained services.
  • To reap maximum benefits, build them as REST services. This will allow for use in a wide range of consuming applications like websites, mobile and anything else that you may think of. Ensure you version the services.
  • Ensure that these services endpoints are exposed by an API gateway, so that you can enable authentication at the least. In addition, you could also throttle the usage. 
  • Start with JSON as the data format for interaction with services. Use XML, if you must.
  • Use a provider model/pattern. This way each cloud provider is abstracted behind a service. Needless to say, all interactions are only through the service interfaces. 
  • When it comes to choice of languages, I would recommend the open source ones - Java, Python, Ruby & Javascript. Predominantly, all cloud providers have client SDK's for these languages. Some of them have for .Net too. Try to choose one or two languages as your base for programming. Incidentally, I chose Python and Javascript. 
In the next post, we will look at the approach and tools required.


Popular posts from this blog

Book Review - The Price of Being Fair

Cloudera Quick Start VM in Hyper-V

Meta Prompting for Success