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
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
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.
Define clear configuration units that can aggregate and create service unit
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,
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.
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
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.
Fifth Step – Automation & Orchestration
This steps what service units are to be automated and orchestrated. The Benefits of process automation and orchestration
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.
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.
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.
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.
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.
Scalable is highly thought about inside of the core architecture of the services, this more of the design of service.
Control has to be ingrained in every single service of the architecture.
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.
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.
Metered by use is again at a component level.
Highly Automation is at every level.
Coming Next Post…Architecting The Hybrid Cloud ……