Cloud Computing …. Designing a Private Cloud

Sorry folks, sorry for not being able to update my blog for a long time. I have been working on designing Cloud based solutions for Private Cloud. So, I thought, I will share some insight here. I am writing this with the perception that the readers have no or very little knowledge about the Cloud computing, so please forgive me if at certain places I point the obvious. Hope, you like the entry and let me know your views in the comments section.

Introduction:

Cloud Computing is the recent buzz word in the IT industry, but as the name, it also does not have a clear or well defined standards or structure or even capability matrix. As a result, it is also the most abused word in the IT industry. With all the jargon out there, it becomes pretty confusing. I attempt to give an insight in all of those. The document is majorly on PaaS (Plat form as a Service)

 

What is Cloud Computing:

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.

 

Time to welcome FLA’s:

Its funny that I say this, but with 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.

 

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 centers 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 Centers. 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). Yes, we IT people are environment friendly too  

We have also seen that the code is so written that it centralizes 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.

 

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.

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.

 

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.

Having said the above, we have will see the questions that we need to ask ourselves before we start doing any work on the pieces of the puzzle.

 

Questionnaire (Pre Design) :

In the below, we can see we have

• What is my expectancy from the cloud?
  • We will only have to focus on providing the services to the applications, what the applications do is not going to be controlled. So the questions, that whether or not the application is bloated, mobile ready, will not be covered. We how ever have to design in a way that if the application is mobile ready, does my underlying infra supports it. Similarly, the design will have to take into consideration the Elasticity of the Cloud.
• What Platforms do we provide as a Service?
  • Essentially, “All” cannot be a good answer in the beginning, going by the 80-20 rule, we will have to pickup the platforms which are used 80% of the times. We can add other Platforms to our belt as we go, and for the platforms which are not used much, we will have very little difference.
• Using Current Infrastructure?
  • A lot of vendors there are pushing for new infrastructure to be bought for the cloud deployment, we need to evaluate how to currently use our current infrastructure and make cloud possible, or do we have to go for the new infrastructure.
• What is my Current approach for providing Platform?
  • This essentially provides the current way, we do platform, this should answer questions like, do I run different Virtual servers for different applications, or we run multiple instances of the application on the same Virtual Server
• What should be my new approach?
  • Again the same questions, but what can we do to optimize that. TBD can be a good answer, if we want to do PoC on all the ones we think we should try.
• Does my Application require PCI / Sabers Oxley Compliance?
  • In most organizations this is a Key factor, and maintaining this might be key for our customers and third parties for business reasons, this will also dictate the placement of services in the network in physical and logical sense.
• Current and New application architecture?
  • In this we need to look at the current landscape of the Applications, e.g. which applications have what platforms and Why?
  • What coding architecture is used, including IDE’s and the development environment?
  • What do we intend to do in the future, do we continue the same way, if not, what tweaking can come in.
• What are my ITIL standards today & tomorrow?
  • We cannot kick out ITIL in most cases, so, how do we incorporate the Change Management and Incident Management process out of the window, how do I incorporate them in my automation.
  • We also have to touch base on, since there is an abstraction, the people using our services will not be worried about the underlying pieces, but we will, how the “Cloud Operations” team will manage the cloud.
• SLA’s?
  • We will have to do a deep dive in this. Since this is cloud, our typical SLA’s will be based on Business Restore and not the actual problem restoration. We will have to build another internal SLA for us to fix the problem from the root.
• Supportability
  • We will have to look at how supportable are the blocks that we choose for the implementation and how much “finger pointing” are we going to have in our environment, work around those.
• Use Public Clouds?
  • Again, this question is one which depends on a lot of prior questions with regards to compliance and such. So what part of the application can we take to the public cloud and what cannot be taken.
  • Will I be using federation, if we go to the Public Cloud, so on and so forth.
  • Can we have the development instances in the Public Cloud.

Having asked ourselves this question, we can actually start choosing the options that we need to build a cloud. One thing we need to keep in mind, that there will be many moving pieces and we might have to end up writing some code ourselves to make this gel together.

Journey of an Platform to the Cloud:

I figured, that rather than just posing some questions, it will be a good idea to take a Platform of a well defined industry standard and look at our choices, as this might help answer some of our questions.

 

The Platform:

Here we will take standard “3-Tier” application architecture The Architecture is used in most of the companies that need to run with PCI/SOX compliance standards. The entity, I have not shown in the diagram is the Load balancer, as they may or may not be available in all the tiers.

 

Now, the Logical interconnects of the application are clear. Let us make some assumptions.
 Web Based Application
 Application Server is Java
 Database is Oracle
 The Database servers have Locally connected storage and connectivity to LUN’s
Now making these assumptions, and keeping the status quo of the application in terms of compliance, the Web-Tier is the only tier that can be moved to the cloud. In most cases, we may not have full blown 3-Tier architecture and we may collapse the Web and Application tier, in which case, we can have the Application tier moved to the Public cloud, you get the picture. If we don’t have to go ahead with the compliance, the whole data can be on a Public Cloud

The Strategies:

The cloud buzz word comes with jargon like, Public, Private, Hybrid, Community, etc. We will look at a few of the strategies and the Pros and Cons of each.

Public:

Move the application and Database to the service provider (Rackspace/Amazon, Cloud.com) and let the complete application sit there.

Pros:

• Easy
• No effort needed from our End other than some process changes
• Scalable

Cons

• Non Compliant with PCI/SOX standards
• Cannot be modified much, SLA’s might not wet too well.
• No Insight of resources.
• Cannot reuse the infra already in place.
• Expensive in the Long run. (e.g. Zynga, a games company used Amazon(AWS) for a while, then they decided to move to a completely private cloud of their own to save some money, while using Amazon(AWS) as backup)

Recommended Use:

We can use the public cloud as a Development Platform, so the developers can benefit from there and we can remove the Dev Infrastructure and repurpose them as Production / QA. We will have to enforce strict policies for the access and set control points, so we don’t end up spending more than needed on the Public Cloud.

Private:

In this, we create our own cloud, by pooling resources and having an orchestration engine which can be designed as per our own needs and standards (This is actually the key player here). The orchestration engine may be a single or a multi component engine, this will point to the pools and do the allocation of the resources as we see fit.

Pros:

• We can design the Cloud as our needs and re use the current infra already in place
• The Orchestration can be controlled by process and ITIL standards can be up kept
• Status Quo of Compliance will remain.
• Physical & Logical separation is possible. Deep inspection of traffic is possible.

Cons:

• Have to manage the Infra
• Need to design the cloud strategy from ground up
• Expensive for small number of resources.

Recommended Use:

This is recommended for most of the enterprises, where they already have a lot of Infra which can be re used. Also, the applications which carry sensitive data, will suffer no loss of status quo. The applications, which need complete privacy, can be pushed here without any issues.

Hybrid Cloud:

This is when part of our application stays inside and part of it goes to the public cloud. This is especially helpful when we need application that need bursting capability in network and/or compute power. The Pro’s and Cons of this are determined by the design.

Recommended Usage:

As mentioned earlier, this is recommended for applications that need unpredictable burst ability. The orchestration engine will play a key in this kind of a deployment.

 

Vendors and Products:

I am just going to enumerate some vendors here, which might help you in looking at their offering.

• VMWare: Virtualization, Orchestration of VMWare using vCloud
• RightScale: Orchestration of Compute (Virtual Servers) across multiple clouds
• Cloud.com: Stack to build compute resources.
• Openstack, Open Nebula, Eucalyptus : All open cloud orchestration engines (Eucalyptus also has an enterprise offering)
• Amazon EC2: Originally targeted as IaaS, but with custom AMI’s and orchestration can be very well be used as PaaS
• cloudfoundry.com – A commercial offering is yet to come out, but you can use this for the vFabric type PaaS offering
• HPSA/BMC: Orchestration
• vBlock: Virtualization and Orchestration of Compute resources
• Abiquo: Orchestration of Compute resources
• vFabric: Light weight, easily deployable components of Platform.
• Azure: IaaS/PaaS, Cloud in a Box, orchestration of compute resources.
• ExaLogic: Cloud in a box, and supports Open source

 

Conclusion:

There is lot more to be said (I will save them for the future blogs), As we can already see that the perfect cloud is far from achievable, we have to set our goals and take steps however small it may be, to achieve it. The good news is that cloud is supposed to be architected as modular, so there will be no flip switch to get this done.

Hope you liked the blog and if you have some points to add, feel free to comment and I will modify the blog accordingly.