Saturday 3 March 2012

Architecting the Private Cloud

 

Private Cloud is next most abused term in current times after SOA. When we get into a conversation with CIO “ lets move onto private cloud” the prompt response comes in lets have a hypervisor and orchestrator and we are done, be it Cisco, VMware, MSFT they all talk the same jargon. I’d like to differ from the standard jargon take a step back. I have written this post based on actual customer interaction I have followed this process. The flow of the article goes from questioning your customer,  the steps involved in architecting private cloud, putting your learnt knowledge to use an example. This article is simple to read chill on…..

Gaining Clarity by Precision Questioning

First and foremost I would ask some questions to the customer just to understand the context correct & get the conversation going in the right direction

1. What do expect to obtain from a private cloud? Some responses that are typical I need resiliency, the current disaster recovery data center is dysfunctional. From this conversation one gets to understand which key attributes have decided to push the conversation of a private cloud & at the same you get to understand there is an indeed business problem.

2.What happens to your IT organization when you deploy a private cloud? Obviously the response is “ haven’t thought about that”. Dwelling deeper into this one would probably get an idea what kind of skepticism is one going to be met with,and what are probable impediments at an early stage and a later stage from an organizational dynamics stand point.

3.Does Investment = Efficiency “What are the steps to IT efficiency” This question is not intended to be around Quality of Services it more around efficiency of IT once it moves to private cloud , some typical  responses are “ does it mean buying new piece of software or getting additional trained resources on private cloud”.

4. Do you think Virtualization = Private Cloud? This is one question where most responses are Yes and we get an idea how much of real education on cloud has the customer had or some marketing pitch from MSFT  or VMware has been there.

5. Does Automation = Efficiency? Define services first or automate first?  This is a tricky question there is no straightforward answer to this some customer may end saying automate first test and some may say I want to build the catalog of services first then automate then either of the approaches are fine

6. When a user selects one more .. what happens? Typical example is I need one more SAP connection in your private cloud what happens is it expected that private cloud will auto provision and hand over the service request in matter of minutes or well it take longer “like I may need order more hardware for every 10 additional SAP connection”. In short we need to get a definition of the service unit what is this one more. There is equal responsibility on the end-user requesting and and the data center sufficing this request, the user is aware there is a cost attached to in terms of compute, storage & network.

7.Does a central console give your application depth end to end monitoring?

Understanding & Drafting The Private Cloud Strategy

 

image

In the green we have a stack of cloud attributes a simplified one from NIST. At the end is link to the NIST guidelines. In the current scenario as it exists today the virtualized instance is provided by hypervisor however the entities that are provide self service portal, service mapping,automatic provisioning, automation resiliency  kind of services are a collection of the application stack and the management stack, This more importantly is a total mess.  They are not segmented properly as one  might expect, In practice at some levels there is no concurrence example the application stack cannot provide for automated provisioning as the components in the underlying architecture are not quite there. And some cases there may  have service mapping but it can be too complicated. The utopian ask will be that we hope to application unit of deployment that could be deployed as is and get to use all the entities as is this is what we call a mature private cloud.  We hope that since we would be at mature private cloud state we would be in a position to move to public cloud more easily.

So what is really the strategy today it’s a purchasing strategy where I buy the technologies with probable entities support and in the near future it will be deployment strategy assuming we have figured out which type unit is deployed on which kind of stack. Azure should eventually be an application strategy.

Purely talking from entities stand point it may not be correct to tell the IT staff to go ahead buy the stack need to go through some discovery process as in some case I will have to rewrite the application stack in some cases the entities fit the bill from feature supportability stand point of view.

Steps to Build a Private Cloud

image

The 3 key benefits of a private cloud are Automation, Virtualization & Integration.

First Step – Standardization

It’s a requirement to standardize the unit of deployment at a component level. Components essentially become the configuration unit a collection of configuration unit become a service unit.  The service unit is defined by the end user example for IT staff a service unit could be bare metal services on the contrary if the end user is a business user it may mean a full blown user with applications or a single application. The service unit is what we finally offer , which gets metered and has a SLA. Example in the below figure.

image

Define clear configuration units that can aggregate and create service unit

image

Second Step – Baseline it.

Baseline essentially means understanding the health of each individual service unit this essentially means do statistical analysis on why did the individual service unit break and number of times too.  Therefore we understand what are the methods where the failure occurred inclusive monitoring and health management. This is adding a procedure of Statistical Analysis to the datacenter monitoring.  The Benefits of Deep application monitoring and end to end heterogeneous application management,

image

How does one achieve Deep Application Monitoring?  Firstly there is a requirement of tool which deeply understand the architecture & dependency of the different layers of the application this would discover the application dependencies which in turn would enable monitoring end user and application components. In case of an alert the information produced at a micro component level will help in isolating the root cause which will help in remediation.

image

Third Step – Service Management

This step is drafting SLA for the services based on step 1 what services are required , step 2 defines how the services are going to remain healthy

image

SLA Management and processes are very similar. But it is all about the service templates that you apply this is where your grab the configuration units and put them together in service units.image

Fourth Step – Process Engineering & Pre-Production

Quality Assurance for Pre-production. Every single process in the environment has to understood unto the last level of detail & documented. Themes for this steps are necessarily are quality assurance & pre-production practices. Pre-production practices make sure everything that gets into production goes through an exhaustive pre-production.

image

Fifth Step – Automation & Orchestration

This steps what service units are to be automated and orchestrated. The Benefits of process automation and orchestration

image

The first question that comes up who orchestrates should be the developers or datacenter  system administrators. In other words the central console of monitoring will need developers to script as well as will be required to the statistical analysis as well do the automation. In the process we move refining the automation process to finally writing the playbook.

 Sixth Step  – Service Lifecycle

ISO 9000, MOF ITIL pretty much comes in here.

image

Seventh Step Self Service

Self Service entity to be enabled and access given over to the end user. Self service should also be in a position to manage capacity.

 

Services Layer in Standard IT Organization – Putting Principles to Practice……

The Services Layer is important wanted to take an example of standard IT organization and see how it maps into the services layer.

Starting with doing on layers of a Private Cloud the figure indicates what it looks like , this may not be 100% complete but its good for a starters conversation. If I grab the layers from a NIST model we start pretty much at physical/ hardware resources which include Real Estate, Power, Cooling , Bandwidth, Server, Storage, Network & Fabric.

The next layer is the Virtualization Extraction which is virtualization layer which virtualization and networking. The next one is Management which goes from Monitoring all the way to security.

Infrastructure as a Service / Service Delivery which is self explanatory. The last is the access layer.

image

Sample of an IT organizational chart

Referring to the org chart below the extreme left “Distributed Systems Management” is the area which takes care the Desktop and other devices in terms tablets, phone etc.. and in addition to it the call center & desktop support. The next vertical is the Application Management (Development & Support) for the business applications which could developers as well. The next is the Data Center Management which include a whole lot of things, the interesting aspects to be noted are business support, financials & chargebacks, Portfolio Management, Process & Compliance, SLA Mgmt & Business Continuity and Disaster Management.

The next vertical is Security which consists the identity management, security & access management & process and compliance. The next is Architecture/ Engineering which includes standards, research & configuration management.

The last but not least is the Business Relationship Management which includes business architect, portfolio management & business architecture. Below is a depiction of Standard IT Organization.

image

What can really be outsourced in above diagram.

  • Distributed System – Outsourced
  • Application Development & Support – Generally Kept in House
  • Data Centre- pretty much everything Outsourced except Business Support in kept in House.
  • Security- Outsourced
  • Architecture/Engineering – Kept in House
  • Business Relationship Management – Kept in House

So basic question which comes up “How does private cloud fit here? Which process/roles are added which change” or “How is going to effect my operation”?

So going back the Cloud attributes the cross referencing of attributes vs. Service Layers.

Access Anywhere impacts the top 2 layers Access & Infrastructure Service / Service Delivery. Scalable, Control, Elastic it impacts the bottom layers.

image

Self Services touches upon Management layer all the way to access. Multi tenancy & customizable is affecting all the layers that’s the basic simple concept of outsourcing.

Failure Resistant can mean many thing it can mean at the application level, it can mean at the data center level or it can be a cloud strategy, by the way it touches upon all the layers. At the end of the day this impacts the complete stack and by and the large the most expensive attribute of the over all cloud strategy. Most of the time this doesn’t really work. This is one which is key decider factor for the cloud strategy.

Metered by usage – If you architecture is not built along lines componentization & service oriented then metering is an impossible attribute to meet. This impacts Access, Infrastructure as a Service & Management & Security.

Highly Automated & On Demand impact all.

So what happens when we apply the cloud attributes to a sample IT organizational chart

Access Management – the one’s green are directly impacted. This one impacts the edges of the service layer.

image

 

Scalable is highly thought about inside of the core architecture of the services, this more of the design of service.

image

Control

Control has to be ingrained in every single service of the architecture.

image

Elastic is purely a data center play. It depends on how does central IT architect the services.

Self Service – it is combination which spans across the whole organization where the control is given to the application. The delegation is something which needs to given a thought.

 

image

Multi tenancy & Customization: are pure outsourcing thoughts.

Failure Resistant this one should be thought from application recovery point pretty much decided at an architectural level.

image

Metered by use is again at a component level.

Highly Automation is at every level. 

Coming Next Post…Architecting The Hybrid  Cloud ……

2 comments:

Aloha!! said...

Enjoyed your article. If the pictures were clear the read would have been more interesting. But I like the style. Wish you all the best

Ajay Solanki said...

Thanks for the comment. I would be more than happy to share the slide deck, Do send an email to me at asolanki77@gmail.com