THE EUROPEAN CONSOLIDATION BOARD


                                      European Consolidation Board for Foreign Industry (ECBFI)

MEASURING THE RIGHT CLOUD PERFORMANCE FOR YOUR BUSINESS NEEDS AND SECURITY COMPLIANCE

 Although there are multitudes of definitions out there, I think it would be safe to define, “Cloud Computing”, as a logical group of computational resources optimized and automated in a multi tenant model to provide scalability, reliability, redundancy and availability.

Cloud Computing, TLA’s (Three Letter Acronyms) are out of the window, we are moving towards Four and Five Letter Acronyms. If you have ever heard or spoken about Cloud Computing, you would have used the words like
  • IaaS (Infrastructure as a Service)
  • PaaS (Platform as a Service)
  • SaaS (Software as a Service)
  • SAaaS (Software Architecture as a Service)
These days, you can take any good old IT terminology, add “aaS” and call it Cloud Computing. (At this point, I just could not help but notice how that word ‘aaS’ sounds. Get the pun?). Any case, since Cloud Computing is the new way of IT, every one wants a piece of it. In the next section, we will try to see the cloud evolution.
 
For those who think that cloud is some form of a new technology, I will have to disappoint you, because it is not. Cloud is a logical evolution of IT. Trying to draw an analogy, let me take you back in time, when the only way you could send data was by purchasing “Leased Lines”. Since those were owned by the company, they could use them at any time and to the extent the data pipe would allow them, but then it was expensive, so the Telco used a concept well known to us, “Over Subscription”. Frame Relay came into existence, so did ATM. When the POP (Points of Presence) of the Telco providers started becoming the cost centres and they needed security and reusability, or virtualization to another degree, MPLS came in to existence.
On the compute side as well, we have seen Virtualization. When, we saw that on an average a physical compute power was only used about 5-10%, we decided to use hypervisors and make one physical box work as multiple virtual boxes, this evolved as Virtual Data Centres. The whole abstraction phenomenon has turned out to be very profitable, for both Corporates (In terms of Cost Saving) and the earth (In terms of lessening the Carbon footprint). 
 
We have also seen that the code is so written that it centralises management and the necessity of the compute power and hence have seen an increase in the Web Applications, which follows the cloud server models.
So moving naturally in the same line of sight, you see that what we call “Cloud” today is just the next level of abstraction in the same sense.
 

ECBFI (European Consolidation) Cloud Standards:


If you are thinking, why the hell did I put this pic here, I will answer the question momentarily. As beautiful and awe inspiring the above picture looks, I would like to shift your attention to Why? The reasons are, there are various clouds in the Sky and each one of them is different. That’s the key, if we have to keep them beautiful and functional; they need to be different and much rather customized to the environment where they will be raining (In our case providing services).
With that opening statement, I think it will be safe to tell that there cannot be single standard in the space of the cloud and hence, that makes it a vast expanse to tread into. In the future there can be standards around some pieces of the cloud, but not the cloud itself. In the absence of such standards, there needs to be a lot of Custom work that needs to go in. In the upcoming topics, we will see the architecture blocks and we will also comment there about the gears that need to be put into place to make them work together.
 

Cloud Architecture:

Here comes the big one (where we can have a lot of arguments float in), the architecture of the cloud. After we have gone through the above understanding, I think, we can safely say that we can treat the fact that “Cloud” can be considered as a Layered Architecture and some people only willing to implement some of those layers. It is also imperative for us to understand that though the layers work or need to work independently of one another in lot of senses, each layer provides services to the layer over it. Consider it like the OSI model or TCP/IP Stack. Though the focus was that each layer work independently, but that was too much hassle for technology to take care of and so a lot of functions “bleed” into other layers as well. We can safely assume that this will happen with the cloud as well and be prepared to it.
image
I am sure the above is a very quick and a shallow way of representing the layers, but they do drive home a broad view of what layer sits on top of whom. Having said the above, in the cloud, the layers have a few sub components.
 
image
 
When looking at providing the service on the Platform space, we can still detail the block diagram to a few more levels and then each block in itself will have an implementation diagram, so on and so forth. Since this blog is only for the high level understanding and choosing a route to the cloud, we wont get into Nitti gritty of the things.
In the below diagram, I have broken down the infra to show some building blocks of the 2 Layers that we will implement, if we need to implement the PaaS architecture.
image
Read more from the ECBFI on frequently asked questions regarding The Cloud - Click Here